Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5) id AA25814; Wed, 24 Feb 1993 18:50:22 +0100 Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA04204 (5.67a/IDA-1.5); Wed, 24 Feb 1993 09:13:42 -0500 Date: Wed, 24 Feb 1993 09:13:42 -0500 Message-Id: <9302221616.AA16415@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 #31 Status: R VIRUS-L Digest Monday, 22 Feb 1993 Volume 6 : Issue 31 Today's Topics: re: virus-definitions Re: my idea for detecting file infectors Re: Virus education Re: Scanners getting bigger and slower Re: Scanners getting bigger and slower Censorship OS2SCAN V100 checked (OS/2) Re: Help! Help, with FORM virus (PC) Re: Jeruslem variant (PC) Re: standardization (PC) Re: Tokyo Virus in NETCB or a false positive? (PC) Re: MtE Infected... (PC) Re: Tremor (PC) Re: F-prot/FSP/bootsum problem. Help! (PC) Re: NAV questions (PC) Re: standardization (PC) Re: Help with FORM (PC) Re: New Virus (PC) Re: windows virus (PC) - is WALDO one? Warning, logic bomb in PKZIP 2.04g, put there by PKWare 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: Fri, 19 Feb 93 06:48:31 -0500 From: KARGRA@GBA930.ZAMG.AC.AT Subject: re: virus-definitions Hi, if we can't get Xcopy and Diskcopy out of this definition, then someone will have to admit, that there are at least two benevolent viruses .... Alfred ############################################################################### Alfred Jilka #This place intentionally left blank. This place intent Geologic Survey, Austria#onally left blank. This place intentionally left blank KARGRA@GBA930.ZAMG.AC.AT#. This place intentionally left blank. This place inte ############################################################################### ------------------------------ Date: 18 Feb 93 21:16:51 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: my idea for detecting file infectors bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes: >This should detect any file infector except for stealth infectors. Almost, but not quite - it will miss any "companion"-type viruses. >This is my idea, and I want to think the following people to trying to >shoot holes in my theory. > >Glenn Jordan >Mike Lambert >Wolfgang Stiller Hey, why not me...*grin*... I see a few problems....by including only a few files, there is a chance of missing certain viruses...for example those which only infect files in the current directory. If none of your "victim" files happens to be located in that directory.....well...then you would not find it. You could of course include *all* your executables, but that would mean a long delay, and a significant waste of space. Still, overall it is an easy-to-implement "early-warning" system. - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 18 Feb 93 21:33:27 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Virus education mechalas@expert.cc.purdue.edu (John Mechalas) writes: > I could write a program, for example, that interrupts all I/O >access to the hard drive. Technically no - you could not....well, maybe on a +386+, using protected mode, debug registers and such...in general you would need hardware to intercept all I/O. Software can be bypassed. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 18 Feb 93 22:45:10 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Scanners getting bigger and slower Gal_Hammer@f111.n9721.z9.virnet.bad.se (Gal Hammer) writes: >Hi All, >I was thinking (Not happen a lot, but...) if every virus have his own sig. depends - some anti-virus programs use "generic" signatures - trying to catch as many viruses as possible with any single one....other products rely on highly specific signatures. >and every week few or some viruses appers, make that "every day" :-( >So don't all the AnitViruses program will start to get bigger and slower ?! Bigger, YES...slower, NO. Why on earth should we use a time-linear (o(n)) search algorithm, when better approaches (like hashing) are available ? Double the number of signatures, and the speed of any decent scanner will hardly be affected at all. There may still be some o(N) scanners around, but that primitive technology is doomed...personally I dropped it in 1991. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 19 Feb 93 05:49:48 +0000 From: phys169@csc.canterbury.ac.nz Subject: Re: Scanners getting bigger and slower Gal_Hammer@f111.n9721.z9.virnet.bad.se (Gal Hammer) writes: >... if every virus have his own sig. and > every week few or some viruses appers, So don't all the AnitViruses program > will start to get bigger and slower ?! The programs certainly will have more and more work to do, although the increase in time need not be proportional to the number and size of strings to look for. Another problem is that the people who have to create the scan strings get over-worked, have more "false positives", less time to check them thoroughly, and the updates could come further and further behind the discovery of the viruses. I wonder how Frisk, McAfee, and the rest survive the work load. I guess they employ Santa's elves in the off-season. Mark Aitchison. ------------------------------ Date: Fri, 19 Feb 93 15:59:43 -0500 From: Donald G Peters Subject: Censorship Someone said: (I'm not jumping on the author, I'm just trying to restate my opinion that we must consider what should be discussed on this forum and what should not...) > The most I can say, without > giving ideas to virus writers, would be... The text which followed that quote was a nice LITTLE summary of what viruses do. If the author was correct, and that was "the most" that we are allowed to discuss here, then I would be gone. However I think most people speak more freely than the above author did, but perhaps not with enough liberty even then. First, does anyone have any idea if there is any law that would prevent anyone from posting virus source code on this forum? Since this is an international forum, do we have to worry about breaking other the laws of other countries? I thought it was illegal in Canada to post virus code anywhere where it is accessible by the public. If that were the case, would we become "wanted" people in these countries?? Second, if there is no legal issue of any sort, at what point does the moderator need to censor information? Someone told me through email that they would not make any public references to certain books because they don't want the bad guys to find these books and learn from them. Is that really our right to judge? If the information is ALREADY public do we have any business censoring it? That tactic may work against the dumb bad guy, but not the smart bad guy. Does educating the dumb bad guy outweigh the benefits of educating the general public? All I really want to know is whether there should be guidelines for this matter. It seems to me that if we could develop guidelines (and who would be all that much better than us?) we could provide something of use to the computer community as a whole. I have NO objection to people keeping information private on the basis of 'trade secrets'. That is, privacy because they want to make money from their ideas. THat's fine. But very often I see people saying (or implying) "I can't talk about that here because that might give ideas to the bad guys." 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.) Since the techniques used by viruses are already widely available, and are useful for people to know about in order to set up defenses, we should never prohibit this information. Even hypothetical virus behaviour can be useful for setting up a defense. But "behaviour" can be considered to be a "specification" for code, and in a few cases there are ways to compile specifications into code, but not in this case. Please feel free to propose things that we should NOT post on this forum. I would agree to censor raw virus code but would like to consider the value of censoring ANYTHING else. ------------------------------ Date: Fri, 19 Feb 93 06:48:14 -0500 From: KARGRA@GBA930.ZAMG.AC.AT Subject: OS2SCAN V100 checked (OS/2) Hi all, again I was checking OS2-antivirussoftware from McAfee. First thing I found, was that OS2VAL does not seem to be aware of its own name. The help-info gives as example: VALIDATE 0.5 for OS/2 Copyright 1988-92 by McAfee Associates. (408) 988-3832 This program prints the validation information for a file. Examples: VALIDATE SCAN.EXE VALIDATE SCANRES.EXE And BTW: Why should I validate SCAN ? I think this should be OS2SCAN... The doc's really give a false sense of security. But Vesselin already took the word from my mouth. OS2SCAN: Documentation: ~ The /SAVE switch does not modify the OS2SCAN.EXE file. Instead, it creates a SCAN.INI file. ^^^^^^^^ This should read: os2scan.INI (a copy of what a DIR showed me in a window) Program: Though gammatech "sentry" is always active to lock bootsector and various files against tampering, OS2SCAN behaves well. (at least on HPFS-drives.) The program however still does not check DLLs by default. Thus it is still necessary to save additional extentions (ADD(AdapterDeviceDriver=Basedevice), DMD(DiskManagerDriver=Basedevice),DLL(DynamicLinkLibrary)) which contain executable code, where ADD and DMD probably will be locked by the system, but you never know if it was not already infected when you got it. Even if there is currently no specific OS2-virus, DLLs might have been damaged by a silly DOS-based virus. Another thing is, that still the option exists to modify all executables by adding checksums. The documentation points out, that there are several programs, where you must not do this, as they are already selfchecking: NOTE: Files which are self-checking (e.g., Lotus 1-2-3) should not be validated with the /AV (Add Validation) or /AG (Add Generic) switches which modify files. Instead, use the /AF (Add File) switch. So please tell us all: why do you still maintain these modifying options ?? To me it is a strange philosophy. Your customers don't want, that something tampers with their programs and data, you give them the means to reach the goal, but tamper with their programs yourself! You seem to be aware of the problems ! And I still can't understand the use of /RF {filename} - This option removes recovery and validation data from log file {filename} created by the /AF option. Is it not sufficient simply to delete this file ?? Or does /AF modify some- thing in a way, the user should not know ? HPFS seems to be supported very good, as this is one of the first shareware- products I have seen, which support long names(i.e. are not restricted to 8.3 filenames.) '/AF rec.data' works perfect! For some mysterious reason, option /DATE still refuses to create a SCANVAL.VAL file on the directory, where OS2SCAN resides. It is not in a rootdirectory too. Neither hidden nor something else. :( Thus option /SHOWDATE still fails. :( Again: In my review of version 99 I suggested to put it in your INI-file, where the date is relatively save from being changed unintended by the user. Do not use the /SUB switch if you are scanning a drive from the root level. Could you tell me why ??? I tried OS2SCAN C: /SUB and OS2SCAN C:\ /SUB, apparently there is no difference.(Maybe an unconfirmed slight speedimpact) The description seems to be better in OS2NSCAN.DOC. I know, that computerists usually tend to shortcut whatever they can, but here is a way to tell people about OS2 and long filenames, instead of 8.3: OS2SCAN C: /NOPAUSE /REPORT A:INFECTN.RPT ^^^^^^^^^^^ How about A:INFECTION-REPORT This should be improved, as you have a (useless) /RF option too: In addition, the SCANVAL.VAL hidden file containing validation codes for the partition table, boot sector, COMMAND.COM, and system files may have to be replaced (unhide the file with the ATTRIB command and then delete it). Why must a user unhide and delete this file. Either there should be a new option to delete it or it is updated like the INI-file or the /AF file. Your important note on false positives has a better place at the beginning of the docs. People hardly read them anyway, and will shurely miss such a note if it is at the very end. OS2NSCAN: Program: This program already misses switches /AG and /AV and the related ones. (according to the docs) I suppose, this is due to the networking environment, that you do not change other peoples data. Anyway: it would be a step in the correct direction. However: the helpscreen shows this: \ - Scan root directory and boot area only /A - Scan all files, including data, for viruses /AD - Scan all local hard drives /AF filename - Store recovery data/validation codes to file /AG filename - Add recovery data/validation codes to specified files EXCEPT those listed in filename /AV filename - Add validation codes to specified files EXCEPT those listed in filename As I don't want to alter my files, I won't test it. But maybe Mr.Goretsky can clarify. Regarding default-extentions the same applies as in OS2SCAN. As I go through the docs, I start wondering, why there is no OS2NCLEAN ? The docs suggest to use OS2CLEAN, if an infection is found with OS2NSCAN. In order to read files on a network, you need a special version of OS2SCAN. In order to write to files on a network you do not ??! I'm not a specialist, but this is a thing I can't understand ... >:] (Hard thinking smiley) Somehow this program was 'improved';) Now you can't run it anymore if there is no network present, which was perfectly possible in version 99. At least the computer is not dead-locked anymore, like it happened with NSCAN for DOS. Docs: There is something mysterious: Options are: \ - Scan root directory and boot area only /? /H or /HELP - Displays help screen /A - Scan all files, including data, for viruses /AF {filename} - Store recovery & validation data to {filename} /BELL - Beep whenever a virus is found Following is a detailed description of OS2NSCAN's options. Please note the /AF and /AG switches modify executable files. This may cause other anti-viral programs to generate a warning. /AF does NOT modify files, does it ? /AG does not exist according to the available options. So how do I understand this difference ? /SAVE The options are stored by creating a file named NETSCAN.INI in the same directory as OS2NSCAN.EXE. ^^^^^^^^^^^ I found the INI to be named: 18.02.93 22.25 33 0 os2nscan.INI Once again: The important note should be placed at the beginning, not at the end, where hardly any user reads it. OS2CLEAN Program: Docs: VIRLIST.TXT: >For replacing the MBR code on MS-DOS 5.00 partitioned hard disks, use the >FDISK.EXE program with the undocumented /MBR switch. This is somehow not precise: you can use MSDOS 5.0 FDISK /MBR for any DOS- formatted HD if it does not use special diskdrivers to circumvent DOS- limitations. This is all for today, Alfred ############################################################################### # Alfred Jilka #This place intentionally left blank. This place inten t Geologic Survey, Austria #onally left blank. This place intentionally left blan k KARGRA@GBA930.ZAMG.AC.AT #. This place intentionally left blank. This place int e ############################################################################### # ------------------------------ Date: 18 Feb 93 21:28:45 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Help! Help, with FORM virus (PC) a_rubin@dsg4.dse.beckman.com writes: [F-PROT pricing info deleted] >(There, now I've said it. You don't have to violate network >advertising guidlines, Frisk.) Thanks for the free advertising.... :-) Anyhow, if you are dealing with FORM, be sure to use version 2.06 or later (2.07 is the latest)....There was a FORM-related bug in earlier versions - it would sometimes refuse to remove FORM from hard disks, claiming it could not locate the original boot sector. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 18 Feb 93 21:36:52 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Jeruslem variant (PC) lx523c@seas.gwu.edu (Le L. Chen) writes: >can not understand how come the first time checked it was ok, later, >after the computer was infected, it can detect them. one possibility is that you might have some virus "dropper" program - a scanner might not find a virus hidden inside it...then you run it, and the virus goes resident, infects other programs, and the next time you run the scanner it would find the other infected files. Another possibility is that the virus might be hiding in some overlay file, that is not scanned by default. Try scanning *ALL* files. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 18 Feb 93 22:13:06 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: standardization (PC) bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes: >I feel that the authors of scanners need to get together, and agree on a >naming system. We did....more than a year ago...:-) Actually, there is a *semi-official* naming standard...the CARO naming scheme, which unfortunately is not used by all the programs on the market. Even the programs that try to stick pretty close to it, like Dr. Solomon's Toolkit, and my own F-PROT do not always agree 100%, but we are at least trying. There are some programs that don't use this naming standard. In some cases they have just not gotten around to it...in other cases you may have a package which is very good at detecting viruses, but not-so-terribly great at distinguishing one virus from another - if the scanner does not even know what virus it is deling with, how can it be supposed to name it correctly ? Finally, the author(s) of the package may just not like the CARO name structure, which sometimes can produce quite long names. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 18 Feb 93 22:33:57 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Tokyo Virus in NETCB or a false positive? (PC) I.LEITCH@lshtm.ac.uk (Ian Leitch) writes: >These and other indications lead me to think that I may have hit >a false positive. Yup, you did...sorry....I have now fixed it, and created a new version of the VIRSTOP program, which fixes this - you can FTP it from complex.is Everybody else, don't worry about getting this (new) version, unless you encounter the same problem (Tokyo false positive), which should be quite unlikely if you are not using this NETCB program. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: Thu, 18 Feb 93 23:00:22 +0000 From: exucad@exu.ericsson.se (Charles Dobbins) Subject: Re: MtE Infected... (PC) mdewaele@TrentU.CA (martin dewaele) writes: >From: mdewaele@TrentU.CA (martin dewaele) >Subject: MtE Infected... (PC) >Date: 12 Feb 93 06:52:20 GMT >I have Norton Anti-Virus 2.1 and it has detected what is called the >MtE Infected virus. Yet the Repair function states that it is unable >to repair the infected file. >Does anyone happen to know what the virus is or the problem which is >creating this warning in Norton Anti-Virus. Norton Anti Virus has some problems with finding false positives for MtE virus's. If you call the Symantec BBS at 408-973-9834 they have updates that fix some of the false MtE problems. We use NAV on a LAN and have had a few MtE problems with it and the patch seemed to help. One odd problem is that it seems to find MtE in 0 byte files mostly. Good Luck - ------------------------------------------------------------------------------ Charles Dobbins Ericsson Network Systems, Inc Systems Programmer P.O. Box 833875 Richardson, TX 75083-3875 (214) 997-0982 - ------------------------------------------------------------------------------ ------------------------------ Date: 18 Feb 93 22:53:13 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Tremor (PC) fergp@sytex.com (Paul Ferguson) writes: > not had an opportunity to effectively measure), but since there were > no references to it within the F-Prot documentation ("New viruses -- > detection added..") or from within the program itself ("Not yet > analysed"), I suspect that detection of TREMOR was a last minute > addition. It most certainly was....in fact the current detection routine is only a temporary solution - not perfect (similar to my first MtE detector), but it should be working 100% in version 2.08. The integrity checker in F-PROT Professional handles it without problems, just like any other similar package. - -frisk - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: Thu, 18 Feb 93 23:03:46 +0000 From: mechalas@expert.cc.purdue.edu (John Mechalas) Subject: Re: F-prot/FSP/bootsum problem. Help! (PC) jornj@colargol.edb.tih.no (jornj) writes: >: FSP+). I have FSP configured so that it checks my bootsum when I boot >: up. The value of the bootsum is not supposed to change, and never >: does until I scan my drive with F-prot. After I finish scanning my >: drive I get an alert from FSP saying my bootsum records do not match, >: and then it shows the newly assigned value. I am confused about why >: F-prot changes my bootsum when it scans my drive and if there is >: anything I can do about it. > >: By the way, my system is a IBM AT (100% compatible) running Stacker on >: a 32m hard drive, and DOS 5.0. > >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). As near as I can tell, this is normal for Stacker. My copy of Intergrity Master always claims a change in the boot sector as well. I am not sure why this is, though, not being very technically literate as far as Stacker is concerned. - -- John Mechalas \ If you think my opinions are Purdue's, then mechalas@expert.cc.purdue.edu \ you vastly overestimate my importance. Purdue University Computing Center \ Stamp out and abolish redundancy. General Consulting \ #include disclaimer.h ------------------------------ Date: Thu, 18 Feb 93 23:23:28 +0000 From: 007 Subject: Re: NAV questions (PC) mcafee@netcom.com (McAfee Associates) writes: >>As far as I know, there is a close link between the authors of SCAN and >>VSUM, and i wouldn't trust the test as a purely independent test. > >There is no close link between McAfee Associates and Ms. Hoffman, at >least, none different from that between her and any other anti-viral >vendor. Really? I wonder why Ms. Hoffman states in her "A word from Patricia..." section: A special thanks goes to John McAfee for the countless hours he has spent reviewing VSUM prior to its release. Seems she has a bit more of a connection with SCAN than "any other anti-viral vendor." -- 007 - -- 000 000 7777 | sbonds@jarthur.claremont.edu 0 0 0 0 7 |----------------------------------------------------------- 0 0 0 0 7 | Childhood is short... 000 000 7 | ...but immaturity is forever. ------------------------------ Date: Thu, 18 Feb 93 23:56:28 +0000 From: 007 Subject: Re: standardization (PC) bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes: >I feel that the authors of scanners need to get together, and agree on a >naming system. A (very) few already have. The naming system is called the CARO standard, and the scanner that adheres most closely with it (that is widely available) is F-prot. Vesselin periodically publishes a cross-reference between SCAN output, F-prot's output, Dr. Solomon's output, and the "official" CARO name for every virus in Vesselin's collection. This can be VERY useful for keeping my virus collection straightened out, but it would be even better to have F-prot spit out the exact CARO name. Some of my variants of jerusalem are impossible to distinguish by F-prot's output alone. (Hey frisk, how about "f-prot /CARO" as a command line switch?? ;-) -- 007 - -- 000 000 7777 | sbonds@jarthur.claremont.edu 0 0 0 0 7 |----------------------------------------------------------- 0 0 0 0 7 | Childhood is short... 000 000 7 | ...but immaturity is forever. ------------------------------ Date: Fri, 19 Feb 93 10:03:44 -0500 From: Bill Hayes Subject: Re: Help with FORM (PC) Thanks very much for the speedy response to my FORM infestation. Nearly everyone recommended F-PROT, and I have the bureaucracy churning out a purchase order for this very good piece of software. I received nearly 50 noted from Virus-L readers, and I think I've been able to send a nice and short (!) reply to everyone. One correspondent stated that F-PROT would be available in the U.S. from a U.S. vendor at about $2.00 per machine. I contacted the vendor and discovered that the "professional" version costs about $50.00 for a single copy. Site licenses go for about $35 per machine. This is supposed to pay for toll-free telephone support, a new check-sum feature, and a printed manual. Bill Hayes Computer Labs Supervisor IANR Communications and Computing Services Institute of Agriculture and Natural Resources University of Nebraska-Lincoln ianr012@unlvm.unl.edu ------------------------------ Date: 19 Feb 93 15:50:31 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: New Virus (PC) ilfc826@vax2.concordia.ca (Tan Bui) writes: > Well, from my point of view, the Whale virus is one of the better viruses > written by the virus authors. It uses stealth techniques and has procedures I disagree. Define "better". Even if we forget about the usual remark that no program that messes with your files without your permission can be a good program, then a "good" (sic!) virus should be a virus that is well written, uses clever tricks, has no bugs, and spreads well. Let's look at Whale: horribly written (spagetti code), full of bugs, unable to survive in the wild. As to the tricks - well there are indeed some armouring ones, but first they are too many and hamper the ability of the program to work and second everything else (tunnelling, stealth) is implemented in a rather clumsy way. No, Whale is definitively not "one of the better viruses"... The most that could be said is that it is the most puzzling one to disassemble. > to keep away the unsuspecting and the less qualified 'debuggers'. It is > a virus from which you can learn a lot, and I am sure that some people Really? And -what- have you learned from it? > will take its source codes for modifications. Fortunately, its source code has never been made available. > Take the Jerusalem virus for example. It is a rather old virus, and yet, > modifications have been made to it, and have been released. The main difference is that Jerusalem is easy to disassembly, understand, and patch. > Although the Whale virus has flaws, we can learn a lot from it. Yes, for instance: 1) Don't play games with the prefetch queue, or your program won't work on many machines. 2) If you don't know how to implement polymorphism, don't try to be smart by using N different decryptors, 'coz they can be detected by just using N different scan strings. 3) If you are going to obscure your code, don't overdo it, or your program will become so slow, that nobody will use it. Well, were the above point really worth writing a clumsy virus to prove them? Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 19 Feb 93 16:08:14 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: windows virus (PC) - is WALDO one? andywang@crown.berkeley.edu (Andrew Wang) writes: > I haven't been able to find any documentation of a virus called Waldo, > but since our data is valuable to us, I am taking the possibility > seriously. Here's some info: We run Word for Windows, Corel Draw, and Excel > almost exclusively. I've just downloaded virscan90 but it turns up nothing. Corel Draw is causing the problem. It contains the message about Waldo and displays it when an old version of Corel Draw is run on the new version of Windows, or something like that. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 19 Feb 93 20:03:46 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Warning, logic bomb in PKZIP 2.04g, put there by PKWare - -----BEGIN PGP SIGNED MESSAGE----- Date: 19 Feb 93 20:03:46 GMT If you read the documentation of the latest PKLite, you'll see that it provides an option that makes "disliting" a PKLited program more difficult. More exactly: > The extra compression option now writes the characters 'PK' > (50, 4B hex) into the psp at offset 5C hex. The user program > can check for this signature and abort if it isn't found. This > way the user program will not run if the PKLITE compression is > removed. This check may look something like the following in > Microsoft or Borland C: > > if (*(unsigned int far *)MK_FP(_psp, 0x5C) != 0x4B50) > exit(1); Well, the new PKZIP 2.04g (and possibly the older 2.04 versions too) make use of this possibility. On execution, they check for the identifier mentioned above, and, if it is not found, they destroy themselves by overwriting argv[0] with 64 Kb of junk. Therefore, if you are using one of the many "disliting" programs available - beware. The only program that allows you to handle the problem is Ben Castricum's UNP. It allows you to attach a small module to the dislited programs, which supplies the 'PK' identifier at runtime. So, if you are disliting the new PKZIP.EXE and PKUNZIP.EXE, make sure that you tell the program to attach this module. If you don't, the programs will destroy themselves at runtime. The logic bomb is obviously put there by PKWare, and does NOT have any other destructive effects. I couldn't figure out any way in which it could destroy anything that it shouldn't. Note: PLEASE, don't start a flame war on whether PKWare's act is ethical or legal; or whether disliting their program is ethical or legal; or whatever. The purpose of this message is just to warn you about a possible problem. Regards, Vesselin - -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK4U/iTZWl8Yy3ZjZAQHiiAP/aL3BfWCB03DnAZo488UwwXNQpkxkic8E EFYavJzZPkfSy6Xc95XVki9EvO3lG7a+jPZ2QOXMdmj2pmMtbYoIcJH0VAt9kXgX wnJg5fCTERt4bjIZRa67jII+dOdTgBR6yjPLCUU8lAPlbYbYCpRZs6j/nV18XQBc E+scisO55a8= =bQMA - -----END PGP SIGNATURE----- - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 31] *****************************************