				Reversing  PECrypt protection				7/4/2000
					by Latigo  


(800x600, wordrap on)


What i'll try to do here is to explain how to 'recover' a PECrypt protectec program. The packed target is my own PeLabs.exe; i don't use it for self-propaganda but because i know this program by heart and its easier for me to play with.
The PECrypt version used is 1.02. and the pe-crypt.ini used is in this same zip file (pe-crypt.ini resides in c:\windows)

I did not use any kind of Option or CRC check because what i want to convey in this tutorial is how to unpack and rebuild this program independently of recurring anti-debugging tricks or similar subterfuges. Yes maybe they can make the unpacking a little bit difficult,but not too much. And if you understand all the contents of this tutorial, then you will not have any trouble defeating such annoyances. One more thing, i assume a base knowledge on the PE header, some unpacking experience and ASM. 
Tools used: and Softice, Icedump, ProcDump, Hiew.
Ok, on with the show.

I will divide the rebuilding process in two sections:
1) Dumping process,some pe fixing.
2) completely rebuilding of section containing Import Address Table. including:

	* Find in what section the original IAT lies and dump it
	* Dll Names decrypting
	* Finding where the IMPORT_DESCRIPTORs array begins.
	* couple of aditional thingies  :)



					-=*=-

1)

The information we need in order to dump the process properly are: The original EntryPoint (from now on called OEP) and the ImageSize. The latter we get with procdump.
So the ImageBase is 0x10000 but the OEP is unknown to us. And to get it, all we need to do is TRACE. Load our target with SoftIce's symbol loader, and TRACE from the EntryPoint to the Original Entry Point. I simply cannot tell you how to do it; you just have to use F8 and F7 to trace your way till the Unpacker routine's exit point. How to spot that place? well a mixture of skill,experience,zen and luck will do it. Besides, you are supposed to have a background on manual unpacking. In our case PECrypt's exit point is 0040D112. That 'JMP EAX' takes us to the OEP which is 401000.

So now we got all we needed in order to do the first dump, and so we do : PAGEIN D 400000 10000 C:\MyDump.exe. Now, the most asked question is.. why dont i see the icon in this exe???
When you dump a process from memory, the RawOffset for each section is the same as the VirtualOffset. (if you dont understand this you need more PE knowledge)
To display the icon, the OS searches for it in the Resource section (rsrc) , and as the OFFSET to the Resource Section is NOT the one that appears on the dumped PE header, it is natural that Windows won't find it. This same concept applies to ALL the sections.
So what we have to do is to replace every RawOffset with its corresponding VirtualOffset. Another thing that you could do is to replace the RawSize with the VirtualSize (thing i did not do in this case,but might prove to be usefull in other cases). You can use Bonker's PeFixer so it will change all sections in one snap; or use procdump and do section by section.

And to conclude this first section, lets change the program's EntryPoint to 1000.

2) 

Don't even expect that after doubleclicking on mydump.exe it will work! nonono. we have dumped it, fixed RawSizes and EntryPoint so far, but we need a complete IAT rebuilding now.

(Again if you dont know how the IAT is composed and how the OS handles it, you will learn nothing here).

PECrypt installs its own IAT. it does this because it needs some APIs to be able to do all the unpacking and shit before it executes the protected exe. Since Windows will handle PECrypt's installed IAT somebody has to do the OS's task of filling the entries in the FirstThunk array with the actual API addresses..and that somebody is the PECrypt unpacking routine.
That lets us know that in _some_ point during the unpacking routine, PeCrypt has to restore the original IAT and play with it. But where in hell does the original IAT lie? what's its section?
In this case, this would be a nice guess,since our target has a section named 'rdata' and that for sure is where the original IAT is. but what if ALL the sections were named 'fuckyou' or something???
Here's a nice trick to know where the original IAT lies.
Put a breakpoint on any API used by Pelabs.exe. Lets say ReadFile. So go to 'file - open' and open a new file. Boom, sice pops, f12 once and we breakpoint again in 401f61. Open another file again and this time instead of pressing F10 on ReadFile, press F8. You will land in 4029e0 which is a jmp [KERNEL32!ReadFile]. Now do a 'code on' in softice. What you get is 'FF 25 28 30 40 00' And that means something like 'Jump to the address that is contained in 00403028' and there you got it! 00403028 is a member of the array pointed by FirstThunk which is part of the IAT!
the RVA 3028 is the same as OFFSET 3028 in our dumped image. So to locate the original IAT containing section's RVA all you have to do is to compare each section RVA with your 'spotted' RVA (3028).

