Inside Code Virtualizer

by scherzo - [email protected]

February 16, 2007

1
Contents

1 Introduction 3
1.1 About Code Virtualizer . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 About this article . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 The Virtual Machine - Light VM 4

2.1 The Virtual Machine itself . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Generating the Virtual Machine . . . . . . . . . . . . . . . . . . . 6

3 The Virtual Opcodes 9

3.1 Disassembling and "Assembling" again . . . . . . . . . . . . . . . 9

3.2 Generating and Writing the Virtual Opcodes . . . . . . . . . . . 14

3.3 Completing the analysis: why does this really work? . . . . . . . 18

4 How to Make an Unpacked version of Code Virtualizer Full 22

5 Hopes for the Future and Acknowledgments 24

5.1 Why write this article? . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2 The general attack approach . . . . . . . . . . . . . . . . . . . . . 25

5.3 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

DISCLAIMER

ALERT: THIS ARTICLE MUST BE USED ONLY FOR SCIEN-

TIFIC/STUDY PURPOSES. THE AUTHOR OF THIS ARTICLE
IS NOT RESPONSIBLE FOR ANY USE OF THE KNOWLEGDE
DESCRIBED HERE FOR ILLEGAL PURPOSES. YOU DO ARE
ONLY ALLOWED TO READ THIS ARTICLE IF YOU AGREE
WITH THIS DISCLAIMER.

2
1 Introduction

1.1 About Code Virtualizer

Code Virtualizer is a powerful code obfuscation system that helps developers

protect their sensitive code areas against Reverse Engineering. Code Virtualizer

has been designed to enact high security for your sensitive code while requiring

minimal system resources.

Code Virtualizer will convert your original code into Virtual Opcodes that

will be only understood by an internal Virtual Machine. Those Virtual Opcodes

and the Virtual Machine itself are dierent for every protected application,

avoiding a general attack over Code Virtualizer.

Code Virtualizer can protect your code in any x32 and x64 native PE les,

like executable les (EXEs), system services, DLLs, OCXs, ActiveX controls,

screen savers and device drivers[1].

1.2 About this article

First of all, I need to say sorry. Probably you will see a lot of mistakes because

of my english but I hope you will understand me.

This article aim to explain how Code Virtualizer works. During the last

month, I spent all my free time analysing the Code Virtualizer Demo 1.0.1.0

unpacked by softworm[2]. Fortunately, I nished my analysis and I can say

that this is the best software I have seen before. Not best in the meaning of

protection, but in the meaning of organization. This was the most pleasing

software I have analysed.

Three important things to notice are that the description and explanation

of the code disassembled by OllyDbg[3] is done in the code execution order.

Most things that I am going to say are applicable only for the 1.0.1.0 version

of Code Virtualizer. For comments on new versions, see "Hopes for the Future

and Acknowledgments. And I will not threat the 64-bit case.

This article is divided in three parts. Firstly I am going to talk about how the

3
Virtual Machine is generated and why Oreans[4] says that each Virtual Machine

has its own characteristics. Secondly I use the concepts described before to

explain how the Virtual Opcodes are generated, how they are executed and

why they emulate the original code of an application. The last part is a bonus:

you are going to learn how to make an unpacked version of Code Virtualizer

full.

Enjoy this article and I hope you learn something reading it.

2 The Virtual Machine - Light VM

2.1 The Virtual Machine itself
I think you have noticed that I called this Virtual Machine as "Light VM. Ac-

tually, not me but Oreans developers did that probably refering to the Themida

Virtual Machine.

Basically each Virtual Machine has 150 handlers and a main handler. By

handler, I mean a kind of function that will deal with the Virtual Opcodes.

In general, they are small (one to six lines of assembly code) and it is really

important to understand each one.

Next I will show the rst structure that I called Handler_Information and

an example of it (gure 1):

• WORD id // a number that represents the handler

• DWORD start // the address of the start of this handler in the Code
Virtualizer le

• DWORD end // the address of the end of this handler in the Code Vir-
tualizer le

• DWORD address // the address of the start of the handler in the protected
le

4
 • WORD order // random number from (0Eh to A4h) that will indicate the
place of the handler in the protected le

Figure 1: Handler_Information structure example

This structure is the principal one to generate the VM. I will not show

you each of the 150 handlers. This is tedious but if you want to study Code

Virtualizer deeper, you must read and understand one by one. I will show you

just the handler I showed in the gure above (gure 1; id = 0000h; start =

006035F0h; end = 006035F8h) and the main handler (gure 3):

