Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5) id AA26643; Wed, 24 Feb 1993 19:57:06 +0100 Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA16951 (5.67a/IDA-1.5); Wed, 24 Feb 1993 09:09:57 -0500 Date: Wed, 24 Feb 1993 09:09:57 -0500 Message-Id: <9302231436.AA26498@first.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@first.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 V6 #32 Status: R VIRUS-L Digest Tuesday, 23 Feb 1993 Volume 6 : Issue 32 Today's Topics: Virus Survey Results Re: How to measure polymorphism re: Tokyo Virus in NETCB or a false positive? (PC) Re: Scanning memory (PC) Rebuilding Partition Tables (PC) PC Magazine reviews virus scanners (PC) Michelangelo detect/removal instructions (PC) Re: Uruguay on PS/2 Ref disk (PC) Re: Virstop 2.07 & Lanworkplace = Windows Hangs. (PC) Viruses in March (PC) Identification (PC) Uruguay virus (PC) Virus Scanner for BBS (PC) Re: F-prot/FSP/bootsum problem. Help! (PC) re:waldo (PC) Re: FORM (again!) (PC) Re: Minimal virus scan? (PC) I-M141.ZIP - Integrity Master (PC) New files on risc (PC) Michelangelo discovery and naming (CVP) Re: Censorship 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: 20 Feb 93 03:35:43 +0000 From: jay@info.umd.edu (Jay Elvove) Subject: Virus Survey Results In November, I distributed a questionnaire to this group on the subject of computer viruses. 10 of you responded, and to those of you, I take this opportunity to thank you once again. So many respondents requested that I share my findings with them, that I thought I'd simply send them to this list. I am including the questionnaire itself for reference, since the culled results are fairly terse. I have UUENCODED the results because, although it is straight text, the table is wider than 80 characters, which may be too much for some mailers. I hope the UUENCODING causes no headaches for anyone. The program is available on (nearly) all UNIX systems and on a great many PCs as well. A PC version is available via anonymous FTP from info.umd.edu in the file /info/Computers/PC/Unix/uuexe520.zip. Jay Elvove email: jay@info.umd.edu Academic Software Computer Science Center University of Maryland ------------------- Virus Questionnaire 1. How many PCs do you use or oversee? 1 2-4 5-9 10-19 20-49 50+ 2. Which of the following best describes your PC computing environment? standalone open lab restricted lab departmental LAN combination 3. Approximately what percent of the above computers are used by each of the following members of your organization? faculty staff grad students undergraduates other clerical technical administrative other 4. In your opinion, how serious a threat do viruses pose to your computing environment? extreme very moderate little none 5. Within the last six months, how many incidents of computer viruses have you seen? 1 2-4 5-9 10-19 20-49 50+ none If the answer to the previous question was one or more, please answer the following four question: (a) What virus(es) have you seen? (b) What was the extent of the damage, if any? (c) How long did it take to remove or otherwise recover from the virus(es) (d) Which of the following groups within your organization has been the source of the greatest number of viruses? faculty staff grad students undergraduates other clerical technical administrative other 6. Whether or not your computer environment has been exposed to viruses in the past, in your opinion, which of the following groups is most likely to be a source of viruses within your environment today? faculty staff grad students undergraduates other clerical technical administrative other 7. In your opinion, how are computer viruses most likely to be transmitted? 8. Which regimen most closely approximates how often you scan your PC(s) for viruses? boot-up daily weekly monthly rarely never 9. How many of your PCs use TSR programs to detect viruses? 1 2-4 5-9 10-19 20-49 50+ none 10. How often do you back up your files? daily weekly monthly rarely never 11. What procedures are in place in your environment to address the threat of viruses (i.e., regular scanning, using TSR programs, backing up files, user education, official policies, etc.)? Please list specific anti-virus products in use. 12. Which category best describes your role within your organization? faculty staff grad students undergraduates other clerical technical administrative other - ---cut here------cut here------cut here------cut here------cut here--- begin 644 vresults.txt M("LM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2L*('P@ M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @ M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @ M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @('P*('P@(" @ M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @5FER=7,@4W5R M=F5Y(%)E2 @?"!O<&5N(&QA8B @?"!R97-T2 @?" @ M('-T869F(" @?" @(&=R860@(" @('P@("!U;F1E2 @?" @ M('-T869F(" @?" @(&=R860@(" @('P@("!U;F1E2 @?" @('-T869F(" @ M?" @(&=R860@(" @('P@("!U;F1E2 @(" @?" @=V5E:VQY M(" @('P@('=E96ML>2 @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @ M(" @(" @('P*('PQ," @(" @(" @(" @(" @?" @(" @(" @,C,@?" @(" @ M(" @(#$@?" @(" @(" @,3(@('P@(" @(" @(" W(" @?" @(" @(" @(#@@ M('P@(" @(" @(" Q('P@(" @(" @(" @('P@(" @(" @(" Q('P@(" @(" @ M(#4S('P*("LM+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM M+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM M+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM M+2L*('P@4')E=F5N=&EO;B @(" @?" @('1S2 @?" @('-T869F(" @?" @(&=R860@(" @('P@ M("!U;F1E7!E(" @(" @?" @("!%1%4@(" @ M?" @("!#3TT@(" @?" @(" @(" @(" @('P@(" @(" @(" @(" @?" @(" @ M(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@ M(" @(" @(" @('P*('QN+V$@(" @(" @(" @(" @?" @(" @(" @-#$@?" @ M(" @(" @,3(@?" @(" @(" @(" @('P@(" @(" @(" @(" @?" @(" @(" @ M(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @ M(" @(#4S('P*("LM+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM M+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM M+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM &+2TM+2L* end - -- Jay Elvove jay@info.umd.edu c/o Academic Software Comp. Sci. Center, Univ. of Md., College Park ------------------------------ Date: Sun, 21 Feb 93 20:09:29 +0000 From: houle@nmt.edu (Paul Houle) Subject: Re: How to measure polymorphism bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >Yes, that's a very good idea. And it can be implemented quite easily, >no need to have the "polymorphic compiler" you are talking about. Just >have some polymorphic engine in the intallation program and use it to >encrypt and prepend a random decryptor to the executable before >installing it. Of course, you could even use MtE for that purpose, but >this is not a wise idea, because then everybody's scanner will detect >your program as infected with an MtE-based virus... :-) I think that the polymorphic compiler approach is still stronger than that of the existing polymorphic engines. It also has the advantage that it will work fine in operating systems and environents that don't like self-modifying code. The compiler could even re-compile itself, so that there wouldn't be one speck of invariant code. Although many of the simple approaches could waste a greal deal of space by adding randomized jumps, etc, an efficient polymorphic compiler could probably work about as well as a poorly-optimized conventional compiler, if not better. Register allocations could be randomized, code could be spaghettied and one could store different implementations for primitive operations. >Of course, the implementation of the polymorphic anti-virus program >should be strong enough - e.g. an integrity checker that shokes when a >virus deletes its dabases of checksums is not good, even if it is a >polymorphic one... :-) Definitely, the most advanced cryptography technology availible should be used. The problem is that the keys have to be laying around somewhere, even if you are using a public key system -- although in that case you might be able to store the private key offline except when the database for the program needs to be updated. Deleting a checksum database would probably be a bad idea for a virus - -- and having your integrity checker choke would certainly be a warning sign. It would make more sense for a virus to alter the CRCs if it were possible for it to read the altered coefficients, keys, or whatever it needs to make validation data. >Oh, yes, and it is enough to make the executable different each time. >You don't need to bother with the names of the data files, if you >provide the possibility to the user to use just -any- names... > I would agree that a program should allow the user to decide where to put important files and what their names should be, but a program that is going to be used by the general population is going to have to have some kind of defaults. Anyone who is fairly computer literate won't have any problem thinking up creative names, but the majority of computer users out there know about word processing and games. I've seen people "freeze up" while trying to do simpler things than just pick a couple of filenames. As such, the program probably should ask the user if he wants to select names for the data base files, and if he doesn't, it should go around and hide them all automatically. ------------------------------ Date: Fri, 19 Feb 93 19:37:24 -0500 From: Ian Leitch Subject: re: Tokyo Virus in NETCB or a false positive? (PC) In Virus-L Volume 6 Issue 26, I wrote: > I have recently downloaded NETCB v0.3b from the UK HENSA (Higher > Education National Software Archive) directory > micros/ibmpc/dos/h/h112. (NETCB is Chat box for Novell networks > and was written by Koos van den Hout.) > (blah, blah) > However, any attempt at execution is intercepted > by VIRSTOP which reports infection with Tokyo virus. > (more blah, blah) > These and other indications lead me to think that I may have hit > a false positive. If so, how can I run it and retain protection > from VIRSTOP? Frisk has confirmed that is was indeed a false positive indication, and has sent me an updated version of VIRSTOP which resolves the problem. Many thanks to frisk for such a swift response. Ian Leitch ---------------------------------------------------------------------------- | Ian Leitch JANET: i.leitch@uk.ac.lshtm | | Information Technology Unit Tel: 071 927 2260 | | London School of Hygiene and Tropical Medicine FAX: 071 436 5389 | | Keppel St., London WC1E 7HT Telex: 8 95 34 74 | ---------------------------------------------------------------------------- ------------------------------ Date: 19 Feb 93 19:44:42 -0500 From: ac999512@umbc.edu (ac999512) Subject: Re: Scanning memory (PC) >>Yup. This is called ghost positive. It can be easily avoided by the >>producer of the scanner with a little bit of intelligent programming. >>I suggest that people REFUSE to use anti-virus software that is so >>stupid. > >Isn't it better to be conservative and look everywhere in memory for active >viruses? I'd much rather see a false alarm than have something be missed >because a scanner was wrong about where viruses could lurk. Also, this sort >of false alarm can only arise if you have scanned an infected floppy. If a >user has an infected floppy, and doesn't know enough about viruses to >understand the ghosting problem, they should consider getting expert help. I agree that scanners shouldn't scream and yell when they detect a virus floating in RAM that isn't active. Yet on the other hand, nothing should be taken for granted as to where a virus is, as stated above. I think it best that scanners should check interrupt vectors and so forth to determine if the virus is active, then inform the user as to the presence of the virus, and whether or not it is active. Flexibility is the best policy. +----------------------------------------------------+ | Ed T. Toton III, | "It's difficult to work in a | | Virus Researcher | group when you're omnipotent" | +----------------------------------------------------+ ------------------------------ Date: Fri, 19 Feb 93 22:35:51 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Rebuilding Partition Tables (PC) >From: chowes@sfu.ca (Charles Howes) >Subject: FDISK buggy? (PC) >- -------ON ANOTHER TANGENT------ >Has anyone written a program that will allow you to create a new >partition table sector from scratch, and if the numbers you give >correspond to the previous partition table's numbers, *poof*, you have >a working hard disk again? (Fdisk /mbr didn't work in this case.) And >then do the same thing for the boot sector if called for? Well I have all of the pieces, just not ready for Prime Time but others are welcome. Basically all of the information is there (I include a write-up in the FixMBR.DOC that comes with the FixUTIL3.ZIP - incidently half of those are FREEWARE and the rest are on free trial until 7th March again this year). First you have the BIOS information retrievable with Int 13 Fn 08. This will tell you what the CMOS thinks the whole disk is (tracks, heads sectors). Next you have the Partition Table - this lists the logical drive information for each partiton (starting sector, number of sectors, partition type). Then you have the Dos Boot Record which gives the same information as the partition table for each partition. If there are multiple partitions, each will have its own DBR (and a recovery program could just "walk the disk" looking for them) since DOS 3.0 they *must* be in the same place. Thus the information can be found in not one but *four* different places on a DOS disk (Unix or Novell are different but the info is still there - just keep fresh batteries in your TI Programmer 8*). Right now I have other things to do, like painting my house 8*( Warmly, Padgett ------------------------------ Date: Sat, 20 Feb 93 04:44:26 +0000 From: Christopher Yoong-Meng Wong Subject: PC Magazine reviews virus scanners (PC) Have others seen the March 16, 1993 issue of PC Magazine yet? Normally, I wouldn't expect this group to care much, but this magazine has tremendous influence in the industry. A summary: 1. Editors' choices are CPAV and NAV. 2. The great grandaddy of virus scanners, Mc Afee's Viruscan family, was not reviewed. Nor was F-prot (though the commercial version was reviewed), except as an aside: "... for those comfortable with command line operation ... original F-prot". ^^^^^^^^^^^^ 3. Scanning tests involved 11 -- count them -- 11 viruses. 4. Review emphasized completeness of package: disinfection, comprehensiveness of service etc, not detection ability. Somehow, this review seems out of sync with almost everything I've read here about virus scanners. Opinions? It seems to me a letter to the letters page signed by a major virus researcher (or ten :-) ) would carry a lot of weight. Chris ------------------------------ Date: Fri, 19 Feb 93 21:06:46 -0800 From: greg@ideath.goldenbear.com (Greg Broiles) Subject: Michelangelo detect/removal instructions (PC) Greetings - given we are again approaching March 6, I thought it might be useful to put together some instructions that would allow DOS-savvy users (yeah, both of them :) to look for Michelangelo without needing to spend time/dollars tracking down scanning software. (And yes, I agree that it's important for folks to take further data protection measures - but it seems like some protection is better than none, especially given the wide distribution of Michelangelo.) What I'd like to do is come up with a text-based description of how to detect and disinfect Michelangelo, and at no cost to users with access to DEBUG and other DOS utilities. Ideally, this could be handed out at user group meetings, posted on (cork :) bulletin boards, FAXed to folks who need it, and so forth. Seems like the first check should be the amount of system memory reported by MEM or CHKDSK - which should be 655,360 on a 640K machine. If a machine has 640K, and MEM/CHKDSK reports system memory of 655,360 - - the machine *as running* cannot be infected, since one of the first things Mich does is to subtract 2K from the total system memory reported. Users whose machines have less common configurations (some amount of system memory used for other purposes, or with less than 640K of base RAM) or who want to check disk(s) without booting them, should be able to do this with DEBUG, like so: DEBUG l 0 0 0 1 [to check a floppy in A: - should be 'l 0 2 0 1' to check C:] s 0 1AC AD 3B 47 02 74 35 B8 01 03 B6 01 B1 03 80 7F 15 FD 74 02 B1 0E 89 0E 08 00 [Moderator's note: the above debug command is a _single_ line of input to debug.] [search for Michelangelo signature - signature string swiped out of Jan Terpstra's VIRSCAN.DAT, revision 930103] If DEBUG returns an address, it's found the signature, and Michelangelo is present in the boot sector of the suspect disk - if not, the disk can be considered Mich-free. Users who find Mich can overwrite it on floppies with the SYS command; users who find it on hard disks can overwrite it with FDISK /MBR, if their FDISK supports it. (If not, they can at least avoid using that machine on March 6 and pursue some other means of removal) I see four potential problems with this approach: 1. It could create a false sense of security, as being Mich-free isn't the same as being virus-free. 2. It would be relatively easy to mistakenly generate a false negative by mistyping the signature string. 3. It could create stress/panic on the part of those folks for whom CHKDSK/MEM don't report 655,360, but are uninterested/unwilling to do further DEBUG diagnosis/detection. 4. It fails to address non-DOS users of PC architecture systems, though it ought to give those people a good kick in the right direction to check themselves with available tools. However, I see some good features, as well: 1. It allows people without ready access to other means of detection to check their systems for infection. I'm relatively well off in that I have a modem and Internet access, and can pick up new versions of scanners on a more-or-less monthly basis; but there are folks in the world still chugging along without easy ways to get software, as well as folks who are put off by the high prices of commercially available antiviral products. 2. It might encourage people to take a more active and involved approach to security. Anyway, I'm interested in hearing comments from the net about this approach. I've tested this on my own system with a captured copy of Mich from last year's follies, and I haven't encountered any anomalies. However .. it's a big world, potentially full of things I haven't thought of yet. Ideas/comments/flames? - -- Greg Broiles greg@goldenbear.com Golden Bear Consulting +1 503 465 0325 Box 12005 Eugene OR 97440 BBS: +1 503 687 7764 ------------------------------ Date: 20 Feb 93 12:38:40 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Uruguay on PS/2 Ref disk (PC) pinman@magnus.acs.ohio-state.edu (Patricia C Inman) writes: >Fprot 2.06 reports: command.com "Infection: Uruguay" on all PS/2 >Model 70/80 Reference Disks Version 1.06. Version 1.03 of the Ref >Disk reports clean. CPAV is current and reports nothing. >I recently went through a scare and collected all disks in the >facility. This is all I have left to cleanup. Is this "normal"? This is a false alarm that was corrected in 2.07 - it is also documented in the NEW.207 file, included with that version. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: Sat, 20 Feb 93 16:40:01 +0000 From: beyer@Lise.Unit.NO (Paal Beyer) Subject: Re: Virstop 2.07 & Lanworkplace = Windows Hangs... (PC) I too had the same problem. I mailed the author, but I have not received an answer. I had to install the old VIRSTOP. The new one seems to have some interesting options so I hope the author can fix this bug. - ------------------------------------------------------------ _/_/_/ _/_/_/ _/ _/ _/_/_/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/_/_/ _/_/_/ _/_/_/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/_/_/ _/ _/_/_/ _/ _/ @lise.unit.no ------------------------------ Date: 19 Feb 93 21:17:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Viruses in March (PC) Here is an incomplete list of viruses that are scheduled to activate in March. Please Use precautions. 903 activates any day in March AH activates any Tuesday CARFIELD activates any Monday CD activates Thursday the 12th DAY10 activates the 30th of any month DAY10 activates the 20th of any month DAY10 activates the 10th of any month FLIP activates the 2nd of any month FORM (18) activates the 18th of any month FORM (24) activates the 24th of any month FRERE JACQUES activates any Friday FROG'S ALLEY activates the 5th of any month I-B (BadGuy 2) activates any Monday I-B (BadGuy) activates any Monday I-B (Demon) activates any Tuesday I-B (exterminator) activates any Monday ITALIAN PEST (Finger) activates any Saturday JERUSALEM (Payday) activates Fridays (not 13th) JERUSALEM (Skism-1) Fridays (after the 15th) JERUSALEM (Phenome) activates any Saturday KAMASYA activates any Tuesday MALTESE AMOEBA activates Mar 15th MICHELANGELO activates Mar 6th MIGRAM activates any Saturday MONXLA activates the 13th of any month PLASTIQUE (Cobol) activates Jan 1 - Sep 21 SMACK activates any Friday SUNDAY activates any Sunday SUNDAY-2 activates any Sunday TAIWAN activates the 8th of any month VICTOR activates any Wednesday Bill - --- * WinQwk 2.0 a#383 * KENEDY activates Jun 6th ------------------------------ Date: Sun, 21 Feb 93 16:36:59 -0500 From: fergp@sytex.com (Paul Ferguson) Subject: Identification (PC) On 17 Feb 93 (19:39:41 GMT), Jim O'Shea wrote - JO> Could you recognise that a file had been infected by a virus JO> purely by inspecting a disassembled listing? I do mean any JO> virus, including one you might not have met before. I accept JO> it might not be possible to be specific but answers like JO> "Yes, given unlimited time." or " Seventy percent probability JO> of a correct answer after spending 6 hours on inspection" will JO> be useful. In a nutshell, yes. It really depends upon what you mean by a "disassembled listing", however. One cannot simply run an encrypted virus through a symbolic disassembler and expect everything to come out in the wash. For more complex viruses, an interactive disassembling aid (SoftICE or simply DEBUG) will allow one with enough skill to trace through the code and unveil the tricks inside. Kind of like a box of Cracker Jacks (tm). ;-) For polymorphic "envelopes" (I dislike the term "engine"), a more intensive analysis of the encryption algorithm is required, but is being done by many developers on a semi-regular basis. (Unfortunately.) JO> I am interested in applying AI to virus detection and I would JO> like to know how effective "Natural" intelligence is first. Natural intelligence will never be completely replaced, but several individuals have made great strides in their heuristic analysis extensions of examining code. Fridrik Skulason's f-Prot does a fantastic job of detecting virus-like code, but does not provide as much detail concerning it's findings as the heuristic flags logged in Frans Veldman's Thunderbyte AntiVirus. (Opinion, opinion.) Paul Ferguson | Network Integration Consultant | "All of life's answers are Alexandria, Virginia USA | on TV." fergp@sytex.com (Internet) | -- Homer Simpson sytex.com!fergp (UUNet) | 1:109/229 (FidoNet) | PGP public encryption key available upon request. - --- fergp@sytex.com (Paul Ferguson) Access <=> Internet BBS, a public access internet site Sytex Communications, Arlington VA, 1-703-358-9022 ------------------------------ Date: Sun, 21 Feb 93 16:37:01 -0500 From: fergp@sytex.com (Paul Ferguson) Subject: Uruguay virus (PC) On 17 Feb 93 (18:36:42 GMT), < pinman@magnus.acs.ohio-state.edu> Patricia C Inman wrote - PI> Fprot 2.06 reports: command.com "Infection: Uruguay" on all PI> PS/2 Model 70/80 Reference Disks Version 1.06. Version 1.03 PI> of the Ref Disk reports clean. CPAV is current and reports PI> nothing. It sounds like a false positive, but I'd hesitate to draw that conclusion. Have you attempted to try a newer version of the product or perhaps a current (bourne within the course of the past two months) version of another virus detection utility? On another note, I am curious as to other what other particpants may have experienced with the relationship between PS/2 reference diskettes and a possible tendancy for PS/2 shops to have a higher percentage of MBR infections (per capita). I have run across several "Big Blue" organizations that seem to have a higher percentage of MBR infections than non- "Blue" shops. Perhaps the reliance on the reference diskettes and lack of safe computing practices at these locations combine for a lower tolerance for STONED and FORM infections? It would appear that way, at least at first glance, but I'll readily admit that apathy in way, shape or form can contribute to a tendancy for infection, whether IBM or clone. Paul Ferguson | "Making duplicate copies and computer Network Integration Consultant | printouts of things no one wanted Alexandria, Virginia USA | even one of in the first place is fergp@sytex.com (Internet) | giving America a new sense of sytex.com!fergp (UUNet) | purpose." - Andy Rooney 1:109/229 (FidoNet) | PGP public encryption key available upon request. - --- fergp@sytex.com (Paul Ferguson) Access <=> Internet BBS, a public access internet site Sytex Communications, Arlington VA, 1-703-358-9022 ------------------------------ Date: Sun, 21 Feb 93 14:31:21 -0500 From: sgt@lakes.trenton.sc.us (Sgt Rock) Subject: Virus Scanner for BBS (PC) I am trying to locate a virus scanner for a GT Power BBS. Preferably I would like to have all file uploads scanned immediately after they are uploaded. I know ZIPLAB+ does that but it won't work with GT Power. If I can't automatically scan uploads when they are uploaded then I'd like to scan uploads as a scheduled even once each day prior to either placing the files in the approriate files area or removing them Can anyone help me with this? Thanks! ------------------------------ Date: Sun, 21 Feb 93 22:49:19 -0500 From: Wolfgang Stiller <72571.3352@compuserve.com> Subject: Re: F-prot/FSP/bootsum problem. Help! (PC) jornj@colargol.edb.tih.no (jornj) writes: > I've experienced the same problem, using Integrity Master and Stacker > 2.0. When I check the 'bootsector' of my stacked volume IM always > claims it has changed... > Is this normal for Stacker? Or do I have a 'problem'? > (I've scanned with scan v99, fprot 2.06 and IM doesn't report any > other problems). Yes, it's a "normal" Stacker function. Stacker creates a pseudo boot sector on the simulated (compressed) Stacker volume. For some reason Stacker insists on constantly changing this sector. Since you can not boot from this sector, there's little reason to check its integrity. A future version of IM will recognize Stacker boot sectors and not bother to check them. If you have a recent release of Integrity Master (The current release is V1.41b but I think I've had the documented since V1.22 or 1.23) the QUESTION.DOC file describes this and provides some other Stacker related tips. Regards, Wolfgang Wolfgang Stiller Stiller Research 2625 Ridgeway St. Tallahassee, FL 32310 U.S.A. ------------------------------ Date: Mon, 22 Feb 93 02:06:21 -0500 From: KARGRA@GBA930.ZAMG.AC.AT Subject: re:waldo (PC) Hi all, we had this discussion on win3-l a year ago. When I read the subject I immediately remembered that. On my PC we regularly ran CorelDRAW 2.0. And sometimes the system crashed with an UAE and telling something like: Module Waldo caused a UAE at adress XXXX, or so. NO, WALDO IS NOT A VIRUS, it probably is a relict of some debugging-code in Corel Draw 2.0. I can't tell if it still exists in CorelDraw 3.0. I haven't seen it until now, despite regular GPFs (Win 3.1 was significantly improved, there are no more UAEs - Unrecoverable Application Errors, now they call them GPFs - General Protection Failures) It's not so much of a problem to find WALDO with a hexeditor in CORELDRW.EXE at offset 0x191 ;) Hope to help, Alfred o / \ o - ------ X ------------ Don't cut here! You damage the screen --- X ----------- o \ / o ------------------------------ Date: Mon, 22 Feb 93 07:00:24 -0500 From: Otto Stolz Subject: Re: FORM (again!) (PC) On 12 Feb 93 (14:53:29 GMT), Julian Haddrill wrote: > I too have had the same problem, with the 'FORM' virus. [...] On Mon, 15 Feb 93 16:23:41 -0500 Paul Ferguson said: > [...] Your problem sounds as if you're either finding "ghost" > signatures in memory (or in the master boot sector, which was not > disinfected properly) or you somehow have managed to re-introduce the > virus into your system in some fashion. On HDs, FORM does infect the DOS boot record, rather than the Master Boot Record, as Paul Ferguson seemed to imply. This detail is important when you try to clean a HD by generic means: you eradicate a MBR infector (such as Brain, Stoned, and their descendants) by means of the "FDISK /MBR" command (after making sure that the partition table is still in place), while you eradicate DBR infectors (such as FORM) by means of the "SYS C:" command. Needless to say that you have to clean-boot first, in any case. Best wishes, Otto Stolz ------------------------------ Date: Mon, 22 Feb 93 12:03:11 +0000 From: v922340@hildebrand.si.hhs.nl (Ivar Snaaijer) Subject: Re: Minimal virus scan? (PC) swesterback@tne01.tele.nokia.fi writes: >We have an automatic virus-scan (in autoexec.bat) on all computers >here at work. As it slows down the boot process to much on some >computers i am planning to scan only parts of the files instead of the >whole disk. > >My question now is if these assumptions are correct: >- - viruses only infects: > *.EXE and *.COM -files that has been used when a virus is in memory > the boot sector > command.com >- - it is enough to scan only memory, the boot sector and for example the > following files: > command.com smartdrv.exe emm386.exe keyb.com > win.com win386.exe lat.exe redir.exe > You assumed right but checking only the last files, will only give you a warning AFTER the system is infected, witch will only be detected while rebooting, so if there is an infection the program that carries the virus inside the system will not be scanned just after some damage is done. >Is that correct? If not please tell me why not! I can also think about >varying the scanned directories from day to day. > >Also is there really any need to scan DLL, DRV, OVL and SYS-files? > The so called overlayfiles are only infectable if they have real EXE header types. otherwise it is some kind of datafile witch hasn't got a regular beginning or end (just another binary). The sys files (like IO.SYS or IBMIO.SYS) are known files, someone who wants to know where it is executed form can ask it, so it's rather easy to infect. #define EXECUTABLES "*.COM *.EXE *.SYS *.OV?" If speed is the problem, you could try TBSCAN, (availeble on SIMTEL as TBAV503.ZIP) in quick mode it scans over 700 EXECUTABLES in 15 seconds (on a 213MB harddisk in a 486 SX 25Mhz system), Scanning in normal mode the same computer does it in 25 seconds, Also the program produses some highly active screen display so no one will be bored (colors and stuff) the program also has a feature that stops it form scanning after every boot-up (you can tell it to only scan once a day). >Sten Ivar. - -- - ----------------------------------------------------------------------------- Rule one in program optimization : Don't do it. Rule two in program optimization (for experts only) : Don't do it yet. Rule three in program optimization (for athlets only) : Just do it. ------------------------------ Date: Sat, 20 Feb 93 13:19:28 -0500 From: krvw@first.org (Kenneth R. van Wyk) Subject: I-M141.ZIP - Integrity Master (PC) I have uploaded to WSMR-SIMTEL20.Army.Mil and OAK.Oakland.Edu: pd1: I-M141.ZIP Integrity Master data integrity/anti-virus sys This is the latest version of Stiller's Integrity Master, version 1.41, that I received on floppy directly from Wolfgang Stiller. Ken - - - Kenneth R. van Wyk Moderator VIRUS-L/comp.virus krvw@FIRST.ORG (Moderator account) ken@THANG.PGH.PA.US (home - until I've relocated to DC) ------------------------------ Date: Sun, 21 Feb 93 15:25:43 -0500 From: James Ford Subject: New files on risc (PC) The following files have been placed on risc.ua.edu (130.160.4.7) for anonymous FTP in the directory /pub/ibm-antivirus: i-m141.zip - Integrity Master v1.41 vsumx301.zip - Virus Summary Listing virx26d.zip - VIRx, Ross Greenberg's Virus detection program - ---------- A hypocrite is one who sets good examples when he has an audience. - ---------- James Ford - Consultant II, Seebeck Computer Center The University of Alabama (in Tuscaloosa, Alabama) jford@ua1vm.ua.edu, jford@seebeck.ua.edu Work (205)348-3968 fax (205)348-3993 ------------------------------ Date: 19 Feb 93 16:25:00 -0600 From: "Rob Slade, DECrypt Editor, VARUG NLC rep, 604-984-4067" Subject: Michelangelo discovery and naming (CVP) HISVIRW.CVP 930210 Michelangelo Discovery and Naming Michelangelo is widely reported (even by the CARO Computer Virus Catalog) to have been discovered in Europe in the spring or summer of 1991. Roger Riordan, however, had reported and named the virus in Australia in February of 1991. He suspected that the virus had been received by the company affected from disks of software from Taiwan, but this could not be finally determined. The date in February of 1991 is very telling. This indicates the existence of the virus prior to March 6 (the "trigger" date) of 1991. This further indicates that the virus, although it "destroys" itself along with the system tracks of disks overwritten on that date, can survive. This is not really surprising: few computer users understand that boot sector infecting viral programs can both infect and infect from any disk, whether or not it is bootable, contains any programs or, indeed, contains any files at all. Riordan determined that March 6 was the trigger date. He mentioned this to a friend who remarked that it was his birthday, and who also happened to know that it was the birthday of the renaissance painter, sculptor and engineer Michelangelo Buonarotti, born March 6, 1475 in Caprese, Italy. The name thus comes from the coincidence of dates. There is no text in the body of the virus, and certainly no reference to Michelangelo. There is no evidence that the author of the virus knew anything of this connection. (As a piece of trivia, March 6 is also Ed McMahon's birthday, leading to jokes about viral messages stating, "Congratulations! Your computer may already be infected!") (Interestingly, in Taiwan the virus is widely known as the "Ninja Turtle" virus. Obviously, in the young and not highly cultured world of "teenage mutant ninja hackers", comic book characters are more familiar than renaissance artists, even though all of the "Teenage Mutant Ninja Turtles" (TM, probably) are named after painters of that ilk. However the cartoon/comic/toy characters have no known association with March 6, and this reference is obviously a mistaken extension of the Michelangelo name.) Given the reports of "discovery" of the virus in the summer of 1991, Michelangelo was very rare in the first half of the year. (Likely even rarer on March 7 than it had been on March 5.) However, it spread extremely rapidly, and by the fall of the year was sufficiently widespread that companies were beginning to ship out products infected with the Michelangelo virus by the beginning of 1992. By the time the public became generally aware of the need to check, in late February of 1992, it is likely that the number of copies was in the millions, if not tens of millions. Luckily, most were caught before March 6. copyright Robert M. Slade, 1992 HISVIRW.CVP 930210 (Upon consideration, maybe "tens of millions" is extreme. Remember, however, that I am talking about "copies" of the virus, not "machines destroyed".) ============== Vancouver ROBERTS@decus.ca | "virtual information" Institute for Robert_Slade@sfu.ca | - technical description of Research into rslade@cue.bc.ca | marketing info disguised User p1@CyberStore.ca | as technical description Security Canada V7K 2G6 | - Greg Rose ------------------------------ Date: Tue, 23 Feb 93 09:08:36 -0500 From: "Kenneth R. van Wyk" Subject: Re: Censorship Donald G Peters writes: > With everyone making these decisions on their own, we will > probably all be shortchanged. We should either have a > guideline to decide by, or have one person make the decision > for us (eg the moderator). I prefer the former idea because > there is always the chance that the moderator could be a > bad guy himself (no offense, moderator.) We do have such a guideline, and it is publicly available for comment. In fact, every new subscriber to VIRUS-L gets a copy of the guideline document, and it is available by anonymous FTP from: cert.org:pub/virus-l/virus-l.README I will gladly e-mail the document to anyone without FTP access. Should I be distributing it elsewhere? I could perhaps add it to the monthly automagic postings on comp.answers and news.answers... The posting guidelines, as I said, are available for public comment. If/when the majority of the group wishes to change or add to the guidelines, I will gladly do so. If the revisions are such that I cannot ethically abide by them, then I will step down from being the group's moderator. > I would agree to censor raw virus code but would like to consider > the value of censoring ANYTHING else. The current guidelines prohibit very little other than raw virus code. They do, however, prohibit the solicitation to copy or exchange raw virus code. Beyond that, there is little in the way of technical discussions that I will not accept for posting. (Other guidelines include politeness, relevant to the subject of computer viruses, etc. For the full list, please read the document.) Cheers, Ken Kenneth R. van Wyk Moderator VIRUS-L/comp.virus krvw@FIRST.ORG (Moderator account) ken@THANG.PGH.PA.US (home - until I've relocated to DC) ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 32] *****************************************