VMP vm

[Conquest]

Next i will provide an example from a real vmp executable. I will include all the said info for the vm as well as you will see what is a handler in really is.

I will attach a windowsxp sp3 notepad(5.1.2600.5512) packed with vmp with minimal protection features so that you can run it inside olly even if u dont have enough protection enabled to hide from vmp

Upon entering the vm you will land on the oep at 01194550 which is an immediate jump. you will see lots of these jumpings in vmp to make the cracker puzzled. but i wont go details about how it works or how to unpack it etc.

Once you are at the ep of the vmp sfx section you need to start tracing/stepping in . most of the codes you see either total crap codes or simple fix-ups

After the jump there is a

011934FA    68 4BA69DC4     PUSH 0xC49DA64B

this pushed value will decide the start and other parameters for the vm. It is the initialization key fo rthis particular vm instance.

now step/trace till 01199AAB where our interesting codes will start.

01199AA3    8B7424 34                                        MOV ESI,DWORD PTR SS:[ESP+0x34]
01199AA7    83C4 04                                          ADD ESP,0x4
01199AAA    9C                                              PUSHFD
01199AAB    F7DE                                            NEG ESI
01199AAD    9C                                              PUSHFD
01199AAE    9C                                              PUSHFD
01199AAF    81C6 8EA584C3                                    ADD ESI,0xC384A58E
01199AB5    0FB6FA                                          MOVZX EDI,DL
01199AB8    F7DE                                            NEG ESI
01199ABA    F7D7                                            NOT EDI
01199ABC    C1ED 06                                          SHR EBP,0x6
01199ABF    66:0FCD                                          BSWAP BP

This is a interesting part of the code since it will decide the start of the virtual machine p- codes. lots of junks are there but if you follow it properly only 3 instructions are useful. I have pointed out them -

01199AAB    F7DE                                            NEG ESI

01199AAF    81C6 8EA584C3                                    ADD ESI,0xC384A58E

01199AB8    F7DE                                            NEG ESI

This is the vm init. after the last NEG ESI if you follow Address pointed by ESI(which here on 1st run is 0x011900BD) you will see the vm p-codes. Here is something very interesting- load the binary in IDA and you will some assemblies at the address 011900BD . Dont get fooled by it. Its not normal/ordinary x86 assemblies and trying to run it will just cause the app to malfunction. Later we will see that the pcode-reader may not start reading the table at that particular address at all. what i mean will make sense a bit later.

Now start tracing again and you will reach at 01198836. this is another very important function. it can be called as p-code reader.

01198831    0375 00                                          ADD ESI,DWORD PTR SS:[EBP]
01198834    F6D0                                            NOT AL

>>>01198836    8A46 FF                                          MOV AL,BYTE PTR DS:[ESI-0x1] <<<

01198839    66:0FBAE9 0E                                    BTS CX,0xE
0119883E    FEC5                                            INC CH
01198840    8D89 5410092E                                    LEA ECX,DWORD PTR DS:[ECX+0x2E091054]

If you havent got puzzled yet, you will see the value at esi is 0x011900BD. Interesting enough the asembly reads 1 less the address i.e. 011900Bc . So the p-codes indeed started at 011900Bc.

Now the pcode stays altered which needs to be changed for main-vm handler to be used(much like polymorphism in c++).
Now keep stepping and you will find these following codes which alters the value in eax(al)

01198846    28D8                                            SUB AL,BL
01198850    34 BA                                            XOR AL,0xBA
01199693    FEC8                                            DEC AL
011995E4    34 26                                            XOR AL,0x26

Just notice the value in eax(al) . its the decoded value for main vm handler to point ot the appropriate vm-pcode- handlers. Always remember that since there is 0~255 possible p- codes there for there can exist 256 sub-vmhandlers for them(they dont though). In simpler words for every vmed code you retrieve there is a vm handler for it. some time 2 or more p-codes point to same vm-pcode-handler
Step again and now you will see the main vm handler-

01199609    8B0C85 888F1901                                  MOV ECX,DWORD PTR DS:[EAX*4+0x1198F88]

it points to vm handler dynamically i.e. as value of eax changes the total value pointed by assembly changes as well. Once again its another table as well. The base of the table is 0x1198F88 . if you look at that position in hex dump you will find the table. it just fetches the appropriate member from the table depending on the value of eax.

 for instance if eax=0, 0x1198F88+0x4=0x1198F88 that is the 1st member of the table For eax=20 it will fetch the 20th member from the table.

If you arent aware, vmprotect can find the code alternation made on unpacked clients as well as running client . There exists similar v-table for that hash calculation as well(Raham Knows more). But i dont have much details of that at the moment(Its vmed and i dont have a 'un-virtualizer).
Now the vm handler is obfuscated. If you look at it , it doesnt even point to anything at all. Now if you step you will find this-

0119A8F0    81C1 B9C48277                                    ADD ECX,0x7782C4B9

Now it points to the proper handler address. We need a jump to this so they do a clever trick- push it and use retn. but before they enter another round of junk codes and fix ups. Finally you will see a retn imm which will jump to the vm subhandler. here it will be this-

0119AA7B    C2 3400                                          RETN 0x34

step in and you are inside the vm subhandler.What it will do is to carry out the particular instruction which was replaced by the vm pcode

I will not get into the details of how handlers work. But just to let you know though the handlers are replace of some assembly instructions ,they are not replica of the instruction. The do several jobs including fetching the values doing the maths etc all in one handler.

Vm Return-
At the end of vm execution the main vm handler points to the vm_retn address. This particular function has several jobs to do. First of all, it restores all the registers including the flags and points to the proper ip. Finding the proper vm retn handler isnt trivial rather it stays un-executed till the vm reads the vm_retn pcode.
You can keep stepping till the handler jumps to something weird but to cut to the chase put a hwbp on the following

011993C1 >  66:0FBAE0 0E                                    BT AX,0xE

most of the codes you will find while stepping is not of our importance so i will just point out the register restores

011993E2    58                                              POP EAX

011993EF    5B                                              POP EBX

0119898D    8B4C24 04                                        MOV ECX,DWORD PTR SS:[ESP+0x4]

0119899A    8B6C24 08                                        MOV EBP,DWORD PTR SS:[ESP+0x8]

011989A1    8B5424 0C                                        MOV EDX,DWORD PTR SS:[ESP+0xC]

011989AD    8B7424 10                                        MOV ESI,DWORD PTR SS:[ESP+0x10]

011994F2    8B7C24 1C                                        MOV EDI,DWORD PTR SS:[ESP+0x1C]

011989B9    9D                                              POPFD

here is one interesting thing which i have found based on 3 different vm samples. Although the p-code mappings change and things like push-pop orders, the vm-pcode handlers remains same for all vms. what does this mean? remember the cpuid feature of vmprotect. Though while using lcf-at scripts you encounter with lots of cpuids via the log, the true resides inside a vm handler. if you look at it properly, the handler is same for all versions(they are full of garbage assemblies to hide that fact). same with other handlers. all are same. just the p-code mappings for them changes.

So till now i have tried to sum up what i have found and its missing a lot of things which i have yet to figure out properly. This includes the initial vm stack and the meaning of the stack values, as well as method of stack based calculations

---------------------------------------------------
Target-
---------------------------------------------------
http://hostr.co/eU7V47XQ2jkN
---------------------------------------------------
password- tuts4you

On last note- if you find any inconsistency in the paper, don be hesitated to point them out. The only reason of writing this paper is to share the knowledge which i have and unless others share their experience its not complete