VIRUS-L Digest Thursday, 13 Jul 1989 Volume 2 : Issue 151 Today's Topics: Re: FAT information (PC) Re: nVIR and AppleTalk (Mac) Viruscan.arc (PC) Ashar virus article Denzuk virus article ANCIENT MACS AND VACCINE Re: icons altered (Mac) Re: system folder question (Mac) Shareware? Hmm... (Mac) INIT29 and data files (Mac) --------------------------------------------------------------------------- Date: Wed, 12 Jul 00 19:04:00 -0400 From: Bob Babcock Subject: Re: FAT information (PC) MIROWSKI@FRECP12.BITNET writes: >It's rarely necessary to care about the distinction between 360 Ko and >1.2 Mo disks, because the information about the format is in the second >sector of the disk (the first FAT sector) and DOS will take this second >information in consideration. The information is also in the Bios Parameter Block (BPB) in the boot sector, and you're asking for trouble if the FAT and BPB disagree. A while back there was a claim in PC Magazine that PC-DOS 3.3 required that the OEM id field in the boot sector contain the characters "IBM". The evidence offered for this was that if the boot sector on a disk which PC-DOS 3.3 rejected was replaced by a boot sector from an acceptable disk, the disk became acceptable. In fact, what was really happening was that there was bad information in the BPB, and PC-DOS was complaining about this. I have a program called SCAT, which I got off of BIX, which writes a valid boot sector on a floppy. The original purpose was to replace a non-standard boot sector which FastBack writes, but perhaps it would also be useful for removing a boot sector virus. If there's any interest, I could send a copy to the moderator for posting. ------------------------------ Date: Wed, 12 Jul 89 22:23:00 -0400 From: "Mark H. Anbinder" Subject: Re: nVIR and AppleTalk (Mac) *On 5 July Joe McMahon said... >If your AppleTalk network only is used for mail or access to >LaserWriters, you shouldn't have a problem. If you have AppleShare >servers, make sure the servers are protected. You may have to disinfect >the odd machine here and there, but the servers should be safe. It's true that if your network is only used for printing that CURRENTLY KNOWN Mac viruses can't spread over the network. Some electronic mail software, though, lets users exchange files or even applications. If an application that's infected is transferred in this way, the infection WILL be transferred. There is no simple way of "protecting" servers themselves against the infection of the files they hold. If an application stored on the server is executed by a person using an infected machine, that application will probably be infected. You cannot run such things as Vaccine or GateKeeper or SAM Intercept on a server machine. Well, you can, but it only keeps software being run ON the server from being infected; it does nothing to prevent software that RESIDES on the server from being infected. The best way to do that is still to make sure that each workstation is as secure as possible, using frequent checks with Disinfectant, Virex, or SAM (currently the three most up to date programs), and protection with such programs as Vaccine, GateKeeper, or SAM Intercept (the best of the three, but not free). For the curious, SAM is a new package of antiviral utilities from Symantec, the same people who created SUM. It stands for Symantec Antivirus for the Macintosh. I haven't finished evaluating it, but it looks great. I will post more about it shortly. Mark H. Anbinder ------------------------------ Date: Wed, 12 Jul 89 23:48:47 -0500 From: "Mark Moody" Subject: Viruscan.arc (PC) Hi, Some one recently asked if Viruscan from Simtel20 had actually detected anything. I used it to scan some floppies and it did detect the Yale/Alemadea Virus on some. I knew it was there but wanted to see what the Prog would do. Hope this helps! Mark ------------------------------ Date: Thu, 13 Jul 89 00:38:49 +0000 From: Alan Solomon Subject: Ashar virus article A comparison of Ashar and Brain Recently, an academic institution in the South of England (who do not wish to be named) finished cleaning out a virus that put " (c) ashar" as the volume label. They sent us a specimen for analysis - here are our findings. Ashar is very similar to Brain, which has been described in detail elsewhere. But there are some interesting differences, which are worth documenting, and they lead to a tentative conclusion. Difference 1 The volume label that is put on the diskette is " (c) ashar" instead of " (c) Brain". The text in the boot sector contains "(c) 1986 ashar & ashars (pvt) Ltd VIRUS_SHOE RECORD" and the "V9.0" is absent. The rest of the text "Dedicated to the dynamic memories" etc is exactly the same, including the mis-spelling of "messeges" and the grammatical errors. Difference 2 In Ashar, the volume label is put into the first available directory entry, whereas with Brain, it cannot be put into the first or second entry. If there is a volume label on one of the first two entries, an attempt to install the system will fail, making the virus more noticeable and more of a nuisance. Difference 3 The body of the virus, and the stored (original) boot sector, is placed in three fake bad clusters. In Brain, this must be on or after cluster 55; the purpose of this is probably to allow space for the Dos system files. Ashar allows the body of the virus to be on any free cluster on the diskette. Difference 4 Brain uses quite a complicated encryption scheme to encode the volume label that it places on diskettes, presumably to make it harder for someone to change it. Ashar uses a much simpler scheme. It stores the volume label as a character string, in negated form, so that all you have to do to decode it is a NEG instruction. There are 11 bytes in Brain, which was previously thought to contain rubbish. These 11 bytes are the negated " (c) ashar ". Immediately after these, there is " (c) ashar $" in clear. These 11 bytes, and the cleartext, are unused by Brain. Difference 5 Ashar resets the floppy disk controller before reading or writing to the device in a number of places; Brain does the reset after the access if it fails. Difference 6 When Brain is installed in memory, and you try to look at the boot sector of a diskette, Brain reads the original boot sector that has been stored further down the diskette, and shows you that normal boot sector instead. This applies to programs that use the data in the boot sector, but also to Debug, Norton, Mace, PC-Tools and other disk sector editors. One of the effects of this is to mislead you into thinking that the diskette is normal. Ashar stores the original boot sector of the diskette, and uses it to continue the boot process after an attempt has been made to boot from an infected floppy. But it does not redirect subsequent attempts to read the boot sector. When you look at the boot sector, you see an infected boot sector. Conclusion on Brain Ashar and Brain are definitely two versions of the same virus; the code is nearly the same, apart from the differences documented above. But Brain has a sophistications that Ashar doesn't have, such as the boot-read redirection, the space left in the FAT and directory for the installation of the system, and the greatly improved encryption system. Brain contains, as an unused remnant, the NEG-encrypted Ashar volume label. That would tend to imply that Ashar predates Brain, and the greater sophistications in Brain tend to confirm this. This would imply that Ashar was the precursor to Brain. If this is true, then the version of Brain which has not got the telephone numbers on the boot sector (but has "Dedicated to the memories"), is previous to the version with the telephone numbers, which would imply that the telephone numbers version is a hack of the real Brain. It is very easy to change the boot sector - any disk sector editor would allow that. Until Ashar, we had no way of telling whether the "Dedicated to the memories" version came before or after the telephone numbers version. Now we have a strong indication that the telephone numbers version came afterwards. One possibility is that Ashar is a kind of hoax; a computer-virus Piltdown that is intended to mislead virus researchers. It would be very difficult to change Brain to Ashar or vice versa unless you had the source code, or a very good disassembly. Why should anyone try to fool virus "palaeontologists" in this way, when such researchers scarcely exist (yet). And it would seem to be a pretty pointless exercise - if a programmer was that good and wanted to make their mark, they would not have simplified Brain, they would have complicated it, or even used it as a basis to write a completely different, and much worse, virus. So, if the telephone-numbers version of Brain comes after the "Dedicated to the memories", the numbers are probably nothing to do with the virus, and the whole story of the Brain brothers and the writing of the virus comes into doubt. More general conclusion In order to discover this kind of information, viruses from the field must be carefully analysed. We need some way for virus researchers to be able to exchange specimens. Reports of vcrus sightings, and summaries and catalogues of viruses are obviously very useful, but to generate the raw material from which these can be produced, actual specimens must be analysed by researchers. Dr Alan Solomon Day voice: +44 494 791900 S&S Anti Virus Group Eve voice: +44 494 724201 Water Meadow Fax: +44 494 791602 Germain Street, Data: +44 494 724946 Chesham Bucks, HP5 1LP Usenet: drsolly@ibmpcug.co.uk England Gold: 83:JNL246 ------------------------------ Date: Thu, 13 Jul 89 00:41:06 +0000 From: Alan Solomon Subject: Denzuk virus article DENZUK DENZUK is a Boot Sector Virus. It replaces the original boot sector with its own - this looks very like a normal boot sector, as it has the usual messages "Non-System disk or disk error", "Replace and strike any key when ready" and "Disk Boot failure". It also has the references to IBMBIO.COM and IBMDOS.COM. If your system files are called IO.SYS and MSDOS.SYS, DENZUK doesn't realize this, but it does mean that the boot sector looks normal. When the boot sector runs, it loads in the rest of the virus, which is located on track 40 (normal 360k diskettes have tracks numbered 0 to 39), head 0, sectors 33 to 41 (normal tracks are numbered from 1). Putting the virus in this place means that some disk-searching utilities won't find it there. It also means that if you Diskcopy the infected diskette, most of the virus fails to copy. This gives us one simple way to clean up an infection - DENZUK could almost be called a copy-protected virus! If you Diskcopy an infected diskette, the DENZUK boot is copied, but not the rest of DENZUK. If you use COPY or XCOPY to copy the diskette, then the infected boot is left behind also. Of course, you must boot from a known clean diskette before you start. When DENZUK runs the code that it has loaded in from track 40, it replaces two of the PC's interrupts, $13 (diskette) and 9 (keyboard). A new interrupt is installed, $6F, which is the old interrupt $13; DENZUK uses this as a short way to call the original routine. The new interrupt 9 looks for two keystrokes. On seeing a Ctrl-Alt-Del, it calls a routine that displays its logo (if it is running on anything apart from a mono monitor), and then reboots. The other keystroke is Ctrl-Alt-F5, which just triggers a reboot. This is a convenient test to see if you are infected, as on a PC that is not running DENZUK, Ctrl-Alt-F5 does nothing. All other keystrokes are passed on to the original interrupt 9 routine. The DENZUK logo is a graphic, with the words "DEN ZUK" in large red letters. The pixels making up these letters come in from each side until they merge making the words; there is also a symbol to the side that looks rather like a stylised globe. Interrupt $13 is used to infect more diskettes. Every time interrupt $13 is called, provided it is referencing one of the two floppy drives (DENZUK will not infect a hard disk), and provided the call is a read, write, verify or format, DENZUK will decrement its infection counter (which is initially set to eight). When the counter reaches zero, this triggers the infection process, and the counter is set back to two. The infection process works like this. First it reads the sector at cylinder 0, head 0, sector 1. It looks for two bytes that are found in DENZUK, and if it finds them, it doesn't infect. If they are absent, it looks for two other bytes which we surmise are an old version of DENZUK; if it finds those, it calls the "Find Denzuk Boot" routine, whereby it reads the boot sector from trach 40, head 0, sector 33 which is where the original boot is stored. Thus, DENZUK will update you if it finds that you are running an out-of-date version of the virus. If DENZUK finds Brain (or Ashar) virus on the boot sector (which it does by looking for the $1234 signature of Brain) then it upgrades you from Brain to DENZUK. First, though, it has to go and find the boot sector from where Brain has put it; Brain has three bytes on sector cylinder 0, head 0, sector 1 that tells you where the original boot sector is, and DENZUK decodes these and reads the boot sector. Whether the diskette was clean, old-DENZUK or Brain, DENZUK now has the original boot sector. It formats track 40 head 0, and writes its nine sectors there. If this write is successful (some diskette drives may not allow writing beyond track 39) then it replaces the sector at cylinder 0, head 0 sector 1 with its own version of the boot sector. The infection process is now complete. It then scans through the directory to see if there is a volume labels there. Brain, you may recall, puts " (c) Brain" as a volume label on the diskette. DENZUK overwrites that with its own label, which is "Y.C.1.E.R.P", where the . is character $F9. DENZUK assumes that it is looking at a 360k diskette, but makes no attempt to ensure that this is the case. This directory scan starts at sector 0, 0, 6, and scans through seven sectors; just right for a 360k diskette. The meaning of this volume label is obscure. There is also a generation counter, which keeps track of how many generations have passed; if this is less than three, then DENZUK refrains from its visible signs - the logo is not displayed on reboot, and the volume label is not changed. The specimen that we had was generation $14. This feature is probably to give it a chance to spread a bit before detecting it becomes easy. DENZUK puts the BRAIN signature on the boot sector - this would stop Brain from infecting a DENZUK-infected diskette. So in a population of Brain-infected diskettes, DENZUK would tend tobe the virus that would get the upper hand. There are a couple of text messages in the virus, which are not displayed. These are: At the beginning: "Welcome to the C l u b - --The HackerS-- Hackin' All The Time " At the end: "The HackerS" It might be thought that DENZUK is actually a helpful virus, in that it kills Brain. This is not so - consider what will happen if DENZUK infects a diskette with more than 40 tracks. Track 40 would be overwritten, and data could be lost as a result. Even worse, DENZUK assumes that all diskettes are 360 kb diskettes, so when it infects them, it puts a 360 kb diskette boot sector on top of the old boot sector. This tells Dos that the diskette has 2+2 FAT sectors and 7 directory sectors, which is not the case. So Dos is not able to read the diskette properly, and interprets the directory as part of the FAT, and (depending on what diskette it is) can get the cluster size wrong, and might ignore some of the sectors on each track. In other words, DENZUK infecting a 5 1.4 inch 1.2 mb diskette leaves it unreadable, although putting a correct boot sector back in place will rescue most of the data (trach 40 head 0 is gone for ever). Other capacity diskettes (other than 360 kb) will also have problems. Our specimen of DENZUK came from an academic institution in the UK, which prefers to remain unnamed. It is the only reported instance of DENZUK in the UK so far, apart from lab specimens. We have added tools for dealing with DENZUK to our Anti Virus Toolkit. If you need more information about this virus, or any of the others, please contact me at the address below. Dr Alan Solomon Day voice: +44 494 791900 S&S Anti Virus Group Eve voice: +44 494 724201 Water Meadow Fax: +44 494 791602 Germain Street, BBS: +44 494 724946 Chesham, Fido node: 254/29 Bucks, HP5 1LP Usenet: drsolly@ibmpcug.co.uk England Gold: 83:JNL246 CIX, CONNECT drsolly ------------------------------ Date: Thu, 13 Jul 89 13:48:57 -0000 From: LBA002@PRIME-A.TEES-POLY.AC.UK Subject: ANCIENT MACS AND VACCINE Sorry to have to keep replying to the LIST at large but I haven't quite got the hang of replying to individual addresses. I've checked our machines and they are only 512K, upgraded to take 800K discs. I've been able to ResEdit Vaccine into my System 3.2 and all seems to be OK now. Not that it will stop our students using their own discs and infecting each other, or from pirating software! Many thanks to everyone who has offered advice and information. Rgds, Iain Noble ------------------------------ Date: Thu, 13 Jul 89 10:25:40 -0400 From: Joe McMahon Subject: Re: icons altered (Mac) >Date: Wed, 12 Jul 89 11:52:48 -0500 >From: Lee Brannon >system, and I now suspect that I may have found a third... > ...My System, Finder, Clipboard > and scrapbook icons have changed. > > Unlike the scores virus...they have changed to better > drawings of the mac plus with shaded screens... Not to worry. Sounds like someone has installed ColorFinder on your Mac. It just hooks the ICON-drawing trap and puts up prettier icons. Look around in your System Folder for the ColorFinder file. You can simply trash it if you don't like it. --- Joe M ------------------------------ Date: Thu, 13 Jul 89 09:35:34 -0500 From: Subject: Re: system folder question (Mac) >Date: Wed, 12 Jul 89 11:52:48 -0500 >From: Lee Brannon >Subject: Macintosh system folder looks suspect > >I am a Mac user who has already run across two virus programs on my >system, and I now suspect that I may have found a third. Any of you >who are using a macinto sh and have come across the following symptons >please drop me a line (especiall y if you know the cause): > > Like the scores virus...My System, Finder, Clipboard > and scrapbook icons have changed. > > Unlike the scores virus...they have changed to better > drawings of the mac plus with shaded screens Sounds to me like the Beta Release of Multi-Finder (called Juggler I believe) which vastly improved the Macintosh Icons, but, alas, they were their same old ugly selves when it was finally released. Acknowledge-To: ------------------------------ Date: Thu, 13 Jul 89 11:36:59 -0400 From: Joe McMahon Subject: Shareware? Hmm... (Mac) I received a visit from a Mac user here at NASA this morning who was very upset about a letter he received concerning Virus Detective(tm). It seems that he had decided that he wanted to keep VD, so after reading the dialog telling where to send the money and how much, he sent in a check for $25. (He had version 2.2; I verified that the "Credits" dialog up to and including version 3.0 specified this amount). He then received a letter from the author *billing* him for an extra $15! It seems that the price went up with version 3.0.1. (I verified that too.) He has returned the disk which was sent him and has requested his money back. I have never heard of any shareware author billing anyone before. I'd appreciate opinions on whether we should continue to support the author by making this software available. I'd even more appreciate a direct response from the author, if he reads this list. I'm posting this partly in the hope that he will respond, and partly because I truly dislike denying access to a good tool possibly because of a one-time mistake or misunderstanding. I'd appreciate _direct_ replies from the readers of this list as to their thoughts and feelings on the subject. Thanks. --- Joe M. Internet: xrjdm@scfvm.gsfc.nasa.gov | "NOOOOO one expects the Spanish Phone: (301) 286-8090 | Inquisition!" -- Cardinal Ximenes ------------------------------ Date: Thu, 13 Jul 89 10:41:00 -0500 From: Holly Lee Stowe Subject: INIT29 and data files (Mac) Chris Krohn (>) replies to Michael Niehaus (> ##) about viruses spreading from data files: > ##All of the other files on the > ##network are data files. Viruses cannot be spread from these data files. > > Not true. The Init29 virus, for example, will infect data files > as well as applications. Chris, I think you've misunderstood what Michael stated. INIT29 can indeed spread to data files, but as far as I know, it is not capable of spreading *from* data files back to applications. Also, for anyone using Macs and trying to teach others about what things to be aware, may I recommend highly a Hypercard stack called the Virus Encyclopedia which is available on GEnie and probably other places. (The author's name is Henry C. Schmitt, and he's from the Northwest of Us, a user group in Arlington Heights, IL.) Also the informational screens from John Norstad's Disinfectant are very helpful. - -Holly If something is preposterous, does it later become postposterous? +---------------------------------------------------------------------+ | @@@ @@@ @@@ @@@@@@@@@ @@@ @@@ @@@ Holly Lee Stowe | | @@@ @@@ @@@ @@@ @@@ @@@ @@@ @@@ Bitnet: IHLS400@INDYCMS | | @@@ @@@ @@@ @@@@@@@@@ @@@ @@@ @@@ IUPUI Computing Services | | @@@ @@@@@@@@ @@@ @@@@@@@@ @@@ 799 West Michigan Street | | Indiana U. - Purdue U. at Indianapolis Indianapolis, IN 46202 | +---------------------------------------------------------------------+ ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253