Hello,
Well I will try my luck here since I found no takers in the newbie messageboard. I am posting about a program (Awave studio 7.0), I thought I unpacked and cracked but I have been fooled. While the program would work ok dumped and patched I did more testing and found it would crash when saveing files.
The heart of the problem is a redirected api call (GetProcAddress). In the packed .exe this call was directed to a section in the packing code

005ce1e8 push ebp
... mov ebp,esp
... mov edx,[ebp+0c]
... mov eax,[ebp+08]
... cmp eax,[005db348] ; mem=ffffffff
... jnz 005d3a0e
... mov eax,[edx*4+005db348] ; gets pointer to decryption code
... jmp 005d3a1e
005d3a0e push edx
... push eax
... call kernel32!GetProcAddress
005da1e pop ebp
... ret 0008

This code checked if -1 was pushed if so then return a pointer to some decrpytion code (005cb4bc) in eax else just go ahead with the api.
I have a working IAT thanks to revirgin but that call it wouldn't resolve. I manualy pointed this call to GetProcAddress and that seamed to work. However at one place the program needs the pointer returned from the original (unpacked program) function to decrypt the save file code.

push 04
push ffff
call [4b3...]
move esi,eax
...
...
call esi

I had it patched to skip this check and it didn't seams to be needed untill I tried the save functions.
I could work around this by patching the address to the save file decryption at the right place but in the dumped version there is NOTHING in memory where the decryption routine should be. While in the packed .exe there is code.
I am guessing that somewhere in the packed .exe the code is writen to that location and that my dumped version never runs the unpakcing code so no code gets placed there.
How can I get around this? It seams devlish that even though the program is unpacked and dumped fine it is still useing code from the unpacker. Please help give me some pointers if you can. I am several days on this and running out of steam.

Well I spent today trying to inline patch the program so I wouldn't have to deal with the missing code. I was able to change the oiep and get it to patch the program but the crc check is kicking in. I can skip this check while in SI to see that it works but I can't seam to get around this either, at least not without SI. I can't patch the jump because it is packed code. I have been following Predetors tute on this program but my version is packed with a differnt version of Asprotect. The CRC isn't hardcoded into the .exe like in his tute. Neither was the oeip (it was xor with another number wich was in .exe)

can someone give me some pointers here. I feel I am close to finishing this but can't seam to get over the last hill.
Thanks.
()whore

Ok,

You are working through this weeks version of asprotect, or by the time you read this yesterdays version

First thing I suggest that you do is d/l asprotect, and read through the documentation.

Asprotect is more than just a wrapper, you can use aspr to further encrypt sections of code within an app, and decrypt it through the asprotect code.

A recent one I have found is to remove api calls from the IT, and use these calls via the asprotect code.

This meant fixing the IT by hand, and also injecting code from the asprotect wrapper back into the exe (where I assume it had originally been).

I could have created these calls but getprocaddress had been mysteriously removed from the IT

What you will have to do is trace the code in the 'original' asprotected target, and see what happens.

You may be lucky and find it jumps back into the .exe

If not then it's a case of finding a suitably sized hole to place the NEW code into.

If I have time tonight I will have a look at it (but real life will probably get in the way)

Kilby...

Thanks for the tips. I will dl asprotect and read through it. Will also try dumping the part of asprotect code that is getting called form my .exe and patching it into my dump. I think that will work.
peace,
()whore

Real life is allways getting in the way.

How ironic this thread is, I was just about to post the same findings from new Advanced PDF Password Recovery Pro (www.elcomsoft.com)...It appears that ASPR decrypts certain pieces of the programs code through this GetProcAddress reroute...It first checks for ASPR by PUSH 0 / PUSH FF / Call getprocaddr....this will return 0 unless hooked, which returns the PTR to an ASPR decrpytion routine (i assume)...I fear this routine may require a valid key, as its always tied to the registration functions =( Anyways, even if you fake everything it will cause an exception...I'm going to explore this further as well, but it'd be nice to have registered sample heh =)

madmax