Exetools  

Go Back   Exetools > General > General Discussion

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 08-17-2013, 13:33
Conquest Conquest is offline
Friend
 
Join Date: Jan 2013
Location: 0x484F4D45
Posts: 125
Rept. Given: 46
Rept. Rcvd 29 Times in 17 Posts
Thanks Given: 31
Thanks Rcvd at 60 Times in 29 Posts
Conquest Reputation: 29
VMP vm

I posted the thread on tuts4you 2 days ago and it will be unjest if i dont post it here-
NOTE: Before you read this remember it is not complete yet and you may find lots of quarries. Stay tuned. I am not expert in this but as i unfold the secrets i will share it here

For previous few days i was busy with learning more about how VMs actually work. Its not complete yet but i have come to have a decent knowledge about how it actually works. This article is about sharing the knowledge with you people in the most 'newbie' friendly way possible for me. Just for the Reminder before i start, its no way should be considered as complete or error-free. Chance is may be my whole view/knowledge about the VMs is wrong and the devs are laughing their a** out looking at the post
Before you start reading this, I would like to thank people who has previously done research on this field specially RolfRolles . Most of the papers which i could find on the net were from this guy. Chinese hackers such as Ximo has some special tools and documents about different features of VMProtect but unfortunately apart from the one translated by SunBeam i couldnt get a hold on any of them.
One the last note. I am a novice hacker and all these researches are done from pure interest and without some serious programming background, They are error prone and lack the depth ofcourse. But i believe in the end it will motivate more 'newbie' hackers like me to learn the features of vm based protectors

What is a VM?
Though Virtual Machines are Software which emulates a computer architecture, in case of VMs used in protective software pieces like themida/vmp they are mere p-code interpreter. What they do is retrieve a p-code and associated data with them and interprets and translates them into sequential instructions. Later we will see that every p-code(vm instruction bytes) is a piece of encrypted code/data which redirects the flow of the code to a particular 'handler'(a handler is a piece of code which does a specific job meant for it only).
All these may sound bizarre and complex to the reader but eventually you will see what it does.
Construction of VMP vm:-
its an RISC stack based vm. Now, lets get into the details -

What is meant by RISC?
Searching Google will yield a shit-ton of results about CISC-RISC Architecture but to cut to the chase Think RISC as an architecture where faster and simpler instructions are compiled to increase the efficiency .
In VMP vm a single CISC(Intel Instructions which are CISC based) instruction in divided into several Shorter and simpler instructions . That is why it is called RISC vm. But due to teh compatibility issue with native intel CISC architecture in the end it yields a much complex VM-handler for the executable. The Executable becomes very large(almost twice of its size when decompressed) and slow

What is stack based vm?
The main aim of usual software protectors is to protect sensitive data from the praying eyes.
So in VMs they mutilate the original information . But again they need to do the original job which they are requested to do. These cant be done on cpu registers once you are inside the vm(well its a bit complex to say we will see what happens exactly later). The registers are still used but not for adding them directly. VMP before entering inside the vm , Pushes all the registers(which are loaded with required data) into stack. The stack becomes its new scrap area of operation. So what it will do is actually use the stack for necessary operations.

What does the vm contain?
The vm actually contains of say encrypted data which gets decrypted during the run time. Some of you may think 'what if we modify it?' it wont simply run unless you know what you are doing just like modifying a normal exe with hex editor

More about the VM?
lots of vm-instances can exists in vmp. each vm instance contains a main-handler, p-codeloader etcetc. what it means is that the vm architecture remains constant in a vm and its all instances. So once you know the architecture properly, you can successfully decompile every vm in the executable. As i have said previously, vms are like piece of encrypted code and the decryptor is only one inside for a specific vm in an executable. so one can just add as many vm as they want but all of them will get 'encrypted' with same algo as well as 'decrypted' for same vm instance

Lets get into the details-

VM initialization key decoder-
What it does is to point to the start of the vm.a push at the start of the vm makes it sure that the key is pushed in the stack. It decodes that 'pushed' value and points to the start address of the vm p- codes. Pretty simple function isnt it? I will provide an example later in the article.

