I read the tutorial, but I'm running into a couple differences with my target app. I was able to load the table and redirect the API call, but I run into problems running the app.

In the tut, he uses RVA 80, which he says does not get CRC checked. RVA 80 is in the PE header, isn't it?!? Also, even after using an offset in the PE header, I got the "File corrupted" message box, which means it is checked anyway.

If I pick an offset with the existing code, I either get the "File corrupted" message or my code gets overwritten with the unpacker's code.

I've tried putting memory breakpoints on the code, but it doesn't break before the message box. I also tried putting breakpoints on _lopen, ReadFile, etc., but it doesn't break. Is this check done in memory or from the file itself?

If I pick an offset at the end of a code section (where the bytes are all zeroes) and put my code there, my code gets overwritten with zeroes before it is called!

Please help! I can unpack aspr 1.x easily, but this new one is hurting my brain...

---Xybyre

CreateFileMapping etc..

Thanks for the tip! It seems as though the checksum is used to decrypt certain memory blocks, so I don't think any changes to existing code areas will work. Also, the checksum code is unpacked into dynamically-allocated memory, so I can't just patch the exe...

In-line patching asprotect 2.x seems to be more difficult than it's worth... I ended up using a R!SC's process patcher. Simple and easy.

Actually, it's not too entirely easy. If the patch occurs before the in-memory checksum, you will get the "45 protection error" message box. But I discovered a trick to make it wait until after the checksum.

I'd still like to learn how to do it the in-line way, so if anybody offers any more help...

You can still inline patch aspr 2.0 as easy as 1.2/1.3 without dealing with any crypto stuff! Regarding the CRC check, i know 2 working methods: 1) Make aspr doing it's crc on a copy of the original exe! 2) Patch the mapped exe in memory back to original state, you'll need to patch aspr so it's mapped "writeable" else you will ofcourse just get an exception!

P.S. the dynamically allocated memory you can handle by intercept right after 2nd VirtualAlloc call!!!

Thank you for the advice. Option 1 still requires an additional file, so it's not much different than using a separate loader. Option 2 still requires changing the code in a packed section of the exe.

From my tracing, I have found that Asprotect decrypts the next block of code before jumping into it. That block of code decrypts the following block, and so on. The code I want to change is way down there, so it has been altered by several passes of decryption. How can I change the code without encrypting my changes x times?

I found the very first decryption block, so I can intercept the jump into the next block (to modify its jump), but there must be an easier way than chaining multiple patches together until it gets to the block I want to modify!

Well i don't use this way anymore but when i did i just made my patcher take a copy of the original exe before patching and renamed extension to .dat and made aspr make the crc on that file!



1. You only need 4 redirections before you can patch some addy right after VirtualAlloc, it will take you max 10min to write that code into the exe so it's not that bad!

2. You can also copy and paste the first decrypted layer into a new section then change EP etc. Never tried that on aspr tho, but it should could be done!




You can change some encrypted bytes at an address after VirtualAlloc so it goes to your cave/section or whatever, for that to work you'll need to find out how the encryption/decryption works. Try set a breakpoint on write to addy and you'll see the bytes getting xor'ed 4-5 times depending on which version of aspr your working on!!!

There are four redirections before the VirtualAlloc, but then I have to redirect the call after the VirtualAlloc to get the base address. Then I have to let it jump back so it can unpack its code to the base address. Then I have to redirect the jump into the unpacked code... I'm working on #7 now. How many more are there?


hmm... maybe this is easier than redirecting all the jumps...

1) a good thing is always to write you redir code back to aspr and the return to that same addy!

2) Redirect after 2nd VirtualAlloc call, there you'll see PUSH 6800800000,6A this is a good point to redirect to your "cave". At this point EDI contains the base addy, so now write value of EDI to somewhere in your "cave" so you can use it to patch the rest of your redirs




That depends on how your patching your target. If your only patching the registration scheme of aspr to make app registered you'll need min 7 redirs (thats if you do things without dealing with crypto stuff!) If you need to patch in the image base of your target you'll need 8 redirs (without crypto stuff again) You'll notice that next time your doing an inline patch you can almost copy and paste your first one

If your now on the 7th redir and you still haven't reached VirtualAlloc then your not patching correct!

JohnWho.

I meant I got past the VirtualAlloc (after four redirs), and was patching my seventh location.

I ended up needing nine redirections total. I patched the file memory map to match the original exe. I was able to get passed the file checksum (no more "File corrupt" message!). But now it crashes with the asprotect Error dialog.

Does this have to do with the bounds? Using asprapi, I see it is bound at 6c9b84, and my patch is at a higher location. Is this the problem? I didn't patch the file with asprapi first...

Soooo close now! Thanks for all your help so far!

Try add 1000 bytes to the last section and change section size, make the 1000 bytes nops so you easily can spot them. Note down the address where your nops starts and run the app and break on MapViewOfFileEx. Now look at your address where your nops start in mem window and you'll see they have been overwritten!! Browse down in mem window and when you see the nops start again then it's where your patch code should start!!! Adding your patch in the already present caves in the file can very easily make aspr crash!

Also remember to save the registers your using in your patch code when going to your cave and then restore them when leaving cave!

You should also try only adding patch code to deal with the CRC and then see if app will run then, in "trial" mode ofcourse! If the app runs fine this way then it's probably one of your redirs after MapViewOfFileEx that was causing the crash and you'll need to find another redir further forward in code!

JW.