I was reading about the DLL injection technique, and I had this question in mind.
Let us assume we want to inject a DLL into a destination process in Windows 7 which has ASLR enabled for kernel32.dll
So any piece of the injected code can't use any winapi or any system call since the address of let's say loadLibrary function in the injector code will differ from the address loadLibrary in the destination process, Won't it ?
So such a call to CreateRemoteThread won't work:
CreateRemoteThread(hProcess,
NULL,
0,
(LPTHREAD_START_ROUTINE) ::GetProcAddress(hKernel32,
"LoadLibraryA" ),
pLibRemote,
0,
NULL );
::WaitForSingleObject( hThread, INFINITE );
Correct me if I am wrong in this reasoning.
No, I believe that is incorrect. The addresses of modules like kernel32.dll are randomized when the machine boots but are the same for all processes.
he can use GetModuleHandle (and GetProcAddress) directly, FROM THE INJECTOR'S IMPORT TABLE, which will redirect to a call to GetModuleHandle ON KERNEL32, to get the Address of LoadLibraryA ON KERNEL32, that can be used on any process
if he passed the hardcoded LoadLibraryA's address directly, he would be passind the address of LoadLibraryA ON THE INJECTOR'S IMPORT TABLE, which is not the same on the target process
one may ask: "why it doesn't translate the import table instead of calling GetModuleHandle and GetProcAddress?". The import table is just a table of pointers obtained by the executable loader using THE SAME GetModuleHandle and GetProcAddress (actually not the same, but similar)
Related
Consider an instruction like CALL DWORD PTR 44244100 that imports and uses a DLL function within an assembly program.We know the address used by the instruction is a Relative Virtual Address (RVA).
1.So why do I reach another VA value in the Thunk value field of the LordPE software when I trace that piece of code by it?
2.Whether DLL's such as User32 or Kernel32 always is loaded at a specific VA or not necessarily?
If not so how does Loader recognize which DLL the address mentioned above belongs to? by searching in Name Table?!
I mean this address is invariant,so if the loaded dll's location is fixed too,then another VA should be assigned to this address first.
Thanks all.
I don't understand the first question.. If you mean thunk as for function imports those aren't RVAs, those are flat addresses. Also address used by instruction in case of code addressing is always relative to current instruction pointer value. RVAs are only used by loader pretty much (and functions like LoadLibrary, GetProcAddr and these).. I think. x86 Processor does not know the concept of RVA that's for sure. Maybe you knew that, it wasn't very clear to me, if that's the case, sorry for lecturing.
Question two! No! It is not fixed! The loader actually goes through import table of your exe and fills in placeholders. Fixed load addresses are no more a thing since windows xp sp3. Hope this helps. If not, this helped me when I was little potato https://msdn.microsoft.com/en-us/library/ms809762.aspx
I was wondering if I had to close the handle if for example I were to call GetModuleHandle this way
GetProcAddress(GetModuleHandle("modulename"), "nameoftheexportedfunction")
what would be the proper way to close the handle? Do I need to do
HMODULE hModule = GetModuleHandle("modulename");
GetProcAddress(hModule, "nameoftheexportedfunction")
CloseHandle(hModule);
Or does it get deleted automatically if the value returned by GetModuleHandle isn't stored into a variable?
GetModuleHandle returns an HMODULE (aka HINSTANCE - see What is the difference between HINSTANCE and HMODULE?). This data type cannot be passed to CloseHandle.
The HMODULE could be passed to FreeLibrary but that is not required either, since GetModuleHandle doesn't increase the reference count on the module. In fact, calling FreeLibrary might cause the module to get unmapped prematurely, leading to a spectacular crash.
In short: GetModuleHandle returns a read-only value, that doesn't need to be disposed off in any way. The first line of code in your question is fine.
The Windows API can be very confusing in this respect, as there are multiple things called a handle, and they all have different rules.
In this case, CloseHandle closes kernel handles, which typically refer to files or other kernel resources such as synchronization objects that are created with a name—which all are identified by being returned as a HANDLE.
GetModuleHandle returns an HMODULE—actually the base address of a loaded EXE or DLL—and, as it is not a HANDLE, does not need to be, and must not be, released with CloseHandle.
As #David Heffernan points out, this does not mean other handle types never have their own destroy/release/un-acquire semantics, and it also does not mean that every HANDLE you get from an API must be passed to CloseHandle either. There is just no substitute for knowing the specific API you are dealing with and its particular handle management requirements.
One should not use functions other than those in kernel32.dll from DllMain:
From MS documentation:
Because Kernel32.dll is guaranteed to be loaded in the process address space when the entry-point function is called, calling functions in Kernel32.dll does not result in the DLL being used before its initialization code has been executed. Therefore, the entry-point function can call functions in Kernel32.dll that do not load other DLLs. For example, DllMain can create synchronization objects such as critical sections and mutexes, and use TLS. Unfortunately, there is not a comprehensive list of safe functions in Kernel32.dll.
...
Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions load other system components. Conversely, calling functions such as these during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized.
My question:
But the documentation does not mention ntdll.dll. - Can I call LoadLibrary for "ntdll" and use functions in ntdll from DllMain:
1) during DLL_PROCESS_ATTACH (load and use functions of ntdll)?
2) during DLL_PROCESS_DETACH (use functions of previously loaded ntdll)?
Also, please, would somebody with 1500+ reputation like to create a new tag titled "dllmain" ?
The answer to the question "is it safe in DllMain" always defaults to "no". In this case, calling LoadLibrary is never okay.
Generally speaking, calling anything in ntdll.dll is not recommended even places where it is safe to do so.
How can I increment refcount of the HMODULE returned by the GetModuleHandle? Can I DuplicateHandle, or I need to go through hops, retrieve module's path and then LoarLibrary on that path? In short, I want to emulate GetModuleHandleEx without using this function (which is XP+).
You cannot use DuplicateHandle() on a HMODULE. The MSDN Library article lists the kind of handles that DH will accept in the Remarks section, a module handle is not one of them.
One reason for this is that a HMODULE is not actually a handle at all, it is a pseudo handle. There's history behind this, back in the 16-bit versions of Windows they actually were handles. But that disappeared in the 32-bit version, they are now simply the address of the module where it is loaded in memory. One pretty standard trick to convert a code address to a module handle is to use VirtualQuery() and cast the returned MEMORY_BASIC_INFORMATION.BaseAddress to (HMODULE). Very handy sometimes.
Yes, the only other way to increment the reference count is to use LoadLibrary().
I'd like to build an application that invokes CancelIoEx on Windows Vista and newer (where it is supported) and does something else on Windows XP (where it is not).
What happens if I compile the application under Windows 7 but run it under Windows XP? What will happen at runtime? Will I get some sort of load error?
How do I get my application to pick one code path or another (avoiding load errors) depending on what operating system is being used at runtime? Please provide sample code.
UPDATE: Please note that the DLL exists on Windows XP but the function does not.
Yes, an application that references a non-existent DLL export will fail to load.
Adding code to take different paths based on the OS version won't help much, because you'll still have the reference to the non-existent function.
Instead, you need to resolve the reference at run-time.
One option is Delay Load Import (with the /DELAYLOAD linker flag), but I don't think this is supported for the core system DLLs (like kernel32).
The other is to use LoadLibrary and GetProcAddress. The code is something like this, though in reality you'd do the lookup once when your app starts, not each time you call the function.
// Declare type of pointer to CancelIoEx function
typedef BOOL (WINAPI *CancelIoExType)(HANDLE hFile, LPOVERLAPPED lpOverlapped);
// Load module; won't fail because it's already imported
HMODULE hKernel32 = LoadLibrary(L"kernel32.dll");
// Look up function address
CancelIoExType pCancelIoEx = (CancelIoExType)GetProcAddress(hKernel32, "CancelIoEx");
// Do something with it
if (pCancelIoEx)
{
// Function exists so call it
pCancelIoEx(hMyFile, pMyOverlapped);
}
else
{
// Function doesn't exist
}
In order to resolve a symbol at runtime, you need to use LoadLibrary and GetProcAddress:
HMODULE kernel32 = LoadLibrary("kernel32.dll");
BOOL (WINAPI *pCancelIoEx)(HANDLE, LPOVERLAPPED) = GetProcAddress(kernel32, "CancelIoEx");
In the case that CancelIoEx is not available, you will get NULL back from GetProcAddress. Once you have the pointer (you only need to do the above once), you can call it normally with:
pCancelIoEx(h, &lp);