p-Code Loader-
This one is very interesting.it reads the pcode bytes (like reading the encrypted data).

p-Code decoder-
Decodes/decrypts the pcode into more useful data

Dispatch Table Handler-
This one needs explanation. when the pcode is loaded in the decoder it(the pcode) means some specific operations to be done. A handler is a pice of code which does those operations. But since the devs are pussy about leaving the handler routines open to all, they 'encrypt them and stores them in an array(or something like that. *containers*) of encrypted handler table. The handler gets loaded and then gets supplied to the handler decoder

Handler Decoder-
Decodes the address of the handler. Remember that handlers are piece of normal codes which are heavily obfuscated.

Handler Entrypoint-
Once the handler address gets decoded they push it in the stack and does some garbage calculations to make you life more miserable than it already is. finally with simple retn imm32
it starts the handler routine

Why is it said that every vm is different?
the reason is pretty apparent.Lets talk about how vms get generated at 1st. The protector does arbitrary calculations to decide which instruction to be assigned to whom. for instance say on one instance c3 gets assigned to add while on another it gets assigned to sub. there is something more. the register on which handler table and pcodes will operate changes as well on every instance of new vm being compiled in a new executable. i have previously said that the vmp pushes all the necessary data before entering the vm, this means the registers.flags etc. it is also randomized on all instances on vm implementation.
One thing to note- vmp vm doesnt do fpu operations(I havent seen a single handler instance of doing fpu calculations). if it needs to do those things it exists the vm,restores the flag and do the fpu calculations on normal. same with some un-supported instructions
Reply With Quote
The Following 5 Users Gave Reputation+1 to Conquest For This Useful Post:
niculaita (08-17-2013), sendersu (08-17-2013), softgate (08-17-2013), Syoma (08-17-2013), user1 (08-17-2013)
The Following 11 Users Say Thank You to Conquest For This Useful Post:
abhi93696 (03-30-2017), ahmadmansoor (10-22-2019), Antitrack (01-24-2018), m0nix (02-18-2019), pertican (07-14-2015), Stingered (03-31-2018), tonyweb (08-07-2016), Turkuaz (03-30-2018), unn4m3D_BR (03-30-2018), WaSt3d_ByTes (04-05-2018)
  #2  
Old 08-17-2013, 13:40
Conquest Conquest is offline
Friend
 
Join Date: Jan 2013
Location: 0x484F4D45
Posts: 125
Rept. Given: 46
Rept. Rcvd 29 Times in 17 Posts
Thanks Given: 31
Thanks Rcvd at 60 Times in 29 Posts
Conquest Reputation: 29
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


Code:
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.

Code:
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 -

Code:
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.

Code:
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)
Code:
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-
Code:
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.
Code:
 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-
Code:
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-
Code:
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
Code:
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
Code:
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
Reply With Quote
The Following 5 Users Gave Reputation+1 to Conquest For This Useful Post:
ahmadmansoor (08-18-2013), besoeso (08-17-2013), niculaita (08-17-2013), softgate (08-17-2013), user1 (08-17-2013)
The Following 2 Users Say Thank You to Conquest For This Useful Post:
abhi93696 (03-30-2017), Antitrack (01-24-2018)
  #3  
Old 09-26-2014, 01:00
pDriLl
 
Posts: n/a
Hi.
I have also looke at VMProtect in the last past weeks and I will show a bit differt way of looking at it.
Insted of going to deep into every instruction I will show how to get a better overview of whats going on by
looking at the code flow and a few instruction only.

I wrote a small program that will run the protected exe and attach a debuger to it.
My debugger will set a breakpoint on the fetch instruction at address 01199609. So every time a vm
instruction is fetched my debugger will stop it and I can look at the vm's register and stack etc.
So in the x86 CPU ESI will be vm's instruction pointer, EDI is ptr to vm's registers r0-r15 and Ebp
will be vm's stack pointer.


.vmp1:01199609 mov ecx, ds:vm_dispatch_table_1[eax*4] <- Fetch instruction
.vmp1:0119A8F0 add ecx, 7782C4B9h

