In this tutorial we will see how to unpack target, repair IAT, fix stolen OEP and we gona say couple words about code replacing. Our target will be AVIpreview.exe. AVIpreview is some freeware abandoned application which I packed with trial version of ACProtect so you don't think that I spreed cracks or warez trough mine tutorials. I chose this app because it's not so big but it has lot of imports which is better for practice than some small crackme. Tools that you'll need:

That is example how ALL decryptor loops in this protector looks. Always is some JNZ that throws you back. Below it is usually some JMP or PUSH EAX or some CALL. Never mind for that, you just place bp below our JNZ and press F9 to decrypt. But there is a loot of such decryptor loops and manually is very hard to precede in this way. Because that I wrote small script that will find such jumps and place bp below it, the execute it to the that bp, remove bp and ask you do you want to continue. But we will get to this later.

1.2 Interesting weakness

Altough protector encrypts it's own code, it doesn't encrypt packed file. That is big, BIG, weakness, because if you pack app without compressing and using CRC check, file can be cracked without unpacking. This is very bad from ACProtector side.

1.2 Antidebug stuff

Now, let me show you how does ACProtect hides imports. But first, we must avoid anti-stuff. First, ignore ALL exceptions in Olly, then use some plugin to hide olly from IsDebuggerPresent check, then place in command line (or command bar) "bp CreateToolhelp32Snapshot+1". You will place bp on second instruction of this API because protector checks first instruction for software bp, and it also chechs for hardware breakpoints. Run it and you should break in kernel32 on that API:

Little explanation: this API create snapshot of all processes, threads and heaps and it's purpose is to determ what program started our packed target. Our target needs to be started by EXPLORER.EXE. If target is started via olly or some other debugger, protector will terminate it and packed target. There is simple trick how to avoid this. I sow this trick in KaGra's tutorial: We will fool protector that there are no processes and rest by paching this API. Do not wory, all changes are temporary in memory so you will not screw your kernel32.dll. Watch this:

These are hidden imports. Value after push will be XOR-ed with second one and than RETN will throw us at that address whic is acctually some API address. This is not hard to fix but there is smarter way to do this. Now we gona unpack our target.

2. FIXING IMPORTS AND DUMPING

ACProtector has some more lacks; it doesn't encrypt import section and it doesn't change it's name. Take a look in the memory map window, .rdata is section which should hold imports. Place memory bp on access on it, hide olly from IsDebuggerPresent check and place CreateToolhelp32Snapshot bp like first time. Run target and you will break exactly at the procedure where protector redirects imports, from 435856 to 435AD7. I will not paste here whole code bacuse is't big, I will show you only the most important parts.

First it uses GetProcAddress to get API. Then it first ckecking is that API MessageBox or RegisterHotKey. Those two API's are important for protector and they are always redirected. I don't know why they are important, but we will prevent that redirecting:

That jump which I called "Bad jump" will trhow you at the place where import will be redirected. To fix that and prevent redirection, you need change that jump to jump where good jumps leads. So change:

This procedure at the end will just destroy import redirection procedure when is done. Run our target to decrypt all imports and you'll stop on the abowe bp. You have just fixed imports! Bravo ;) Now you need break on the code section where false OEP is and dump file. I eaxplained how you will avoid anti-debug stuff already, after that use lordPE for dumping file. Fix imports with ImpREC where OEP is 00412AEB=00012AEB, our false OEP. There will not be neither one invalid import :) If you have just one or two invalid, then you have done something wrong.

Run dumped_.exe and file will just close or crush. That is expected since we have stolen OEP issue. We gona fix that now.

3. STOLEN OEP AND FIXNG DUMP

ACProtect has stole lot of instructiones from OEP and mix them with some junk. It is hard to clear false code and restore stolen bytes exactly, but we can fix this little different and easier. We gona just copy-paste all that code to our dumped file , not taking worry what is junk and what is not. First we need to prepare dumped file.

