I am a relative Newbie on this subject. I admit to having a healthy respect
for the Asprotect protection software. So much so, that I have chosen
memory patching to get around the problem. Seems the proliferation of
loaders and in-mem patchers support my position. Without incurring
the dreaded BIG RED LETTERS nor divulging too much information
(not sure how much is too much, would appreciate some enlightenment),
I thought I would share (in a general sense) how I was able to get these two (Evaluation versions both protected by the latest and greatest version of Asprotect) to run with my patches without using a loader or helper app on winxp pro.

The memory patch approach methodology was the same in both cases, however, the means in doing so, differed slightly. I'm probably not breaking
any new ground here, but fostering an exchange of ideas on this subject seems to be a good idea. If interested, contact me and I will provide you the details. Perhaps, then, someone, more technical than myself, can provide further details and clarification to the general audience on a more generic way to accommodate win9X/NT, etc. IMHO, this approach lends itself
to patching directly without any modifications.

You are very welcome to describe the methods you used, right here in the forum, just as long as you don't use any specific targets as examples, so please go right ahead!

(I removed the target names from your thread title, so that you can more freely demonstrate your techniques without getting into trouble with the forum rules)

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.

As a final note, not attributable to asprotect, but I bring this up. I noticed a
rather strange looking *.dll file being loaded that resided in my:
C:\documents and settings\user\local settings\temp folder.
The file was: _update.dat which is a dll file masquerading in sheep's clothing.
Upon further inspection, this file was not part of the original app. Apparently,
I had a spyware dll file and exe file on my computer that attached itself
to this application. So if you have a process running on your machine
called sysupd.exe, get rid of it. Also get rid of the _update.dat file. Also good
idea to get rid of any temp files in the folder I describe above.

Hi!

Great work, condzero!

/Manko

Thanks for sharing your ideas condzero. One thing to note about this kind of "dll injection" where you put a copy of the dll in the program's own folder, is that Microsoft changed this behavior in Windows Server 2003 (and also in Windows XP SP1 I think), so that dll's from the system32 dir are still loaded first, even if there is a dll with the same name in the program's own folder (yes, it was for the exact purpose of circumventing such dll injection attacks actually ).