VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Mutation Engines

Xine [1]
November 1996

[Back to index] [Comments]

Since I first heard about the idea of a Mutation engine I was interested to see the code that would explain how such a devious piece of code could work. I had taken apart several viruses, but most mutation engines due to thier nature are difficult to dissassemble. So after seeing other people's code I decide to try my hand at this type of coding. This article will illustrate the path I took in designing and building a Mutation Engine.

To start I will try to define what a Mutation engine is, its code that can be link or added to a regular program or virus that will:

  1. Encrypt itself as well as the program that is linked to it
  2. Create a Decryptor that will be run first before the main program
  3. Each Decryptor that it creates has a different signature

Ok, now lets explain the defination, a signature (when refering to code) is a piece of code that should be unique to that code. An example of this is the signature:

	EA 05 00 C0 07

Which is the hex code for

	jmp 07c0:0005

This (which some may reconize) is the first line of code for the Stoned virus though it is short piece of code, placing this piece of code in the first part of the boot sector use to cause many Av products to false alarm. (not tested lately)

Now a true mutation engine could alter this code to some other code that would accomplish the same thing, though this is possible it would make the engine huge. Mutation Engine writers have taken a easier way out they encrypt the main code and the engine then put a decryptor as the first thing that is run.

This means that the only signature that has to alter is the decryptor, this is the main type of engine that is created these days.

The first part of the creation process is to create a encryptor/decryptor that this should be fairly simply encrytion. I played with the standard xor/add/sub but they were spotted immeditaly by TBAV and F-prot as encrypted code. Since the main idea of a mutation engine is to fool both people and scanners this was not a good start. Well while reading the usenet group I saw a mention of a encryption that uses shl/shr. Many people may wonder if you use a shl/shr the leading bit or end bit is lost this is not true it is moved the carry flag. By simply adding this to the front or end of the register (or word) you can have reversible encrytion. Now TBAV will find most of these except for even number shifts like 2,4,8 while F-prot seems to miss most of these (only in heurstices and the /parnoid). (I was told this is because the shl 2,4,8 code can also be used as a quick multiply or divide, so tbav will not flag this encryption). So I soon had this as a decryption module

	mov bx,offset virus_code
	mov cx,4		;encrytion key
	mov ax,cs:[bx]		;get the word to encrypt
	clc			;not needed I was young forgive me
	shl 1			;ok so ax before this code is
				; ax 1000 0000 0000 0000 cf = 0
				;after the shl
				; ax 0000 0000 0000 0000 cf = 1
	jnc no_high_bit		;
	inc ax			;this simpy makes ax =
				; ax 0000 0000 0000 0001
	dec cx
	jcxz done_unencr	;ok done shifting it again
	jmp short again		;shift it again
	mov cs:[bx],ax		;Store the decrypted code
	add bx,2		; move our pointer
	dec dx			;track how much is left
	jnz decrypt


Ok, so there we have a decryptor now use a shr and you have the encryption routine (its in the code read it ;) ).

Ok now at this point I have a encryption engine that will fool TBAV and F-prot ( unless you use the f-prot /paranoid which the average user just does not do) but this is not a mutation engine. Well one simple mutation is to change the registers its a simple thing just requires some research that debug or a decent assembly book will show. All assemble instructions are built in a pattern take push ax which in hex is 50h or 1001 0000b now push bx is 53h or 10010 011b

note that the 3 last bits are they only thing that changes this follows through so that for the word registers

ax000 0
cx001 1
dx010 2
bx011 3
sp100 4
bp101 5
si110 6
di111 7

Ok so with some simple and/or instruction we can change the registers any other register of course we must not just randomly change registers we have to track which register we have use and make sure that we change all bx to cx.

This is where some people start to get lost because we start treating code we are going to run as data. Take this example:

	mov cx,0004		;b90400h


	db 0b9h			;10111 001 <- cx
	dw 0004

Now the mutation for this code might look like this

	mov ax,[shift_reg]	;
	and ax,11111000h	;this will isolate the mov
	or ax,00000111		;this would make the instruction
				;mov di

A better way would be to use a random number generator and get a number between 0-7 then OR that into it rather than the constant I used. Of course you must track what registers you use as you go.

Now using this technique we have a limited mutation engine and just so you do not forget F-prot still catches it. So the next simple mutation use a sorta undocumented form of the shl instruction.

	shl AX,1 D1 E0 1101 000 1 1110 0000 <-USUAL CODE
	SHL AX,1 D1 F0 1101 111 1 1110 0000 <-UNDOC

	SHL AX,1 C1 F0 01 <-UNDOC


Now the unuasual part while all of the above code does the same thing shift the bits in the AX reg left the ones with the F0h are not used by many assemblers. (Though I have read that a shareware Assembler may use these codes maybe to track code that was produced by it). Using the "undocumented" form will fool f-prot every time but the c1 f0 01 will flag tbav with (and I love this flag) " 1 found instruction that will require an 80186 processor or above" Like they have add no instructions to the code set after the 8086!! But for a virus generated code this would not be a flag you want. Since any flag that was not there before will cause a problem.

Ok so we have a simple mutation a reversible simple encryption and at least 4 forms of the decryptor code not including the mutation of the registers. The next part is to add do nothing or noise code. This is where careful creativity comes into play. Noise instructions or Do nothing bytes are instructions that actauly do, do something they just do not affect your code. NOP, XCHG AX,AX are some examples of do nothing code. In the early days of mutation engines and herustic scanners just adding nops and xchg code could make the virus unscannable. But as scanners improved they now will watch for such do nothing code, either ignoring it and seeing the real code or warning the user that there is code that serves no purpose but to hide a virus. Again I found that you could use some of these ideas say 1 or two nops in a row but too many and TBAV went to red alert. So I thought instead of using just one byte instructions why not have routines that called interrupts. just find ones that do not affect to many regs or put push regs code pop regs this way none of the real code is affected. An Example

	push ax			;1 get the shift flags only affects the
	mov ax,0200h		;3 ax reg so push it then pop it.
	int 16h			;2
	pop ax			;1

Combine all these ideas togther and you can have an interesting piece of code that will produce several differnt variations on the decryptor. Well thats about all for me. If your realy interested in fooling with making a mutation engine get ahold of of as many source codes as you can and examine them then attempt one on your own. Even if you fail in making a viable mutation engine you will understand them far better. I did not bother to make my code a true engine its an example thats all.

[Back to index] [Comments]
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! aka