Open your favorite hex editor and add 1000(hex) bytes to the end of dumped_.exe (file that is fixed with ImpREC) and save changes. It could be less than 1000 but who cares. Then load that file in LordPE's PE editor, click on sections, select last one (.mackt) and click to edit section header. There change VirtualSize from 1000 to 2000 and RawSize from 1000 to 2000 too. Save changes. We have done that because there we will paste our code so wee need bigger last section. One more thing, use LordPE's rebuilder to rebuild dumped file so you can open it in olly. Bu be sure that in Rebuilder options is checked only Validate PE.

Now open packed file and get to the CreateToolhelp32Snapshot check. Fix it, and return to protector code where you'll see some api calls. Ignore that and scroll down to end of this procedure, place bp there:

That is just beggining of decryptor layers. You need to decrypt them and find stolen bytes. As I sad on the begining, there are large number of decryption layers and it's hard to trace manualy. Now is time to use my small scrip that will make this easier. Run "ACProtector - pass layers.txt" script and that script will ask you do you want to decrypt next layer. Keep clicking "Yes" untill you get here:

This code between POPAD and PUSHAD is stolen OEP's code with some obfuscated code. Trace to 0043866B PUSH EAX, then select all that code from 0043866B 4386B8 and binary copy it. Open another instance of olly and open in it our dumped file and go to 441000 where you can see that there are lot of empty space. That is part of our last section which we expanded. Now, binary paste there all code that you have copied from first file. You will do that for all code that we found. Now use again our script untill you get at the next part and the binary copy-paste that code too right after first pasted part. Pasted code must continue on each other. You will find next stolen code at these addresses:

After this last one, you will get ACProtect nag window. Click OK on it and script will normally stop on next decrypted place and ask you do you want to continue. Click "No" because you should be at the very end. There should be some CALL's and this part below:

Place bp, run and execute that jump and you will find yourself on jump that throws you at the false OEP:

0043DEB6 JMP DWORD PTR DS:[43DEF8] ; AVIPrevi.00412AEB

This is not much important for us, but you can also binary copy that jump too and paste it to dumped file. Then save all that changes to dumped file by selecting all that code and selecting "Copy to executable -> selection". Shit! I got message "Unable to locate date in the executable file.". Damn! That means that we need more space in our dumped file, I didn't added enough bytes or I started to paste bytes to far. But don't panic folks, we can fast fix this without doing all this job again. Just copy dumped_.exe in the came folder so you have now "Copy of dumped_.exe" there. Don't close your two olly so you do not lose all your job. Open copy of dumped in hex editor and add 2000 bytes more. Then in LordPE set VS and RS to 4000. Use PE rebuilder again. Then all code that you have pasted to dumped_.exe from 441000 to 44130A, binary copy it and paste it to "Copy of dumped_.exe" from the same address (altough addres isn't important). Now save changes, yes it works, and close that olly. Stolen code is retrived, we just need to set new OEP. Open dumped file in LordPE's PE editor again and for EntryPoint enter 41000, then save changes. Now, the moment of truth! Run file.... YES!!! It works! Open some avi file and program will work OK :) Congratulation, you have just unpacked ACProtector Pro 1.35.

4. CODE REPLACING

I will just sad couple words about code replacing. ACProtect substitute some simple instructions like MOV DWORD [xxxx],yyyy to some CALL zzzz which calls protector code. There that stolen instruction will be executed after lot of junk code. The best way to repair this would be to not touch nothing, just leave it there. Our AVIpreview had lot of this instructions which I didn't touch and our unpacked file works fine. This kind of code replacing needs more studing.

5. FINAL WORDS

That was all folks. There is some more things that needs to be discussed about ACPtotect , but maybe in next tutorial. ACProtect is not bad protector and it's not for begginers.

As usuall, greets goes to BIW crew and all users. See you in next tutorial :)