PDA

View Full Version : Unpacking ASProtect 1.2x



Best Programmer
سه شنبه 15 اردیبهشت 1383, 04:25 صبح
Tools Needed:
OllyDbg
ImpRec 1.6 FINAL
LordPE
Do a google search and get the latest versions you can :)

Target: Notepad Get it http://biw.rult.at/tuts/mrbarbyaspr12x.rarhere
Difficulty: 3/10 (hopefully you will be smoothly guided through :) ).

Dumping and Finding the Stolen Bytes

Intro

I spent a long time looking for some tutorials on unpacking ASProtect with OllyDbg... having only found 1 or two in English (which was pigeon English at best ;) ) I thought I would put together the information I have collected for anyone else who like me did not have a clue as where to start. Anyway, let's go!

Three main steps to unpacking ASProtect:

1. Find the OEP (orignal entry point, where the orignal unpacked program would start) and make a full dump.
2. Look for any stolen bytes (aspr sometimes 'steals' bytes from the original program, maybe 5 or 6, so we have to replace them if it has done so).
3. Fix the IAT (import address table; this tells the program where to find the imports (DLL functions). Aspr, and many other packers, screw this up to make our job harder. Thankfully there are many good tools out there to help us repair it :) )


1. Let's find our OEP.

One little note: the program that I'm demonstrating on is in French... I found it with a French tutorial I accidently downloaded but to save me downloading aspr I used this for an example :)

Right, load our target into Olly. Hit yes on any warnings we get. This next part is important - go into 'Debugging Options' and under the 'Exceptions' tab make sure that the only thing ticked is 'Ignore memory violations in KERNEL32'. We are going to use the fact that Olly breaks on exceptions to our advantage :)

We do not want to trace through the aspr code ourselves... we will get very lost very quickly. Thankfully aspr makes many exceptions, and as I just said we will use this to our advantage. So simply hit F9 and straight away we will get to an exception. Now my method of finding the OEP is simply to count how many times I have to press shift+F9 (pass exception) until the porgram runs. So, try this yourself.

Here's what I got: after pressing F9 to run, I hit shift+F9 20 times. On the 20th time it ran. So start the program again, hit F9 and then press sgift+F9 _19_ times, thus stopping just before the program starts.

(NOTE: This program was packed with a trial version of aspr and so sometimes a nag is displayed. This changes the number of times you need to pass exceptions and so if this happens just start again.)

You can feel it can't you - we're getting close to the OEP :) Now pass the final exception with shift+F8 (stepping instead of continue running). This then (I don't know why) puts you in a dll... not to worry. But wait, let's just stop and think. We might as well use our tools to our advantage, and if we look in our CommandLine plugin help we see a command call TC - Trace Condition. Syntax is as follows:

TC [condition] (register)

So (while we are still in the dll, although it doesn't really matter where you are, as long as you are close to the EIP) let's set this trace command:

TC EIP < 900000

EIP is the register that contains the line that we are on, so this TC traces until the EIP is less than 900000. This will find our OEP for us without having to sift through a load of code!

Found the OEP? Good. It's at the address 004010CC and Olly will display this:

004010CC . 55 PUSH EBP
004010CD ? 8BEC MOV EBP,ESP
004010CF . 83EC 44 SUB ESP,44
004010D2 . 56 PUSH ESI
004010D3 . FF15 74634000 CALL DWORD PTR DS:[406374]
004010D9 8B DB 8B
004010DA F0 DB F0
004010DB 8A DB 8A
004010DC 00 DB 00
004010DD 3C DB 3C ; CHAR '<'
004010DE 22 DB 22 ; CHAR '"'
004010DF 75 DB 75 ; CHAR 'u'
004010E0 1B DB 1B
004010E1 56 DB 56 ; CHAR 'V'
004010E2 FF DB FF
004010E3 15 DB 15
004010E4 FC DB FC
004010E5 64 DB 64 ; CHAR 'd'
004010E6 40 DB 40 ; CHAR '@'


As you can see the code looks quite odd... this is because Olly has not analysised it and it doesn't really know what to display... but trust me that this is actually the correct code :)

Don't press anything now. We want to make a full dump of our process, so click on Dump debugged process in the ollydump plugin and hit dump - the default settings in there are fine.

2. Stolen bytes.

I'm covering this to make sure this is tutorial complete and incase you want to reference back to this when unpacking other targets. Aspr sometimes 'steals' bytes from the un-compressed code making our dump useless if these bytes are not replaced.

It can be hard to find these bytes but thankfully we used the TC command which logs every command that it goes over. So click on 'View' and then 'Run Trace' and we see the log. Scroll down to the very bottem and we see that last few commands that have been processed.

Now let me tell you what you are looking for when searching for stolen bytes... there are three options that I know of:

1. StolenByte1
StolenBytes2
StolenBytes3
etc.
etc.
PUSH [address of OEP]
RET (to the OEP)


2. StolenByte1
StolenByte2
StolenByte3
etc.
etc.
PUSH EBX
PUSH ESI
PUSH EDI
......
......
......
REPZ STOSB
POPFD
POPAD
JMP (to OEP)

3. This is our favourite... no stolen bytes at all:
POPAD
JMP (to OEP)


So, look at our trace window and we can see this:

00903B4F 8901 MOV DWORD PTR DS:[ECX],EAX
00903B51 03C3 ADD EAX,EBX
00903B53 894424 1C MOV DWORD PTR SS:[ESP+1C],EAX
00903B57 61 POPAD
00903B58 FFE0 JMP EAX

And as we can see there are _no stolen bytes_. Makes our job easier :) Do some further reading if you find a target which does have stolen bytes :)

