Results 1 to 5 of 5

Thread: Asprotect patching exposed

  1. #1

    Exclamation Asprotect patching exposed

    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.

  2. #2
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    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)

  3. #3
    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.

  4. #4
    Hi!

    Great work, condzero!

    /Manko
    // Wish I had more time... But I guess I would still use it for other things than RCE... :)

  5. #5
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    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 ).

Similar Threads

  1. Asprotect..
    By Hopcode in forum Malware Analysis and Unpacking Forum
    Replies: 18
    Last Post: October 25th, 2002, 15:22
  2. Asprotect 1.4 !!!
    By +SplAj in forum Advanced Reversing and Programming
    Replies: 6
    Last Post: January 13th, 2002, 16:37
  3. Asprotect V1.3?
    By LunarC in forum Advanced Reversing and Programming
    Replies: 19
    Last Post: August 23rd, 2001, 00:00
  4. Inline memory patching Asprotect
    By Instructor in forum Advanced Reversing and Programming
    Replies: 1
    Last Post: July 15th, 2001, 08:28
  5. CommView 2.3 and Asprotect memory patching
    By TOTEU in forum Advanced Reversing and Programming
    Replies: 12
    Last Post: October 31st, 2000, 00:50

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •