From abacus.hgs.se!mikael Sun Mar 28 02:34:45 1993 remote from vhc Received: by vhc.se (1.65/waf) via UUCP; Sun, 28 Mar 93 01:37:06 GMT for mikael Received: from Abacus.HGS.SE by mail.swip.net (5.65c8-/1.2) id AA27712; Sun, 28 Mar 1993 01:34:54 +0100 Received: by abacus.hgs.se (5.65c/1.5) id AA04461; Sun, 28 Mar 1993 01:34:45 +0100 Date: Sun, 28 Mar 1993 01:34:45 +0100 From: Mikael Larsson Message-Id: <199303280034.AA04461@abacus.hgs.se> To: mikael@vhc.se VIRUS-L Digest Thursday, 25 Mar 1993 Volume 6 : Issue 48 Today's Topics: scanners. Re: Laws and Viruses Beneficial/Non-destructive viruses UNIX Virus detectors and correctors?? (UNIX) scanners. (PC) Michelangelo (PC) Master Boot Records, History, & Circular Partition Tables (PC) Re: Integrity checking (was: Scanners (PC)) Re: Kampana virus (PC) Re: EXE/COM switch (PC) Re: F-PROT (PC) Re: IBM PC Boot Seq (was Partition table viruses (PC)) Re: Minnow-V virus correction (PC) Re: New (?) virus ? (2294) (PC) Re: Removing virus on stack drive (PC) Uruguay on PS/2 ref disk (PC) Problems w/ lan prrotect (PC) Re: Signitures (PC) Re: [Stoned] (PC) Re: 'MZ' and 'ZM' signatures (PC) Vir-Sig (PC) Memoirs of an (untrustworthy) virus researcher (CVP) 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. (The complete set of posting guidelines is available by FTP on cert.org or upon request.) Please sign submissions with your real name. Send contributions to VIRUS-L@LEHIGH.EDU. Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on cert.org (192.88.209.5). Administrative mail (comments, suggestions, and so forth) should be sent to me at: . Ken van Wyk, krvw@first.org ---------------------------------------------------------------------- Date: Sun, 14 Mar 93 08:26:01 +0100 >From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: scanners. Malte Eppert writes: >> Look. In order for a file to infect a virus it must either add >> itself to the file, or overwrite or replace the first file's >> cluster (known methods of infection, correct me if I'm missing >> anything). If you run a CRC check DAILY, you WILL locate these >> changing. > True, but if you got a slow virus (which only infects when a file is > intentionally written to), you just would say to yourself: Ah, of course > the file has changed. I have done it by myself. You simply would regard > any reported changes as legitimate, e.g. recompiling an EXE. That's why > you couldn't catch "any virus". I see what you mean. I thought 'slow' only refered as to the speed of the damage the virus causes. Can you think of an idea (or is there one already) to bypass this? > The DOS file fragmentation, a theoretically possible infection described ------------------------------ Date: Sat, 20 Mar 93 21:57:34 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Laws and Viruses ulogic!hartman@netcom.com (Richard M. Hartman) writes: > > From a legal standpoint it might be enough to define a virus > >as "a sequence of instructions that intentionally performs an unwanted > >and undocumented modification within a computing system for which it is > >intended." > As in Microsoft's undocumented software interrups in the various > DOS versions? How about the "hidden" Windows functions? Well, one could argue that they are not "unwanted"... :-) > > Possibly "malicious software" would be a better term but IMHO > >the word "computer virus" has passed beyond any hope of control. > Hold on. I think you may have something here. Since when has > legal terminology been required to match up with common usage? > Perhaps "malicious software" is just what we need to define as > a legal term. Especially since the definition of virus is so > mutable.... Indeed, this is the better term to use. It can be associated easily to "intentional damage" and does not state that "virus" is something necessarily malicious, definition problems aside... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Sun, 21 Mar 93 23:22:24 +0000 >From: cburian@ux4.cso.uiuc.edu (Christopher J Burian) Subject: Beneficial/Non-destructive viruses Requesting help on beneficial/non-destructive viruses used as tools. I've read a very little bit about viruses generated for a specific task that disappear into a network; carry out their intended function (send data back to user, etc); then "retire" themselves. Can anyone provide references to books, popular magazines, or scholarly journals? How much research has been done in this area? I haven't yet found a single source on this topic. I need mostly technical/semi-technical information. Need only a very little amount of legal/political information on subject. I wouldn't bother the net with this if I could find even a single reference with bibliography. Thank you for your help. E-mail please. - ----------------- For PGP key, email --------------------------------- | Chris Burian | To: pgp-public-keys@toxicwaste.mit.edu - ----------------- Subject: MGET burian ------------------------------- ------------------------------ Date: Mon, 22 Mar 93 12:48:18 +0000 >From: dennisk@aplcenmp.apl.jhu.edu (Dennis M. Kavanagh) Subject: UNIX Virus detectors and correctors?? (UNIX) Hello everyone... I am in the unenviable positon of figuring out how much trouble my site is in because we do not have any virus scanning for our UNIX boxes. Can someone help me determine if this is a real difficuly or just a management fiction? If this is REAL, are there any scanners that will help?? Thanks... ------------------------------ Date: Sun, 14 Mar 93 08:20:00 +0100 >From: Inbar_Raz@f210.n9721.z9.virnet.bad.se (Inbar Raz) Subject: scanners. (PC) frisk@complex.is (Fridrik Skulason) writes: >>I was categorizing scanners. About defending against NEW viruses, there are >> a lot of ways. For example, a protective shield that is mounted on a file. >> True, it's effective only against the normal end-of-file-leaching viruses, >> but still, a lot of them DO work like that, including the new ones. > well, it might work... > ...unless the virus is a "stealth" virus Oh god. Stealts disinfect on the fly. How could I forget. This gives me an idea, though. If you prepare a boot disk, that boots just like your computer, not only system files, AND you shield your files, then if you occasionally boot from that floppy, whom we assume is UNINFECTED, then the shield WILL catch stealth, will it not? > ...or the program does some self-testing > ...or the program contains internal overlays These are exceptions. Same exceptions as for PKLite. >>Making CRC checks from a BOOTING FLOPPY will also catch ANY virus, > unless it is a floppy-only infector, or a companion virus, or an unknown > "slow" virus. First, let me make it clear that by saying a Booting Floppy, I mean an uninfected one. I am still sure that even in today's world, one can produce a virus free boot disk. Anyway, if it's a boot infector, than it won't infect your Hd, will it? If it's slow, it doesn't matter. 'Slow' relates to it's damaging mechanism, meaning it takes time to notice the virus's damage, like the FAT damage with the 4096. But still, the virus has to INFECT, otherwise it can't run. Inbar Raz - - -- Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660 Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 nyvirus@weizmann.weizmann.ac.il - --- FMail 0.92 * Origin: |||||||#|||||||| Inbar's Point |||||||#|||||||| (9:9721/210) ------------------------------ Date: Mon, 15 Mar 93 11:27:11 +0100 >From: Malte_Eppert@f6051.n491.z9.virnet.bad.se (Malte Eppert) Subject: Michelangelo (PC) Hi Vesselin! > BTW, I am very curious how many Michelangelo hits have happened > this year... I know about at least two. One in Braunschweig, another one in the Vechta area, both Northern Germany. cu! eppi - --- GEcho 1.00 * Origin: No Point for Viruses - Eppi's Point (9:491/6051) ------------------------------ Date: Fri, 19 Mar 93 23:10:26 -0500 >From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Master Boot Records, History, & Circular Partition Tables (PC) Subject: IBM PC Boot Seq (was Partition table viruses (PC)) >From: virusbtn@vax.oxford.ac.uk >The early versions of MS-DOS used a similar method of booting either from >floppy disk or hard disk. However, as disk drives got bigger, different >routines were developed for hard disk boots. In order to cope with multiple >partitions etc a sector (called the Master Boot Record or Master Boot >Sector), located at track 0, head 0, sector 1 is loaded and executed. This >code examines the data held in the partition table and locates the position >of the active partition on the disk. The code then loads this second boot >sector (called the DOS Boot Sector or Partition Boot Sector) which in turn >loads the appropriate system files. Mr. Ford makes some very good points & is essentially accurate except for a hysterical note: Fixed disk support was added to MS & PC DOS with version 2.0 (1983) and FDISK appeared at the same time. Originally, the only fixed disk available for the PC was the ST-412, 10 Mb drive with 306 tracks, 4 heads, 17 sectors per track, and 512 byte sectors so multiple DOS partitions were neither necessary nor documentedly possible. However, in 1983, DOS did not dominate the market as it does now. In fact, when the IBM-PC was about to be introduced, MS-DOS was the fourth choice in a list of three (ROM BASIC, UCSD Pascal, DR CPM/86) - it was only when Softech acquired the P-code (and wanted a $450 license fee per copy) and CPM/86 slllliiiippppppeeeeddd (it did release eventually & I have a copy) that IBM turned to the developer of the ROM BASIC and asked for help. As a consequence those first MBRs did occupy offset 1be-1fd and did have for four partitions but it was expected that one would be for DOS and the others would accomodate other OSs. So several operating systems could be loaded and by moving the "active" mark, the user could select which would boot. Larger disks appeared quickly and a number of partitioning drivers appeared so that they could be used. Probably the most popular was Disk Manager whose DMDRIVER.BIN is still found on older drives. In fact it was not until DOS 3.2 that our current scheme of extended DOS partitions was introduced and drives with letters beyond D: (two physical drives were supported from the start) became a DOS "feature". The above comes into VIRUS-L relevancy with the recent discovery that a circular partition table can prevent booting of a PC even from floppy. However the fix is easy, just drop back to DOS 3.1 or earlier and the PC will boot just fine since DOS did not even look at non-active partitions back then. Then you can take out DEBUG and fix the problem. Warmly, Padgett ------------------------------ Date: Sat, 20 Mar 93 17:55:32 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Integrity checking (was: Scanners (PC)) RADAI@vms.huji.ac.il (Y. Radai) writes: > > Then, Vesselin introduced the idea of a DOS file fragmentation > > attack. You could not detect that with a file-oriented CRC checker, too. > First, Vesselin didn't introduce the idea. It was known to some of us > in 1988. Well, nevertheless it was me to -introduce- the idea to the general public, so that people are aware about the danger... I agree that you (and a few others) knew about it before, but you didn't piblish it... I myself heard about it from a virus writer in 1990, so I decided that it is better to inform the good guys - since the bad guys already knew it... :-) Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Sat, 20 Mar 93 18:01:09 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Kampana virus (PC) FESQUIVE@ucrvm2.bitnet (Fabio Esquivel) writes: > Well, right now Scan V102 says it is the Anti-Tel A-Vir! virus, and > F-Prot 2.07 says it is a "New variant of Kampana". Well, it's just a naming confusion - the virus that SCAN calls Anti-Tel is the Kampana virus, according to the CARO naming convention, which F-Prot uses (unlike SCAN). The strange thing, however, it that F-Prot detects it as a new variant. I know of 3 Kampana variants - A, B, and C. F-Prot calls both Kampana.B and Kampana.C "New or modified variant of Kampana". > I inmediately read my VsumX of January 1993 and found some description. Well, VSUM is not the most exact source of information about viruses... > The variant I have infects diskettes as described there, but the > encrypted messages are different (the encryption consists of applying > NOTs to the text bytes). > In the encrypted boot record you can read (literally): > "Campa:a Anti-TELEFONICA (Barcelona)" Well, this text -is- present in Kampana.A... > I also have the Alameda virus, which I found several years ago. F-Prot > 2.07 says it is a new variant of Alameda (this didn't happen before). As far as I know, Frisk recently has introduced exact identification of boot sector viruses. This means that he keeps maps and checksums of the non-variable parts of the infected boot sector. If he has made a mistake and included a variable field in the map, the checksum sometimes will fail to match and the virus will be reported as "new". The only easiest way to verify that is to send him a copy of the virus that is reported as new. > Do I really have new variants of these viruses? Or is it just a problem > of misidentification by F-Prot? About Kampana - I don't know; might be a new variant. About Alameda (F-Prot should call it Yale, BTW) - it's probably a misidentification. > I'll be glad of sending copies of both viruses to Fridrik and Aryeh, if > they are interested; the trouble is that I'm on a BITNET node and I think > I can't send binary files to InterNet nodes (just simple mail). Just XXENCODE the binary file - this will convert it into text form - and e-mail it as regular message. An alternative is to use DEBUG to generate a hex dump to a text file. However, the XXENCODE approach is better - because you could first put the file in an archive and protect it with a password - just in cases the message with it is received by somebody else by mistake... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Sat, 20 Mar 93 18:26:53 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: EXE/COM switch (PC) Peters@DOCKMASTER.NCSC.MIL (Donald G Peters) writes: > VB wrote that my proposal was already discussed in "Virus News > International." This publication is not available in any of 10,000 > libraries in the USA, including the Library of Congress, so I am > unable to verify his claim. (I had the OCLC database searched.) The > publication is a new, small, costly, British publication from > Paul Robinson. Since I don't know VB personally, I would like to > see a copy of the unnamed article before I will believe it, but > it is unobtainable in the USA. The discussion I mentioned as an answer to a letter from a reader, who proposed the "more general" idea of modifying the executable extensions. If you badly need the article and provide me with a fax number, I'll fax a copy to you. > VB went into depth about "some" viruses which won't be affected by > this system. Didn't I already state that? What I had asked for the > "experts" to do was to indicate which types (or which specific > viruses would not work with this method. VB's reply was highly > generic (so far; but see below.) Well, my reply was exact - I told you that the existing non-resident viruses will be stopped by the "general idea" and that most of them will infect the files incorrectly (and thus make them crash) if your particular modification of the idea is implemented. It will cause the same effect to the "fast infection" function of the fast infecting viruses - but will not stop most of them from infecting in the usual way (i.e. on file execution). You seem to need particular data - i.e. which viruses exactly will be stopped and which not. Unfortunately, there are about 2,200 known viruses, and I definitively don't keep the properties of all of them in my head... > but if not I agree. The difference is in my proposal there is no > need to mess with COMMAND.COM which causes many problems of its own. Are there really so many programs that rely on the command interpreter being called "COMMAND.COM"? I don't know about any; my command interpreter is called 4DOS.EXE and it doesn't seem to cause any problems... > VB stated that "most viruses" will not be fooled by the EXE/COM > switch. I suppose we could all accept this statement by faith. I'm afraid that you'll have to; I don't have the possibility right now to verify that at least 1,101 viruses will not be stopped by your idea... > However, my original post did ask for details to justify any such > claim. VB later said that "dozens" of intelligent viruses would > still work despite my method. Isn't that a contradiction, > considering the large number of viruses out there? Well, if it can be shown that at least one virus is not stopped by a particular virus protection scheme, this means that this protection scheme cannot be relied on protecting you against all viruses... :-) How many viruses would you like to see that will not be stopped by your idea? > VB pointed out that "many" resident viruses infect files > during a DOS EXEC (function 4B). Is "many" a relative or absolute > term? What do you mean by relative or absolute? Almost all memory resident viruses infect on Exec. Most of the existing viruses are memory resident. By "most" here I mean "more than the half". Alas, you'll have to believe my work which is based on experience - I don't have the exact numbers handy. And, with about 2,200 known viruses, there are "many" viruses in almost any possible class... :-) > Even if they used EXEC, that does not mean that they will > succeed when the EXE/COM switch is pulled on them. At this point it Correct. For instance, the Jerusalem viruses infect on Exec, but -do- depend on the file extension - they consider *.??M files to be of COM-type and everything else to be of EXE-type. However, most resident viruses, especially the ones written nowadays, do make use of the MZ/ZM magic number. Again, I don't have exact numbers supporting my claim - it is based just on experience. > VB then goes on to say that those viruses which don't have smarts > "will crash". So VB says my method will stop non-resident viruses > and fast infectors. Great news! The method works with these two > entire CLASSES of viruses. This is not exactly what I said. The viruses that are not smart enough to use the MZ/ZM magic number, instead of the file extension, -will- be able to infect files, even if your idea is implemented. The files will crash -after- infection, which probably will lead to the early detection of the virus, but they will be infected anyway. That is, your particular idea will not -prevent- the infection even in those cases. The "more general" idea (changing the extensions to something completely different), however, -will- prevent the infection in those particular cases (non-smart viruses that infect on Exec). Second, I didn't say that the method will stop the fast infectors. I said that it will affect the fast infecting function of these viruses. That is, your particular idea will cause the infected files to crash after infection (if the virus is not smart enough) and the more general idea will prevent the infection (again, if the virus is not smart enough). The "regular" infection function of the viruses, however, will still work. And, most of the fast infectors (no exact numbers) do make use of the MZ/ZM magic number. > VB says it is not a "reliable protection scheme". And AN said it > was "not a sufficient solution". I agree that it is not sufficient; Actually we meant the same thing - that you cannot rely on it for virus protection. I think I have mentioned somewhere else in my message that it doesn't hurt to implement it - you just must not rely on it for protection. > VB educated me (and others, I hope) about using a COPY command > in AUTOEXEC to replace the COMMAND.COM file at bootup. Hey, I like > that too. Maybe a combination of these "little" things will make > a significant (but never "ideal") system. A similar "idea" is the ReadOnly attribute. Several dozens of the existing more than two thousand viruses are stupid enough to be unable to infect files with this attribute set. So, it doesn't hurt to set it, and it is cheap too. Just don't rely on it for virus protection. > conclusions. My question to APP is how do I resolve the difference > between the description in Norton's book and Duncan's book regarding > how to load a program WITHOUT executing it. One book says to use > subfunction 1 and the other says subfunction 3. Neither book gives > enough detail that I can gain a good understanding of it without > experimenting first. Take a look at Ralf Brown's Interrupt List. It's available in electronic form (e.g., oak.oakland.edu:/pub/msdos/info/inter33?.zip) and is an excellent reference about any kind of interrupts used on the PC. The virus writers seem to use it extensively (particularly the Tremor virus that appeared lately seems to be written "by the book"), so it wouldn't be a bad idea if the good guys can use the information too... :-) Particularly to answer your question - subfunction 1 means "load but don't execute" and is used by the debuggers. Subfunction 3 means "load external overlay" and is used exactly for that purpose. Both subfunctions are undocumented, I think... > Conclusion: My question to the "experts" was partially answered > when VB said that non-resident infectors and fast infectors would > be fooled by this technique. That is quite a statement of support > in my view, and makes this method worthy of consideration for some > environments. Again, I'm afraid that you have misunderstood me. I think I have already expressed my opinion more clearly this time, but here is the summary again: Your idea will cause most non-resident viruses and the fast infection function of some of the fast infecting viruses to infect the files incorrectly and make them crash on execution. It will not prevent infection, it will not stop most resident viruses, it will not stop the regular infection function of the fast infectors, and in general it shouldn't be relied on for virus protection. It doesn't hurt to implement it, but it's probably no much more protecting you than the ReadOnly attribute. Oh, yes, I almost forgot. There -is- one drawback in implementing your idea. Norton's SpeedDisk will refuse to move around the files whose extensions does not match the type while it is defragmenting the hard disk. It probably thinks that those files use some kind of copy protection scheme and doesn't touch them. It marks them as "unmovable files" but doesn't list them in the list of unmovable files, which confuses many people... > Question: Has this forum ever listed and categorized the existing > viruses? I would like to be able to construct a list of non-resident > and fast infectors that would be stymied by the EXE/COM switch. Sigh... This is yet another need for detailed and exact information about the existing viruses... Unfortunately, there are many information sources about viruses (check the FAQ), but none of them is complete, exact, or useful enough to provide you an answer to this question... :-( Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Sat, 20 Mar 93 21:26:03 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: F-PROT (PC) martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) writes: f you boot from a clean floppy, because Monkey encrypts > and moves the partition table data, so f-prot can't find the hard > disk partitions at all. (It should still be able to check the MBR, > though.) Indeed, it should be able to scan at least the MBR... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Sat, 20 Mar 93 21:48:47 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: IBM PC Boot Seq (was Partition table viruses (PC)) virusbtn@vax.oxford.ac.uk writes (about the ExeBug virus): > Therefore, if you boot from a clean floppy, and fdisk/MBR and SYS your hard > drive, any boot sector virus is gone, right? WRONG :( > All BIOSes are created equal - but some are more equal than others. If the > CMOS information tells *certain* BIOSes that there are no floppy disk drives > present on the system then the machine is booted from the hard drive. > Therefore every time you FDISK or SYS the hard drive, the virus re-infects, > because you are attempting to disinfect with the virus active in memory. That's correct, but particularly with ExeBug there is one more problem. First, the virus is stealth, so when it is active in memory, you cannot "see" that the MBR is infected. Second, when you try to boot from a floppy, due to the CMOS "fix", the machine boots from the hard disk and loads the virus. However, the virus checks whether a floppy is present in the A: drive, and if it is so, BOOT FROM THAT FLOPPY. So, if you don't watch -very- carefully, it LOOKS as if you have booted from a floppy. A quick inspection of the MBR enforces this impression, because the virus stealths the MBR... > This doesn't work on all PCs, but is a problem on some. However, there are > free utilities available which can disable the virus in memory, and then > disinfect the hard drive. It's messy, but unfortunately that's the way it is. Another way is to run the CMOS setup program (usually by hitting Del during the bootstrap) and to correct it to indicate that drive A: -is- present. > Low level formatting works too, as this routine is usually executed from ROM. > However, Low level formatting is a last resort - you don't need to do that > to recover. Low level formatting is NEVER necessary and can be DAMAGING to some IDE drives. In short, don't do that. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Sat, 20 Mar 93 22:01:11 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Minnow-V virus correction (PC) fergp@sytex.com (Paul Ferguson) writes: > BL> I was aware of Zero Hunt inly infecting files with areas of 00 > BL> hex. Usually data or buffer areas. This is how that Zero Hunt > BL> can infect files, but not show a increase in the filesize. > > Bill, this area is called "stack space". The oiginal sample of the > Minnow-V (the original name of the virus; I think one of the McAfee Sorry, Paul, but it is not called like that, in general. It is true that COMMAND.COM contains an area of zeros that it uses as stack space. It is also true that usually, if you don't initialize your stack segment, the linker will fill it up with zeros. However, the Zero_Hunter viruses do not look particularly for stack areas; they are just looking for any areas of zeros which is large enough to contain the virus body, regardless what the purpose of this area is. > two viruses), but rather, Minnow-V is an infect_on_execute (host), > TSR virus. According to Patti Hoffman's reference, there is a 411 byte > variant, although I have never seen it. It does exist; we have it. BTW, the "original" variant is 415 bytes, not 416. We are currently calling those viruses Zero_Hunter.A and Zero_Hunter.B, although Zero_Hunter.416 and Zero_Hunter.411 is probably more appropriate... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Sat, 20 Mar 93 22:10:02 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: New (?) virus ? (2294) (PC) v922340@hildebrand.si.hhs.nl (Ivar Snaaijer) writes: > TBSCAN (v5.04) showed behind a lot of files a U and a K witch mean > an undocumented dos call and an odd stack. executing a file that didn't > have the UK flags, resulted in the fact that it did get the flags, > I have beta tested TBSCAN v5.10 witch claims it is the 2294 virus, You probably have the Terminator_II virus. It seems to be in the wild in the Netherlands. > (v5.04 doesn't recognize it) ... it stroke me like an abnormality, > because TBSCAN had recognized all the viruses i have on stock, I v'e tried > F-PROT witch says that the file is strange but doesn't report a virus > eigter, SCAN v99 doesn't see anything, and i gonna try v102 this afternoon > Is there anybody who can tell me more about this virus. (acept it is > 2294 bytes long) F-Prot 2.07 still does not recognize it. Dr. Solomon's FindVirus 6.15 does recognize it and calls it Term-2294. SCAN 102 does recognize it too, but reports it as two viruses - Bert [Bert] and Terminator 2 [Term2]. Don't confuse this with Terminator-B, which is reported as Terminator 2 [Tm2] by SCAN (note the difference in the virus id) or the Terminator.918 and Terminator.1501, which are reported as Cuban [Cub] by SCAN... Lots of naming confusion, I know... :-( Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Sat, 20 Mar 93 22:17:55 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Removing virus on stack drive (PC) pwong@igc.apc.org (Pete Wong) writes: > I recently discovered that a virus exist within my computer. My PC is > stacked with a Stacker. I used the Norton Anti-Virus to scan the drives and > it advised me to turn off the computer and boot it up again with an un-affect e > boot disk. Since my drives are stacked, the NAV would not read drive C or D. > I also tried to boot it up with the Stacker files in the un-affected DOS boot > up disk. Once I use the NAV to scan the drives, it would say there is a viru s > detected in the memory and then it would not scan any further. This goes the > same for scanning the floppy drives. > The virus is called Stoned. Stoned infects only the first -physical- disk drive (80h). In theory, it is possible to find it on another physical drive - if you have installed an already infected hard disk as a second one. It -never- infects logical disk volumes, like the ones created by Stacker. Therefore, you can safely reboot from a clean diskette and remove the virus from your hard disk, regardless that you are not able to access the stacked volume. NAV must be able to do that. If it isn't - call your local Symantec tech support. Another possibility is that the whole story is just a ghost false positive - NAV is detecting some scan string in memory, not necessarily the virus. Make sure you have disabled any other anti-virus programs (like VSAFE from CPAV) when you are performing the virus check. What happens if you boot from a clean floppy? You can't access the stacked volume, of course, but does NAV still find the virus in memory? If it doesn't, then it is certainly a false positive. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 21 Mar 93 23:44:00 +0000 >From: kari.laine@compart.fi (Kari Laine) Subject: Uruguay on PS/2 ref disk (PC) There is something funny F-Prot has given false alarms on several different files about Uruguay-virus and when I tried whether it will really find the Uruguay-virus - it didn't find not at least the sample I have - funny. Kari Laine FVRC +358-0-502 1456 - ---- +-----------------------------------------------------------------------+ | Delivered by: ComPart BBS Finland +358-0-506-3329 19 lines V.32bis | +-----------------------------------------------------------------------+ ------------------------------ Date: 22 Mar 93 00:25:00 +0000 >From: kari.laine@compart.fi (Kari Laine) Subject: Problems w/ lan prrotect (PC) Hello Paul, You seem to list all the important properties BUT not the ability to find viruses. If I were you I would have a little more straight look on that property concerning Intel LANProtect. Whew thats some kind of a network you are referring - 70 servers ?! Hope you don't get virus there - would make kind of a havoc in that environment Regards Kari Laine FVRC BBS +358-0-502 1456 - ---- +-----------------------------------------------------------------------+ | Delivered by: ComPart BBS Finland +358-0-506-3329 19 lines V.32bis | +-----------------------------------------------------------------------+ ------------------------------ Date: 22 Mar 93 01:22:44 +0000 >From: physmsa@phys.canterbury.ac.nz (Mark Aitchison, rm814,ext6947) Subject: Re: Signitures (PC) Note that DOS executables (even .COM files) may start with either MZ or ZM; not many use ZM but the system still checks for it. These are the initials of somebody involved with PC/MS-DOS around about version 2. Viruses might go to the bother of checking for ZM as well as MZ simply for the sake of completeness (I wonder how many do - you might be able to stop a few by switching the M & Z and see how many viruses can still infect; not enough to make it worthwhile probably, but it might be a fun exercise). Just possibly, some virus swaps them as a signature for itself, rather than changing the seconds of the date stamp, etc. Personally I'd be suspicious if I saw a file that starts "ZM" since it is so extremely command to use MZ. Mark Aitchison, - ------------------------------------------------------------------------------- Mark Aitchison, Physics & Astronomy Phone : +64 3 3642-947 University of Canterbury, Fax : +64 3 3642-999 Christchurch, New Zealand. E-mail: phys169@csc.canterbury.ac.nz - ------------------------------------------------------------------------------- ------------------------------ Date: 22 Mar 93 01:46:02 +0000 >From: physmsa@phys.canterbury.ac.nz (Mark Aitchison, rm814,ext6947) Subject: Re: [Stoned] (PC) theodore@unity.ncsu.edu (Andrew M Smith) writes: >Has anyone heard of the [Stoned] virus and if so, then what does it do? > Yes. This virus is VERY very common :-(. Grab a copy of the FAQ. >Also, I have an odd question concerning infected disks...If I have an >infected disk and run a magnet across it, will all data (and the virus) be >erased??? Yes, so long as the disk then needs reformatting. Don't do this with hard disks, of course. The sort of magnets that hold things to fridges, etc, can reliably wipe 5.25 inch disks by wiping the magnet across both sides of the diskette while it is still in the envelope. Probably it can be wiped with less than this... my experiments a few years ago show that at about a foot away no domestic magnet would wipe any bytes from a disk, and against the outside cover all reasonable magnets would totally wipe any 5.25 inch disk. It is very hard to wipe a 3.5 inch diskette, though. But you don't need to use a magnet. Reformatting should do it (there are a few caveats to this: (1) Some viruses write code on an extra track (most diskettes drives can do one or two more tracks than DOS uses)... this wouldn't be removed but is no problem since it cannot be executed after teh boot sector is replaced (2) Some modern format programs do a quick format that might leave some virus there - I haven't found one yet that leaves a live virus, but possibly it could happen if it was doubly-infected in the first place - very unlike ly though! (3) If the format was written by a 360Kb drive, formatting with a different dr ive can leave a thin part of the original track. It is uncommon for this to be a problem, but I have twice seen diskettes that were formatted yet some of t he original sectors could be read on the original drive. It is a good idea t o reformat or disinfect 360Kb diskettes on a 360Kb drive, or wipe them with a magnet. Virusses or not, writing to 360Kb diskettes in a 1.2Mb drive can h ave unreliability problems (for a long time now I haven't had problems, but it is still error-prone). Mark Aitchison, - --- - ------------------------------------------------------------------------------- Mark Aitchison, Physics & Astronomy Phone : +64 3 3642-947 a.h. 3371-225 University of Canterbury, Fax : +64 3 3642-469 or 3642-999 Christchurch, New Zealand. E-mail: phys169@csc.canterbury.ac.nz - ------------------------------------------------------------------------------- ------------------------------ Date: Mon, 22 Mar 93 02:27:23 -0500 >From: Michal Weis Subject: Re: 'MZ' and 'ZM' signatures (PC) Yes, that is right, that viruses test 'ZM' and it meens 'MZ' in memory: cmp word ptr ds:[0000], 'ZM' this instruction is used in viruses to check if it is a EXE file - it test the EXE signature MZ (Lo Hi - intel's notation). That's right, but... I've analyze some viruses and they test for 'ZM' too (i think it was pogue or dedicated2sara): it test it this way: cmp word ptr ds:[0000], 'ZM' ; test for normal 'MZ' EXE signature : and: cmp word ptr ds:[0000], 'MZ' ; and now test for 'ZM' in EXE signture. WHY? I don't know, but I'm sure that they test for 'MZ' and for 'ZM'. What meen 'ZM' signature? Ask Microsoft (may be)... Regards, - -- This is not a trick, this is --- _ ---------------------------------- , _ _ | ) , /| / )/ ) |/ /| / | / / / /---' | ' \_/ / (_/|\ \_/ - ------------------------------------ |_) ---- Origin: weis@elf.stuba.cs -- ------------------------------ Date: 22 Mar 93 10:35:25 +0000 >From: demetre@phaethon.intranet.gr (Demetre Koumanakos) Subject: Vir-Sig (PC) Hi all, It has been now more than 2 months since I was able to find a new Vir-Sig file for TBAV from any of the known sources (Simtel, garbo.uwasa.fi, ect.). Does anyone know if there is a newer version of Vir-sig dated January 1993 ? If yes, were can I FTP it from ? +----------------------------------------------+ | Demetre Koymanakos - Amazing Remote CBCS | | +30-1-8136778 - V32 V42bis - 24hours | | Athens - Greece | | Internet : demetre@intranet.gr | | IntlNet : 57:3003/3 FidoNet : 2:410/101 | +----------------------------------------------+ ------------------------------ Date: 20 Mar 93 17:57:00 -0600 >From: "Rob Slade" Subject: Memoirs of an (untrustworthy) virus researcher (CVP) MEMOIR3.CVP 921214 Memoirs of an (untrustworthy) virus researcher I had been involved with a three day data communications course. These types of seminars are generally pretty intense. At the end of the thrid day, the other instructor and I were "winding down", when one of the hotel pages showed up with a message for me. Unusually, this course was in my home town. The message was from my wife, and, to make a long story fit into the restraints I place on this column, she was passing along an emergency message. One of the financial institutions in town had been hit by a virus. In a panic, they had phoned the sysop of a board that I supported. The sysop, at the insistence of the bank, phoned my home. My wife, at the insistence of the bank, called the hotel. (This may seem like window dressing, but the insistence of the bank does form an important part of this story.) Those of you who have been in this position know that "virus attacks" usually don't involve viral programs. They are far more likely to involve things like power cords, diskettes that have been stapled to folders and disk caching programs. In addition, it was the end of a long, hard three days. But, when the call goes out, you heed the call, right? I phoned the contact at the bank. To my surprise, the contact was fairly knowledgeable about computers. Even better, careful note had been taken of all the untoward activity. It certainly sounded viral-like. What was more, it was a completely unknown virus behaviour, seemingly circumventing the security of a certain LAN OS (whom we know but do not name). All of this took only about ten minutes to ascertain. Having discussed all this at length, I stated that I concurred that this was a viral occurrence. However, given that it was unknown, I could not proceed any farther until I actually got to their site and ran further tests. At this point, we hit a snag. "Oh, no" she said. "You can't come down here. It would violate our security." I must have misheard. Their security was already compromised, was it not? Yes it was, she confirmed. To a sufficient degree that she had pestered my friends, colleagues and family until she got me? Yes. And we had determined that this beast was exhibiting viral behaviour, but was an unknown quantity. Yes. Yet the bank, having determined that it had a significant yet unknown virus loose in their LAN, would not allow the expert they had called upon into the data centre (for the purpose of dealing with said problem) because the entry of the security consultant would constitute a security risk? Yes. In other words, their security was broken, but they wouldn't let me fix it because that violate their security. Exactly. There was, of course, only one thing to say. "Good luck." copyright Robert M. Slade, 1992 MEMORI3.CVP 921214 ============== Vancouver ROBERTS@decus.ca | Slade's Law of Computer Institute for Robert_Slade@sfu.ca | Literacy: Research into rslade@cue.bc.ca | - There is no such thing User p1@CyberStore.ca | as "computer illiteracy"; Security Canada V7K 2G6 | only illiteracy itself. ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 48] *****************************************