Figure 2: Handler 0000h

Figure 3: Main Handler

5
 There is a particularity in the main handler: you can see three times the

DWORD 11111111h. They are dierent depending on the protected application.

The rst DWORD is the address of the seventh line of the main handler in the

protected le. The second one is the "image base" of the Virtual Machine. The

last DWORD is the total number of handlers in that VM.

2.2 Generating the Virtual Machine

Here I will give arguments to proof after that the phrase "Those Virtual Opcodes

and the Virtual Machine itself are dierent for every protected application,

avoiding a general attack over Code Virtualizer." is not a very important feature.

The rst step done by Code Virtualizer is to write the main handler. Next the

other 150 handlers will be written following the Handler_Information.order se-

quence from 1Eh to A4h. As Handler_Information.order is randomly generated

the result will be a dierence sequence of handlers for every protected

application (if you want an example, see [5]).
Now I am going to explain how the handler 0000h (see gure 2) is written.

The same process occurs for every handler.

The next step is showed by the code below:

Figure 4: LODS special case

This piece of code looks for LODS instructions. This is not applicable for the

handlers 0154h and 0156h. But why these checks? Well, the LODS instruction

in a handler represents the reading of 1, 2 or 4 Virtual Opcodes. And to increase

the security, Oreans developers insert random code after the LODS instruction.

To do that, they use another structure that I have called Special_Handler. Here

6
you are:

• WORD Handler_Information.id // see Handler_Information structure

• BYTE instruction3 // number that says what kind of instruction will be

written as the third instruction

• BYTE instruction2 // number that says what kind of instruction will be

written as the second instruction

• BYTE instruction1 // number that says what kind of instruction will be

written as the rst instruction

• BYTE instruction4 // number that says what kind of instruction will be

written as the fourth instruction

• DWORD Random1 // random number that will be part of the instruction

2

• DWORD Random2 // random number that will be part of the instruction

3

Table 1: Table of possible random instructions. Each of these instructions can

be written in DWORD, WORD or BYTE format using the respective registers
ax, bx, al, bl.

instruction1 instruction2 instruction3 instruction4

0 sub eax,ebx sub eax,Random1 sub eax,Random2 sub ebx,eax
1 add eax,ebx add eax,Random1 add eax,Random2 add ebx,eax
2 xor eax,ebx xor eax,Random1 xor eax,Random2 xor ebx,eax

Figure 5: Example of Special_Handler structure

So before those operations, the handler 0000h (gure 2) will be like this:

7
 Figure 6: Handler 0000h before addition of 4 instructions

The next step is another security feature. Some kind of instructions are

mutated by the Oreansf1.F4 function exported by Oreansf1.dll module. This

means that the code of each handler will be obfuscated and more, this mutation

engine is strictly related to the option Virtual Machine Obfuscation. Actually,

this option only changes the complexity of the mutated opcode. This is really

something strange because there is no dierence if the complexity of the VM is

low or highest in a general attack to Code Virtulizer (for more comments, see

"Hopes for the Future and Acknowledgments").

Figure 7: Handler 0000h with mutated opcodes

8
 Before that, a JUMP to the main handler is written so the next handler will

be called.

The next security feature is quite fun to see: all the 150 handlers are mixed

randomly!!! For example, a piece of the handler 0161h is followed by a piece of

the handler 0001h and the handler 0069h, etc...

So in the end there will be a complete obfuscated, unique and dicult code

to be analysed. Really! I do not think so :).

3 The Virtual Opcodes

3.1 Disassembling and "Assembling" again

I know that the things are obscure. You probably still have no idea about how

those handlers work but I promise that it will be clear in the section 3.3.

The gure below shows a macro not virtualized. The code that will be

virtualized starts at 0040106Eh and ends at 0040107Dh.

Figure 8: Macro not virtualized

Next a PUSH 0040108Dh and RET will be added to the original code so the

program can continue its execution normally.

9
 After that, the exported function Oreansf1.F1 disassembles the original code

as you can see below. It was really a surprise to me when I saw that; I hoped

that Code Virtualizer would threat the code through the bytes of the original

code not through strings. It uses Delphi functions to threat strings and I think

this is not the faster way but for sure it is easier.

Figure 9: Code disassembled

Now the function OreansX2dllR.F1 exported by OreansX2dllR.dll will do

the principal and most complex work of assemble the assembly code in a Code

Virtualizer syntax and generate the most important structure that I have called

OreansX2.

OreansX2 structure:

• DWORD instruction // type of instruction following the Code Virtualizer

syntax

• DWORD sux // sux for the instruction

• DWORD data1 // data for the instruction

• DWORD data2 // data for the instruction

10
• WORD unknown // unknown use

Table 2: Table of possible instructions for OreansX2 structure

OreansX2.instruction instruction
00 LOAD
01 STORE
02 MOVE
03 IFJMP
04 EXTRN
05 UNDEF
06 IMULC
07 ADC
08 ADD
09 AND
0A CMP
0B OR
0C SUB
0D TEST
0E XOR
0F MOVZX
10 MOVZX_W
11 LEA
12 INC
13 RCL
14 RCR
15 ROL
16 ROR
17 SAL
18 SAR
19 SHL
1A SHR
1B DEC
1C NOP
1D MOVSX
1E MOVSX_W
1F CLC
20 CLD
21 CLI
22 CMC
23 STC
24 STD
25 STI
26 HLT

11
Table 3: Table of possible instructions for OreansX2 structure (cont.)

OreansX2.instruction instruction
27 BT
28 BTC
29 BTR
2A BTS
2B SBB
2C MUL
2D IMUL
2E DIV
2F IDIV
30 BSWAP
31 NEG
32 NOT
33 RET

Table 4: Table of possible suxes

OreansX2.sux sux
00
01 ADDR
02 %sADDR, %d
03 %sADDR, %.8x%h
04 BYTE PTR %s[ADDR]
05 WORD PTR %s[ADDR]
06 DWORD PTR %s[ADDR]
07 QWORD PTR %s[ADDR]
08 %sBYTE PTR [%.8x%h]
09 %sWORD PTR [%.8x%h]
0A %sDWORD PTR [%.8x%h]
0B %sQWORD PTR [%.8x%h]
0C ADDR, BYTE PTR %s[%.8x%h]
0D ADDR, WORD PTR %s[%.8x%h]
0E ADDR, DWORD PTR %s[%.8x%h]
0F ADDR, QWORD PTR %s[%.8x%h]
10 %s%d
11 %s%.8x%h
12 reserved
13 reserved
14 reserved
15 reserved

12
 Table 5: Table of possible suxes (cont.)

OreansX2.sux sux
16 reserved
17 reserved
18 BYTE
19 WORD
1A DWORD
1B QWORD
1C reserved
1D reserved
1E FLAGS
1F %s[ADDR]
20 %sBYTE %d
21 %sWORD %d
22 %sDWORD %d
23 %sQWORD %d

As you can see, the syntax is quite logic. It uses XOR, ADD, etc. for

well known instructions and obvious names like MOVE, STORE, LOAD for

"special" instructions; the suxes use a single variable ADDR and well known

formats like DWORD PTR [ADDR].

I still do not understand completely how those instructions are generated

from the original code disassembled but I think that this is not a problem if

you do some tests to see the pattern. Next I show you one assembly instruction

followed by the equivalent block of Code Virtualizer instructions with their

respective OreansX2 structure (see the le [5] for more examples).

13
 Figure 10: Example of Code Virtualizer syntax

I do not know if you have noticed it, but the rst parameter of the rst

OreansX2 structure above is 80000002h. 02 means MOVE as you can see in the

Table 2, but this 80 means that this instruction has a relative address. That is,

the address F0000028h is relative to the image base of the Virtual Machine.

3.2 Generating and Writing the Virtual Opcodes

Having a vector of the OreansX2 structure, now a sequence of operations will

be done to reach the next structure that I have called Pre_Handler. The size

of this structure is 28h bytes.

• DWORD counter // counter that is incremented by 0Eh for each Pre_Handler

structure

• DWORD real_opcode_mark // this DWORD is the address of the orig-

inal opcode in an allocated memory. This is only applicable to the rst
Code Virtualizer instruction of the block of instructions that represent the
original opcode

• DWORD unknown1 // unknown use

• DWORD counter_0E // this the Pre_handler.counter plus 0Eh (unknown

use)

14
 • BOOL is_special // True if the original opcode is any kind of call, jump,
conditional jump and others. In this case, a special structure will be gen-
erated for those instructions

• BYTE instruction // Same as OreansX2.instruction

• DWORD sux // Same as OreansX2.sux

• DWORD data1 // Same as OreansX2.data1

• DWORD data2 // Same as OreansX2.data2

• WORD unknown2 // Same as OreansX2.unknown

• 7 bytes unknown

• BOOL is_relative_address // TRUE if the instruction has a relative ad-

dress

Figure 11: Example of Pre_handler structure

So now the principal structure that is directly related with the Virtual Op-

codes generation can be studied. I have called this structure as Handler.

• WORD handler // this is the principal parameter: it is the the one who
will determine what handler must be called. It is equivalent to Han-
dler_Information.id

• DWORD Pre_Handler_addr // address in memory of the correspondent

Pre_Handler structure that generated this Handler structure

• DWORD memory_opcode // memory address of where the Virtual Op-

code represented by this structure will be written

15
 • BYTE type_of_handler // 0 if the handler does not read Virtual Opcodes
through LODS intrscution. 1, 2, 4, 8 if the handler reads 1, 2, 4, 8 Virtual
Opcodes

• BYTE unknown2 // unknown use

• DWORD data1 // data for the Code Virtualizer instruction (like for ex-
ample LOAD 18h, data1 will be 18h)

• DWORD data2 // data for the case of 64-bit Code Virtualizer instrution

• DWORD le_opcode // address in the protected le of where the Virtual

Opcode represented by this structure will be written

Figure 12: Example of Handler structure

Each Handler structure can generate 1, 2 or 4 Virtual Opcodes and that is

a must to understand how the vector of Handler structures is generated.

This is not so complicated but if I put each case here, this article would be

too big. So I will just comment how this works and if you want more details see

[6].

Basically each vector of Handler structures starts with the handler 015Bh

and ends with the handlers 0161h and 015Ch. The handlers 015Bh and 015CH

do not exist actually. They are there just to tell Code Virtualizer that special

code must be inserted to handle when the execution of Virtual Opcodes is

initiated and when it is nished. This special code will be showed shortly.

Between those handlers the Pre_handler structure is threated like this: if

Pre_handler.is_special is TRUE, the handler 0161h will be added to the corre-

spondent Handler structure. After that, a dierent sequence of Handlers struc-

tures is generated for each of the cases: MOVE, LOAD, STORE, SHL, ADD,

16
SUB, IFJMP, RET, UNDEF and default case (for the others Code Virtualizer

instructions). You can see more details about those sequences in [6].

Having understood how the vector of Handler structures is generated, you

can nally understand the brilliant part of Code Virtualizer: how the Virtual

Opcodes are built.

The rst thing to say is about when Code Virtualizer nds the handlers

015Bh and 015Ch. There is a pre-built virtualized code (this means that the

Code Virtualizer instructions and the others structures are not there) that is

responsible to initialize and unitialize the Virtual Machine for example, catching

or returning the registers and ags before the protected application executes its

Virtual Opcodes.

So now I am going to talk about the generation of Virtual Opcodes given the

Handler structure. The rst thing that Code Virtualizer does is quite surprising.

Using a random number generator, it decides about the execution of a specic

CALL. This CALL is responsible to generate "fake" Virtual Opcodes. That

is, those Virtual Opcodes are going to be executed but they will not change

anything in the program (like a sequence of NOPs) and so they are useful to

obsfucate the real Virtual Opcodes. Besides, there are ve dierent sequences of

"fake" Virtual Opcodes diculting even more the analysis of the program. And

I say more, the option Virtual Opcode Obfuscation (low, normal, high, highest)

is strictly related (I meant only related) with these "fake" Virtual Opcodes.

Depending on that option, the chance of the random number generator allow the

recursively execution of the specic CALL more than one time can be increased

or decreased. So for example, in the middle of the emulation of a instruction,

there can be a lot of "fake" Virtual Opcodes. They can increase the size of the

Virtual Opcodes by a factor of 3!!!

Unless the "fake" Virtual Opcodes, you can say that the Virtual Opcodes

would be identical if you protect an application twice and compare the Virtual

Opcodes. What make them dierent, is a global variable in the Code Virtualizer

that I have called key.

17
 So if the handler 0010h must be called, given the Handler_Information.order

and the Special_Handler structure (see section 2.1 and 2.2 for the explanation

of these structures), the inverse operations of the ones described in Table 1 (that

is ADD, SUB, XOR) will be executed to reach the correct Virtual Opcode. The

things are a little confusing I think. So let's clear them.

3.3 Completing the analysis: why does this really work?

The aim of this section is to explain step-by-step the initialization of the Virtual

Machine and the execution of the Virtual Opcodes. To do that, I will use a

le that I prepare and that does not have fragmented handlers and mutation