To make it clearer:

Section		RVA

.text		1000
.rdata		3000
.data		4000
.rsrc		5000

Do you see it now? the 'piece' of original iat we got is in RVA 3028 and rdata starts at 3000 and ends in 4000. so our piece fits somewhere in that section!.
Again, here we have no problem locating the section containing the iat because its called rdata and we know it must be there. The above mentioned 'trick' (if you can call it like that) is usefull when you dont know which section contains the original IAT.

Ok now we know that the RVA to the original IAT is 3000. Let's try to spot the point where it is decrypted and dump it. Load the Pelabs.exe in Sice's Loader and BPM 403000 W .We land in 40a80b and see a loop there. That loop is decrypting something so i let it finish, do a 'D EDI' and start searching for legible API names. ('e' in SoftIce and about 15 'page downs' will make it).
Yeah! Import Table is decrypted in memory. Lets dump it! PAGEIN D 403000 4CE C:\rdata.dmp.
Now we must 'stick' this rdata section to our dumped image. Open rdata.dmp in hexeditor, select all the bytes, open now the dumped .exe go to offset 3000 and paste all the bytes!.
Now all we need to do is to change the Import Table RVA in the PE header; but we dont know that! we have a recovered rdata section which contains the IAT but we dont know the RVA to it!!

Here we pull another trick:(learned from one of R!SC's tutorials) 
First we locate a the first dll name inside the IAT and take note of its RVA. Then we search for those bytes inside the rdata section, thus stoping inside the first IMPORT_DESCRIPTOR structure! Go back 12 bytes and there you are! at the IAT RVA.
But there is a minor detail here. Our dumped rdata section has no DLL names!!!!!! Fucking PECrypt!!! We could guess the dll names just by looking at the Imported Functions,but what if the program used a custom dll named 'IHateLeetCrackers' ?. So let's discover which dlls are used. 

We know that PECrypt routine gets each imported API's address with GetProcAddress, and we know that one of the two parameters to GetProcAddress is a handle to a DLL. And that handle is obtained via GetModuleHandle. So lets load Pelabs.exe in SoftIce's symbol loader and lets bpx GetModuleHandle AFTER the rdata section is decrypted. Bpm GetmoduleHandleA x do "d esp->4"
After each break i check the data window looking for a dll name which im sure the PECrypt does not import. There, we get to COMCTL32.DLL; F12 once to go back to code and note the address that contains the name of the decrypted dll. Its 40f704 so lets BPM 40f704 w, D 40f704 and load the program again. Ignore the first time SoftIce pops, but not the 4 following ones! the STOSB at 40BD82 made Sice break. That means that something is being read from ESI, procesed, and put back in EDI. hehe looks like the thing we are looking for. Upon further examination we find that at 40BD53 there is a LODSB that reads from our rdata section right from each dll's name RVA. So in order to know what name belongs to which RVA, we are going to load the program once again and each time Sice breaks (ignoring the first one always) we substract one from the address found at ESI (dll name RVA) and write it down (LODSB incremented ESI), F7 on 40BD86, D on  40f704 and finally write down that dll name.
The next thing to do is to put those dll names back where they belong to. Take each written down adress, transform that to an OFFSET inside Pelabs.exe (easy just substract the ImageBase from the given address) and type the corresponding dll name. 
Now we can attempt the trick to learn what the RVA to the IAT is; and doing so we come to know that its 30BC, so go and replace the existing one (which pointed to PECrypt's own IAT) using  procdump.
So far we have dumped the exe, changed entry point, fixed section's offset,dumped iat,found dll names,found iat RVA and changed it. Lets try to execute the exe. BOOM gpf...FUCK! what now!?!?!?
After some investigation i realize that what is making Pelabs.exe crash is that the members of the OriginalFirstThunk of each IMPORT_DESCRIPTOR point to garbage. So to simplify things ill just make the OriginalFirstThunk point to the same thing as the FirstThunk.
For this i coded a little program to do it quickly. (the program also changes each dll name).
Well let's try executing Pelabs.exe now...WOO00 HO0O0OO it werks!!!!!!!!!!! :)
Yes i know, our executable is 64k and the original size is 20 k. But i won't cover PE optimization in this tutorial. If you want a smaller file use procdump to optmize it.

That's it! PECrypt wrapper defeated!!
Well i think im done. Hope you learned something! 
Greetings go to all #cracking4newbies.
Bye!

latigo@ciudad.com.ar
www.latigo.cjb.net






