Vinay A. Mahadik (vamahadik fastmail fm), Feb 2006
http://www.vinay-mahadik.info/


Purpose:
--------

This utility is essentially a combination of the "AppInit_DLLs" and "Hot Code Patching" tricks applied to reverse engineering. Very briefly, this is how it works:

- The utility is compiled as a DLL
- The AppInit_DLLs value in the registry (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs) is modified to point to this DLL. 
- This way each Win32 exe that uses user32.dll loads this DLL (and its dependencies) at load time. (No reboot is necessary contrary to what the Richter book says).
- Inside the DLL, you check whether the exe name is the one you want to monitor, else you just return.
- For the target exe, the DLL is loaded very early on by the loader (when user32.dll is loaded).
- It first creates a thread that initially checks if the exe is unpacked in memory. The threading is required for polling the exe for its unpacked status (for exes that are indeed packed).
- Once it finds that the exe is unpacked in memory, it patches the exe's memory image so that the debugging info target subroutine has a jump to a "shellcode" in the DLL.
- The shellcode is relocatable so the DLL can be loaded at a non standard imagebase, and things should still work. (I rebased the DLL to test this).
- The shellcode first saves the state of the process to memory so it is free to process and do almost anything it wants.
- There I dump all the debug info into a log file on disk. This is just an illustration, you could do pretty much anything you want in the shellcode such as gathering/logging (or even altering) the state of the process.
- Then the state is restored, and the instructions that were patched are executed as part of the shellcode's trailer itself.
- Then we jump back to the start of the original unpatched code as if nothing happened.
- This repeats each time that subroutine/base address is executed.


Build:
------

On MS VC++ (tested on .NET 2003):
	cl /c RE_DLLCodeInj.cpp
	link /DLL RE_DLLCodeInj.obj


Pros:
-----

- Relocatable shellcode/dll, image base collisions will not affect the shellcode functionality.
- Ideal for cases where a GUI based Win32 app first unpacks in memory.
- A scritable debugger can be used to jump to the shellcode inside the DLL when the "execute" breakpoint is hit. Typically, this can't be used because the scripting is usually too slow, and/or the debugger might get detected when it attachs or starts the process under it.
- CreateRemoteThread method loses out on the activity that occurs before it attaches to the process. The AppInit_DLLs trick starts from the time the exe is loaded.
- Can be used along with Microsoft's detours library. This latter is more suited for *function* hooking/instrumentation. Try using it for patching the middle of a function inside an exe that unpacks after loading - not easy/suited.


Cons:
-----

- Will not work if code integrity checks are calculated over the patched ares of the process. A scritable debug execute breakpoint can be used in that case (slow/might be detected as well).

Example:
--------

See Skype_logs file for dumps from too debugging functions present inside the Skype 2.0 binary. These take in var args but based on certain global variables, never actually dump the logs to a file in the release version of Skype. RE_DLLCodeInj can be used to extract those logs out into a file.
