Log in

View Full Version : Does As-Protect use "Exception handling"?


riPPadoGG
December 13th, 2001, 09:24
Hi All,

I unpacked Cresotech Type Recorder.. AsProtect 1.2..
But when I ran it after unpacking, there came in a message-box saying that an Error occured as memory in the range of E00000+(message had the exact memory loc) was accessed.
The interesting point was that it was not a Windows message, Soft-Ice did not break(was faults on). I used Symbol loader, and noped out the call to the wild..(3rd one from OEP) The proggie ran like anything..

My question is why did Windows/S-Ice did not complain about the exception?
Is this due to "Exception handling from within the program??"

regards
riPPadoGG

HAVE A NICE TIME REVERSING

+SplAj
December 13th, 2001, 10:48
yes it's possible the programmer used SEH.

If you see code like

push ebp
push 403616
push dword ptr fs:[edx]
mov fs:[edx],esp
....

then the new exception handler code is 403616 and the exceptions will be filtered there....?

However, what you found is a 'fixed' link to redirected code to aspr code that is no longer there....(same technique as the IAT redirection)

Try and re-run original exe and set a bpr/bpm on that location and trace it to it's real code.

eg

48E818 Call [49068C] == aspr Call FEC784 == Call 48E534

so in the unpacked code hex edit the hardcoded 84C7FE at offset 0x9068C with 34E548 (reverse byte order !!!) and that one is fixed....next prob

Hope that helps ?

Spl/\j

riPPadoGG
December 14th, 2001, 02:36
Hi +Splaj...

Yes, that is correct.
It might very well be a call redirected to some really valid part of code.
Looking back, NOPing out was TOO hasty..
The program actually kicks off(GetModuleHandle et al) from the Call before..

What sort of a doGG am I?

PANT PANT...
SNIFF SNIFF SNIFF...



regards
riPPadoGG

NB: Looking forward to your tuts..

LIFE IS SHORT... BYTE HARD...

JMI
December 14th, 2001, 03:23
riPPadoGG:

Here's a snippet from one of those tuts, since is addresses the specific point +SplAj raised and you discovered. Our resident "coding God", see text below, had just finished unpacking and fixing the import table of Awave Studio 7.3, an Asprotect 1.2 protected target. He then tried to run his unpacked file, called "dumped.exe" and discovered two additional issues, one of which was a reference back to Aspr code that wasn't there anymore, which was important for the proper working of the program. Here it is:

____________________________________

Try and run your dumped.exe and you get a message' EXIT you must not rename the program executable file [Awave.exe].'
Yeh ? well fuck off I am a coding god and can do anything to you that I want. So rename your dumped.exe to Xwave.exe and use an hex editor at raw offset 0xD9520 and 0xD952C and change Awave to Xwave

Re run Xwave.exe and whoooo WTF we crashed and burned at some goddam 0xF1C774 ???

Lets debug

Start Awave.exe with Symbol Loader and trace till we find when we get to F1C774 :-

I found it at : 0187:0046D5D4 CALL [004EBA08] ->

EAX=00498101 EBX=00F30A44 ECX=00000001 EDX=00F35648 ESI=00000000
EDI=004EB858 EBP=816B09D8 ESP=007BFD38 EIP=0046D5DA o d I s Z a P c
CS=0187 DS=018F SS=018F ES=018F FS=2297 GS=0000
------------------------------------------------------------------
0187:004EBA08 74 C7 F1 00 00 00 00 00-00 00 00 00 00 00 00 00

------------------------------------------------------------------
0187:00F1C774 55 PUSH EBP 
0187:00F1C775 8BEC MOV EBP,ESP
0187:00F1C777 53 PUSH EBX
0187:00F1C778 56 PUSH ESI
0187:00F1C779 8B5D0C MOV EBX,[EBP+0C]
0187:00F1C77C 8B7508 MOV ESI,[EBP+08]
0187:00F1C77F 8BC3 MOV EAX,EBX
0187:00F1C781 E8E25DFFFF CALL 00F12568
0187:00F1C786 A3B435F200 MOV [00F235B4],EAX
0187:00F1C78B 8B15B435F200 MOV EDX,[00F235B4]
0187:00F1C791 8BC6 MOV EAX,ESI
0187:00F1C793 8BCB MOV ECX,EBX
0187:00F1C795 blah blah blah..............

CALL [4EBA08] is a redirected call to the memory pointed there :- F1C774 and because this code is no longer available in our Xwave.exe - we are running without aspr remember, we need to figure out what this call does. It is NOT an API call but does decrypt some code and returns (RET 008 = = very important) to our code at 46D5DA.

My tactic was to re-run Awave.exe and just after this call had been made to decrypt some code and then dump at 46D5DA. Re-do the fix up with LordPE , Entry Point, IAT/IT bin reloaded etc etc and then change the bytes at offset EBA08 in this dump from 74 C7 F1 to a spare location, like raw offset F0000 and then put a RET 008 . So patch :-
At raw offset 0xEBA08 replace the 74 C7 F1 with 00 00 4F and at raw offset 0xF0000 put the bytes C2 08 00 -> RET 008 and save.

rerun the Xwave.exe and I think we are close still evaluating .....but f*ckin close ......................
____________________
end of snippet

I've got all the +Splaj materials to upload except something he mentioned about "html unencryption" and if I don't hear from him by sometime tomorrow I'll upload the original discompress materials + the latest tuts on Awave Studio and CV3.1. When you read the tut on CommView, don't forget to check out the long thread, started by evaluator discussing changes in the protection with a later build of version 3.1. Very informative reading. You'll find it here:

http://www.woodmann.net/forum/showthread.php?threadid=2263

regards and cudos to the author of this tutorial series. He really shows the way for us to follow and learn.