engine[7].

When the protected application reaches a macro, the code is redirected to a

PUSH/JMP sequence in a section created by Code Virtualizer.

Figure 13: PUSH/JMP example

The value pushed is the address of the rst Virtual Opcode and the jump is

to the main handler.

18
 Figure 14: Virtual Opcodes

Figure 15: Main Handler

The code started at 004072D8h is always called before the execution of every

handler. It is responsible to call the handler specied by the Virtual Opcode.

The key is initialized with the the address of the rst Virtual Opcode and it

19
is stored in the EBX register. The ESI register has the current address of the

Virtual Opcode read and the EDI register has the Image base of the Virtual

Machine. The stack is used to store values and the EAX register is used for

operation like XOR, ADD, etc.

So when the code reaches the address 004072D8h, the registers are like this:

Figure 16: Register in the Main Handler

Now the byte 62h is read and after some operation with the key (those

random operations explained in the section 2.2; see gure 15), when the code

reaches the address 004072E4h, the registers are like this:

Figure 17: Jumping to handler 2Dh

As you can see, the key was changed and the ESI register was updated. Now

the code jmp dword ptr ds:[edi+eax*4] seems obvious: as EDI has the image

base of the Virtual Machine, the EAX value obtained from the Virtual Opcode

plus some operation is very important to call the handler if you notice that there

is a table of pointers to handlers:

20
 Figure 18: Piece of table of pointers to handlers

By now, you know how every handler is called and it is possible to explain

why the Virtual Opcodes are unique for every protected application: because

of the key. The key is changed a lot of times and it is address depedent. As the

Virtual Opcodes depend on the key (see section 3.2 for explanation) and the

size of the Virtual Machine is not constant, the Virtual Opcodes are unique.

The rst two instructions of the Main Handler (PUSHAD and PUSHFD)

push onto the stack the registers EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI

and the Flags. After, the pre-built Virtual Opcodes that I have talked about are

responsible to pop those registers in the rst 38 bytes of the Virtual Machine.

Now a instruction like XOR ECX, ECX will change the value in the address

00407014h. At the end of the execution of the virtualized code, the registers

are restored in their correct position allowing the application to continue its

execution.

Figure 19: Virtual Machine registers

Now that is your time. I will not comment every executed line. I gave you

the basis and I hope that the things are more clear now. So trace the example

21
program [7] and understand how the others handlers are executed.

4 How to Make an Unpacked version of Code

Virtualizer Full

This section is here because, I do not know if you remember that y from

unpack.cn released a version of Code Virtualizer Demo cracked, but his release

only allow the use of more Virtual Machines per application and does not allow

you to protect two or more macros with the same Virtual Machine. To clear

the things I did this section.

The rst thing you must know is where information about the protection

options are stored and how they are changed to restrict the use of Code Virtu-

alizer (yes, maybe you will not believe me but the custom options are there in

the demo version; big mistake:) ).

So here I show you the structure that keep information about the protection

options:

Figure 20: Data structure of protection options

• Virtual Opcodes Obfuscation: 0, 1, 2, 3 are low, normal, high and highest

respectively

• Virtual Machine Complexity: 0, 1, 2, 3 are low, normal, high and highest

respectively

• Number of Virtual Machines: the number from 1 to 5 indicates the number

os Virtual Machines that will be created

• Last Section Name: 1 if the name of the last section will not de changed

22
 or 0 in the opposite

• Strip relocations: 1 if the relocations will be striped or 0 in the opposite

Below you can see the how the demo version works (by the way, a patch of

NOPs solves the problem):

Figure 21: First patch

So now I can say that the restriction of only normal Virtual Opcodes Obfus-

cation and Virtual Machine Complexity are broken. There is still some patches

for the case of only one Macro per application.

Another important piece of code:

Figure 22: Virtual Opcodes generator function

And in the line 00609C82h, a NOP must be inserted:

Figure 23: Second patch

Change from JE to JMP to protect more than one time your application:

Figure 24: Third patch

23
 NOP this block of code to avoid the MessageBox Demo Limitation and the

only one Macro limitation:

Figure 25: Fourth patch

Change the JLE to JMP to allow you increase the number of Virtual Ma-

chines per application:

Figure 26: Fifth patch

Congratulations, you have the Custom 1.0.1.0 version of Code Virtualizer.

5 Hopes for the Future and Acknowledgments

5.1 Why write this article?

As I said in the disclaimer, the main purpose of this article is to transmit the

