Hooking IAT address is incorrect - c

I'm trying to locate the entry for wglGetProcAddress (OpenGl32.dll) imported in a test application. For some reason, the import whose name is "wglGetProcAddress" does point to the same function returned by calling GetModuleHandle and GetProcAddress on Opengl32.dll.
The executable file has been loaded into memory and is a process with its thread currently suspended. The following code correctly reads the names modules and their functions imported by that executable. Hence, the IAT should not contain RVAs since it has been loaded.
HMODULE h = GetModuleHandle("OPENGL32.dll");
DWORD expect_addr = (DWORD)GetProcAddress(h, "wglGetProcAddress");
PIMAGE_IMPORT_DESCRIPTOR import_desc = (PIMAGE_IMPORT_DESCRIPTOR)(pmem + import_dir);
while (import_desc->Name)
{
PIMAGE_THUNK_DATA thunk = (PIMAGE_THUNK_DATA)(pmem + import_desc->OriginalFirstThunk);
while (thunk->u1.Function)
{
PIMAGE_IMPORT_BY_NAME import = (PIMAGE_IMPORT_BY_NAME)(pmem + thunk->u1.AddressOfData);
printf("%s 0x%X\n", import->Name, thunk->u1.Function);
if ((DWORD)expect_addr == (DWORD)thunk->u1.Function)
{
printf("Found wglGetProcAddress\n");
}
else if (!strcmp((const char*)import->Name, "wglGetProcAddress"))
{
printf("Found wglGetProcAddress's import, but the function has a different value.\n");
}
++thunk;
}
++import_desc;
}
GetProcAddress from that original value returns the address 60XXC245 where XX varies, but thunk->u1.Function always returns 0xA46D8. Everything in thunk->u1 (Function, AddressOfData, Ordinal and ForwarderString) has
the same value. The names of the import descriptors and imports correct. Does anyone see what I'm missing?
Edit:
I'm trying something else: I'm scanning pmem (image of the executable in memory) for what I expect is the IAT entry, but it doesn't locate that either:
HMODULE h = GetModuleHandle("OPENGL32.dll");
DWORD expect_addr = (DWORD)GetProcAddress(h, "wglGetProcAddress");
printf("Looking for 0x%X\n", expect_addr);
for (int i = 0; i < pmem_size - sizeof(DWORD); i++)
{
if (*(DWORD*)(pmem + i) == expect_addr)
{
printf("0x%X at 0x%X\n", *(DWORD*)(pmem + i), i);
}
}
SOLVED: I didn't realize it, but calling CreateProcess with CREATE_SUSPENDED prevents the windows loader from populating FirstThunk with the actual addresses. If I let the process run for a second and then suspend the thread, it hooks the IAT address perfectly fine. Now I have to go look for a way to fix that.

u1.Function represents the relative offset to the IMAGE_IMPORT_BY_NAME entry (or the ordinal entry if the IMAGE_ORDINAL_FLAG bit is set). this is why it doesn't match the value from GetProcAddress, because it isn't the address of the function, its the address of the function import entry.
When you have found the thunk matching your function, you need to use this too lookup the virtualized address altered by the linker, form the other thunk list. altering your code so it does this yeilds:
while (import_desc->Name)
{
PIMAGE_THUNK_DATA thunk = (PIMAGE_THUNK_DATA)((DWORD)GetModuleHandle(NULL) + import_desc->OriginalFirstThunk);
int i = 0;
while (thunk->u1.Function)
{
PIMAGE_IMPORT_BY_NAME import = (PIMAGE_IMPORT_BY_NAME)((DWORD)GetModuleHandle(NULL) + thunk->u1.AddressOfData);
void** p = (void**)((DWORD)GetModuleHandle(NULL) + import_desc->FirstThunk);
printf("%s 0x%X\n", import->Name, p[i]);//thunk->u1.Function);
if ((DWORD)expect_addr == (DWORD)p[i])
{
printf("Found wglGetProcAddress\n");
}
else if (!strcmp((const char*)import->Name, "wglGetProcAddress"))
{
printf("Found wglGetProcAddress's import, but the function has a different value.\n");
}
++thunk;
}
++import_desc;
}
To get the IAT entries, I do things a little differently:
inline const void** GetImportAddress(HMODULE hModule, IMAGE_IMPORT_DESCRIPTOR* pTable, size_t nThunk)
{
const void** pAddressBlock = (const void**)((DWORD)hModule + pTable->FirstThunk);
return &pAddressBlock[nThunk];
}
const void** GetImport(HMODULE hModule, const char* szDll, const char* szFunction)
{
const char* szDllName = NULL;
IMAGE_IMPORT_DESCRIPTOR* pTable = GetImportDescriptor(hModule);
while(pTable->Characteristics != 0 && (szDllName = GetImportTableName(hModule,pTable)) != NULL)
{
if(!lstrcmpiA(szDll,szDllName))
{
IMAGE_THUNK_DATA* pThunkData = GetThunk(hModule,pTable);
if(pThunkData != NULL)
{
size_t nThunk = 0;
while(pThunkData->u1.AddressOfData != 0)
{
if(pThunkData->u1.Ordinal & IMAGE_ORDINAL_FLAG)
{
if(IMAGE_ORDINAL32(pThunkData->u1.Ordinal) == (DWORD)szFunction)
return GetImportAddress(hModule,pTable,nThunk);
}
else
{
IMAGE_IMPORT_BY_NAME* pImport = GetImport(hModule,pThunkData);
if(!lstrcmpA(szFunction,(const char*)pImport->Name))
return GetImportAddress(hModule,pTable,nThunk);
}
nThunk++;
pThunkData++;
}
}
}
pTable++;
}
return NULL;
}

