From lehigh.edu!virus-l Thu Nov 19 23:15:32 1992 Date: Thu, 19 Nov 1992 10:23:44 -0500 Message-Id: <9211191448.AA21875@barnabas.cert.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@cert.org Reply-To: Sender: virus-l@lehigh.edu Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "Kenneth R. van Wyk" To: Multiple recipients of list Subject: VIRUS-L Digest V5 #185 Status: R VIRUS-L Digest Thursday, 19 Nov 1992 Volume 5 : Issue 185 Today's Topics: Re: SCAN Ver 97 & Monkey Virus (PC). Re: Need info on MONKEY virus (PC) Re: SCAN 95b doesn't find MtE in EXE files (PC) Re: Dangerous bug in CLEAN 97 (PC) Re: F-Prot's (v2.05) memory scanning. (PC) Re: How good is Norton Antivirus? (PC) Monkey Virus (PC) Re: How good is Norton Antivirus? (PC) Re: KEY Press virus & McAfee v97 (PC) F-PROT question (PC) Re: VSUM Listing (PC) Apologies to Padgett, and clarification (PC) Stoned virus Recovery (PC) Re: SCANV97 don't work in OS/2 dosbox (OS/2) (PC) re: CHRISTMA effects (CVP) Re: CHRISTMA Effects (CVP) Things that keep me awake at night Australian anti-virus site Being forthcoming... MtE detection tests (part 1/5) (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. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu 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 ---------------------------------------------------------------------- Date: Tue, 17 Nov 92 03:43:45 +0000 From: mechalas@mentor.cc.purdue.edu (John Mechalas) Subject: Re: SCAN Ver 97 & Monkey Virus (PC). martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) writes: >But it isn't trivial, so instead you might want to get a copy of >my KILLMONK program, which does that and more for you. It uses >some careful identification strings, checks that the recovered MBR >is correct, etc. Also makes scanning and cleaning of floppies >easy. And strictly speaking, it doesn't require a clean boot, as >long as the only virus messing things up at the time is Monkey. > >I think KILLMONK may have been posted at some of the ftp sites. >If you can't find it, or want me to send it (uuencoded) via >e-mail, drop me a note. (It's free of course, and worth every >virtual cent!) I found killmonk.zip at oak.oakland.edu, so I assume it is at all of the SIMTEL20 mirrors. It's in the trojan-pro directory, by the way. - -- John Mechalas | If you think my opinions are Purdue's, then mechalas@mentor.cc.purdue.edu | you vastly overestimate my importance. Purdue University Computing Center | Help put a ban on censorship :) General Consulting | #include disclaimer.h ------------------------------ Date: Tue, 17 Nov 92 01:42:46 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: Need info on MONKEY virus (PC) >From: martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) >Third, the Monkey virus specifically (and successfully) >bypasses Padgett's Disk Secure program. This virus represents >a rare case: a very specific attack against a very specific >disk security system. Fortunately most scanners will find >the virus in memory. Again this stresses the importance of >having a multi-layer antivirus strategy. Like I said, no software is proof against a directed attack, *however* the DOS validator (CHKSEC) in the latest DS will detect the fact that the proper code is not resident in memory and the Monkey cannot prevent *that*. Incidently, it was said that FixMBR cannot remove the Monkey - this is true however if FixMBR was executed *before* infection and the .DAT file saved, use of it as directed after booting from floppy will restore the MBR & table as will the DiskSecure recovery disk. Cooly (in Chicago in November ?) Padgett ------------------------------ Date: Tue, 17 Nov 92 07:32:33 +0000 From: mcafee@netcom.com (McAfee Associates) Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC) Hello Vesselin, you write [a ">>" means I write] [...part about SCAN 97 missing representative samples from each set of your MtE-based viruses deleted for brevity...] > Unless, of course, you mean my previous >message, in which I stated that SCAN 95b does NOT detect the MtE-based >viruses in ANY infected EXE files AT ALL, which is also true. Correct. SCAN 95-B was released before we had any samples of MtE-based viruses which infected .EXE files. Detection was added in V97 (the V96 release was skipped due to a Trojan horse). >Regardless which of my messages you meant, they are both true and I >have facts that prove both of them. If you consider my message about >those facts to be alarmist, you are free to think so. Try to explain Okay. >it to your users. But please, don't object the facts. The facts are I have been :-). I don't believe I was objecting to your results. >that SCAN is still unable to detect reliably ANY of the MtE-based >viruses. It was my duty to warn its users about this. [... my comments about MtE-based virus spread deleted...] >I am not arguing about how widespread the MtE-based viruses are. They >are not. What I am arguing about is that SCAN 97 is not able to detect >reliably ANY of them. For a known virus, there is no such thing as >99.8% detection. You either can detect it, or you cannot. Try Are you sure? I can see two opposing schools of thought forming here: One of "all or nothing" detection (the binary operation school of thought), and one of "percentages" of detecting (the analog school of thought)? Without getting too far off track, here, I believe that there will be more "percentage" reports in the future, especially as more complex forms of viral code emerge. >explaining your users that they should not be alarmed, because SCAN >misses "only" about one infected file in every 50. Besides, 319 missed >samples of 15,994 is 98% (not 99.8%), i.e. one missed sample in every ^^^^^^^^^^^^^^^ My mistake. Sorry about that. >50. [...my suggestion for wording of reports deleted...] >OK, I'll use this wording the next time. But I will not miss to say >that "SCAN version xx missed X out of Y samples of the Z virus, which >means that this version of SCAN is NOT able to detect the Z virus >reliably. I've notified McAfee Associates of the problem and they will >(hopefully) fix it shortly." Beautiful. >> >an article posted somewhere (maybe even here), which described how >> >McAfee Associates sponsored a particular set of anti-virus product >> >evaluations and insisted that only old versions of the scanners of >> >their main competitors were tested. > >> McAfee Associates has sponsored (that is, paid for) anti-virus product >> testing by a number of independent organizations, using then-available >> versions of competitors' anti-viral programs. To do otherwise would be >> worthless. > >More exactly, the article said that McAfee insisted that OLD versions The article (I wish I knew which one) could have have said that. It does not mean that it is true, though. >of the competitive scanners were used in those tests and that he was >quoted saying that he wants his competitors to show worse results in >such tests. To do otherwise might be worthless from the economical I think its fairly easy to guess that John McAfee would like his programs to do better then anyone else's in a test. I'm sure that is hardly unique, though. >point of view, but it would be honest from the human point of view... [...deleted...] >I hope so. This is one of the reasons for posting my message. Just >have in mind that the bugs in security-related software (like >anti-virus programs) are more dangerous. I'll do my best to continue >reporting them. If possible, would you mind sending me a copy of any such reports? (Only on McAfee Associates software, that is). Thank you. Regards, Aryeh Goretsky Technical Support PS: SCAN V99 should be available about the time you read this. I'd be very interested in hearing how it does--the MtE-based virus detector was rewritten. AG - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | mcafee@netcom.COM Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714 95054-3107 USA | USR HST Courier DS | or GO MCAFEE Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR ------------------------------ Date: Tue, 17 Nov 92 07:38:39 +0000 From: mcafee@netcom.com (McAfee Associates) Subject: Re: Dangerous bug in CLEAN 97 (PC) Hello Vesselin, you write: [...message about CLEAN not removing the Michelangelo from 1.2Mb diskettes deleted for brevity...] >McAfee Associates has been notified of the bug and they are probably >already working on the solution. Hopefully, the bug will be fixed in >the next release of CLEAN. [...deleted...] Noted and in the queue of things to be looked into. A new version of CLEAN should be ready early next week fixing this, barring any unforseen problems. Regards, Aryeh Goretsky Technical Support - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | mcafee@netcom.COM Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714 95054-3107 USA | USR HST Courier DS | or GO MCAFEE Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR ------------------------------ Date: 17 Nov 92 08:58:23 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: F-Prot's (v2.05) memory scanning. (PC) cz1jed@orac.sunderland-poly.ac.uk (J.EDWARDS) writes: >After hours of failing to get Windows to install, the owner suddenly >announced he thought his computer might be infected. I ran F-Prot >straight away and sure enough it announced it had detected 'Stoned' in >memory. I booted from my clean floppy and when running F-Prot again >it claimed the hard-disk was infected with not 'Stoned' but >'Michaelangelo'. The reason for this is simple - The memory scan only reports the virus family, not the exact variant name. As Michelangelo has been classified as a member of the "Stoned" family, it reports "Stoned". When you scan the boot sector, F-PROT identifies the variant - in this case Michelangelo. - -frisk ------------------------------ Date: 17 Nov 92 09:02:20 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: How good is Norton Antivirus? (PC) sbonds@jarthur.Claremont.EDU (007) writes: > + The ability to allow the user to add new scan strings, including the use > of wildcards. (F-prot does this w/o wildcards.) No - you can use wildcards - although it does not allow variable-length wildcards. A "??" in the pattern stands for a single, variable byte. - -frisk ------------------------------ Date: Tue, 17 Nov 92 08:16:51 -0500 From: William Webber Subject: Monkey Virus (PC) Copy of Monkey virus found: UK London (JMP 01D0). Reguards William Webber... ------------------------------ Date: Tue, 17 Nov 92 15:47:41 +0000 From: C.Bradford@cs.ucl.ac.uk Subject: Re: How good is Norton Antivirus? (PC) My norton anti-virus is very old, but it does the job. Although it keeps moaning about it's age.....oh well......ho...hum ------------------------------ Date: 17 Nov 92 17:08:43 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: KEY Press virus & McAfee v97 (PC) mcafee@netcom.com (McAfee Associates) writes: > >point is, however, that SCAN is occasionally not very accurate in determinin g > >exactly which virus you have. > I understand that, believe me. We will fix any such problems reported > to us. Will you? Any such problems? Let's hope... Because, if memory serves correctly, I am reporting such problems to you since about a year... Such problems include: 1) Viruses mentioned in VIRLIST.TXT but never reported by SCAN. 2) Viruses reported by SCAN but never mentioned in VIRLIST.TXT. 3) Viruses mentioned under one name in VIRLIST.TXT, but reported under a slightly different name by SCAN. 4) Viruses described with wrong properties in VIRLIST.TXT. 5) Several (often - completely different) viruses reported with one and the same name. This is the most dangerous problem, since it causes misidentification. As a reply of one of my reports about these, I got a very angry reply from John McAfee himself. The reply was posted from your account, so you should know about it. It claimed that the viruses mentioned by me are actually closely related. Those viruses were Number of the Beast, Compiler.1, and Darth Vader. Anybody who has bothered to disassemble them knows that they are completely different... BTW, SCAN 97 still reports all the three of them as "512 [512]"... :-( 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.0 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: Tue, 17 Nov 92 12:21:12 -0500 From: tuan Subject: F-PROT question (PC) Virus-lers, Can any tell me why "Blem wit" is the program name when I load virstop.exe? Background: PS2 node connected to novell netware LAN...Ipx and net5 are loaded first and then virstop is loaded from the network drive. Is this a problem? if no, why does it occur? if yes, what are the side affects? thank you for all your help. -tuan nguyen- programmer pace university ------------------------------ Date: Tue, 17 Nov 92 18:27:53 +0000 From: gerald@vmars.tuwien.ac.at (Gerald Pfeifer (Prak Gusti)) Subject: Re: VSUM Listing (PC) 0005555440@mcimail.com (Scott Begin) writes: > [ Some questions about VSUM ] Yes, it runs an 8088 to 80486, and on Hercules as well as on VGA.... The VSUM-package contains everything you need except DOS.... It is available on most antiviral FTP-Sites (try risc.ua.edu, urvax.urich.edu) BUT: Some experts (Bontchev, Frisk...) in this group do *not* recommend VSUM. A while ago I heard that the VTC Hamburg (where Bontchev works) is going to release a dBase version of there virus catalog. I have not seen it yet, but if anyone in this group knows, please let us know..... Please no flaming about this topic!!!! Gerald ........................................................................... . Gerald Pfeifer (Jerry) Technical University Vienna, Austria . . gerald@kongo.vmars.tuwien.ac.at Home: Mondweg 64, 1140 Wien, Austria . ........................................................................... . Sorry, I'm not a native speaker (flames to /dev/null) . ........................................................................... ------------------------------ Date: Tue, 17 Nov 92 12:20:55 -0700 From: martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) Subject: Apologies to Padgett, and clarification (PC) Reading over two of my recent posts, about the Monkey virus, I realize one could get the impression I am critical of Padgett Peterson's "Fixutils" and "Disk Secure" packages. Not at all! I still find Disk Secure to be the best, simplest, and cheapest software way I know of to protect against MBR infectors. That's why the University of Alberta uses it in all its "public access" DOS computer labs. And that, unfortunately, is why Monkey was written to by-pass Disk Secure. Far from a statement against Disk Secure, this is a lesson on the limitations of any software-based protection system: a directed attack, however unlikely, is always a possibility. Similarly FixMBR demonstates an interesting and straightforward way to recover from almost all MBR viruses. But not from Monkey, and presumably once again for the same reason. :) Tim. ------------------------------------------------------------- Tim Martin * Spatial Information Systems * "I really don't see how returning University of Alberta * the product helps me." martin@cs.ualberta.ca * ------------------------------------------------------------- ------------------------------ Date: Wed, 18 Nov 92 00:20:07 +0000 From: rahul@hfglobe.intel.com (Rahul Ravel) Subject: Stoned virus Recovery (PC) Hi all, About 1 1/12 weeks ago I posted a query on how to get rid of the Stoned virus on a friend's pc. Just wanted to say 'Thanks" to all who e-mailed. FYI, I used Paul Padgett's FixMBR utility to restore the original boot record. No loss of data. Thanks, Paul! - -Rahul, rahul@hfglobe.intel.com "Only my own opinions here" ------------------------------ Date: Tue, 17 Nov 92 05:27:09 +0000 From: sci240s@monu6.cc.monash.edu.au (Wey Jing HO) Subject: Re: SCANV97 don't work in OS/2 dosbox (OS/2) (PC) co@bildsun1.mednet.gu.se (Christer Olsson) writes: >I'm trying to use scan version 97 in a DOS-box but OS/2 trows out the >scan with an error message saying that SCAN uses illegal 386 >instructions. >Version 95 works fine, but not 97. >The machine is a AST 486/E Premium at 33 Mhz with 10 Mb of memory and >OS/2 2.01 beta. It works for me in OS/2 with the OCT'92 CSD applied. The only complains I get are that certain files are currently being used. - -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Wey Jing Ho Tel: 61-3-573-2567 E-mail : sci240s@monu6.cc.monash.edu.au< >Physics Dept., Monash University ( Caulfield Campus ), Melbourne, AUSTRALIA< ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ------------------------------ Date: Tue, 17 Nov 92 12:29:59 -0500 From: "David M. Chess" Subject: re: CHRISTMA effects (CVP) > From: rslade@sfu.ca >IBM's internal network, >VNET, was more heavily hit than either EARN or Bitnet, and drastic >action, in the form of a general system shutdown, was felt to be >needed to clear up the mess. This is an urban legend, I'm pretty sure (if you have a good primary source for the statement, let me know). I was on vacation when CHRISTMA hit, but was involved to some extent in the followup investigations. As far as I know, VNET was never shut down as a whole; it was even more a distributed system then than it is now, and I don't think anyone knew then of a way to shut it all down if they'd wanted to! The various systems that were hit responded in various ways. Some wrote little demons that went through and purged any CHRISTMA EXECs that showed up in the spool, some that were lightly hit did this manually, and some that were very heavily hit no doubt elected to shut down while dealing with it. But the story that "IBM's internal network was completely shutdown" is a myth, as far as I know... DC ------------------------------ Date: Tue, 17 Nov 92 08:38:29 -0500 From: Bridget Rutty Subject: Re: CHRISTMA Effects (CVP) The CHRISTMA exec did NOT destroy itself after sending copies. I erased several from our users minidisks. Also, I did not have to shutdown our system. I just listed all the reader files in the system and purged any CHRISTMA exec I found. But, there weren't many - I forget exactly how many there were but it was less than a hundred. Other sites merely drained their RSCS links (software that delivers mail and files to other computers) while they cleaned up. There may have been some sites that found it necessary to shutdown but I have not heard of any. What really stopped the explosion of files was the BITNET sites that installed a trap in RSCS to erase any CHRISTMA file sent to it. When installed in a few strategic nodes, this trap is very effective at stopping this type of trojan horse. Two more attempts at distributing CHRISTMA were stopped as well as a couple of others whose names I forget. The defense is good enough that most people aren't aware of the subsequent attacks. I haven't seen any attempts to distribute such trojans in a couple years. Bridget Rutty SYSBXR@SUVM.BITNET ------------------------------ Date: 17 Nov 92 02:14:30 +0000 From: ygoland@edison.SEAS.UCLA.EDU (The Jester) Subject: Things that keep me awake at night Silence. That is what I hear on this net.group. I hear silence. There is some discussion about a particular program's ability to detect a virus and then there is the reason I still read this group, new product announcements. But the one thing I'v never seen is a discussion of the mechanics of fighting viruses. Is the viral world satisfied with it's basic tools, scanner, activity/change monitor, and heuristic analyizers? Is that the end? Are all of the people in the community doing nothing more than comming up with new scan codes for whatever virus has shown up this week, trying to understand the ugly inards of some os so they can tweak their monitors a little better, and trying to see yet another combination of code that only a virus would use? Why is there no real discussion on techniques and ideas? Is this part of the conspiracy of silence that infects the viral community? Just curious, Yaron (The Jester) Goland - -- RSA proved you could patent math, whats next? Fire? "Sorry, you can't rub those two stones together! First is a Patented Process" -The Jester ------------------------------ Date: Tue, 17 Nov 92 05:58:41 +0000 From: bob@psychnet.psychol.utas.edu.au (Robert G. Reid) Subject: Australian anti-virus site An small selection of current Anti-Virus software is once again available for Australian net users (AARNET) at: ftp.psychol.utas.edu.au (131.217.35.98). Please address any correspondence re this facility to: bob@psychnet.psychol.utas.edu.au - -- bob@psychnet.psychol.utas.edu.au ------------------------------ Date: Sat, 14 Nov 92 16:16:45 -0500 From: tyetiser@umbc5.umbc.edu (Mr. Tarkan Yetiser) Subject: Being forthcoming... Hello Aryeh, mcafee@netcom.com (McAfee Associates) writes: > Bugs can be fixed. Bearing in mind that I am, after all, a McAfee > Associates employee, I believe that McAfee Associates (and myself) have > been very forthcoming to users about reporting bugs, fixing them, and > suggesting workarounds while the bugs do get fixed. In keeping up with this tradition of open communications with your users, would you please share with the readers of this newsgroup the press release from McAfee Assoc., dated May 11, '92 and titled "Dark Avenger Mutation Engine No Threat to Protected PCs", with the contact name Mr. McKiernan? Out of curiosity, is William McKiernan a McAfee agent or employee? If the requested article is not posted here, curious individuals can contact me by e-mail to get a copy of what I am talking about, and judge for themselves the nature of the statements made there. I shall not comment. [Moderator's note: It is with great trepidation that I am approving this message. Gentlemen, before this gets out of hand, I want to remind you both to keep this discussion civil. Otherwise, you can eliminate the middle man by forwarding any follow-ups directly to /dev/null... :-\] Regards, Tarkan Yetiser VDS Advanced Research Group P.O. Box 9393 Baltimore, MD 21228, U.S.A. (410) 247-7117 ------------------------------ Date: 02 Nov 92 18:12:38 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: MtE detection tests (part 1/5) (PC) Hello, everybody! Here is the long awaited report about the MtE detection tests that we performed at VTC-Hamburg. It is rather longish, so maybe Ken should consider splitting it into parts. Normally, I should have put it for anonymous ftp, instead of publishing it here, but the preliminary results of the tests raised enough interest and discussions, so I decided to publish it in a whole in this newsgroup. Nevertheless, it - - -is- available for anonymous ftp as ftp.informatik.uni-hamburg.de:pub/virus/texts/tests/mtetests.zip [Moderator's note: The complete text of Vesselin's MtE tests are also available from: cert.org:pub/virus-l/docs/mtetests.zip As I had previously indicated, I have broken Vesselin's tests down into five parts and will post each seperately.] Enjoy. Comments, questions, and suggestions are welcome. 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.0 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 ===== [part 1/5] MtE Detection Tests 1. What is the MtE and what is all this fuss about. MtE stands for "MuTating Engine". This is a library routine, written mostly by the Bulgarian virus writer known as Dark Avenger. It comes as an .OBJ file. Every virus writer could simply link this routine to his viruses. He must also call the routine in a special way and this will make the virus to which the MtE is linked extremely polymorphic. That is, each new instance of the virus in each new infected file will look differently. This is achieved by encrypting the virus body, using each time a different key. The idea is not new - even the old Cascade virus does this. However, the virus must eventually execute itself, therefore it must decrypt itself. Viruses like Cascade always have a small unencrypted part in the beginning, called "decryptor". It's task is to decrypt the rest of the virus body. Because the major part of the virus body is differently encrypted each time, no scan string can be selected from it - it just looks differently in each infected file. However, one can pick a scan string from the decryptor, because it is not encrypted and looks always in the same way in all files. This is exactly how the scanners handle viruses like Cascade. The polymorphic viruses like Phoenix, Tequila, V2P6, etc. take the self-garbling one step further. They also have an unencrypted decryptor in the beginning, but the decryptor is not always one and the same - the virus modifies it from one infection to another. Some viruses make just simple modifications, so their decryptors can be detected, using a wildcard scan string. That is, a scan string that can contain "don't care" bytes - indicating that the particular value of that byte is not important. The more polymorphic the virus, the more difficult is to scan for it. Some polymorphic viruses are so sophisticated, that it is not possible to detect all forms of their decryptors, even if wildcard scan strings are allowed... Such viruses are V2P6, V2P6Z, and others. In order to detect them, the scanners must use a special, algorithmic approach, specific to each particular virus. This is very difficult and time consuming, since the producer of the scanner must analyze very carefully the polymorphic engine of each such virus, and figure out what code it can generate, and write a special "detection engine" to detect this code. In general, the ability to detect extremely polymorphic viruses reflects the quality of the R&D department of the particular producer of anti-virus software. The viruses that are using the MtE (we'll call them MtE-based viruses) are extremely polymorphic. Much more than V2P6Z, for instance. And there are still many scanners on the market, that are unable to detect reliably even this relatively old and simpler virus. Furthermore, V2P6Z is relatively simple as virus - it is based on the old Vienna virus and does essentially the same. It is not very infectious, because it is nonresident and infects only COM files in the current directory and in the directories listed in the PATH variable. Since the MtE can be linked to any new virus, nothing prevents the virus writers from writing extremely sophisticated, infectious, and destructive viruses, that will be hard to scan for. Fortunately, the MtE cannot be used to make an already existing virus polymorphic. The virus has to be re-designed from scratch, in order to make it MtE-aware. However, nothing prevents a virus writer from writing a new virus (or modifying the source of an already existing one) and to make it MtE-aware. Therefore, it is only a question of time, before such viruses appear and are spread widely. That's why, it is important that the currently existing scanners are able to detect the MtE-based viruses reliably. Currently only a few MtE-based viruses exist, and all of them are either incredibly stupid, or buggy, or both. Neither of them represents a significant threat, and neither of them is able to spread widely. However, as explained above, detection of MtE-based viruses is important, in general, therefore, detection of the currently existing MtE-based viruses demonstrates an important ability of the scanners. Currently, the number of the scanners that claim to be able to detect the MtE-based viruses is no more than 2-3 times the number of the already existing MtE-based viruses... As we shall see below, the number of them that are able to do this reliably, is even smaller. ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 185] ******************************************