586 lines
17 KiB
Plaintext
586 lines
17 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
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 <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> 1 junk instruction
|
||
Unused <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20><><EFBFBD> 3 junk instructions
|
||
Unused <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD> 7 junk instructions
|
||
Use dos interrupts <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20> <20> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 15 junk instructions
|
||
Unused <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 31 junk instructions
|
||
Prefetch traps <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 63 junk instructions
|
||
Unused <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 127 junk instructions
|
||
Int 3 generation <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 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 <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> random junk
|
||
Unused <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20><><EFBFBD> random hostility
|
||
Unused <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD> exe file
|
||
Unused <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20> <20> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> constant size
|
||
Unused <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 256 byte alignment
|
||
Down decryptor <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 16 byte alignment
|
||
Use displacement <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> Unused
|
||
No jumps allowed <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 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.
|
||
|
||
|