VIRUS-L Digest Thursday, 28 Mar 1991 Volume 4 : Issue 49
Today's Topics:
Re: Virus naming
Re:Mutation of Stoned/Implications for self check boot sectors(PC)
STONED Problems (PC)
Re: Unknown virus help! (PC)
Re: Integrity Checking, programs & system
Re: FPROT vs SCAN (PC)
WANTED: Best way to protect laboratory PC/XT & PC/AT clones? (PC)
WHALE virus (PC)
Azusa (PC)
VPCScan Demo Version (PC)
Stoned (PC)
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
---------------------------------------------------------------------------
Date: Wed, 27 Mar 91 09:52:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: Virus naming
[email protected] (David.M.Chess) writes:
> The trouble with hash codes, or dates, or anything else semi-automatic
> is that, when there get to be enough of them, the names start to
> become useless. At IBM, we tried to use number-names whenever
> possible early on, but the disadvantages became apparent after not too
> long. If there's a 453 and a 435 virus, for instance, it's Real Hard
> to remember which is which!
I agree, but there are two reasons for a virus name:
(1) To indicate in "human-friendly" terms roughly what it is, and
(2) To positively identify which virus it is.
In the first case, you usually aren't concerned if it is a slight
modification of a well known virus (so long as it does the same
things), and it is nice if there are just a few, easily pronounced
names to remember. To start with, that is what we had. Now, the system
is breaking down because there are so many, often minor modifications,
and a lack of communication or standardisation by anti-virus workers.
Having a lot of easy-to-remember but incorrectly applied virus names
is worse than useless. Hence my suggestion for a change.
Ideally, there should be a method of identification, given nothing but
the virus itself. So if people over the other side of the world also
find the same virus, you can definately say "yes, this is the same
virus" without having to send a copy of the whole thing. It would be
nice if such a method for positive identification also helped with an
easily remembered name as well. Well, that is possible (e.g. with my
CHECKOUT program), and it partly involves the "family plus number"
method you mentioned.
This is how it works...
You create a hashcode that consists of two parts (see my BOOTID
program), one part has bit-flags that identify certain good and bad
things the boot code is doing. Similar viruses get similar codes here.
If you can't be bothered working out what this part of the code means,
the CHECKOUT program has an option that explains it all in English.
The other part of the code is a seemingly-random code derived from the
bytes in the boot sector. Two viruses that are similar but slightly
different will get totally different codes, so this part is of little
use to us humans. But the total code can be used to look up a list of
known good and bad boot sectors. This would have a "popular name",
that hopefully is assigned carefully, perhaps by one person or
organisation. So, if it is a known virus, you get two things, the
hashcode plus a sensible name. If it isn't in the list of known
viruses, you just get a hashcode, the last 3 characters of which I, at
least, find easy to identify the basic type of virus from at first
glance.
Now, this hasn't been extended to other types of virus yet, but I have
a plan in mind, which puts more emphasis on what the virus does, and
less on the code it uses to get there, but it is still determined only
from the contents of the virus, rather than some obscure historical
fact that gave it a name. As I have said, there is still a place for
"family" or "generic" names for viruses, *but* it should be a lot more
organised than at present, otherwise there will be more and more cases
of confusion - which can be dangerous since some variations of some
viruses have to be handled very differently.
By the way, BOOTID and CHECKOUT are both free from
cantva.canterbury.ac.nz, 132.181.30.3, in the pc subdirectory. There
will be a new version released within the next week, with better
analysis facilities in the CHECKOUT program, and a slight change to
hashcodes produced by both programs, to allow for some types of good
(e.g. "virus-immune") disks that gave "worrying" results. Keep sending
suggestions, though!
Mark Aitchison, Physics, University of Canterbury, New Zealand.
------------------------------
Date: Wed, 27 Mar 91 13:14:00 +1200
>From: "Nick FitzGerald" <
[email protected]>
Subject: Re:Mutation of Stoned/Implications for self check boot sectors(PC)
In VIRUS-L Digest V4 #47:
"David.M.Chess" <
[email protected]> wrote:
>Pat Ralston <
[email protected]> writes:
>
>>Table" "Your PC is now Stoned! LEGALISE". Please note that Legalise
>>is NOT spelled with a Z as in other versions and is in all uppercase
>Now I'm taking an unusual (for me) risk here, as I'm at home with the
>tail end of a nasty cold, and can't verify it, but I'm Pretty Sure
>that the standard normal everyday Stoned virus spells the word with an
>"S" ("LEGALISE").
Yep - originating from New Zealand, where we speak proper English (
8-) ) the author of Stoned, like most New Zealanders (and probably
Aussies and the English themselves), spelled "legalise" with an "s".
Pity none of them read the Oxford English Dictionary, or any of the
standard references on "correct" English usage (this is a cryptic
comment, whose significance will be uncovered by the truly inquisitive
- - enjoy).
> . . . There are also many cases in which the word
>"MARIJUANA" has been overwritten (probably, I am told, by hard disk
>controllers that keep some data in an "unused" part of the master boot
>record, and overwrite that word in the process).
I have seen several copies of Stoned from various machines exhibitting
the munged legalise message, and often wondered what may be causing
it. I've also seen copies with apparently random bytes in the "free"
space between the end of the message and the bootable disk signature
bytes. If David is right, however, there are serious implications for
the "self- checking boot sector" type schemes that have been discussed
here recently. If some HD controllers cavalierly write to what they
assume is unused space in the MBR, change-checking boot sectors are
going to have a hell of a time.
David - are you thinking about the (I think) Zenith machines that
write the boot time and date in the MBR each boot up, or do you mean
something different?
- ---------------------------------------------------------------------------
Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
Internet:
[email protected] Phone: (64)(3) 642-337
------------------------------
Date: Wed, 27 Mar 91 13:25:00 +1200
>From: "Nick FitzGerald" <
[email protected]>
Subject: STONED Problems (PC)
In VIRUS-L Digest V4 #47:
Padgett Peterson <padgett%
[email protected]> wrote:
> Recently a number of people have mentioned STONED infections
>trashing hard disks & think that the following is why.
>
> Today, nearly every partitioning software aligns the partitions on
>even track boundarys for simplicity. Since the Partition Table resides
>on track (cyl) 0 head 0 sector 1, the balance of this track is usually
>left alone and the first partion starts on the next track. However,
>this is just convension and not a requirement. In fact FDISK 1.00
>which came with DOS 2.x began the first partition on track 0 head 0
>sector 2 and has no "hidden" sectors.
>
> Since DOS version 3.0 came out in 1984, the later convension has
>been followed and Norton's DI usually reports 17 "hidden" sectors (all
>of track 0 head 0).
Whilst Padgett's postings are usually very valuable, the above is a
little misleading. Some OEM versions of DOS (some of them still
labelled MS DOS) with version numbers 3.0 and above have versions of
FDISK that still begin the first partition at 0,0,2 - from memory, I
think Falcon DOS 3.1 is one such. This may give a tiny bit more
usable disk space, but causes grief after a Stoned strike.
> STONED does not bother to check and just copies the original
>partition table code to track 0 head 0 sector 7. No problem if this is
>a "hidden" sector but disastrous (to DOS) if not. THIS IS REPAIRABLE.
>
> DOS keep two copies of the FAT (which STONED just overwrote) and
>several utilities exist (Norton Disk Doctor is one) that will copy #2
>onto #1 if some utility (like CHKDSK/F) hasn't corrupted the second
>copy. It can also be fixed manually by someone with a bit of
>experience.
Unfortunately, this implies that recovering from Stoned on such a disk
is much simpler than it really (usually) is. FAT#2 is not "used" by
DOS, in that all DOS file allocation work is done on the basis of
FAT#1, but FAT#2 is maintained and updated by DOS. Not knowing
exactly how this is done, I just shelled back to DOS and did a bit of
FAT editing and file creation/ updating work and discovered that with
3.3 and a 20 Meg HD not all of the FAT is held in memory by DOS (not
surprising given that it is about 50 sectors - with floppies I think
all of FAT#1 is held in RAM). Any alterations to the file structure
are saved to both copies of the FAT, but only the modified sectors are
written out to disk. That last point is important - when the FAT is
updated not all of FAT#1 is copied to FAT#2, only the changed sectors
are copied. What this means for a Stoned HD is that if there has been
*NO* file creation, deletion, or updating that affects the area of the
disk *near* (sorry, can't be specific) the part of the disk that is
mapped by the 6th sector of FAT#1, you can recover from Stoned by
copying the sector at 0,0,7 (the original MBR) back to 0,0,1 and then
copy the sector in FAT#2 that corresponds to FAT#1's 6th sector back
to 0,0,7 (exactly which sector will depend on disk size, and possibly
on whether the disk has 12 or 16 bit FAT's).
So Padgett's recovery scheme only works if you happen to discover your
HD is infected between the actual infection (booting from an infected
floppy) and the first attempt to create or update a file, which
results in the 6th sector of FAT#1 being updated (at which point the
Stoned code is copied to FAT#2).
PLEASE NOTE: Whilst the FAT handling is the same, the above advice
about disinfecting a Stoned HD *ONLY* applies to disks which were
FDISK'ed with an "old" version of DOS - i.e. where FAT#1 starts at the
sector after the MBR. On other HD's it is usually just a matter of
copying the sector at 0,0,7 back to 0,0,1.
> Consequently, I suspect that those experiencing FAT-type problems
>had the misfortune to have a drive that was partitioned using "old"
>software and then became infected with STONED.
Yes, but note my rider above, about what is an "old" version of FDISK.
If your HD is defragged then recovery from Stoned on a system prepared
with "old" versions of FDISK is simple and relatively straightforward,
even if both FAT's do get corrupted.
- ---------------------------------------------------------------------------
Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
Internet:
[email protected] Phone: (64)(3) 642-337
------------------------------
Date: 27 Mar 91 09:50:06 +0000
>From:
[email protected] (Fridrik Skulason)
Subject: Re: Unknown virus help! (PC)
[email protected] (***CURTIS***) writes:
>Hello all.
>
> I have a little problem with my 386 PC. A few days ago I had
>the Jeruselem B virus on my machine (it's going ripe round here). II
>got rid of it but somehow it kept coming back.... (I know about the
>memory resident thingies etc etc) In the end I got rid of it.
Hm...maybe I should have replied directly by mail, but there are a few
points which might be of interest to other readers of the newsgroup,
so...
You do not say which scanner you used, but at least I know it is not
my own, as it will display a different message when infected. :-)
The reason iy "kept coming back.." might be that some program with an
extension other than .COM or .EXE was infected, and the scanner only
scanned "normal" executable files, not overlay files, for example.
Another possibility is that you have an infected file which has been
compressed (PKLITE or LZEXE) after being infected, as most scanners
will not be able to detect viruses in compressed files. When
something like this happens, it is generally advisable to scan all
files, just to make sure.
>Yesterday, I ran my virus checker from hard disk. It came up with the
>warning "Virus checker Infected. Do not use"
Three possibilities here - A: The file had been infected and disinfected,
but the disinfection might leave 1-15 extra
bytes at the end.
B: The virus had damaaged the file when infecting
it - which happens in <5% of Jerusalem
infections - Disinfectin may not be able to
detect the damage in all cases.
C: The file is just normally infected.
>So I ran the write-protected version I had on floppy, No virus's found.
This might indicate a hidden virus (overlay, or packed as I
mentioned), and just a damaged scanner.
>Next I copied the virus checker from floppy to HD and ran it.
This clearly indicates you have an active virus in memory at that
point - and an infected scanner. As the scanner did not detect any
virus, there are two possibilities:
A: A new virus - or a lousy scanner :-)
B: A "stealth" virus, which the scanner will not find in the files,
unless you boot from a "clean" system diskette before scanning.
However - it is very unlikely this is a "stealth" virus, as the virus
scanner would then probably not have been able to detect any changes
to itself.
>It, again, said it had been infected. On further investigation I found
>that whatever I had was appending itself onto the end of the file, around
>10-15K worth. However, the virus only appends to a file once.
If you see the file increase happen, you don't have a "stealth" virus,
but this is a bit strange as 10-15K in one chunk does not indicate a
Jerusalem is involved - actually there are very few viruses in that
range, and I suspect a new one - the 40th this month :-(
I would strongly suggest sending a sample to the anti-virus people active
on comp.virus.
>Has anyone out there got a good virus killer (shareware of course!)
>that they could arc and mail me??
Well, I have one - I wrote it :-) but I am not sure what is causing
your problems - if it is a new virus, my scanner will not be of much
help, until I have updated it.
If your scanner is just unable to detect the virus, you might try a
different scanner, but "10-15K" might indicate a new virus.
- -frisk
Fridrik Skulason University of Iceland |
Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion
E-Mail:
[email protected] Fax: 354-1-28801 |
------------------------------
Date: 27 Mar 91 10:21:27 +0000
>From:
[email protected] (Fridrik Skulason)
Subject: Re: Integrity Checking, programs & system
padgett%
[email protected] (Padgett Peterson) writes:
>> SCAN does have an "internal" self check, but if a "stealth" virus is
>>active in memory, it will defeat any kind of integrity check.
>
>NO ! It will not defeat "any kind of integrity check" though "stealth"
>will defeat SCAN's if the /nomem switch is in use (wish we had italics) While
>the "stealth" seen so far will defeat a program integrity check, it will NOT
>defeat a system integrity check (the six bytes).
I don't mean to be insulting, but I have said it before, and I will
say it again: The six-byte check is no sustitute for a full system
integrity check! Athough it will detect most wiruses, it will NOT
detect them all, in particular it will miss some "stealth" viruses,
like the "Number of the Beast".
The method will also miss viruses like Saddam, Do-Nothing, Micro-128
and all non-resident viruses. Worse, it will "detect" all TRS
programs, even programs like PRINT.COM
However, my main point is this - it is possible to make a program
integrity check which will detect infection by all "stealth" viruses
known today, and (I hope) tomorrow's viruses as well.
I cannot go into details, but I do have a working program which is
able to do this - more details next month.
- -frisk
------------------------------
Date: 27 Mar 91 10:38:25 +0000
>From: adlacy%
[email protected]
Subject: Re: FPROT vs SCAN (PC)
I use both F-PROT and the McAfee suite.
I used John McAfee's virus s/w for a while before F-PROT. Up till then
I had found nothing to beat it.
Fridrik Skulason's F-PROT is fantastic. But it has some problems.
I use F-DRIVER.SYS as I find it quicker on my XT than VSHIELD
(although VSHIELD has the added protection of refusing to warm boot
off an infected floppy).
However SCAN is better than F-FCHK, as it is much faster. [Note I do
NOT know which scans for more viruses]
I use F-DISINF to disinfect Boot Sector Viruses...it's faster than clean
generally...but I use CLEAN to cleanup file viruses.
I also use F-LOCK and F-POPUP to protect against unknown viruses and
trojans [as they look out for funny stuff like direct writes to disk,
and deleting locked com/exe files..etc.]. I have found a small problem
with these unde DESQVIEW v2.3 in that when you tell it shut off for the
duration of the running program, they sometimes do just that...or they
sometimes shut off for as long as I keep the DOS window open under DV.
As I say...a small problem, as if I did suspect something I wouldn't
test it Desqview in the first place...and I usually do test EVERYTHING I
d/l v. thoroughly before running.
cheers, Andy!
------------------------------
Date: 27 Mar 91 11:19:31 +0000
>From:
[email protected] (A J Annala)
Subject: WANTED: Best way to protect laboratory PC/XT & PC/AT clones? (PC)
We have about 30 IBM PC's (some stand alone two floppy systems, some
stand alone hard disk systems, and some connected via DE-100 and 3C501
cards to thick wire ETHERNET) in our laboratory. One investigator
found a virus -- yet to be identified on his home computer -- we are
now somewhat panic'd & very curious about how best to protect our
laboratory computers. We have obatined a copy of McAfee Associated
VIRUSCAN Version 6.9V75 from computer center. Is this product
adequate protection -- or should we invest in one of the regular
commercially distributed products (e.g. Norton stuff)? My background
as an old time computer center manager doesn't really help much here.
Perhaps someone would be kind enough to offer some general advice.
Thanks, AJ Annala
------------------------------
Date: Tue, 26 Mar 91 22:15:55 -0500
>From:
[email protected] (Stephen E Turpin)
Subject: WHALE virus (PC)
Does anyone have information or a cure for the WHALE virus?
Apparently, it writes a large file to your disk until the disk is
unusable.
Thanks.
Steve Turpin
------------------------------
Date: Wed, 27 Mar 91 11:31:48 -0500
>From: Padgett Peterson <padgett%
[email protected]>
Subject: Azusa (PC)
It seems that quite a few folks are getting hit by the AZUSA
virus. Removing it, while not very difficult, is complicated by the
fact that the virus has completely overwritten the master boot record
code so that the original cannot be simply retrieved from another
location as with most such viruses (STONED, JOSHI, etc). Since the
virus has also overwritten the ASCII warning messages, simple patching
of the virus code to remove the infection is not a good solution.
The virus does contain the essential partition table
information from the uninfected code in the proper offset (BE - FD) so
removal of the virus requires the following steps:
1) Obtain a "good" master boot record from the same DOS version or
higher.
2) Cold boot the infected machine from a write protected floppy
3) Extract the partition table information from the virus
4) Graft the partition table into the uninfected MBR code
5) Overwrite the virus with the composite MBR code.
The following assembly language fragment can be used to
perform this function. It assumes that a "good" MBR has been loaded
into offset 200h-3FFh and that the infected PC has been cold-booted
clean. (DEBUG format).
MOV AX,0201 ;read a sector
MOV BX,0400 ;into offset 400h-5FFh
MOV CX,0001 ;MBR
MOV DX,0080 ;fixed disk
INT 13
CMP WORD PTR [03FE],AA55 ;make sure it was read
JZ 0118
JMP 013C ;exit with ERRORLEVEL if not
PUSH CS ;align segment registers (0118)
POP DS
PUSH DS
POP ES
MOV SI,05BE ;point si & di at table areas
MOV DI,03BE
MOV CX,0020 ;40 bytes = 20 words
REPZ
MOVSW ;put table into clean MBR
MOV AX,0301 ;write one sector (0127)
MOV BX,0200 ;from the "good" area
MOV CX,0001 ;to MBR
MOV DX,0080 ;of infected disk
INT 13 ;we could read it before so
JB 0127 ;try again on failure
MOV AX,4C00 ;exit ERRORLEVEL zero (pass)
INT 21
MOV AX,4C01 ;exit ERRORLEVEL one (fail) (013C)
INT 21
Padgett
ps - fiddling at this level is not for the inexperienced, caveat y'all.
------------------------------
Date: Wed, 27 Mar 91 11:49:57 -0700
>From: Chris McDonald <
[email protected]>
Subject: VPCScan Demo Version (PC)
As a registered user of Ross Greenberg's program Flu-Shot+, I received
a demonstration version of VPCScan of the commercial program Virex-PC
bundled within version 1.8 of Flu-Shot+. I used the demonstration for
several days, and then purchased the full commercial product.
Since I routinely evaluate security-related software products for my
agency, I had occasion to run the demonstration version on Tuesday, 26
March since I wanted to compare its feature against the actual
commercial product. I received the following message prior to the
execution of the demo: "This demonstration expires in 6 days." This
morning I ran the demo again, and the counter was down to "5 days". I
am waiting with anticipation to see what happens on April 1st.
I must note that the read.me file contained within Flu-Shot+ which
described the demo at no time indicated a shelf life. In fact, the
file states: "This demo may be distributed freely, but may not be sold
without the express written permission of Microcom, Inc. and Ross M.
Greenberg." I have no objection to someone offering a demo, or in
encouraging that someone "freely" distribute it under the vendor's
instructions.
I would think that it sure would have been nice to have included some
type of statement in the read.me file alerting REGISTERED, fee paying
customers of Flu-Shot+ of the demo's expiration date--particularly
when it appears April 1st is the drop-dead date.
Since I know Ross has access to this forum, I would simply like to ask
if this was a designed feature on his and Microcom's part, or whether
I perhaps have a "hacked" version of Flu-Shot+.
Chris Mc Donald
[email protected]
------------------------------
Date: Wed, 27 Mar 91 15:17:47 -0500
>From: Padgett Peterson <padgett%
[email protected]>
Subject: Stoned (PC)
>From: Pat Ralston <
[email protected]>
>Subject: Mutation (or not) of Stoned (PC)
>Stoned can be found on floppy disks but not the hard disk.
There appear to be two cases in which the STONED will not infect a
hard disk: one has to do with an internal variable in the virus
(offset 8). The second is if the first four bytes of the master boot
record (absolute sector one) match those of the virus (EA 05 00 C0).
In this case, the virus "thinks" that the disk is already infected. I
have heard of several "vaccines" that perform this function. The
dangerous part is that the virus still goes resident in such a machine
and while it will not infect the fixed disk, it will infect floppies
presented to it. (some variants only 360k, some anything).
At least the STONED is easy to detect/get rid of.
Padgett
(we also walk dogs)
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 49]
*****************************************
Downloaded From P-80 International Information Systems 304-744-2253