Using this info we can decode the opcode/dispatch table
After decoding we can see all instructions and the address where they are executed.
For now I wont try to understand all om them. Only the opcodes that calls out of the VM.

Instruction (opcode) Table:
00 - 01198355
01 - 011999EE
02 - 0119854B
03 - 01199FD0
04 - 0119856B
05 - 01199406
06 - 0119AA44
07 - 01198C5A
08 - 0119955D
09 - 0119A5C5
0A - 01198EFF
0E - 0119A3DD
11 - 01199487
12 - 01199B6D
13 - 0119A1EB
14 - 0119A52A
17 - 01198F6E
18 - 01198CFD
1B - 0119A16B
1D - 01199A2E
1E - 01198739
20 - 0119A469
22 - 0119A000
24 - 01199615
25 - 01198F18
26 - 01199F94
28 - 01198338
29 - 0119972A
2C - 0119A06E
2D - 01198E62
2F - 0119996D
34 - 011986A3
35 - 0119A6A0
36 - 011982C5
37 - 011983FA
3C - 0119853E
3D - 01199B02
3E - 0119A6AE
3F - 01199B1E
41 - 011982EB
42 - 011984BA
44 - 0119A8E7
47 - 0119A7FE
49 - 01198948
4C - 01199A4E
4E - 01199978
51 - 01199DFE
54 - 01199643
55 - 0119A7C5
57 - 0119A625
59 - 011993C1
5D - 011998B7
61 - 0119892D
63 - 0119A80C
67 - 01199900
6D - 0119848C
6E - 01198BA1
7A - 0119A0CD
8A - 0119A5B3
8C - 011999B6
A6 - 01199510

Found 61 instructions

Not all of them is in use when we run it.
After a full run we can see some stats about which opcode that are executed and the number of times they are executed.

Number of used opcodes 48
25 - 1198F18 cnt:75945 <- pop rx (x can be 0-15)
14 - 119A52A cnt:14002
61 - 119892D cnt:11788
1E - 1198739 cnt:44532
7A - 119A0CD cnt:11759
2C - 119A06E cnt:3341
42 - 11984BA cnt:15
22 - 119A000 cnt:297
01 - 11999EE cnt:513
28 - 1198338 cnt:24
1D - 1199A2E cnt:516
12 - 1199B6D cnt:10353
02 - 119854B cnt:24146
37 - 11983FA cnt:3517
2D - 1198E62 cnt:6463
4C - 1199A4E cnt:1126
04 - 119856B cnt:1489 <- Jump
17 - 1198F6E cnt:2
6E - 1198BA1 cnt:3
54 - 1199643 cnt:1625
07 - 1198C5A cnt:337 <- Call out function
44 - 119A8E7 cnt:856
6D - 119848C cnt:98
06 - 119AA44 cnt:691
8A - 119A5B3 cnt:989
03 - 1199FD0 cnt:248
20 - 119A469 cnt:521
A6 - 1199510 cnt:1354
4E - 1199978 cnt:1013
1B - 119A16B cnt:1012
24 - 1199615 cnt:519
5D - 11998B7 cnt:26
3C - 119853E cnt:2
08 - 119955D cnt:1
3D - 1199B02 cnt:5
0A - 1198EFF cnt:43
26 - 1199F94 cnt:4
2F - 119996D cnt:15
34 - 11986A3 cnt:19
11 - 1199487 cnt:3
18 - 1198CFD cnt:3
29 - 119972A cnt:3
41 - 11982EB cnt:4
55 - 119A7C5 cnt:17
47 - 119A7FE cnt:2
09 - 119A5C5 cnt:2
05 - 1199406 cnt:2
59 - 11993C1 cnt:1 <- Exit VM and decode registers

So we have 48 instructions that are in use.

No when we run it the debugger starts printing out the execution flow and as we can see here
(VM Entry point. VM is running backward!)

Looks like my IP is one byte off coz of the code running backward. This will not affect the analyze.