Related

How to get module image name from an arbitrary address in Windows kernel space?

I'm trying to see how I can get a loaded module image name from an arbitrary address from the kernel code.
In user mode I would do this:
void* pAddr;
VOID* pBase;
WCHAR buff[MAX_PATH] = {0};
//Get address of some function in some module (just to test it)
pAddr = GetProcAddress(GetModuleHandle(L"kernel32.dll"), "GetCurrentProcess");
//Get module base address
RtlPcToFileHeader(pAddr, &pBase);
//Get module image file name
GetModuleFileNameEx(GetCurrentProcess(), (HMODULE)pBase, buff, SIZEOF(buff));
Is there a way to do the same in kernel mode if I have pAddr that can point to some address in kernel or user space?
EDIT: While waiting for the answer I came up with my own code (using undocumented way of traversing PEB):
#ifdef CALLING_FROM_KERNEL_MODE
//Kernel mode
TEB* pTEB = (TEB*)PsGetCurrentThreadTeb();
#else
//User mode
#if defined(_M_X64)
//64-bit
TEB* pTEB = reinterpret_cast<TEB*>(__readgsqword(reinterpret_cast<DWORD_PTR>(&static_cast<NT_TIB*>(nullptr)->Self)));
#else
//32-bit
TEB* pTEB = reinterpret_cast<TEB*>(__readfsdword(reinterpret_cast<DWORD_PTR>(&static_cast<NT_TIB*>(nullptr)->Self)));
#endif
#endif
PEB* p_PEB = pTEB->ProcessEnvironmentBlock;
PEB_LDR_DATA* pPLD = p_PEB->Ldr;
const WCHAR* pModName = NULL;
LIST_ENTRY* pLE = &pPLD->InMemoryOrderModuleList;
LIST_ENTRY* pLE_Head = pLE;
while(pLE_Head != pLE->Flink)
{
PLDR_DATA_TABLE_ENTRY pLDTE = CONTAINING_RECORD(pLE, LDR_DATA_TABLE_ENTRY, InMemoryOrderLinks);
size_t szcbSizeOfImg = (size_t)pLDTE->Reserved3[1];
if((size_t)pAddr - (size_t)pLDTE->DllBase < szcbSizeOfImg)
{
pModName = pLDTE->FullDllName.Buffer;
break;
}
pLE = pLE->Flink;
}
The problem is that although it works from a user-mode, from a kernel mode PsGetCurrentThreadTeb() seems to return NULL. Does this mean kernel threads do not have a TEB?
this can be done by creating list of all loaded modules via ZwQuerySystemInformation with SystemModuleInformation
void fgt(PVOID *Callers, ULONG Count)
{
NTSTATUS status;
ULONG cb = 0x10000;
do
{
status = STATUS_INSUFFICIENT_RESOURCES;
if (PRTL_PROCESS_MODULES prpm = (PRTL_PROCESS_MODULES)ExAllocatePool(PagedPool, cb))
{
if (0 <= (status = NtQuerySystemInformation(SystemModuleInformation, prpm, cb, &cb)))
{
do
{
PVOID Caller = *Callers++;
if (ULONG NumberOfModules = prpm->NumberOfModules)
{
PRTL_PROCESS_MODULE_INFORMATION Modules = prpm->Modules;
do
{
if ((SIZE_T)Caller - (SIZE_T)Modules->ImageBase < Modules->ImageSize)
{
DbgPrint("%p> %s\n", Caller, Modules->FullPathName);
break;
}
} while (Modules++, --NumberOfModules);
}
} while (--Count);
}
ExFreePool(prpm);
}
} while (status == STATUS_INFO_LENGTH_MISMATCH);
}

memory leak in hiredis using valgrind

