3

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.

phwd
  • 19,975
  • 5
  • 50
  • 78
CnativeFreak
  • 712
  • 12
  • 27

2 Answers2

8

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.

hmjd
  • 120,187
  • 20
  • 207
  • 252
  • so this mean that modules such kernel32.dll are loaded only once ? and when an executable is loaded and it has it in import table it just get a pointer to the already loaded dll ? then can you please explain the section "ASLR and LoadLibrary" in this link http://www.insecure.in/papers/vista_dll_injection.pdf why GetModuleHandle is at the same address and LoadLibraryA is not ?? – CnativeFreak Dec 19 '11 at 23:38
  • @CnativeFreak, it says this "Since at each reboot (or two) the address of kernel32.dll (which contains the LoadLibrary procedure) might change we use GetModuleHandle to retrieve the address of LoadLibraryA which will be the same in the remote thread address space." in that document. It does not say that `GetModuleHandle()` is at the same address. – hmjd Dec 19 '11 at 23:41
  • "we use GetModuleHandle to retrieve the address of LoadLibraryA which will be the same in the remote thread address space" why would GetModuleHandle be the same in the remote thread address space while LoadLibraryA is not ? – CnativeFreak Dec 19 '11 at 23:45
  • @CnativeFreak, they are both the same. It is just stating that is how it is done and that the address of any function exported by kernel32.dll cannot be hard-coded. – hmjd Dec 19 '11 at 23:47
  • GetModuleHandle aslo exported from kernel32 why it can be hardcoded and LoadLibraryA cant be ?? what i cant understand why can he use GetModuleHandle directly and cant use LoadLibraryA directly – CnativeFreak Dec 20 '11 at 00:09
  • Oh .. now I get it ..I am very sorry for the inconvenience question .thanks alot @hmjd – CnativeFreak Dec 20 '11 at 00:35
  • 1
    The address of the module may not change but that does not make what the OP is doing safe! Consider the case where your app is running with shims enabled (something which you do not control!) or even the case where some other pieces of software which also performs EAT hooks is running in your process (again, not something you control). In that case, GetProcAddress could return a pointer to a function in another module to what you're expecting/asking, including one which is not loaded in the process which you're going to call CreateRemoteThread on, in that case the target will crash. – RaptorFactor Dec 17 '13 at 07:21
-3

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)

Tulio150
  • 1