011900BC: 25->25 [x86:01198F18] (sp[0]:00000000 sp[1]:00000000 sp[11]:EF9353B9)
011900BA: AB->14 [x86:0119A52A] (sp[0]:00000000 sp[1]:00000000 sp[11]:C49DA64B)
011900B5: 61->61 [x86:0119892D] (sp[0]:050E5A20 sp[1]:00000000 sp[11]:EF9353B9)
011900B4: F0->25 [x86:01198F18] (sp[0]:00000202 sp[1]:050E5A20 sp[11]:EF9353B9)
011900B2: F0->25 [x86:01198F18] (sp[0]:050E5A20 sp[1]:00000000 sp[11]:C49DA64B)
011900B0: CF->25 [x86:01198F18] (sp[0]:00000000 sp[1]:7C90E514 sp[11]:7C817077)
011900AE: 25->25 [x86:01198F18] (sp[0]:7C90E514 sp[1]:7FFDB000 sp[11]:00B500B4)
011900AC: 25->25 [x86:01198F18] (sp[0]:7FFDB000 sp[1]:0006FFB0 sp[11]:00B700B6)
011900AA: F0->25 [x86:01198F18] (sp[0]:0006FFB0 sp[1]:0006FFF0 sp[11]:7FFDB000)
011900A8: F0->25 [x86:01198F18] (sp[0]:0006FFF0 sp[1]:7C90E514 sp[11]:80544CFD)
011900A6: F0->25 [x86:01198F18] (sp[0]:7C90E514 sp[1]:00B700B6 sp[11]:0006FFC8)
011900A4: CF->25 [x86:01198F18] (sp[0]:00B700B6 sp[1]:00000246 sp[11]:865FC370)
011900A2: CF->25 [x86:01198F18] (sp[0]:00000246 sp[1]:00B500B4 sp[11]:FFFFFFFF)
011900A0: 25->25 [x86:01198F18] (sp[0]:00B500B4 sp[1]:EF9353B9 sp[11]:7C839AD8)
0119009E: FD->25 [x86:01198F18] (sp[0]:EF9353B9 sp[1]:C49DA64B sp[11]:7C817080)
0119009C: 25->25 [x86:01198F18] (sp[0]:C49DA64B sp[1]:7C817077 sp[11]:00000000)
...
.. cut ..
...

(Instruction 0x25 should be pop rx)

Now by looking at the execution flow I could see that opcode 0x07 was very interesting.

010DFD3C: 19->07 [x86:01198C5A] (sp[0]:010D432E sp[1]:0006FF88 sp[11]:7C91BEC2) lit:00000000
01194772: 19->07 [x86:01198C5A] (sp[0]:01195873 sp[1]:7C800000 sp[11]:0006FA08) lit:00000000
01194772: 19->07 [x86:01198C5A] (sp[0]:01195873 sp[1]:7C800000 sp[11]:0006FA08) lit:00000000

Oh and btw. My debugger reads the original byte code and looks it up in my opcode table to find the
first entry of that opcode. For opcode 0x19 we can see that it is the same as opcode 0x07.

So it looks likes opcode 0x07 is a call out of vm function so lets look closer at this instruction.
Whenever this instruction is executed I dump vmprotects stack (Ebp)
So now I run the code without printing every instruction but only instruction 0x07.

Opcode 0x07 stack log
0 ( 1) f(010D432E) (0006FF88, 010D29DB, 00530057, 000066FF).. time 00000000 ticks
1 ( 1) f(01195873) (7C800000, 0006FF78, 010D073B, 00530057).. time 00000000 ticks
2 ( 2) f(01195873) (7C800000, 0006FF78, 010D50DE, 00530057).. time 00000000 ticks
3 ( 3) f(01195873) (7C800000, 0006FF7C, 010D1E42, 00530057).. time 00000000 ticks
..
18 ( 1) f(0118DC2B) (010DA75D, 01001000, 00530057, 000066FF).. time 00000006 ticks
19 ( 2) f(0118DC2B) (010E0EAA, 01009000, 00530057, 000066FF).. time 00000000 ticks
20 ( 3) f(0118DC2B) (010E20E5, 0100B000, 00530057, 000066FF).. time 0000009E ticks
..
335 ( 1) f(01018870) (01000000, 00000001, BB1606C4, 00530057).. time 00000070 ticks
336 ( 2) f(7C801AD4) (01001000, 00007748, 00000020, 0006FF98).. time 00000000 ticks