knowledge that I have learned to you. Besides that, I need to say that I intended

to write a tool instead of this article. And I have also started it but as I am not

a programmer I saw that with the amount of free time that I will have I would

not be able to write this tool.

So what I hope is that someone gets interest in writing this tool (just e-mail

me). I can help and even provide source code of what I have coded until now.

But be aware that this is not an easy work.

24
 An important thing to say is that this is a very resumed article. I mean

there is a lot of details that I omited (no time and so tired now to say them)

and others details that I did not notice. If you have any questions or if you saw

something wrong in my article or if you wants to improve this article just e-mail

me.

And my main hope is to see a similar article about the Themida Virtual Ma-

chine. Let me say, this would not be too dicult now before this article mainly

because Themida uses the same DLLs as Code Virualizer and because Oreans

developers themselves told us that Code Virtualizer is a version of Themida

Virtual Machine a little simpler (remember the Light VM ).

And a word for Oreans: this is really a great tool to protect sensitive code

areas but as you said not 100% safe (there is not anyone 100% safe). I think

there is not a similar one in the market too good as this one. Keep your good

job improving this software!

5.2 The general attack approach

So here I will comment my ideas about a tool to deal with Code Virtualizer and

how to threat new versions. The toll is divided in three parts:

• Preprocessing

 Get all information about the le using the PEheader

 Look for Virtual Machines

∗ Fill the VM class with information about the Virtual Machine

∗ Identify every handler

 Look for Macros

∗ Get the total size of the Virtual Opcodes

∗ Find jumps to the macro. This is the place where the original

code was

• Analysis

25
  Find the "fake" Virtual Opcodes and eliminate them

 Retrieve the Code Virtualizer instructions

 Analise them and retrieve the original code

• Posprocessing

 Save the original code in the correct place

 Correct the PEheader

 Save the le

The two most dicult things are to nd and identify each handler in the Virtual

Machine and to retrieve the original code from the block of Code Virtualizer

intructions.

For the rst thing I say, you have two options: study the mutation engine

and do reverse engineering (very dicult); or as the mutation engine does not

mutate all the opcodes I noticed that it is almost 100% possible to nd each

handler by their not mutated instructions.

For the second thing I say, you have two options: study how the Code Vir-

tualizer instructions are generated from the original disassembled code and do

reverse engineering (dicult); or do some tests with dierents kind of instruc-

tions and see the pattern. By the way, a hint is that a very well recognizable

handler is used always for every original instruction: the STORE FLAGS. This
makes the work of nd the number of original instructions easier.

This tool must support dierent versions of Code Virtualizer. As the struc-

ture of it does not change, you need to adapt a few things for example new

handlers, modied handlers, and other things.

A fun example: commands like ADD, XOR, SHL, etc. have in general three

handlers; one for the byte operation, one for the word and one for the dword.

But when I rst saw the three handlers for the SHL instruction I saw something
very strange:

26
 Figure 27: Code Virtualizer bug

But only in the version 1.2.0.0 we saw: "[!] Fixed Virtualization of "SHL

reg16, imm""[8]. Interesting, isn't it?

5.3 Acknowledgments
I must say a big thanks to people who helped me directly and indirectly to write

this article. So here you are:

• Melvill, Portuogral, forgetoz and Spec0p (CRKTeam): people really im-

portant to me. They introduced me to the Reverse Engineering and helped

me a lot. This article is especially dedicated to them.

• softworm: well... what can i say? Without his really good job, this article

would not exist.

• Ricardo Narvaja and CrackSLatinoS: really good tutorials

• The Reverse Engineering Community (the ones where I am active): Crk-

Portugal, ARTeam, Unpack.cn, Tuts4you, EXETOOLS

References

[1] Code Virtualizer Help File - Code Virtualizer Help.chm

27
[2] http://www.unpack.cn/viewthread.php?tid=5802&fpage=
1&highlight=code%2Bvirtualizer

[3] OllyDbg v1.10 by Oleh Yuschuk - http://www.ollydbg.de/

[4] http://www.oreans.com/

[5] ..\Annex\Example of Code Virtualizer instructions.rtf - this le is included

in the le Inside Code Virtializer.rar

[6] ..\Annex\Analysis of Code Virtualizer instructions - this folder is included

in the le Inside Code Virtializer.rar

[7] ..\Annex\handler.exe - this le is included in the le Inside Code Virtial-
izer.rar

[8] http://www.oreans.com/CodeVirtualizerWhatsNew.php

28