Return-Path: Received: from IBM1.CC.Lehigh.EDU by abacus.HGS.SE (SunOS 4.1/SMI-4.1-01) with sendmail 4.1/SMI-4.1-01 id AA12193; Fri, 26 Jun 92 21:28:21 +0200 Message-Id: <9206261928.AA12193@abacus.HGS.SE> Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6970; Fri, 26 Jun 92 12:03:12 EDT Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id 8228; Fri, 26 Jun 92 12:02:52 EDT Date: Fri, 26 Jun 1992 11:59:45 EDT Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V5 #122 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: RO VIRUS-L Digest Friday, 26 Jun 1992 Volume 5 : Issue 122 Today's Topics: GROOVE Virus (PC) Re: Protecting Windows from viruses (PC) Ultrascan (PC) Looking for evaluations of Victor Charlie (PC) Rumours in Turkey (PC) Virus-l stuf of late MtE analysis & report (PC) AIDS Information Trojan (not virus) (PC) (CVP) Apple virus 1, 2 and 3 (Apple ][) (CVP) Product Test 25, Dr. Solomon's Toolkit (PC) Revised Product Test 24, ViruSafe, V4.55 (PC) Product Test 51, PC-RX (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@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. 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: 25 Jun 92 22:13:32 -0400 From: ESSMAN <74656.557@CompuServe.COM> Subject: GROOVE Virus (PC) Has anyone heard of a new MTE virus cxa alled GROOVE? I have a sample here and I have comfirmed the ay t it will infect EXE as well as COM files. In addition, most A_V -V products that detect MTE miss tyh his one. Lastly, this product seems to target A-V products in much tha e same way that PEACH does except this one targets multiple products. Eric Essman ------------------------------ Date: Thu, 25 Jun 92 18:12:35 -0300 From: andy@exp.uvs.edu.sr (Andy Lo A Foe) Subject: Re: Protecting Windows from viruses (PC) asuvax!gtephx!fraserr@windom.UCAR.EDU (Ross Fraser) wrote: > Secondly, can a virus infect the windows .ini files? how can a user > protect against it, since they are normally written by WINDOWS during > normal operation? The .ini files from Windows are normal text files, so they cannot be infected by viri. Windows does not execute anything from these files, it mearly reads information from them... Regards, /-------------------\/-------------------------------------\ | /\ |\ | |~\ |_| | Fax/Bbs : (597)-491-117 | | /~~\ | \| |_/ | | Internet : andy@exp.uvs.edu.sr | | Andy R. Lo A Foe | UUCP : upr2.clu.net!uvs!exp!andy | \-------------------/\-------------------------------------/ ------------------------------ Date: Fri, 26 Jun 92 08:08:30 +0000 From: ldang@sfu.ca (Leon Duong Luong Dang) Subject: Ultrascan (PC) I have heard of rumors about a virus checker called Ultrascan and need to confirm whether this program exist or not. What I heard about this program is that it can detect 99% of the virus and has a superior heuristic engine and it can generate methods to check most mutated strands (sounds tooo good to be true). Can any one confirm on the above . thanx.. ------------------------------ Date: Fri, 26 Jun 92 06:53:20 -0400 From: John Kida (jhk) (Vienna) Subject: Looking for evaluations of Victor Charlie (PC) I am conducting and evaluation of Victor Charkie 5.0 in the coming days... My company correctly so does not wish to assume that our current protect method will always be the best .... So I continue to Evaluate other Anti-Virus apploications..... Has anyone already perform such an evaluation of this application? And if so where is it? Have already checked NIST...they didn't have as of Jun 15, 1992... +----------------------------------+----------------------------------------+ | John H. Kida | Voice: (919) 867-7738 | | Network Administrator | Data : (919) 867-0754 | | SSDS, Inc. (Remote) +----------------------------------------+ | 601 Dashland Ave. | Internet: jhk@washington.ssds.com | | Fayetteville, N.C. 28303 | UUCP : !uunet!ssds!jhk | +----------------------------------+----------------------------------------+ ------------------------------ Date: Fri, 26 Jun 92 13:09:17 -0500 From: Stefano Toria Subject: Rumours in Turkey (PC) I have heard a second-hand rumour (second-hand at best) according to which there are some antivirus vendors who are practising a consistent dumping policy in Turkey. It seems that one vendor offered its products to a major bank, and he was answered that these other two vendors offered their products for a price that is substantially less than the recommended retail or registration price. I do not wish to change a rumour into a gossip by giving the names. I know that V-L is read in Turkey; can anyone down there confirm the above? I can give further details privately. Regards, - -------------------------------------------------------------------------- Stefano Toria | MC-link, Rome, Italy | "Fatti non foste a viver come bruti, Voice: (+ 396) 4180300 | ma per seguir virtute e conoscenza" Fax: (+ 396) 8413057 | - -------------------------------------------------------------------------- ------------------------------ Date: Thu, 25 Jun 92 23:52:00 -0400 From: fc Subject: Virus-l stuf of late I am very pleased to see more technical discussion coming to the fore in V-L, but it's somewhat disconcerting to see people claiming things on my behalf. Especially when they agree with me! I think Vesselin is basically right that the reason integrity checking doesn't have the same problem with probablistic misses as the typical scanners (on mTe) is that the probability of a false negative is quite low, but then, why do we need 100% detection from scanners? I think when scanners get to where they miss only 1 in 2^32 evolutions, they have met the same spec as an integrity checker with 32 bits. Let's call for 99.99999999% accurate scanners, not 100%!! I am somewhat taken aback by the claims that integrity checkers get substantial numbers of false positives or that they require users to make decisions when they don't know how. IT has never produced a false positive to my knowledge, and with a decent implementation, we can easily automate all of the decisions to the values set by corporate policy makers. On the other hand, people who need to know about changes should have tools that let them know what they need to know automatically. The point is that the claims against integrity checkers don't wash - they are apparently just product specific problems that require some better design work. As to the value of scanners for detecting known viruses, there is no question that people recognize this value already. The problem is that they don't associate the enormous costs until after they have been scanning each disk for a few weeks and updating their scanner every 4 hours to keep up to date. They start to back down and only use the scanner when they think they have a problem, and they don't scan each disk because people naturally fail to follow procedures, and they ignore the possibility of internal attackers intentionally bypassing controls, etc. I guess they reason I think we should have integrity systems AS WELL AS scanners, is that I think our current systems have a severe lack of integrity, and until our operating systems are built with some better integrity mechanisms in place, we will need 3rd party products. One other point - I think it is a mistake to claim that a virus defense that was in place BEFORE windows 3.1 was available CAUSES windows 3.1 to crash. I think that Windows 3.1 CAUSES the system to crash because their designers forgot about integrity in the rush to shove another million seller at the unsuspecting world. I think that we mistakenly force the small companies to keep adapting their software to the big companies, when we should tell the big company that we will buy their new product when it is 100% compatable with our current integrity protection software. After all, it was Microsoft who was at least 50% culpable for getting us all into this mess by providing 10 years of low integrity operating systems. On the other hand, OS/2 is such an improvement over DOS and Windows, that I am willing to forgive, and even perhaps appreciate, their protection against accidentally corrupting the file system by limiting some low-level and undocumented DOS calls. It doesn't bother me even a little bit that Norton utilities cannot corrupt my file system! FC ------------------------------ Date: 22 Jun 92 17:15:11 -0400 From: "Tarkan Yetiser" Subject: MtE analysis & report (PC) Hello everyone, following report is provided for your information. More tests are being conducted and results will be posted soon. ----------------------------------------------------------------------- 22 Jun 92 Mutation Engine Report Copyright (c) 1992 by VDS Advanced Research Group All Rights Reserved P.O. Box 9393 Baltimore, MD 21228 (410) 247-7117 prepared by Tarkan Yetiser This report is provided to satisfy the curiosity of the public. We were approached by some third parties to perform an analysis on MtE. We would like to share the results of our analysis with everyone. If you find an error or inaccuracy in this report, please feel free to contact us. All constructive criticism is welcome. TABLE of CONTENTS I. Mutation Engine and Viruses. . . . . . . . . . . . . . . . . . . 1 II. How to Catch Viruses and MtE-based Viruses . . . . . . . . . . 2 III. Mutation Types and Detection Algorithms. . . . . . . . . . . . 3 IV. Live Tests and Results . . . . . . . . . . . . . . . . . . . . 5 A. Comments on Test Results . . . . . . . . . . . . . . . 5 V. A Simple Message . . . . . . . . . . . . . . . . . . . . . . . 6 I. Mutation Engine and Viruses We have analyzed the so-called MtE (Mutation Engine by a "Dark Avenger" from Bulgaria), and sample viruses based on it; namely, Pogue and Dedicated. We have also conducted tests to examine what kind of a potential this miscreant has, and collected empirical data on how popular scanners deal with the MtE. We have also implemented a little program (CatchMTE) that can recognize MtE-based code using an algorithmic technique. The program in executable form is available free of charge as a service to the public. Due to possible misuse, the source code and a more detailed (at the opcode and bit-mask level) analysis with decryptor samples and algorithms necessary to detect MtE will be made available in a limited fashion. Under no circumstances, actual virus samples will be provided; except the missed samples can be sent to known anti-viral product developers who wish to enhance their programs. For those who are not familiar with the MtE, some preliminary info will be presented first: MtE is NOT a virus per se, but an object module that can be linked into a virus to give it polymorphic capabilities. MtE expects to be called as a routine that can encrypt a certain portion of code and can generate a suitable decryption routine. It uses a random number generator to vary each mutation so that it will not be possible to recognize the new variant by using simple scanning techniques. The random number generator is not part of the MtE object module. A sample pseudo-random number generator is included with the archive Dark Avenger distributes. A virus writer could also supply his own random number generator. Though all this may sound ordinary, MtE got so much attention not because it is just another encryptive virus but because it can provide even simple viruses with a feature that makes it difficult to scan for them. MtE is just like a library routine that you link into your virus and call when needed. It is a little over 2K in an object module named MTE.OBJ. A person who calls himself "Dark Avenger" claims to have developed MtE, and distributes it by uploading to BBSes in Bulgaria. The archive contains a fairly detailed documentation on how to use MtE, and even includes a demonstration virus, a non-resident COM infector known as "Dedicated". Shortly after MtE made its appearance, a modified copy of this virus called "Fear" is also seen. Why this person is engaged in such potentially harmful activity, or how he/she gets away with it is not something we know about. Curious individuals who would like to learn more about the history of virus production in Bulgaria and other social as well as technical issues are invited to read an excellent paper written by anti-virus researcher Mr. Vesselin Bontchev of Virus Testing Center, University of Hamburg. The paper is titled "Bulgarian Virus Factory", and it is available via anonymous FTP. It provides insight into some of the cultural aspects of the virus underground in Bulgaria. Mr. Bontchev's contribution to anti-virus research is much appreciated; otherwise, we probably would have never known what goes on inside the Bulgarian virus factories. II. How to Catch Viruses and MtE-based Viruses Scanning for many known viruses is usually a trivial task. You disassemble a sample, extract a sequence of bytes that would exist in each infected executable object, put it into a pattern matching engine, and then look for that pattern in executable objects that that virus is known to target. This method proved to be quite useful in fighting many viruses seen in the wild. Assuming a carefully chosen scan string, you can find the virus easily without too many false positives. Not so for polymorphic viruses. These viruses try to defeat common scanning methods. They keep their body encrypted to defy analysis, and encrypt the new copy inserted into an executable object using a different key so that it will "look" as if a different virus infection has occurred. However, even these viruses require a plaintext code that will decrypt the rest of the virus. Scanners can use strings extracted from the plaintext portion of the virus to identify them. It is usually necessary to include wildcard bytes (don't-care bytes) to be able to deal with the varying parts of the decryption routine. Naturally, false alarms are more likely to occur. MtE is more advanced than such viruses seen before. We would like to emphasize that the contents of each mutation and the corresponding decryption routine MtE generates is far too variable to extract a simple (or even wildcard) scan string. It is necessary to analyze the MtE itself as well as many sample mutations. After that, certain characteristics of the code MtE generates can be used as telltale signs to detect its presence. Avoiding false positives while maintaining 100% detection ratio is quite difficult. Armed with an 80x86 instruction set guide (we used Turbo Assembler 3.0 Quick Reference Guide), and a good disassembler (we used Mr. Zandt's DIS86 available via anonymous FTP), and a few known viruses based on MtE (Pogue and Dedicated with payload removed), we analyzed the MtE code, and the mutations generated. Tests were conducted on a 40Mhz 386 with a 100 meg HD and MS-DOS 5.0, and a 4.77Mhz IBM/XT with a 30 meg HD and PC-DOS 3.3 installed. A simple program that generated decoys (small, fully functional programs) was used to create a large number of samples. In the case of Pogue, the virus was allowed to remain resident and infect each decoy program as it is created. Since the Dedicated virus is not resident, it was necessary to create decoys first and then infect them by running the virus (infects in the current directory). After the tests, we archived the samples and stored them on floppy diskettes, and removed them from the hard drives of the test machines. In the Intel 80x86 architecture, it is possible to express a computation in very dissimilar ways. This is possible because certain registers can be substituted in place of another one and still achieve the same result. For example, you can index an array by using SI, DI, BP or BX registers. Or you could XOR a certain value at a given memory location by loading that value in AX, BX, CX or DX first, and performing the XOR on that register, and then putting the result back into memory, etc. Even other possibilities exist. When stepping through elements in an array, you can increment the index register by ADDing to it, INCing it, or ADDing and then SUBtracting from it. It should be clear that such flexibility helps MtE significantly. Of course, variability is something string scanners do not handle too well, since there are many combinations to search for. MtE goes even further than that. The size of the decryption routine is also variable, making it infeasible to assume certain things that would hold for many polymorphic viruses. It also sets up a lengthy sequence of redundant instructions before the decryptor enters the decryption loop. For over 90% of the mutations, MtE generates a convoluted 16-bit XOR-type encryption; however, in many cases it uses indirect ways to apply the XOR mask to a memory value. For example, it computes the mask, and then gets the value to be decrypted into a register, applies the mask and put the result back into that memory location. Besides, memory access is done using many different instructions such as MOV and XCHG. There are also many redundant instructions peppered freely throughout the decryptor. In some cases (5.5%), MtE generates a decryptor with a null effect. The decryptor does not actually decrypt anything, and the virus code is in plaintext. The frequency of such cases seems to depend on the random number generator. It is funny to note that some popular scanners misidentify such extreme cases where the virus is not even encrypted. To handle these mutations, it is sufficient to extract a signature from the MtE itself. It is also possible to extract one from known MtE-based viruses and identify the virus directly. At any rate, a scan string from MtE itself should be used in case a future virus creates a plaintext variant. We must also mention that even these plaintext mutations contained a fully working copy of MtE. They successfully propagated and generated encrypted mutations in future generations. MtE appears to generate correct code in all cases. The deviation between new generations started using plaintext parents and new generations started using encrypted parents was negligible. III. Mutation Types and Detection Algorithms MtE generates 4 "types" of mutations. They are as follows: 1. Double-reference (detectable using Method-1) ( ~ 91.0% ) 2. SUB-NEG (detectable using Method-2) ( ~ 2.0% ) 3. Single-reference (detectable using Method-3) ( ~ 1.5% ) 4. Plaintext or no-reference ( ~ 5.5% ) By implementing three algorithms and one scan string for the plain mutations, it is possible to recognize MtE-based viruses while keeping false positives to an acceptable level. We have one such program that achieved 100% hit rate during our tests. Some others also claim 100% hit rate; and we have tested them as well. A more detailed analysis of mutation types is not made public due to possible misuse of such information. IV. Live Tests and Results Test #1 Base Virus Name: Dedicated SCAN 91 F-PROT 2.04 CatchMTE 1.0 by Name (1) 67 69 60 as MtE (2) 933 931 940 misidentified -0 -0 N/A missed -0 -0 -0 Hit Rate 100% 100% 100% (1) SCAN91 --> [Mut], F-PROT 2.04 --> Dedicated, CatchMTE --> Dedicated (2) SCAN91 --> [DAME], F-PROT 2.04 --> MtE, CatchMTE --> MtE-based Test #2 Base Virus Name: Pogue SCAN 91 F-PROT 2.04 CatchMTE 1.0 by Name (1) 0 0 56 as MtE (2) 935 936 944 misidentified (3) -65 -61 N/A missed -0 -3 -0 Hit Rate 93.5% 93.6% 100% (1) SCAN91 --> N/A, F-PROT 2.04 --> N/A, CatchMTE --> Pogue (2) SCAN91 --> [DAME], F-PROT 2.04 --> MtE, CatchMTE --> MtE-based (3) SCAN91 --> [7S], F-PROT 2.04 --> Gotcha, CatchMTE --> N/A A. Comments on Test Results It seems that both F-PROT 2.04 and SCAN 91 misidentify some Pogue mutations that are in plaintext. F-PROT "quickscan" missed ALL mutations. You are advised to use SECURE scan mode of this product. The extra speed comes with 0% hit rate on MtE-based viruses! F-PROT 2.04 missed three encrypted Pogue mutations. We examined these samples and found them to be of Type-3, and detectable using Method-3. The samples worked as expected. One of those three that were missed was called "suspicious" and guessed to be a variant of the Gotcha virus. We can only speculate that F-PROT lacks Method-3 detection algorithm and uses a heuristic in such cases. Surprisingly, Virx 2.3 missed one of these same mutations. Due to annoying user interface, we were unable to include Virx 2.3 in our full test suite. It should be noted that misidentification of 6% of Pogue mutations is a little alarming. All these misidentified mutations were found to be working and capable of generating new mutations. V. A Simple Message It is dangerous to assume that scanning is adequate since there are some products that can detect MtE-based viruses 100% of the time. We identified at least two ways to make MtE less predictable. Of course, such information will not be disseminated. However, considering the availability of MtE to the hackers all around the world, and the "glory" Dark Avenger will enjoy due to media hype, it's only a matter of time such improvements will be discovered by irresponsible individuals. Besides, this may start a new trend among virus writers to create things like MtE. Keeping up with new virus signatures was hard enough (though manageable), but keeping up with many mutation engines is not going to be trivial. Unfortunately, locking up these "mutant engineers" is not a practical solution, and not even legally possible in many parts of the world. The message is clear. The first line of defense against viruses is NOT using scanners. Although they proved to be very useful, you are highly encouraged to consider other approaches such as integrity checkers as a first line of defense. Even the less sophisticated integrity checkers have a better chance to catch mutating viruses, long before their developers get a chance to analyze the virus samples. The reason is that viruses have a tendency to modify existing code to propagate in most cases. Their spread can be controlled using a non-virus-specific solution that concentrates on the main characteristic of most viruses. Such an approach is not only more cost-effective but also more secure. If your company still relies on a virus scanner to protect its PC- based computing resources against viruses, you are walking on thin ice. - ------------------------------------------------------------- Regards, Tarkan Yetiser VDS Advanced Research Group P.O. Box 9393 (410) 247-7117 Baltimore, MD 21228 e-mail: tyetiser@ssw02.ab.umd.edu ------------------------------ Date: Thu, 25 Jun 92 23:10:25 -0700 From: rslade@sfu.ca (Robert Slade) Subject: AIDS Information Trojan (not virus) (PC) (CVP) HISINT5.CVP 920625 The "AIDS" Trojan (not virus) I'll conclude the introductory history with the AIDS Information Disk trojan for two reasons: 1) it deserves a place in the history of "malware" in any case and 2) it was so widely; and incorrectly; reported as a virus. In the fall of 1989, approximately 10,000 copies of an "AIDS Information" package were sent out from a company calling itself PC Cyborg. Some were received at medical establishments, a number were received at other types of businesses. The packages appeared to have been professionally produced. Accompanying letters usually referred to them as sample or review copies. However, the packages also contained a very interesting "license agreement": "In case of breach of license, PC Cyborg Corporation reserves the right to use program mechanisms to ensure termination of the use of these programs. These program mechanisms will adversely affect other program applications on microcomputers. You are hereby advised of the most serious consequences of your failure to abide by the terms of this license agreement." Further in the license is the sentence: "Warning: Do not use these programs unless you are prepared to pay for them". The disks contained an installation program and a very simplistic AIDS information "page turner" and risk assessment. The installation program appeared only to copy the AIDS program onto the target hard disk, but in reality did much more. A hidden directory was created with a nonprinting character name and a hidden program file with a nonprinting character in the name was installed. The AUTOEXEC.BAT file was renamed and replaced with one which called the hidden program, and then the original AUTOEXEC. The hidden program kept track of the number of times the computer was rebooted, and, after a certain number, encrypted the hard disk. The user was then presented with an invoice and a demand to pay the license fee in return for the encryption key. Two major "versions" were found to have been shipped. One, which waited for 90 reboots was thought to be the "real" attempt: an earlier version which encrypted after one reboot alerted authorities and was thought to be an error on the part of the principals of PC Cyborg. The Panamanian address for PC Cyborg, thought by some to be a fake, turned out to be a real company. Four principals were identified, as well as an American accomplish who seems to have had plans to have sent 200,000 copies to American firms if the European "test" worked. The trial of the American has just been suspended, as his bizarre behaviour in court is seen as an indication of "diminished responsibility". copyright Robert M. Slade, 1992 HISINT5.CVP 920625 ============= Vancouver ROBERTS@decus.ca | "The only thing necessary Institute for Robert_Slade@sfu.ca | for the triumph of evil Research into rslade@cue.bc.ca | is for good men to do User CyberStore Dpac 85301030 | nothing." Security Canada V7K 2G6 | - Edmund Burke ------------------------------ Date: Thu, 25 Jun 92 23:12:18 -0700 From: rslade@sfu.ca (Robert Slade) Subject: Apple virus 1, 2 and 3 (Apple ][) (CVP) HISVIR1.CVP 920625 Apple Virus 1, 2 and 3 The earliest case of a virus that succeeded "in the wild" goes back to late 1981, even before the work of Fred Cohen. In fairness, this does not appear to have been noted by many until long after the fact. For the benefit of those who do not delight in flame wars the author will not be identified: those who have followed the history of viri will know whom I refer to as Joe :-). The idea was sparked by a speculation regarding "evolution" and "natural selection" in pirated copies of games at Texas A&M: the "reproduction" of preferred games and "extinction" of poor ones. This led to considerations of programs which reproduced on their own. (I see no reason to doubt the author's contention that there was no malice involved: this was, after all, the first case that we know of. Indeed, it was Joe's contention that a virus had to be relatively "benign" in order to survive.) Apple II computer diskettes of that time, when formatted in the normal way, always contained the disk operating system. Joe attempted to find the minimum change that would make a version of the DOS that was viral, and then tried to find an "optimal" viral DOS. A group came up with version 1 of such a virus in early 1982, but quarantined it because of adverse effects. Version 2 seemed to have no negative impact, and was allowed to "spread" through the disks of group members. Eventually security was relaxed too far and the virus escaped to the general Apple user population. It was only then that the negative impact of the virus was seen: the additional code length caused some programs, and one computer game in particular, to abort. A third version was written which made strenuous efforts to avoid the memory problems: parts of the coding involve bytes which are both data and opcode. Version 3 was subsequently found to have spread into disk populations previously felt to be uninfected, but no adverse reactions were ever reported. (For those who have Apple DOS 3.3 disks, location B6E8 in memory, towards the end of track 0, sector 0 on disk, should be followed by eighteen zero bytes. If, instead, the text "(GEN xxxxxxx TAMU)" appears, the digits represented by the "x"s should be a generation counter for virus version 3.) The story has an interesting postscript. In 1984, a malicious virus was found to be spreading through the schools where all this took place. Some disks appeared to have some immunity. These immune disks turned out to all be infected with version 3. copyright Robert M. Slade, 1992 HISVIR1.CVP 920625 ============== Vancouver ROBERTS@decus.ca | "If you do buy a Institute for Robert_Slade@sfu.ca | computer, don't Research into rslade@cue.bc.ca | turn it on." User CyberStore Dpac 85301030 | Richards' 2nd Law Security Canada V7K 2G6 | of Data Security ------------------------------ Date: Fri, 22 May 92 11:57:38 -0600 From: Chris McDonald ASQNC-TWS-R-SO Subject: Product Test 25, Dr. Solomon's Toolkit (PC) ******************************************************************************* PT-25 May 1992 ******************************************************************************* 1. Product Description: Dr. Solomon's Anti-Virus Toolkit is a collection of programs for the detection, removal, and prevention of malicious program activity. This product test addresses version v5.55, February 1992. 2. Product Acquisition: Dr. Solomon's Anti-Virus Toolkit is copyrighted by S&S International, Berkley Court, England. The commercial program is available in the United States from Ontrack Computer Systems, 6321 Bury Drive, Suite 16- 19, Eden Prairie, MN 55346. Their telephone number is 612-937-1107; the FAX number is 612-937-5815. The Toolkit cost is $149.00 for a single copy with an additional fee for two different types of update services. Site licenses are available. The program is also available through software mail order firms at a significantly reduced cost for a single copy. 3. Product Tester: Chris Mc Donald, Computer Systems Analyst, White Sands Missile Range, NM 88002-5506, DSN: 258-4176, DDN: cmcdonal@wsmr-emh03.army.mil or cmcdonald@wsmr-simtel20.army.mil. [Moderator's note: The remainder of this product review (and MANY other product reviews) is available by anonymous FTP on cert.org (192.88.209.5) in the pub/virus-l/docs/reviews directory, under the filename "mcdonald.solomon.toolkit".] ------------------------------ Date: Thu, 28 May 92 15:42:42 -0600 From: Chris McDonald ASQNC-TWS-R-SO Subject: Revised Product Test 24, ViruSafe, V4.55 (PC) ******************************************************************************* PT-24 July 1991 Revised May 1992 ******************************************************************************* 1. Product Description: ViruSafe is a commercial software package to detect, disinfect and prevent computer viruses and malicious programs for the MS-DOS environment. This product test addresses version 4.55. 2. Product Acquisition: ViruSafe is available from XTREE Company, a division of Executive Systems, Inc., 4330 Santa Fe Road, San Luis Obispo, CA 93401. EliaShim MicroComputers originally developed the software. The suggested retail price for a single copy is $99.00. Site licenses are available. XTREE telephone numbers are 800-634-5545 or 805-541-0604. 3. Product Tester: Chris Mc Donald, Computer Systems Analyst, Information Systems Command, White Sands Missile Range, NM 88002-5506, DSN: 258-5712, DDN: cmcdonal@wsmr-emh03.army.mil or cmcdonald@wsmr-simtel20.army.mil. [Moderator's note: The remainder of this product review (and MANY other product reviews) is available by anonymous FTP on cert.org (192.88.209.5) in the pub/virus-l/docs/reviews directory, under the filename "mcdonald.virusafe".] ------------------------------ Date: Wed, 17 Jun 92 11:30:14 -0600 From: Chris McDonald ASQNC-TWS-R-SO Subject: Product Test 51, PC-RX (PC) ******************************************************************************* PT-51 June 1992 ******************************************************************************* 1. Product Description: PC-RX is a viral detection and disinfection program for IBM personal computers or compatibles. This product test addresses version 1.1, March 1992. 2. Product Acquisition: PC-RX is available from Trend Micro Devices Incorporated, 2421 West 205th Street, Suite D-100, Torrance, CA 90501. Site licenses are available. 3. Product Tester: Chris Mc Donald, Computer Systems Analyst, White Sands Missile Range, NM 88002-5506, DSN: 258-4176, DDN: cmcdonal@wsmr-emh03.army.mil or cmcdonald@wsmr-simtel20.army.mil. [Moderator's note: The remainder of this product review (and MANY other product reviews) is available by anonymous FTP on cert.org (192.88.209.5) in the pub/virus-l/docs/reviews directory under the filename "mcdonald.pcrx".] ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 122] ******************************************