Grumble: VMProtect Woes

[redbull]

Hi Guys,

I have a target which I am 99% sure is VMProtect 1.8 (def bigger than 1.7 and no sigs detect it).

It is giving me gray hairs. I am able to find the parts in the loader which write the data back to the original segments and the target is a Delphi executable. I know it must return to OEP shortly after that section. I must say this was a rather tricky protector using threads and exception handling to run more unpacking code.

I have dumped it (without having the correct OEP) and I have also used Universal Import Finder (1.2) with success in building the IATs. (Great Tool BTW, very very nice idea).

I studied the videos on VMProtect unpacking (the one from Nooby jumps to mind).

Not understanding the chinese is a problem for me, but I tried to do it all myself. The problem was this being a different version, the code looks different.

I have two questions:
1. Is there a way to do a dump (based on signature) because I know the compiler was Delphi ??
2. Is there any other resources on VMProtect unopacking other than the IAT ollydbg scripts and the two SWF videos on TUTS4YOU??

I know there are a bunch of calls to VirtualProtectEx which is how I found where the protector was writing the segments back. Are there other things I can look at to get closer to an OEP??

You can dump file after it would be completely unpacked, then restore imports and edit pe header (OEP, etc.).

For me the best way to work with files protected with vmp is - study protector itself, starting from import, then antidebug, etc (what I'm actually doing now).

Then everything will be clear for you and you won't need someone advices. ;-)

[taos]

You can try that. Search for an old version of this app and if it was not protected with VM take note for original OEP. "Normally" this kind of compilers uses similar OEP address. Then you can be closest to OEP with this value.

[ahmadmansoor]

can u upload ur target somewhere

[redbull]

Hey All,

Thanks for the offers of help. I was actually closer than I thought when I first posted the message.

My target was crashing, but not because the OEP was wrong, but because even after running UIF, the IAT was still farked.

It was my stupidity in not realising I was at OEP.

I am performing the following steps to get a clean dump file:
1. Run trial mode exe in debugger, break somehwere in process code.
2. Run UIF and do not directly fix imports.
3. Dump (even procdump worked quite well)
4. Locate OEP, and edit EXE file.
5. Fixing Imports by hand (in progress) (dump as you go to save changes to a new exe)
6. IAT rebuild (not done, using hand or script)
7. Test, rinse, repeat. (not done)
8. Optimize dumped exe structure. (not done)

My target as mentioned before was Delphi app.
Nothing too special except that the intialization code at OEP was a bit more complex than expected.

Finding the OEP

Delphi programs have a string identifier after each method (n debug mode, and important methods are flagged in release mode).

Example for sort is:

RETN
db 0
dw 0
dd ?
dd ?
identifier: db "aspectsorter"
dw 0

The OEP of all my other samples (From Delhi 5.0 to Delphi 2009 vcl) showed that the last "marked method" in the active ".code" block is the Entry Point. (This can be changed at compile time).

A quick scan for this binary string in Olly "E8 ?? ?? ?? ?? 00 00" found what I needed, I then traced back to find the OEP (push ebp).

Interestingly RDGPD got it right first time, with its Delphi entry point scanner (runtime one), run against my clean dump.

Delphi OEP code (v6.0 and v7.0)

push ebp
mov ebp, esp

; .... Intialization code with far calls ... lots of work with EAX. Stack is clean

call far
db 0
dw 0
dd ?
dd ?
identifier: db <exename without ext (eg delphi project name)>
dw 0

Rebuilding IAT by hand

I break at OEP using hardware breakpoints on the real exe.

Then I open the file I am fixing.

Searching for the jmp tables is easy, my Olly search string is "FF 25 ?? ?? ?? ?? 8B C0 FF 25". I am also locating them by running Olly on the dump to trap exceptions.

in dumped file:

0040761E 8BC0 MOV EAX,EAX
00407610 - FF25 78563412 JMP NEAR [DWORD DS:12345678] ; garbage
00407616 8BC0 MOV EAX,EAX

in good copy:

0040761E 8BC0 MOV EAX,EAX
00407610 - FF25 DCA37600 JMP NEAR [DWORD DS:76A3DC] ; advapi32.AdjustTokenPrivileges

So I just copy and replace the the bytes from the orignal process over to the new dump.

Olly has such a nice binary copy function.

I started doing that yesterday, have not played with the target in a while.

Any advice on how to clean up the exe once I am finished ??

[ahmadmansoor]

hehe ...my friend just share with us ur target to work to gather .

and nice job ..

[Nooby]

please upload your file, with the work that you have done I'm confident that you will understand when I show you how it is done.