Sign In
Create Account
Maybe some of you have interested about software like VMProtect, Themida or Exeshield.
These tools secure native x86 exes with several antidebugger protection and virtualize native code to vm bytecode. Virtual Machine bytecode as you know or not, is not supported by x86 debuggers so analisis of code is impossible. Steping over opcodes will trap debugger.
Look, this is simple exaple of Steping (f7 in olly) via obfuscated code. Let say you set memory break point on string somewhere in application data. Let it be BP on access. BP is taken and you see this in disassembly window:
02EB0000 - 00 04 FF - add [edi+edi*8],al
02EB0003 - FF 22 - jmp dword ptr [edx]
02EB0005 - 10 33 - adc [ebx],dh
As you check values in EDI, EDX or EBX, there is no address where you set the break point.
So, what happened?
These opcodes were executed not by procesor but via virtual machine.
The real VM codes was:
LOAD DWORD PTR [VM_EAX], VM_EBX
PUSH VM_EBX
...
As you can see, code looks totally different than you can observe via debugger.
This is the most annoying and the best method to protect your code.
But most famous vmizers have unpackers. Let say you you want to write your own vm.
This is hard task. At first you will need to write interpreter of x86 code.
Then you have to translate it to your own opcode set. Of course is not required.
Look, let say you will get PUSH EAX opcode from original source.
PUSH EAX is 0x50 byte.
Let say your translated VM opcode "PUSH VM_EAX" will be 0xFF600000000000 (7 byte long, i will explain later).
VM interpreter should read from stream every 7 bytes and analyze it.
So, vm read 0xFF600000000000, our "PUSH VM_EAX". VM needs to get vm_eax and push it to vm stack.
Propably code of this operand should look like this:
@INTERPRETE_PUSH_EAX
PUSHAD
MOV EDX, 0
MOV EAX, [VM_REGISTERS_TABLE+EDX*4] // let say VM_EAX is first dword at VM_REG_TABLE
MOV ECX, VM_STACK_ADDR
MOV DWORD PTR[ECX], EAX
ADD VM_STACK_ADDR,4 // dword++
POPAD
JMP @VM_INTERPRETER
But what with VM_JMP and VM_CALL? How to translate real, relative address to vm address with no corruption?
My way:
Use static size opcodes in vm, the longest documented opcode of x86 is 7 byte long.
Count all opcodes from start code section till end.
When you will translate x86 code, all relative and absolute jmps and calls like
this one
JMP 0xAABBCCDD change into JMP OPCODE_NUMBER_78765
As you can see, you will need to calculate where destination lead.
Then you can obtain address of vm operand like this NUMBEROFOPCODE*7, simple, isnt?
Alright, but our VM will work on operating system. We need to exchange data with kernel, shell itp.
In this case we need to make point of insertion of real x86 code.
Let say translate this CALL DWORD PTR [&<kernel32.Sleep>].
In VM, we need to obtain address of Sleep function. We can do this via VM handler, loadlibrary and getprocadress which is common for lot of VM's.
Then we need to put all VM_REGISTERS to real CPU registers, jmp to procedure, store CPU registers to VM_REGISTERS and back to intepreting vm bytecode.
CODE:
@INTERPRETE_CALL_DWORD_PTR
//PTR ADDR is stored in VM_OPERAND_LEFT
PUSHAD
PUSH VM_OPERAND_LEFT
CALL VM_GETREALADDR
PUSH EAX // RESULT library name
CALL DWORD PTR [&<Kernel32.LoadLibrary>]
PUSH EAX //Handle to library
PUSH EBX // RESULT proc name
CALL DWORD PTR [&<Kernel32.GetProcedureAddress>] // Adress will be stored in EAX
MOV VM_REAL_ADDR, EAX
;Here goes loop from VM_STACK and pushing it on real stack, we skip this
;Here goes loop which taking VM_REGISTERS to CPU registers
PUSH VM_REAL_ADDR // PUSH - RET used as CALL
RET
;Recover VM_REGISTERS
POPAD
ADD VM_EIP,7 // Theoretical
JMP @VM_INTERPRETER
I hope i help you in understanding how advanced protection work.
All codes are theoretical and may contain mistakes.
Thanks
