VIRUS-L Digest Thursday, 3 Oct 1991 Volume 4 : Issue 181
Today's Topics:
Re: Infectable Areas (PC)
IDE Drive Problems (PC)
BEACH.GAL.UTEXAS.EDU facelift!
Re:New virus (PC)
Re: Problems running F-PROT 2.0 on 386's (PC)
Re: Unencrypted scan strings
Help Virus-L re Netware infection (PC)
virus archives (AMIGA)
Re: Hardware vs. software (vs. public attitudes)
HELP with possible PC infection (PC)
DIR II Removal Information (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: Tue, 01 Oct 91 18:21:52
>From:
[email protected]
Subject: Re: Infectable Areas (PC)
>From:
[email protected] (Vesselin Bontchev)
>
[quoted from somebody a long, long time ago in a computer far, far away]
> > Other side comments: Mr. Bontchev mentioned that to his awareness
> > VirX was the only program which scanned inside of PKLite'd files
> > as well as LZEXE'd files... That's not true. McAfee Associates
> > places high import on the ability to scan inside of compressed
> > executables. PKLITE and LZEXE detection have been standard inside
> > our programs for some time now.
> Mr. Schweres is modest. McAfee's SCANV program was the =first one=
> to decompress and scan inside LZEXEd files, very shortly after LZEXE
> appeared. For a very long time, it was the =only one=. I'm surprised
> that Mr. Bontchev didn't remember this.
>Anyway, my original (and incorrect) claim was that as far as I know,
>only VirX is able to scan inside both LZEXE'd and PKLite'd files. It
>is the first program that was able to scan inside PKLite'd programs.
>As Morgan Schweres pointed out, now SCAN is able to do it too. I'm not
>quite sure about F-Prot, but know that Frisk intends to implement it.
>Yet another useless thing that the anti-virus researchers are forced
>to implement by their users... like the disinfection, for instance...
>:-)
As far as *I* know, VIRx (and the commercial VPCSCAN, part of the Virex
package) is still the only scanner to look inside of PKLITE files that
have been compressed with the "-e" (non-extractable) switch turned on.
Ross,
Author, VIRx and VPCSCAN
------------------------------
Date: Wed, 02 Oct 91 13:52:59 +0000
>From:
[email protected] (Nick DeGilio (x37505))
Subject: IDE Drive Problems (PC)
I`ve discovered a very nasty problem with various IDE drives and
I'm wondering if anyone else out there has seen the same problem.
We had problems with the filesystem on an iRMX partition disk and
originally thought it was our software that was writing sectors of
0xF8's to the filesystem on the disk. We eventually discovered the
problem was with the IDE drives during a reset.
If the controller is writing the disk and the disk receives a hardware
reset, the sector that the controller was writing is filled with 0xF8's.
The data (0xF8) was specific to the TEAC IDE drive(SD-340) and was 0xE7 for
the Connors IDE drives(CP3044, CP3084).
We duplicated the problem at work and on my machine at home using a simple
DOS program that continually writes to a specific cylinder on the drive
and pressing the system reset button.
I realize there is a small window at which time the sector being written
is not finished and may contain bad data (and a bad CRC), but I can cause
this problem 80% of the time. I cannot get this problem to occur on MFM,
RLL, or ESDI drives.
I was wondering if anyone out there has seem this problem at all and maybe
thought that a virus infected their system and caused 0xF8 (or 0xE7) to
be written on the disk.
I would be most appreciative of any feedback.
Thanks !
- -----------------------------------------------------------------------------
Nick DeGilio When in doubt, use brute force.
[email protected] -- Ken Thompson
70511,
[email protected]
- -----------------------------------------------------------------------------
------------------------------
Date: Wed, 02 Oct 91 10:01:00 -0500
>From:
[email protected] (John Perry KG5RG)
Subject: BEACH.GAL.UTEXAS.EDU facelift!
Hello Everyone!
First off, I owe everyone an apology. The anti-viral archives
on BEACH.GAL.UTEXAS.EDU have been less than spectacular for the past
several months. Without going into a lot of detail, the problem was
due to technical difficulties. But the situation has finnaly been
corrected! BEACH now has all of the latest popular anti-viral software
for the MSDOS and MACINTSH arenas. The file have been updated by
yours truly to all the latest versions of everything I could find. I
invite everyone to use BEACH for all of your anti-viral needs. We're
back on the air!
John Perry KG5RG |
[email protected] - Internet
University of Texas Medical Branch | PERRY@UTMBEACH - BITnet
Galveston, Texas 77550-2772
------------------------------
Date: Wed, 02 Oct 91 12:42:07 +0300
>From:
[email protected] (Shulman Ilya A.)
Subject: Re:New virus (PC)
> A new, fast moving, and very destructive virus has been
>reported from multiple countries in Eastern Europe. The virus uses
>a completely new technique for infecting and replicating and it
>cannot be easily identified or removed with existing anti-virus
>removers.
Naturally, this virus handles disk(s) device(s) driver(s) and then
handle 4 functions of device drivers ---- Build BPB,Ouput,Write,Write+Ver
In SU we have 2 anti-vir programms that cure this virus.
>The virus infects by first placing itself in the last cluster of
>host disks.
It's size is 1024 (1536 in memory) in this case he allocate 1-2 last clusters
due to disk structure
>It then modifies the directory entries for all
>executable files in the system so that the directory chains point
>to the virus. Then it encrypts the original pointers for the
>executable files and places the encrypted pointers in unused space
>within the directory area. The result of this is that
It infects files only when somebody want to access files/directory
Also it didn't infect files that has the small size, I checked 512,1024 and
2048 bytes, 512 and 1024 were free
>A disruptive characteristic of this virus is that if an infected
>system is booted from a clean floppy, none of the executable files
>can be copied from the system. Neither can they be backed up. If
>the system is not booted from a clean floppy, then the files can
>be copied and backed up, but the virus will copied along with the
>programs. It's a catch 22 situation. Additionally, if an infected
>system is booted from a clean floppy, and then a CHKDSK /F
>is run, then all executable files in the system will be destroyed.
also if you boot from the clean disk you can't copy any EXE or COM files
to diskette because when you try you'll copy only virus body due to
EOF in FAT (1 copy) in the last cluster
>The virus is also a stealth virus. While it is active in memory
>it is difficult to detect.
^^^^^^^^^^^^^^^^^^^^ actual size of the disk :-) but
you can detect virus very simple via:
1 insert protected flopyy disk to drive and try to delete files from
it. If virus is active then you don't get any error messages
N.B. on 3.5" disks some strange errors may be get such as
Devide Overflow
2 check last cluster in the 1 and 2nd copies of FAT if in first you found
EOF but in second not than it may be thesignal that those virus is hear.
>The Virus has been named DIR-2. It has been reported at numerous
>sites in Bulgaria, Poland, Yugoslavia and Hungary. We received our
>copy for analysis from Tamas Szalay in Budapest.
The virus has been named in SU ( as far as it appeared here in early summer)
as DRIVER-1024 (due to scheme of infection) or DIR but not DIR-2
Few Tips for anti-virus developer.
1 magic number (via files encoded) is the word at offset 33fh in virus body
eg in last (or pre-last) cluster. Then all you have to do is
scan via directory and on _EVERY ENTRY_ do
ROL magic,1
if you find COM or EXE file with some data at offset
DIRECTORY_ENTRY_STRUCT[14h] and DIRECTORY_ENTRY_STRUCT[15h]
(the last word in reserved area )
then you must xor this word with the magic word before rol magic eg
while(NotEndOfTheDirectory)
{
GetNextEntry
IF(COM || EXE)&&(LASTWORD NOT NULL)
{
/* Virus I think, but it will be better to check
LASTWORD means las word in the reserved area in DIR
first cluster of the file for virus before correct */
IF(CheckCluster)
{
/* virus in cluster */
xor LASTWORD,MAGIC
PutEntry
}
}
rol magic,1
}
that is simple block-scheme :-) to check and correct directory
in every directory you have to start decoding with original magic number
2 There were the situation when disk was infected and virus occypies not
the last cluster and not even near. That is why I think that there may
be situation when 2 or more copies of virus may be present on one disk
3 There were the situation when disk was infected but the last cluster
was empty in this situation it is possible to recover disk with analyzing
of file size and trying to restore magic. The percent of normal
recovering growth with the number of infected files in this directory
4 it is better to check all files on disk with the size 1024,2048 bytes
to check their for virus. As far as you can copy virus neither file
5 Also it is better to correct FAT to do 1 and 2nd copy equal for a proper
programms operation such as DiskEdit etc.
All questions are appreciated here.
Regards.
- --
/-----------------------------------|---------------------------------------\
| Ilya A. Shulman. | E-Mail:
[email protected] |
| Institute of Radio Engineering | :
[email protected] |
| & Electronics ACAD.Sci. of USSR. | phone :(7-095)203-17-16 |
------------------------------
Date: Tue, 01 Oct 91 22:25:22 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: Problems running F-PROT 2.0 on 386's (PC)
>Seems we are having trouble running F-Prot 2.0 on ANY 386 machines.
>Getting a "Cannot read drive C" error. Anybody else getting this?
There is normally ABSOLUTELY no problem in running the program on a
'386 machine. There is a problem on one specific version of DOS -
Zenith DOS 3.30-PLUS. If you are using that version I know of the
problem, if not I would like to hear more about your setup.
This version of DOS is able to use >32M partitions, but my program
assumed this was only true for DOS 3.31 and above. I think I have the
problem fixed, and version 2.01 whould work without problems,
I have not been able to test it yet, however - as I have been unable to
locate a copy of Zenith DOS 3.30PLUS in Iceland.
- -frisk
------------------------------
Date: Tue, 01 Oct 91 22:19:46 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: Unencrypted scan strings
> > one sample in which two tiny changes were made, one of which was
> > in the middle of one of our signatures.
My experience is pretty similar - I have several cases of pairs of nearly
identical viruses, where some minor changes have been made.
In some cases the changes seem to be the result of a random bit error,
as the resulting code does not "make sense". In other cases I find an
attempt to bypass some scanner, for example if the change involves
just swapping two instructions.
The frequency of these cases is low - only around 1% of the viruses I have.
In most cases where a virus is patched to produce a new variant, the changes
are more extensive - sometimes changing the activation dates, text messages
and even the function of the virus. These patched viruses may be 10-15% of
all viruses, but one usually just cannot determine whether some of the
changes were made to disable some specific scanners or not.
> It seems obvious: if a virus author wants to change his virus to
> avoid detection by some scanner, all he needs to do is rewrite it
> very slightly, then reassemble.
True, but you forget that many virus variants are not created by the original
author, but by someone else, who does not necessarily have access to the
source code.
> But the one thing that encrypting search strings *did* accomplish
> very well (until now) was preventing third parties from testing the
> scanners.
Huh ? What do you mean ? The availability of the search strings is not at
all necessary to test a scanner - you only need a large collection of
viruses, to see if the scanner generates any false negatives, and a huge
collection of "clean" software to see if you get any false positives.
I see absolutely no need for anyone but the developer of the scanner to
know which search strings are used, and I certainly don't see how they
help in "testing" the scanner.
- -frisk
------------------------------
Date: Wed, 02 Oct 91 16:39:00 -0500
>From:
[email protected]
Subject: Help Virus-L re Netware infection (PC)
Dear Virus-L
We have a Novell network running Netware 386 3.11 with about 160 people
currently online. We are also using Palindrome Tape Backup System, as I was
looking through the tape backup log TNA_LOG I noticed several errors in the
format of:
WARNING: 724 Possible VIRUS! Size change in: SYS:LOGIN/LOGIN.EXE.
I have run NETSCAN and SCAN #77 on my machine and the server but nothing is
detected. I have also run PcTools Virus Scan with the same results.
The file size has changed 956 bytes but the date and time are still the same.
Any ideas on what the problem is? Also these other files had the same error.
CONSOLE.COM, SLIST.EXE, LOGOUT.EXE, COLDBOOT.COM, SETERROR.EXE, PSERVER.EXE.
Thanks,
Joseph Tucker...
------------------------------
Date: Wed, 02 Oct 91 16:39:46 -0600
>From: Kevin Kadow <
[email protected]>
Subject: virus archives (AMIGA)
I can't seem to find the FTP site with the descriptions of AMIGA viruses
(e.g. infection vectors, harmful effects, effective countermeasures)
Specifically, I'm looking for info on the AUSTRALIAN PARASITE, which seems
to create a l/disk-validator file on the floppies it infects.
- --
[email protected] kadokev@iitvax (bitnet)
My Employer Disagrees.
------------------------------
Date: Thu, 03 Oct 91 11:08:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: Hardware vs. software (vs. public attitudes)
[email protected] (Fred Waller) writes:
> No scheme can truly be _perfect_ since perfection, as defined by
> implication above, may never be achieved. But I repeat: a humble
> paper write-protect tab comes as close to perfection, in this sense,
> as anything can. Certainly close enough, and infinitely closer than
> any software ever could. Can we not learn something from this?
I agree (very much) that we need a lot of people using (relatively)
simple protection techniques, rather than a few people using very
complicated ones, at the moment. But I must point out there are
problems in relying too heavily on write-protect tabs:
(a) Some software from suppliers (already write-protected, shrink-wrapped) has
been found to contain viruses, that got into the system "too early",
(b) You might need to take the tab off to bring some data or a program into
your system; as soon as you do, your system can become infected. Or the
programs might come in via a modem or network. If you want to obtain any
new program, you run the risk of infection; if you let someone write data
onto one of your diskettes, it could become infected.
(c) Even if the only communication with the outside world your system has is
to take data on diskettes, that are write-protected, to another system, if
the write-protect hardware is faulty on that machine (a few are) then your
diskette could become infected.
But the main problem is this: what you need more than anything else is
a write-protect tab for your hard disks. Even if there was one big
enough (:-), you would still want to take it off every so often to
upgrade software, etc.
I feel the ABSOLUTE MINIMUM protection that everyone should be using is:
(a) write-protect some system diskettes and NEVER take the tab off (glue it on!)
after you've copied a backup system and anti-virus software onto them from
a clean system. You may like to only ever boot from such floppies, instead
of your hard disk, for safety, but simply having these "safe" diskettes to
check the system every week is probably enough to curb the main viruses.
(b) if you ever let others use any of your diskettes (or you obtain one from
someone else) run a good scanner over it as soon as possible,
(c) have a TSR program looking for viruses in boot sectors automatically
whenever you access a diskette.
(d) Have some software or hardware protect important, unchanging areas on your
disk. Hardware could mean having two drives, with the write-line snipped
(and supplied via a resistor). Software includes DrDOS 5/6's password
protection system (built-in, but not 100% water-tight) and/or DISKGARD
(also available via anonymous ftp), and quite a number of other programs.
(e) Software or firmware to check the MBR and DOS boot sector when starting up.
All of these steps are either free or can cost as little as $1
(depending on quantity, educational/corporate pricing policies, cost
of labour, etc). All the software you need is available as shareware,
so it can be at least tried for free. (If you don't know where to
obtain any of the software, ask me)
So why don't more people make use of such anti-virus measures?? You
might like to debate whether certain things should or should not go
into the "essentials" list above, but I feel the thing to debate is
why most BIOS manufacturers didn't put tests into their ROM's years
ago, and why MicroSoft and Digital Research don't put more virus
protection into the operating systems. At least that way, the majority
of PC's might hinder rather than promote the spread of viruses. In
fact, don't just debate it, write/phone/e-mail them! Tell them they'll
be co-respondents the first time a computer operating vital medical
equipment fails through a virus and kills a patient, because their
system isn't safe enough.
Unfortunately, viruses do well because of (on the whole) apathy on the
part of computer users, and MicroSoft (sorry to single them out, well
perhaps they deserve it), have responded to that apathy with even
greater complacency. This discussion shouldn't really be a choice
simply between hardware and software; a third, much more important
component should be there: public attitudes.
Mark Aitchison, University of Canterbury, N.Z.
------------------------------
Date: Thu, 03 Oct 91 02:05:33 +0000
>From:
[email protected] (James Mark THOMAS)
Subject: HELP with possible PC infection (PC)
I have been getting erratic behaviour from my PC and was wondering if it is
due to a virus.
System: 286/16
dos 4.00
40mb hard disk
2 meg total memory (extended)
History:
-joshi virus detected and cleaned from hard disk 3 months ago by
scan v77
-in the last few days, the computer hangs when there are no keypresses,
eg when a directory is listed using "list.com" sometimes and I mean
occaisonally, it hangs, cannot be rebooted from the keyboard, and must
be hard booted.
-mem reports less memory than a few weeks ago. Now 523216, previously
528xxx. There are no extra tsrs or changes to config.sys.
-scanV82 (obtained from simtel) reports no viruses.
Questions:
-is there a way to tell if my computer is infected?
-could it be a hardware fault?
Thanks very much in anticipation.
Jim
[email protected]
------------------------------
Date: Tue, 01 Oct 91 17:04:00 +0000
>From: Joe Wells <
[email protected]>
Subject: DIR II Removal Information (PC)
After disassembling and analyzing the DIR II, and some excited
interchange of information with Igor at McAfee and Glen at Microcom,
here is the info needed to remove the DIR II (which Igor, Glen, and I
would like to see renamed the Cluster virus). More specifically, here
is the info needed to write a disinfector.
A disinfector should be written only by a qualified (preferable asm)
programmer and tested extensively. A test prototype using the system
below cleaned the C: and D: drives on a 40 meg quickly. The drive was
massively infected, including many sub-directories. The prototype used
logical disk reads and writes.
The virus code will be found in the last cluster on the drive. It will
occupy 2 sectors. The code is 1024 bytes.
Each directory sector is infected as a unit. The virus uses an
encryption key (stored internally and variable from infection to
infection) to xor the dir entry cluster element of files with COM or
EXE extentions. The key is rotated left 1 bit for each entry WHETHER
THE EXTENTION IS EXE, COM, OR WHATEVER.
Even though a directory may span several sectors, the internal key is
used to start each one.
To disinfect, read the virus code from the last cluster. Get the
encryption key and save it.
The key is the word at offset 33F in the virus code.
The prototype simply checked all sectors and did simple testing to
determine if it was a directory listing or not. Any other method of
finding the sectors would work as well. Once a sector is found, set a
pointer to the first entry. Check the word at [ptr + 1Ah] for the
last cluster number. The word at location [ptr + 14] is normally 0 in
directories (unused by DOS), but here will be the original file start
cluster in encrypted form. If infection is found, get the original,
xor it with the key and put it at [ptr + 1Ah].
Rotate the key (rol key,1) for every entry, infected or not.
Add 20h to pointer for the next listing and repeat. There will be 16
entries per sector to check. If infection was found and fixed, write
the sector back to disk. When done, overwrite the virus code.
Testing will be hard, unless you have the virus. If you don't have it,
don't bother. If you do have it and write a disinfector, let me know.
Sincerely hoping you don't have it,
Joe Wells
Virus Specialist (deprogrammer?)
Certus International
216-752-8181
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 181]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
