Aspack 2.11c- Inline Problem
 

The Target: http://www.runtime.org/gdbnt.zip

The Problem:
Another Runtime software protected by ASPACk 2.11c (same as Captain Nemo).I had no problem inline patching Captain Nemo but I'm unable to inline patch this Getdataback.
To crack the program:
While manual unpacking I found these signature bytes:
Now for inline patching when I goto "006353B6" I see this :?

So I cannot see that JNZ to make it jump to my injected code. How to do the patching now? Plz help.

Regards,

seems it has some mistery... maybe it's modified in some way? this is not standard-aspack...

EDIT:
the complete file is xor'ed in some way.
all is done here:
00635518 80B7 5DC99F45 A9 XOR BYTE PTR DS:[EDI+459FC95D],0A9
maybe you can place your inline-patch somewhere after this :)

Hi Ferrari

I am running windows xp, I did patch the two locations you indicated without any problem.

what do you mean by inline patching them?, do you mean at run time?, I didn't try this one.

Hi ferrari
 

As said earlier, some of the starting aspack code is decrypted at 00635518. After the decryption is done, the program does not make the jump at 00635590. The following jump at 00635599 is hardcoded from the beginning. I'm sure you can find that useful for some inovative use of code injection? :)

regards,
hobgoblin

Oh I completely forgot about this thread :eek: For the past few days I'm facing problems connecting to exetools with my actual IP. Anyways I'll try out your suggestions guys. But can you explain one thing guys. Before cracking "Runtime's GetDataBack" I cracked "Runtime's Captain Nemo" which is packed with the same Aspack 2.11c. Here is my crack:

http://grinders.withernsea.com/patches/captain_nemo3.31_crk.rar

And I didn't face this problem while inline patching Captain Nemo. Why?

Thnx Markus, Brite, hob :)

Regards,
ferrari :)

Hi ferrari
 

I just took a brief look at Captain Nemo (hmm, seems like a nice little proggie),and from what I saw both program have some encryption going on at the beginning. The difference is that when it comes to Nemo, the encryption doesn't cover the jumping code to the unpacked code. I don't really know what this is, but it may very well be some modified kind of Aspack. Maybe the programs are packed with Aspack, and then later on the opening code is encrypted in some way. Don't really know whether this is caused by Aspack itself or some 3rd party program. The encryption method used is very simple though.I have every now and then seen programs modified after being packed, but usuallu they don't cause too much trouble. I'll have to take a deeper look at this to come up with some more info...

regards,
hobgoblin

When the program run, the code from 6354F7 to 635590 will XOR the content from 635017 to 63546B with A9.

So, to make the prog to jump to our injected code (e.g. jmp to 635741),in your unpacked file

006353B6 75 08 JNZ SHORT gdbnt.006353C0
006353B8 B8 01000000 MOV EAX,1
006353BD C2 0C00 RETN 0C

change to

006353B6 E9 86030000 JMP gdbnt1.00635741
006353BB 90 NOP
006353BC 90 NOP
006353BD C2 0C00 RETN 0C

So, we know 7 bytes need to be changed. XORing E9860300009090 (each byte) with A9 will get 402FAAA9A93939. Now, replace DCA111A8A9A9 with 402FAAA9A93939 at offset 6353B6 in the original file. Then you
may inject your code later (e.g. at 635741). The code we inject need not to be XOR with A9 because they are not in the affected range (635017 to 63546B).

Hope this help. Sorry for the poor english. :)