I did it simpler. I coded a stub for the real dll: a new dll exposing the same methods of the original dll, eventually through export forwarding if you don't know the original DLL prototypes.
from matt Pietrek..
Quote:
Export Forwarding
A particularly slick feature of exports is the ability to "forward" an export to another DLL. For example, in Windows NT®, Windows® 2000, and Windows XP, the KERNEL32 HeapAlloc function is forwarded to the RtlAllocHeap function exported by NTDLL. Forwarding is performed at link time by a special syntax in the EXPORTS section of the .DEF file. Using HeapAlloc as an example, KERNEL32's DEF file would contain:
EXPORTS
•••
HeapAlloc = NTDLL.RtlAllocHeap
How can you tell if a function is forwarded rather than exported normally? It's somewhat tricky. Normally, the EAT contains the RVA of the exported symbol. However, if the function's RVA is inside the exports section (as given by the VirtualAddress and Size fields in the DataDirectory), the symbol is forwarded.
When a symbol is forwarded, its RVA obviously can't be a code or data address in the current module. Instead, the RVA points to an ASCII string of the DLL and symbol name to which it is forwarded. In the prior example, it would be NTDLL.RtlAllocHeap.
|
The what I did is to code my DllMain and insert the patching code into the DLL_PROCESS_ATTACH case.
The patched code does these things:
-load the original renamed library (with a leading _ )
-initialize the exports I would to overwrite (if any) through GetProcAddress.
-patch the memory of the DLL (through the handle returned by loadLibrary).
-exit from Dllmain
in the case I wanted to change some of the original Dll's export behaviour I also coded a function with the same prototype of the original one, which do required tricks and after call the original export.
Doing this way I was able to easily code a loader for a asprotected dll which pathces in memory all the nags and insert some missing code, stolen by asprotect.