Hacker 2/HACKER2.mdf/virus/virusl2/virusl2.95

Text File | 1995-01-03 | 11KB | 268 lines

VIRUS-L Digest              Friday, 21 Apr 1989         Volume 2 : Issue 95

Today's Topics:
Administrative trivia
Reading the boot block (PC)
Virus disassemblies (PC)
Virus Cookbook for MS/PC-DOS (PC)
New document for anonymous FTP

---------------------------------------------------------------------------

Date:    Thu, 20 Apr 89 16:36:44 EDT
From:    [e-mail] (Kenneth R. van Wyk)
Subject: Administrative trivia

Just a bit of trivia for you all.  VIRUS-L turns 1 year old this
Saturday, April 22, 1989.  We're now up to about 1175 direct
subscriptions on the mailing list, and the comp.virus Usenet newsgroup
should be available shortly.

I think that, if nothing else, we've helped increase awareness.  That,
in itself, is progress.

Thanks everyone,

Ken

------------------------------

Date:    Thu, 20 Apr 89 20:32:42 CDT
From:    "Len Levine" <[e-mail]>
Subject: Reading the boot block (PC)

>From:         Peter Jaspers-Fayer <[e-mail]>
>Subject:      CheckSum Methods of Virus Detection (PC)
>
>No check is made of the BOOT sector.  Which brings me to the following
>questions:
>
>1) Does anyone have a similar program that DOES checksum the BOOT sector in
>   several sections?

The command:

debug <filetest.go >nul:

With the following contained in the file 'filetest.go':

- --- begin ---
L cs:1000 2 0 10
r cx
200
n c:\boot.blk
w cs:1000

quit
- --- end ---

will put the boot block into a file 'boot.blk'.  It uses the
system program debug.  I got this idea from the network from a
user Forrest Gehrke ([e-mail]).  Note that everything
from the 'L' in the first line to the 't' in 'quit' must be
included, especially the blank line before the 'quit'.  I used a
capital L for clarity, a lower case character works just fine.

The code does this:

  l cs:1000 2 0 10

This command will load the 10h sectors of the hard disk (2)
starting with sector 0 contiguously into memory starting at
location cs:1000.

  r cx
  cx:0000   (This is what the DEBUG will come back with.  That
             message will be lost if you use the >nul:
             command suggested.)
  :200      (You key in the 200  for the number of bytes
             you want to write).

  n d:\foo   (Naming filename FOO on drive d:)

  w cs:1000 (Write starting at address cs:1000)
            DEBUG will respond with a message saying it is writing
            200 bytes. That message will be lost if you use the
            >nul: command suggested.

  q         (quit DEBUG)

Any errors that I made are of course my own, not his.  The file
'boot.blk' can then be tested by the usual means.

Note that a virus that affects every read made from the disk,
detects an attempt to read the boot block, and passes you a copy
of the good boot block instead of the infected one, will defeat
this.  If so, a very well written virus was encountered.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

Date:    Thu, 20-Apr-89 17:11:42 PDT
From:    portal!cup.portal.com![e-mail]
Subject: Virus disassemblies (PC)

Earlier this month, Jim Goodwin gave me a file containing numerous
virus disassemblies and asked me to forward it to the researchers
subscribing to VIRUS-L.  I consulted with Ken van Wyk on this, knowing
that the distribution of virus disassemblies is a rather sensitive
issue.  Ken graciously offered to allow Jim to post a message to
VIRUS-L describing his virus disassemblies and explaining how to
contact him to obtain them.  The following is Jim's message:

 ---- start of forwarded message ----
Original-Date: 04/19/89 12:03:15
Original-From: JIM GOODWIN

Mr. van Wyk: I appreciate your position on the distribution of
disassembled viruses, and while we differ somewhat in our opinions on
this issue, it was very gracious of you to express your respect for my
own position.  I think we can gain a great deal from a detailed
analysis of existing viruses, both from an antiviral development
standpoint and from a psychological standpoint.  Much can be discerned
about the nature of a perpetrator's mind from an analysis of his code.
I have just finished the disassembly of the 1704 virus, for example,
and can now tell you quite a bit about the perpetrator of this virus.
The virus was surprising in a number of respects.  It has two levels
of encryption, which made it extremely difficult to disassemble, and
it has the most advanced activation mechanism I have yet seen in a
virus. The activation involves randomizations, tests for machine
types, tests for clock types and screen types, date checks and a host
of other parameters.  It is also the first virus I've come across
that will NOT infect a true IBM PC.  It will only infect clones.  The
code to test for the true blue IBM machine was quite simple, and
follows:

.     (Checks copyright at ROM address 0F000:0E008H)
.     MOV   CS:[BX+DS:161H],AX
.     MOV   CS:[BX+DS:163H],ES
.     MOV   AX,0F000H
.     MOV   ES,AX
.     MOV   DI,0E008H
.     CMP   WORD PTR ES:[DI+6], 4249H   ; Check 'IB'
.     JNZ   A_CLONE
.     CMP   WORD PTR ES:[DI+8],4DH      ; Check 'M'
.     JZ    KILLVIRUS

In spite of some creativity and ingenuity within this virus, there
were some telltale signs of a programmer that had done little "system
level" programming before.  The virus, for example, cannot infect any
file greater than 64K in size, and is unable to infect EXE files (only
COM files).  There is nothing inherent in the virus architecture to
prevent it, it simply appears that the designer was unfamiliar with
EXE header formats and felt uncomfortable with segment register
manipulations for large files.  Also, the designer's use of interrupts
1C and 28 appear to be very inefficient.  In spite of this, the virus
is effective at identifying itself (through an interrupt 21 link) and
avoiding conflicts with other memory resident processes. The telltale
key to the sophistication level of the programmer, however, was the
use of interrupt 21 for the infection process.  Using this interrupt,
almost any virus protection product will be able to stop it or detect
it.  We tried a number of products against it and they all worked,
even Flu-shot+, which is able to catch only the crudest of viruses.
So the designer was apparently unfamiliar with I/O techniques that
would avoid filter detection.  All in all it is quite a schizophrenic
virus.

In any case, I thank you for the opportunity to post this message
telling everyone that my virus disassembles (12 to date) are available
to select researchers.  They may obtain them by calling Mr. McAfee's
Homebase Virus board at 408 988 4004 and leaving me a message.

I have read, by the way, the Virus-L message log (provided by Gary
Tom) and found it of interest.  It seems that the work you folks are
doing meshes well with the research done by Mr. McAfee and his team in
California. They have been very helpful in logging infection
occurrences and collecting live viruses.  The Sentry program by Mr.
McAfee has also been invaluable in the collection process and should
be used by any team that is attempting to "trap" viruses in a large
host collection base (we have it in over 6,000 systems now and it has
caught us a total of 31 new viruses).  He has just made the program
public domain so there's no excuse for anyone not to use it.

I would also like to take this opportunity to thank Gary Tom for his
tireless assistance in forwarding information between us.

If I can be of any assistance in explaining any of the material that
you already have, then please feel free to contact me.

Jim Goodwin  From the Homebase Virus BBS

408 988 4004

 ---- end of forwarded message ----

I am mailing John McAfee's Sentry program to Ken in uuencoded ARC
format so that it can be considered for addition to the
lll-winken.llnl.gov and LISTSERV archives.  It is available for
downloading from John's Homebase BBS.  John also has a virus message
section on his BBS that he has recently opened up for public access;
VIRUS-L subscribers are invited to call up his BBS and check it out.

Gary Tom, Tandem Computers Inc., Cupertino, CA
[e-mail]
sun!portal!cup.portal.com!garyt

[Ed. Sentry is now on lll-winken.llnl.gov for anonymous FTP in the
file ~ftp/src/pc/sentry.arc.  Thanks!]

------------------------------

Date:    19 April 89, 10:43:20 EDT
From:    <[e-mail]>
Subject: Virus Cookbook for MS/PC-DOS (PC)

I have a problem. I would like to modify the behavior of a .EXE file
to solve it. I believe that the techniques for doing this are the same
as those which a virus might employ in its effort to infect such a
file.  "Infecting" .COM files is simple enough, but the particular
program I would like to modify is a .EXE file.

The program is TELIX, a pretty good little shareware communications
program which, to my constant irritation, does not support F11 and F12
on the enhanced keyboard. I can write the patch to fix the keyboard
problem, but I don't know how to infect the .EXE file with the
solution.

If one of you kind folks could tell me how a virus program propagates
itself to a .EXE file, I promise not to use the information for
unscrupulous purposes. (I'm not a mad scientist. I just want to
install a patch.)

                            Hopefully,
                            Jeff Clough

Programmer for the august body of the Computer
Center of Georgia State University.
[e-mail] or 404-651-4537.BELLNET

------------------------------

Date:    Fri, 21 Apr 89 08:38:12 EDT
From:    [e-mail] (Kenneth R. van Wyk)
Subject: New document for anonymous FTP

I've just placed the following virus paper on lll-winken.llnl.gov for
anonymous FTP:

Developing Virus Identification Products
by Tim Sankary

The filename is ~ftp/virus-l/docs/identify.txt.  Thanks, Mr. Sankary.

Enjoy,

Ken

------------------------------

End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253