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 VIRUS-L@IBM1.CC.LEHIGH.EDU (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: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: Tue, 01 Oct 91 18:21:52 >From: c-rossgr@microsoft.com Subject: Re: Infectable Areas (PC) >From: bontchev@fbihh.informatik.uni-hamburg.de (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: degilio@serum.kodak.com (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. degilio@serum.kodak.com -- Ken Thompson 70511,1470@compuserve.com - ----------------------------------------------------------------------------- ------------------------------ Date: Wed, 02 Oct 91 10:01:00 -0500 >From: PERRY@BEACH.GAL.UTEXAS.EDU (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 | perry@beach.gal.utexas.edu - Internet University of Texas Medical Branch | PERRY@UTMBEACH - BITnet Galveston, Texas 77550-2772 ------------------------------ Date: Wed, 02 Oct 91 12:42:07 +0300 >From: ish@ire.msk.su (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: ish@ire.msk.su | | Institute of Radio Engineering | :postmaster@ire.msk.su | | & Electronics ACAD.Sci. of USSR. | phone :(7-095)203-17-16 | ------------------------------ Date: Tue, 01 Oct 91 22:25:22 +0000 >From: Fridrik Skulason 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 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: JTUCKER@VAX2.CSTP.UMKC.EDU 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 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. - -- technews@iitmax.iit.edu kadokev@iitvax (bitnet) My Employer Disagrees. ------------------------------ Date: Thu, 03 Oct 91 11:08:00 +1200 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: Hardware vs. software (vs. public attitudes) turtle@darkside.com (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: jmt@mundil.cs.mu.OZ.AU (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 jmt@mundil.cs.mu.OZ.AU ------------------------------ Date: Tue, 01 Oct 91 17:04:00 +0000 >From: Joe Wells <0004886415@mcimail.com> 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