FOG
A polymorphic encryption algorithm
by Eclipse
Disclaimer:
I have made this mutation engine for fun purposes only.
It is made for use in viruses, but not as to promote any
intentional harm or damage on computer systems.
This engine is dedicated to those of you out there who find the
concept of replicating programs fascinating. Trojan and
destructive virus writers: Get a life.
USAGE: CODE MODIFICATION INSTRUCTIONS
1. Enter the statement "extrn fog:near, fog_init:near, rnd:near"
into your code in your code segment. Its not really necessary to
include the "rnd" part if you do not need a random number generator
in your code. You might also find it handy to include the switch
definition file (switches.inc) in your code.
Example (ideal mode):
......
.model tiny
.radix 16
ideal
segment code word
assume cs:code, ds:code, es:code, ss:code
org 100h
extrn fog:near, fog_init:near, rnd:near ;here
include "switches.inc" ;and here
......
or (MASM simplified mode):
......
.model tiny
.radix 16
.code
org 100h
extrn fog:near, fog_init:near, rnd:near ;here
include switches.inc ;and here
......
or (MASM mode):
......
.model tiny
.radix 16
code segment word
assume cs:code, ds:code, es:code, ss:code
org 100h
extrn fog:near, fog_init:near, rnd:near ;here
include switches.inc ;and here
......
2. Initialise fog. Do so by calling fog_init with the appropriate
parameters:
AH : Debugger hostility switches (see below)
AL : Junk generation switches ( ---"--- )
CL : General switches ( ---"--- )
CS:DX : Code to encrypt
SI : Size of code to encrypt
DI : Where in the decrypted code control should be passed.
eg. if execution starts at the beginning of the code,
DI = 0.
Note that this initialization could be done only once, f.ex. at the
installation of a TSR virus, and later only be called when there was
need for updating the information, typically changing from COM to EXE
mutation mode.
On return from fog_init only one register will have changed;
CX = Max size of decryptor and encrypted code. This
will be the amount of bytes to stealth if you
are making a stealth virus and have specified
constant code size (sw_const_s) or if you want
a tip of how much memory you gonna need for
encryption, otherwise ignore.
Example:
....
mov ah, sw_prefetch or sw_int3
mov al, sw_015_gi
;or more efficiently:
;mov ax, (sw_prefetch or sw_int3) shl 8 or sw_015_gi
mov cl, sw_const_s
mov dx, cs:[myoffset]
mov si, sizeofvirus
xor di, di
call fog_init
....
3. Mutate by calling fog with the following parameters:
ES : Free segment. This is where the mutated code will be put.
Must contain enough memory for the encrypted code
and decryptor. When you define high junk generation, the
decryptor can be rather ...errr... massive...
BP : Offset of code. Eg. if you write the mutated code to the
end of a COM file, then BP should be set to filesize+100h.
Example:
....
mov bp, ax
add bp, 0100
mov ax, cs
dec ax, (bufferneeded+0fh)/10h
mov es, ax
call fog
mov ah, 40 ;CX = number of bytes, DS:DX = buffer
int 21
....
4. Take note of the register values on return from the
fog mutation algorithm:
DS:DX = ES:0 = Buffer where decryptor and encrypted code will
be found.
CX = Length of decryptor and encrypted code.
All other registers are preserved.
USAGE: MEMORY REQUIREMENTS
When calling fog you should make sure that you have an
encryption buffer big enough to accomodate even the largest
decryptors + your encrypted code. On its most demanding setting
(sw_255_gi / sw_maxhostile) fog will require approximately 16k
of memory. If you use fixed file size, the memory required can
be even more massive. However, if you reduce the junk generation,
fog will need much less memory.
When you call fog_init, CX will return the maximum size (in bytes)
needed.
Note: Take a look on what I do in AirRaid. I steal a temporary
block of memory just to do the encryption, without allocating
it. This will work nicely most of the time.
USAGE: ASSEMBLY INSTRUCTIONS
Fog is written in TASM 3.0 (C) Borland Inc. and is designed
to work with tasm and tasm-compatible assemblers.
To use the fog object module in your code:
tasm /m3 myvir.asm
tlink (/t) myvir fog
If you select to assemble fog down from the source, you should
use
tasm /m3 fog.asm
before linking the resultant object module into your code.
-------------------------------------------------------------------
The code size of FOG in its present condition is 55Bh (1371) bytes.
-------------------------------------------------------------------
If you modify the source, assemble with TASM /m3 /l and take a
look on top of the lst file; there will be a constant named
fogsize - this is FOG's effective length.
TECHNICAL OVERVIEW:
Fog constructs its decryptor in a stepwise manner.
The flow of execution when encrypting can be summarised like this:
* Choose Initialization strategy
* Choose Crypt strategy
* Choose Base updating strategy
* Choose Loopback strategy
(Decryptor and encryptor are finished here !!!)
* Add a jump to starting point in code, often this will be just a JMP 0.
* Encrypt main code
* If some alignment or static code size is chosen, pad the encrypted
code until it has the right size.
* Set all registers according to the correct feedback values, and
return to caller.
STRATEGIES:
**** Init Strategy ****
This is done by randomly choosing registers for key, base and count
and generate MOV reg, imm16 instructions with the appropriate numbers.
Junk (if selected) will be filled in between these instructions.
**** Crypt strategy ****
The standard crypto instruction will be of the type:
( The / separates options that are used with equal probability )
RND 1..15 * (XOR/SUB/ADD CS:/DS:/ES:/SS: [BX/SI/DI]/[BX/SI/DI+disp16], imm16/reg)
RND 0..7 * (ROL reg,1)
The segment overrides DS:/ES:/SS: will of course only be created in
COM file mode, in EXE mode only CS: will appear.
So decryptors can look like this:
XOR SS:[SI+0490],FD81 + junk
XOR CS:[SI+0490],DX "
ADD CS:[SI+0490],DX "
SUB CS:[SI+0490],8755 "
XOR ES:[SI+0490],5886 "
ADD SS:[SI+0490],770B "
ADD DS:[SI+0490],0322 "
ROL DX,1 "
ROL DX,1 "
ROL DX,1 "
or like this:
XOR SS:[BX],DX + junk
At the same time as the decryptor instructions are generated, the encryptor
is inversely built in the encryptor buffer.
As you will have noticed, the key is always word sized.
**** Base updating strategy ****
Base updating instructions can be of the type:
ADD reg, 2/-2
or
SUB reg, 2/-2
or
DEC reg
DEC reg
or
INC reg
INC reg
**** Loopback strategy ****
Loopbacks will look like this:
LOOP ...
or
DEC reg
JNZ .....
(The above will only be used if backwards jump is less than 128 bytes.)
or
DEC reg
JZ 03
JMP ....
or
DEC reg
JZ 05
MOV reg, offset ....
PUSH reg
RET
There are many more ways to do this, of course, use your
imagination and add some.
STRONG POINTS:
* Cryptographic toughness
FOG utilises a powerful mutation encryption algorithm, making
the encryptors very variable indeed. Cryptanalysis is going to
be hard on this one, as there is between 1 and 15 random
xor/sub/add/rol operations with different keys on each element
to be encrypted. With the change of just one constant in the
enclosed source this number can be much increased.
* Junk instruction generation
The junk instructions, generically generated by FOG, includes
instructions of 1, 2, 3, 4, 5 and even 2*7 bytes, and FOG can
generate up to 255 such junk instructions between *each*
good instruction. I've had test decryptors varying between
20 bytes and 10k (!).
* Configurable
FOG is configurable in most aspects. Based on what you tell it, it
will behave very differently from configuration to configuration.
Examples:
1. mov al, sw_nogarb
call fog_init
This will cause FOG to generate short decryptors without any garbage
or debugger hostile instructions at all. Turning off garbage also turns
off debugger hostility, so any value in AH will be ignored. The
encryption will however be just as strong as before, and the decryptor
will still mutate.
2. mov al, sw_007_gi
mov ah, sw_int3 or sw_prefetch
call fog_init
This setting will cause FOG to generate between 1 and 7 junk
instructions between each good one. Randomly interspersed in
these junk instructions will be some debugger hostile instructions,
in this case int 3's and prefetch traps. The int 3's are just
bothersome when debugging, the prefetch traps will fool the unin-
telligent debuggers and some of those programs who try to auto-
matically decrypt the encrypted code; TbClean crashes spectacularly.
3. mov al, sw_255_gi
mov ah, sw_debug
call fog_init
This setting will cause FOG to generate medium to very big
decryptors, as there will be between 1 and 255 garbage instructions
between each good instruction. However, setting ah to sw_debug causes
the garbage generated to not contain any debugger hostility at all,
and *no encryption will be performed*.
4. mov cl, (sw_r_garb or sw_r_host)
call fog_init
This will tell FOG to ignore any settings of AH or AL, and randomly
choose a setting for itself. Thus the setting may be one of extreme
garbage generation and/or hostility or the opposite. Note that FOG
will behave according to this until next time you call fog_init, and
another random setting will be chosen. If used in a virus, his would
have the effect that samples of one generation could be *totally*
different from samples of another generation
5. mov cl, sw_const_s
call fog_init
This will cause FOG to generate decryptor+encrypted code of
constant size each time you encrypt. This will be of use for
stealth virus production. Fog manages this by padding all
encryptions up to the point where it's very unlikely that a
bigger decryptor will be created. Note that with high junk
configuration there often will be a nauseatingly huge pad area
at the end of files.
6. mov cl, sw_align16
call fog_init
Some people make viruses that need to be padded up to a paragraph
border, for self recognition or other purposes. With this setting
FOG will do that.
7. mov cl, sw_align256
call fog_init
Same as previous, but with 256 byte page borders.
* Generic programming
This engine is released with the commented original source code.
It's of course possible to improve the engine, and it's relatively
easy to do so around its current framework. For instance is the garbage
generation modular, by adding another module and updating the jump
addresses FOG will spew out the new instructions just as easy and
randomly as those included in the source. You may also note the
vacant switches, where you may add more configurable options.
One of FOG's strongest points is just this; by releasing the source
it will mutate not just decryptors, but with time also it's own
functionality.
WEAK POINTS:
* Decryptor obviousness
Decryptors generated with this engine do not have any mechanisms to
hide that they are decryptors (except junk). They do not generate
any codesequence to fool scanners into believing that this is a
legitimate program. Thus, heuristic scanners may smell a rat,
especially TbScan when FOG uses low junk/hostility settings.
TbScan detects the presence of a decryptor and sometimes succeed
to decrypt the encrypted program. On high junk/hostility settings,
however, TbScan mostly chokes and dies. The prefetch traps generate
much noise, in the sense that they mess with memory and cause TbScan
to whip out @, 1, D and U flags galore. On rare occasions they also
cause the program to terminate or even hang. I have included jmp
instructions in the standard set of functions from FOG, however
these sometimes generate TbScan @ and J flags.
* Scanning vulnerability
When high debugger hostility is chosen, FOG generates fixed
codesequences that might be scanned for, particularly the
prefetch traps. This might be something to have in mind.
* Huuuuuuge decryptors
As mentioned before, with high garbage settings FOG may generate
very large decryptors indeed. This may cause not only a considerable
file growth, but also a noticeable timelag upon decrypting.
* Statistical analysis vulnerability
There is a chance that FOG will be vulnerable to statistical analysis.
I have not performed any statistical computations on FOG's decryptors
myself, but I think this might be done. However, scanners will have
a hard time detecting *all* FOG encrypted viruses, due to FOG's
variability.
THE DEMO VIRUSES:
Enclosed you will find the source and executables of different
versions of AirRaid, which is the demo virus for this engine.
AirRaid is a non-destructive resident *.com infector, made
specifically for this purpose. Its lameness is also by intent.
It will infect any *.com file (of proper size) executed. Infection
marker is 'AR' at byte 4 and 5 in the file.
The different versions are made to demonstrate the easy way you
can configure the virus to do what you want.
Ver 1. Plain virus, Fog not attached.
Ver 2. Fog attached, configured to no garbage.
Ver 3. Fog attached, configured to 15 garbage instructions,
max hostility, fixed length
Ver 4. Fog attached, configured to random garbage, random hostility.
SWITCHES (as defined in the switches.inc file):
AH AL
Debugger hostility F E D C B A 9 8 7 6 5 4 3 2 1 0 Junk generation
Unused 컴컴컴컴컴컴컴� � � � � � � � � � � � � � � � 1 junk instruction
Unused 컴컴컴컴컴컴컴컴� � � � � � � � � � � � � 읕� 3 junk instructions
Unused 컴컴컴컴컴컴컴컴컴� � � � � � � � � � � 읕컴� 7 junk instructions
Use dos interrupts 컴컴컴컴� � � � � � � � � 읕컴컴� 15 junk instructions
Unused 컴컴컴컴컴컴컴컴컴컴컴� � � � � � � 읕컴컴컴� 31 junk instructions
Prefetch traps 컴컴컴컴컴컴컴컴� � � � � 읕컴컴컴컴� 63 junk instructions
Unused 컴컴컴컴컴컴컴컴컴컴컴컴컴� � � 읕컴컴컴컴컴� 127 junk instructions
Int 3 generation 컴컴컴컴컴컴컴컴컴� 읕컴컴컴컴컴컴� 255 junk instructions
CH CL
Internal switches F E D C B A 9 8 7 6 5 4 3 2 1 0 General switches
Unused 컴컴컴컴컴컴컴� � � � � � � � � � � � � � � � random junk
Unused 컴컴컴컴컴컴컴컴� � � � � � � � � � � � � 읕� random hostility
Unused 컴컴컴컴컴컴컴컴컴� � � � � � � � � � � 읕컴� exe file
Unused 컴컴컴컴컴컴컴컴컴컴� � � � � � � � � 읕컴컴� constant size
Unused 컴컴컴컴컴컴컴컴컴컴컴� � � � � � � 읕컴컴컴� 256 byte alignment
Down decryptor 컴컴컴컴컴컴컴컴� � � � � 읕컴컴컴컴� 16 byte alignment
Use displacement 컴컴컴컴컴컴컴컴� � � 읕컴컴컴컴컴� Unused
No jumps allowed 컴컴컴컴컴컴컴컴컴� 읕컴컴컴컴컴컴� Unused
That's all for now. Take a look at the enclosed demo virus, AirRaid,
to see how FOG can be used.
ABOUT THE AUTHOR:
I am a tertiary student from Australia's Sunshine State of
Queensland. My interests include Rugby League, Cricket and
low-level programming. Normally concentrating on visual and
audio demonstrations, I turned my hand to polymorphism due to
the unique challenge of that type of coding. I will only
continue to pursue my virus programming career while the field
remains interesting.
HOW TO CONTACT THE AUTHOR:
You can only contact me via my friend Qark, who is has internet
access unlike myself.
Included in the original package there should be 12 files:
FOG .ASM Fog source code
FOG .DOC This file
FOG .OBJ Fog object module
SWITCHES.INC Switch definition include file
AIRRAID1.ASM AirRaid ver. 1 source
AIRRAID2.ASM AirRaid ver. 2 source
AIRRAID3.ASM AirRaid ver. 3 source
AIRRAID4.ASM AirRaid ver. 4 source
AIRRV1.ZIP AirRaid ver. 1 samples
AIRRV2.ZIP AirRaid ver. 2 samples
AIRRV3.ZIP AirRaid ver. 3 samples
AIRRV4.ZIP AirRaid ver. 4 samples
Any other file is not acknowledged by me.
Eclipse.
Queensland, Australia, June 1995.
- VLAD #5 INDEX -