Exetools - RE:loaders

from _www.woodmann.net/forum/ ... "Asprotect patching exposed"

"Case 1. utilized one of the application's dll files to do my memory patching. Yes, the dll file was also protected with Asprotect, but it seems that the level of protection for dll's is not the same as for the module.exe file.

Case 2. utilized a system dll (msimg32.dll) called by the application to apply the memory patch.

In both cases, the methodology of applying the patch was the same. The timing is one key issue. Having an application that supplies it's own means to patch it (dll) is a good thing. When this option is not available, as in the second case, you can still find a way. Seems, in case 2, the application looks for a couple of system dll's in it's own program folder first, before looking in the usual system32 folder. I found this out by using NTFILMON (a wonderful utility supplied by the folks at www.sysinternals.com). So I used this to my advantage, and copied the rather small 5k system dll (msimg32.dll) into the program folder and applied the patch to it.

As I said before, the timing is the key. Both dll's don't come into play (load), until after both apps have gone through the unpacking/protection schemes of
Asprotect. This allows for more liberal usage of the registers and call stack
without worry of Asprotect, if you need to do so.

Case 1.
Overlay the beginning of the *.dll asprotect code (.aspr section) with:

JMP (*.DLL ADDRESS / bottom of the .aspr code section) to our patches:
NOP
NOP
...
our patches: (in most cases replacing a JNZ instruction with a JMP)
located near the bottom of the *.dll code, but first,
PUSH EDI; save the register
followed by a series of:
LEA EDI,DWORD PTR SS:[MODULE.EXE ADDRESS]
MOV BYTE PTR SS:[EDI],0EB
where module.exe address is the address(es) of the module we are
memory patching too. Note: we are also doing the same here with the
effected *.dll.
...
then,
replace the overlayed bytes at the top of our *.dll
MOV BYTE PTR DS:[<ModuleEntryPoint>],???
MOV BYTE PTR DS:[*.DLL ADDRESS],???
MOV DWORD PTR DS:[*.DLL ADDRESS],???
where ??? is whatever instructions were originally overlayed
then,
POP EDI; restore the register
then,
JMP Copy_of_.<ModuleEntryPoint>
we jump back to the top of the *.dll file and execute the original
code.
This is a one-time patch, where once the *.dll is called and our
memory patching has been executed, the *.dll's original code
that has been restored will execute. Our memory patched code
will execute only once.

Case 2. Samething, however your patches can be applied to the more
normal text/code section (i.e. there is no .aspr section).

There is no need to use procdump or any utility to expand
the code. The changes I describe (using any hex editor) can be made
directly. I have one caveat. In case 1, I hard coded a base address on the *.dll file using a pe editor. In the second case, the system *.dll file had a hard coded base address. So I admit, I used direct addressing in my lea instructions.
So the issue of relocatability still needs to be addressed, also, the memory
addresses of *.dll files on different operating systems. I am using winxp
pro. That's where you folks come in. The point being, that sometimes we
can make use of already linked *.dll files and not have to use an external
program (loader?) to memory patch the code...."