I ran valgrind on my code which uses hiredis, it points out the following individual lines in my code :
redisAsyncConnect()
redisAsyncConnectUnix()
redisLibuvAttach()
uv_loop_new()
I have used 'redisAsyncDisconnect' to free up the memory for the first two cases, couldn't find the right method for third one. For the fourth one i used uv_stop(). But still valgrind says there is definitely a loss in memory in all the four, what is the right way to release the memory ?
Just doing a simple google search shows the method redisLibuvAttach() just does a simple malloc
static int redisLibuvAttach(redisAsyncContext* ac, uv_loop_t* loop) {
redisContext *c = &(ac->c);
if (ac->ev.data != NULL) {
return REDIS_ERR;
}
ac->ev.addRead = redisLibuvAddRead;
ac->ev.delRead = redisLibuvDelRead;
ac->ev.addWrite = redisLibuvAddWrite;
ac->ev.delWrite = redisLibuvDelWrite;
ac->ev.cleanup = redisLibuvCleanup;
redisLibuvEvents* p = (redisLibuvEvents*)malloc(sizeof(*p));
if (!p) {
return REDIS_ERR;
}
m emset(p, 0, sizeof(*p));
if (uv_poll_init(loop, &p->handle, c->fd) != 0) {
return REDIS_ERR;
}
ac->ev.data = p;
p->handle.data = p;
p->context = ac;
return REDIS_OK;
}
The method on_close in that file shows you can simply free(handle->data) :
static void on_close(uv_handle_t* handle) {
redisLibuvEvents* p = (redisLibuvEvents*)handle->data;
free(p);
}
Or just make sure that method is called.

Replacement for NSAddImage (in GLLoadGen)

The GL loader generated with GLLoadGen contains the following code:
static void* AppleGLGetProcAddress (const GLubyte *name)
{
static const struct mach_header* image = NULL;
NSSymbol symbol;
char* symbolName;
if (NULL == image)
{
image = NSAddImage("/System/Library/Frameworks/OpenGL.framework/Versions/Current/OpenGL", NSADDIMAGE_OPTION_RETURN_ON_ERROR);
}
/* prepend a '_' for the Unix C symbol mangling convention */
symbolName = (char*)malloc(strlen((const char*)name) + 2);
strcpy(symbolName+1, (const char*)name);
symbolName[0] = '_';
symbol = NULL;
/* if (NSIsSymbolNameDefined(symbolName))
symbol = NSLookupAndBindSymbol(symbolName); */
symbol = image ? NSLookupSymbolInImage(image, symbolName, NSLOOKUPSYMBOLINIMAGE_OPTION_BIND | NSLOOKUPSYMBOLINIMAGE_OPTION_RETURN_ON_ERROR) : NULL;
free(symbolName);
return symbol ? NSAddressOfSymbol(symbol) : NULL;
}
This function apparently loads the address of the OpenGL function name. However the calls to NSAddImage and related are deprecated since OSX 10.5. What is the current (non-deprecated) approach to load the function addresses?
dlopen(), dlsym() and friends are probably the best option. This will also make your code more portable, since they are available on most Unix systems as well.
Following is some code I've used in the past to load GL functions on Mac OSX (tested on version 10.8, should still work OK for Mavericks):
// Handle to the OpenGL dynlib:
static void * glLibrary;
// Path to GL on OSX. True for version 10.8.
static const char * glLibPath = "/System/Library/Frameworks/OpenGL.framework/Versions/Current/OpenGL";
// Loads the OpenGL library:
void LoadGL()
{
// Load GL dynlib:
glLibrary = dlopen(glLibPath, RTLD_LAZY);
if (!glLibrary)
{
const char * error = dlerror();
// handle error
}
}
// Unloads the GL library:
void UnloadGL()
{
if (glLibrary)
{
if (dlclose(glLibrary) != 0)
{
// problem...
}
glLibrary = NULL;
}
}
// Grab a function pointer form the previously loaded GL library:
void * GetGLFunctionPointer(const char * funcName)
{
assert(funcName != NULL);
assert(glLibrary != NULL && "OpenGL dynlib not yet loaded!");
return dlsym(glLibrary, funcName);
}
// Usage example:
int main()
{
LoadGL();
void * fn = GetGLFunctionPointer("glEnable");
assert(fn != NULL);
UnloadGL();
return 0;
}

Execv failing even when command is available

