[Conquest]

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