So opcode 0x07 calls x86 code and then returns back to VM. Code that is executed is f(xxx)

After a full run again we can see what functions are called. I could easy find LoadLibrary
and GetProcAddress by looking at the stack.
I do not find the number of argumens that every function is using so I always print out 4 of them.
It is also easy to see that function f(0118DC2B)(src, dst) will unpack/decode data to the original section.

Call out function count:
010D432E (10) LoadLibrary
01195873 (312) GetProcAddress
7C80B475 (1)
7C810800 (1)
7C810B17 (1)
7C80943C (1)
7C80B9A5 (1)
7C80BA14 (1)
7C809BE7 (2)
7C801AD4 (2)
0118DC2B (3) Copy/Unpack data
7C809A2D (1)
01018870 (1)

So after some time this vm will exit and jump into the program's code section like all packers usually does.

Last opcode executed before jump to code section:
0103F39A: 12->12 [x86:01199B6D] (sp[0]:0006FF88 sp[1]:00000286 sp[11]:010A8244) lit:00000000
0103F399: FD->25 [x86:01198F18] (sp[0]:00000286 sp[1]:00000286 sp[11]:010A8244) lit:00000000
0103F397: 1E->1E [x86:01198739] (sp[0]:00000286 sp[1]:E108B29A sp[11]:01007568) lit:00000000
0103F395: 78->59 [x86:011993C1] (sp[0]:0102E07B sp[1]:00000286 sp[11]:010A8244) lit:00000000

So opcode 0x59 is the last instruction and is probably the exit vm function.
This should execute the code at location stack[11].
(Every vm's I have looked at have this address at stack location 11)

Opcode 0x59 stack log
01007568: f(010A8244) (0103CDF1, 01001898, 00000070, 7C817077)..

Here we can see the return address (01007568) after the function is called like a standard API call.

Function 010A8244 will decode the x86 registers and jump to 1007568.
When I follow this code I can see some small function that is executed before the coe jumps into a new vm again.
We can do the same thing for the new vm and analyze it at a higher level before diving downt and decode every instructions.


So by looking at this analyze it looks like the first vm will prepare all sections in the program and then unpack/decode them.
After this the vm will look up imports I guess and then jump to the code section.
GetProcAddress was called 312 times for 10 dll's.
The 0x7Cxxxxxx is DLL calls but I did not bother to look them up.

Hope this will help some to get a better overview of what giong on in the vm.

Oh and also. Sorry for my bad english and my typos.
Reply With Quote
The Following 4 Users Gave Reputation+1 to For This Useful Post:
Conquest (09-26-2014), DMichael (09-26-2014), niculaita (09-26-2014), tonyweb (10-04-2014)
  #4  
Old 09-26-2014, 03:40
niculaita's Avatar
niculaita niculaita is offline
Family
 
Join Date: Jun 2011
Location: here
Posts: 1,342
Rept. Given: 947
Rept. Rcvd 89 Times in 61 Posts
Thanks Given: 4,282
Thanks Rcvd at 479 Times in 338 Posts
niculaita Reputation: 89
no virtual exe but virtual os: can somebody show how to change vmware virtual machine hardware parametres like bios, hdd volume, CPU etc ? I would realy apreciate that!
Reply With Quote
  #5  
Old 03-30-2018, 12:48
unn4m3D_BR unn4m3D_BR is offline
Friend
 
Join Date: Mar 2012
Location: Inside any debugger
Posts: 12
Rept. Given: 27
Rept. Rcvd 0 Times in 0 Posts
Thanks Given: 33
Thanks Rcvd at 6 Times in 4 Posts
unn4m3D_BR Reputation: 0
vmprotect v3.xx

Thank you guys for sharing this information. Are there any updates regarding vmprotect v3.xx?

I've been looking for a tutorial on manual unpacking vmprotect v3, so I can understand it better, but no luck.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT +8. The time now is 18:48.


Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX, chessgod101
( 1998 - 2024 )