I'm trying to call execv after manually saerching for the program to execute.
In my case,
c is a struct which has args as an array of strings having the arguments passed while receiving input. nargs is the number of arguments.
c->args[0] would contain "ls","cat" etc.
I tried printing the value of the args[0], fullPath etc. in my child process. They all show values like "/bin/ls","/bin/cat" etc. But when I call execv, it returns -1 with an errno of 2, which I understand is the error for "No such file or directory". But I'm sure the file is there because thats what my PathResolver is returning after checking all permissions.
Can anyone point where I might have made a mistake.
//The part happening inside child
char *fullPath = PathResolver(c->args[0],1,&permission);
printf("FullPath: %s -- Permission: %d\n",fullPath,permission);
if(permission==0)
{
fprintf(stderr, "%s: Command not found\n",c->args[0]);
}
else if(permission==-1)
{
fprintf(stderr, "%s: Permission denied\n",c->args[0]);
}
else
{
char* args[c->nargs+1];
int m=0;
for(m=0;m<c->nargs;m++)
{
strcpy(args[m],c->args[m]);
}
args[c->nargs] = NULL;
printf("%d\n",execv(args[0], args));
printf("errno: %d\n",errno);
}
PathResolver function
char* PathResolver(char *command, int ResolverMode, int *Permission)
{
*Permission = 0;
char *returnString;
returnString = malloc((sizeof(char)));
char *strPath = getenv("PATH");
char *del = ":";
char *strToken = strtok(strPath,del);
FILE *f;
while(strToken)
{
char filePath[100];
sprintf(filePath,"%s/%s",strToken,command);
if(access(filePath,F_OK)>=0)
{
if(access(filePath,X_OK)>=0)
{
*Permission = 1;
sprintf(returnString,"%s%s ",returnString,filePath);
if(ResolverMode == 1)
break;
}
else
{
*Permission = -1;
}
}
strToken = strtok(NULL,del);
}
sprintf(returnString,"%s\b",returnString);
return returnString;
}
strcpy(args[m],c->args[m]); is undefined behaviour, because args[m] is not a pointer to valid memory.
The following might be simpler:
char * args[c->nargs + 1];
for (size_t m = 0; m != c->nargs; ++m)
{
args[m] = c->args[m];
}
args[c->nargs] = NULL;
There's no need to copy the strings.
(This may not be your actual problem, but it certainly prevents your program from being correct.)
execv() expects the program name to be prefixed by a full path as 1st parameter.
To have PATH searched instead of providing a path use execvp().
Update:
Also this line
returnString = malloc((sizeof(char)));
does only allocate 1 byte to returnString, which is way to few for how you use returnString.

Should I IUnknown::Release interfaces created with DllGetClassObject

I'm trying to debug some code that uses COM, which I am a beginner at.
The two calls to IUnknown::Release at the end have got me worried.
The interfaces were created with DllGetClassObject and IClassFactory::CreateInstance.
I have seen other similar code that does not call IUnknown::Release on these - which is correct?
int OpenMixer_Win_DirectSound(px_mixer *Px, int index)
{
DSPROPERTY_DIRECTSOUNDDEVICE_DESCRIPTION_DATA desc;
HMODULE hDsound = INVALID_HANDLE_VALUE;
GCO DllGetClassObject;
IClassFactory *pcf = NULL;
IKsPropertySet *pps = NULL;
HRESULT hr;
ULONG bytes;
LPGUID guidIn;
LPGUID guidOut;
UINT deviceIn = -1;
UINT deviceOut = -1;
int ret = FALSE;
guidIn = PaWinDS_GetStreamInputGUID(Px->pa_stream);
guidOut = PaWinDS_GetStreamOutputGUID(Px->pa_stream);
do {
hDsound = LoadLibraryA("dsound.dll");
if (hDsound == NULL) {
break;
}
DllGetClassObject = (GCO) GetProcAddress(hDsound, "DllGetClassObject");
if (DllGetClassObject == NULL) {
break;
}
hr = DllGetClassObject(&CLSID_DirectSoundPrivate,
&IID_IClassFactory,
(void **)(&pcf));
if (hr || pcf == NULL) {
break;
}
hr = IClassFactory_CreateInstance(pcf,
NULL,
&IID_IKsPropertySet,
(void **)(&pps));
if (hr || pps == NULL) {
break;
}
/* Do stuff with the interfaces */
} while( FALSE );
if (pps) {
IUnknown_Release(pps);
}
if (pcf) {
IUnknown_Release(pcf);
}
// Free the library. Note that portaudio also opens dsound.dll
// so this probably doesn't do anything until Pa_Terminate is called.
if (hDsound != INVALID_HANDLE_VALUE) {
FreeLibrary(hDsound);
}
}
Absolutely. Both functions create a new interface pointer, they will have a reference count of 1, the AddRef() function was already called. When you're done with it then you have to call Release(). You'll leak memory if you don't. Every interface in COM works this way.
Yes. As seen in DllGetClassObject sample, the return ppvObj will have a refcount.
Yes, DllGetClassObject() will create an object and pass ownership of that object to your code. Your code will now own the object and be responsible for releasing it by calling IUnknown::Release().

Resources