The final step is to write down the OEP for later use.



Fixing the IAT

This part used to be very hard... not any more though beacuase we have ImpREC :D
Fire up ImpREC and then the ASProtected target. Select the appropriate process from the pull down menu and ImpREC will load all the info it needs. Now hit IAT AUtosearch (don't worry about entering the OEP, it isn't really needed) and put the 'Size' up to 1000 (just to be safe :) ) Once you've done that click on 'Get Imports'.

You'll now see all the imported functions found. However, it isn't that easy because some of them are invalid and need fixing/deleting. So click on 'show invalid' on the right and then right click on the selected Thunks and click on 'Trace Level 1 (disasm)'.

(OFF TOPIC: In this case it has fixed all the invalid Thunks. However, if there are any left you would want to select them and right click and under plugin tracers and pick ASProtect 1.22. If there are still some invalid one lefts then simply delete them.)

Now save our import tree just in case we mess up.

Let's fix our dump! Click on 'Fix Dump' in ImpREC and then select the exe that you dumped using ollydump. Cross your fingers and it should have worked :) Now there is only one more thing left do to correct our dump. We need to fix the Entry Point (EP) of the program because ImpREC has changed it... so fire up LordPE and select your dump with the fixed IAT. Now we need the enter the correct EP. Remember that the EP value is an RVA (relavtive virtual offset) so we can't just enter the EIP in Olly. You can either work it out yourself or if your lazy like me open up your initial dump with w32dsm goto the entry point and read off the offset at the bottem (hehe, remember your newbie days with w32dsm and hiew?). Or if your more lazy then I can tell you the EP - it's 10CC (no pun intended!).

Put it into LordPE and hey presto - run your dump and it works! You have successfully unpacked ASProtect! Another thing you might notice is that it has also removed the nag... the nag calling code was somewhere inside the unpacking code which obviously isn't executed any more :)

Outro

Now you could go about cleaning up your dump... removing unpacking code that is no longer needed etc. However this is slightly out of the scope of this tutorial. It would be better practice to go and find yourself some more tutorials on aspr and start unpacking some more programs. Unpacking aspr is not as hard as you may think... once you've done it a few times there's nothing to it! You'll also find newer verisons to be very similar to what you have seen here, so don't be put off by them :) I have found unpacking to be a very interesting and rewarding branch of software reversing... it's also something worth knowing because it allows you to unpack things there aren't any unpackers for...

I hope you have understood this tutorial; I tried to explain everything as best I could but if you have any more questions then don't hesitate to email me.

MrBarby - mrbarby@cwazy.co.uk