VIRUS-L Digest Monday, 29 Jan 1990 Volume 3 : Issue 24 Today's Topics: Re: Shrink-Wrapped Software Re: "Desktop Fractal Design System Not Infected" Re: Internet worm writer stands trial (Internet) Re: Signature Programs More re: Desktop Fractal Design System Re: Signature Programs Re: Signature Programs STONED Virus data (PC) WDEF Virus in California (Mac) More about UVDs Three new viruses (PC) The V651 virus (PC) Re: Virus vs. worm 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., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk --------------------------------------------------------------------------- Date: 26 Jan 90 21:00:24 +0000 From: draughn@iitmax.iit.edu (Mark Draughn) Subject: Re: Shrink-Wrapped Software cosell@BBN.COM (Bernie Cosell) writes: >ensys.ensys.com!silvlis.com!msm@sgi.sgi.com (Michael S. Maiten) writes: > >}WHMurray@DOCKMASTER.ARPA writes: > >}> Users can protect themselves >}> and discourage this risky practice by refusing to deal with retailers >}> that offer them the right to return. > >}Stores that offer return policies are exactly the ones with whom I do >}deal, since it is almost impossible to see if the software will meet >}my needs by reading the box or trying out the store demonstration >}copy. What they should do is to be more careful when accepting the >}returned items (check for missing materials, and check for infection >}of the disks) before returning the person's money. > >Actually, isn't this almost totally trivial for the store --- all they need >to is, before they re-shrink-wrap, do a sector-by-sector, byte-by-byte >comparsion of the *entire* disk(s) that were returned against a master set >the store keeps. It doesn't seem hard, and surely cannot take long, and far >as I can tell totally elminates the problems. This requires the stores to keep safe copies set aside for every piece of software they sell. It's a lot of work and it costs a lot in terms of time and equipment. How about this instead: Software vendors could ship the media separate from everything else in the piece of software, including the license to the software. When someone buys a piece of software from the store, they get the entire package and the disks. (Having separate media also makes it easy to choose 5.25" v.s. 3.5" etc.) If the customer returns the software, the store keeps everything except the actual disks. The disks are returned to the vendor. The vendor then sends the store a new set of disks. The store still has the same number of legal, licensed copies, so nothing much has changed. This seems like a good idea because the vendor already has the equipment, expertise, legal permissions, and master copies needed to produce virus-free copies of the software. The cost of doing this is small--just the cost of making and shipping a few disks. Whether the cost should be carried by the vendor, the store, or the customer is a detail that market forces will probably control. My guess is that the retail stores will end up eating the cost as part of the cost of good customer service. There are problems with cheating--the retailer could re-wrap, or the vendor could simply re-ship returned software--but I don't think this will make things worse. The retailer has relatively little to gain by cheating when he can get good copies so cheaply. The PR damage from even a single incident of shipping infected software should keep the vendor from cheating. How does that sound? - -- EMAIL: draughn@iitmax.iit.edu+--------------+ Academic Computing Center BITNET: SYSMARK@IITVAX | Mark Draughn | 10 W. 31st St. VOICE: +1 312 567 5962 +--------------+ Illinois Institute of Technology ALSO: ...{nucsrl|att}!iitmax!draughn Chicago, Illinois 60616 ------------------------------ Date: Fri, 26 Jan 90 14:50:52 -0500 From: Eric Roskos Subject: Re: "Desktop Fractal Design System Not Infected" Since writing the posting in today's VIRUS-L with the above Subject line, I have received some seemingly rather hostile mail criticizing the above statement. I would urge people who object to the above statement to (a) reread the original posting, (b) note the quotation marks around the statement, and (c) reread past issues of VIRUS-L regarding this problem more closely. My point in writing that particular Subject line was, and is, that to date there is no evidence *which has been presented on VIRUS-L* that the Desktop Fractal Design System, as shipped from the publisher, is infected. There is only the claim that it is, and the statement (secondhand) that the publisher is "aware" of the problem. Whether they are aware that some people say the program is infected, or whether they have copies of it from their stock that are infected, is not known from this statement. On the other hand, we do have evidence -- I have it right here -- that at least one copy is *not* infected, as purchased from a local bookstore (Reiter's Scientific Bookstore in Washington, DC). This also is not evidence that the copy was not infected when shipped -- someone might have bought the copy, disinfected it, and returned it to the store, for example -- but the converse possibility is true for the allegedly infected copies. Since I write-protected the disk before I used it the first time, I know it has not been written upon since I unwrapped it. It would be helpful to those of us who have to deal with these issues to know more about details of alleged virus infections, things such as: - Did you personally open and install the infected disk? - Did you write-protect the disk before doing so? - How many copies do you have that you know to be infected? - What is the version number of the software? Is there any other date or serial number information involved? More facts and less rumors would be helpful, both in understanding the problem, and ensuring that it is properly identified, particularly when a virus report contains some highly specific information (such as stating that a particular item of software is infected). (Incidentally, I would add here that it would also be beneficial to software publishers if they would publish their software on floppy disks without write enable notches in them. IBM used to do this with their early PC software disks; I don't recall seeing any like this in a long time. It would protect the publishers from being falsely accused of spreading a virus when in fact the disk was infected by the user during installation; although it would also eliminate their ability to claim the latter if they were, indeed, responsible for the infection. All around, the practice would seem to be an improvement.) Disclaimer: I have no connection with the author or publisher of the Desktop Fractal Design System; I simply own an uninfected copy of it. ------------------------------ Date: 26 Jan 90 13:38:02 +0000 From: woody@rpp386.cactus.org (Woodrow Baker) Subject: Re: Internet worm writer to go to trial Jan 16th. (Internet) > >Gene, in your report (_The Internet Worm Program: An Analysis_), you Where or how can I get a copy of this report? Cheers Woody [Ed. It is available via anonymous FTP from cs.purdue.edu in /pub/reports. I also keep a copy of it on the CERT anonymous FTP, cert.sei.cmu.edu, in /pub/virus-l/docs.] ------------------------------ Date: 26 Jan 90 13:53:51 +0000 From: woody@rpp386.cactus.org (Woodrow Baker) Subject: Re: Signature Programs Where can a description of ISO 8731-2 be obtained at little or no cost? Cheers Woody ------------------------------ Date: Fri, 26 Jan 90 18:51:35 -0500 From: Eric Roskos Subject: More re: Desktop Fractal Design System In keeping with my own suggestion, I checked the version number on the copy of this software that is not infected; it is version 1.0, as labeled on the disk (near the bottom of the green label on the disk), and when started up it also displays 1.0 as the version number. Can someone who has an infected copy post the version number involved? If it is a different version, that will give some insight. Thanks... - --E.R. PS - This copy I have was purchased about the 2nd week in December. There is not any other date or serial number marking present, other than a serial number for the floppy disk itself, "46892C", stamped on the back in ink. ------------------------------ Date: Fri, 27 Jan 90 00:28:39 +0000 From: utoday!greenber@uunet.UU.NET (Ross M. Greenberg) Subject: Re: Signature Programs 71435.1777@CompuServe.COM (Bob Bosen) writes: > > >1- The PERCENTAGE of the file that is subjected to the sophisticated >algorithm. This can sometimes be quite a small fraction of the whole >file. (The remainder of the file can be processed by an industry- >standard CRC algorithm. There are various techniques deriving from >cryptology that can be used to cause the effects of the sophisticated >algorithms to "ripple through" all the way to the final signature.) >Properly implemented, these techniques can result in a reliable, >virtually unforgeable signature that is calculated almost as quickly as a >conventional CRC. True, only if you're looking for a known pattern. Otherwise, you're guessing that your algorithm is smarter than the bad guys. Not on my machine you don't! You're gonna have to scan the whole file, every byte to tell me if there has been a change. It's incredible what a simple one byte change may produce: changing an INT25 to an INT26 (or vice versa) makes for a difference that can destroy your hard disk. A one byte difference. > >2- WHEN the signature is calculated. Obviously you can infuriate your >users if you make them stand around twiddling their thumbs while all your >files are authenticated in batch mode during the bootstrap process. On >the other hand, if most authentication is done "on the fly" as programs >are loaded, users hardly notice the delays. Assume that your user has a mongo file, maybe .5Meg of code s/he wants to load up. For the reasons cited above, you have to do *something* with each byte of the code. Take an XT, clocking at 4.77MHz. Add algorithm for *each* byte. Stir slowly. In the case of the XT, very slowly. Now, start adding to the complexity of the algorithm. Notice the chair in front of the terminal suddenly gone empty? That's because the user got frustrated at the time cost of a very sophisticated algorithm. > >3- How OFTEN the signatures are calculated. It really isn't necessary to >recalculate each and every signature every day, or even every time a >program is executed. Sensible authentication frequencies will depend on >the work environment, presence of known threats, and the value of assets >controlled, but may average once or twice a month in typical business >environments. Every time the file is loaded. Unless you'll guarantee the user, in writing, that there is no chance the next time I run a program on a supposedly clean system that I'm not running a damaging program. Of course, if you'll guarantee me that the system the user is on is clean and you'll also guarantee me that the user has introduced *no* new program whatsoever onto their system, well, maybe I can see your point. Would you be willing to guarantee this type of thing? > >4- The ALGORITHM chosen. Although its strength is not as well researched >as DES, ISO 8731-2 has withstood at least some respectable public >scrutiny, and runs at least ten times as fast as DES. Early indications >are that SNEFRU is a very strong algorithm that is much faster than DES. >RSA is much slower than DES. (And as I've consistently said since my >earliest posting, CRCs of varying strengths are available and can be used >in appropriate combinations with some of the more sophisticated algorithms >to speed things up still further.) Any two simple routines will outfunction a singular more complex routine. A well known routine, no matter the nomenclature, is easily breakable by anyone who a) understand the algorithm and b) has a dis-asm program handy. Two differing methods, say a simply checksum and a simple bit-add-rotate will do the trick faster and be just as effective. > >By judiciously balancing these variables, it is possible to create a >fast, reliable, sophisticated system that performs so quickly that users >hardly notice it. Interesting claim, but I've not seen usable proof yet -- usable to the real world, that is. I agree that complex algorithms will produce complex results that are difficult to get around -- but so what? > I have to agree with Ross Greenberg that a >sophisticated algorithm that performs poorly won't get used at all, and >is therefore worse than an unsophisticated algorithm. But I also know, >from direct, first-hand experience, that we need not limit ourselves to >thinking of sophisticated algorithms as being slow performers. All things >considered, there is really no reason NOT to abandon the simplistic >algorithms in favor of those that are likely to be beyond compromise by >virus writers for several years to come. I'd be interested in two things, both of which are (I think) easily available. One: timing results on real live files with anyone of the more sophisticated routines you propose versus sime CRC and checksum, and Two: any proof at all that one is going to prove more difficult than the other for a determined bad guy with a debugger and the ability to do "MOV DS:[BX], OPCODE_FOR_NOP" when they feel like it. Ross M. Greenberg, Technology Editor, UNIX Today! greenber@utoday.UUCP 594 Third Avenue, New York, New York, 10016 Voice:(212)-889-6431 BIX: greenber MCI: greenber CIS: 72461,3212 To subscribe, send mail to circ@utoday.UUCP with "Subject: Request" ------------------------------ Date: Fri, 27 Jan 90 00:36:46 +0000 From: utoday!greenber@uunet.UU.NET (Ross M. Greenberg) Subject: Re: Signature Programs 71435.1777@CompuServe.COM (Bob Bosen) writes: >When I began this in-depth series of discussions on authentication >algorithms and signature programs late last year, I was alarmed and >frustrated by the lack of attention being paid to the subject of well- >researched "standard" authentication algorithms. Bob continues, indicating that a bunch of people seem to agree with his premise that sophisticated algorithms are inherently superior than the less sophisticated ones. As one of the named parties, allow me to disagree, in part: for authentication that need be done only once, let the routine be as sophisticated as the data being authenticated need be. For data that must be scanned and authenticated regularly, I think that the expression "good enough" must come into play, alas. Otherwise, the 100% authoentication method will turn to 0% as the user simply stops using it. Ross M. Greenberg, Technology Editor, UNIX Today! greenber@utoday.UUCP 594 Third Avenue, New York, New York, 10016 Voice:(212)-889-6431 BIX: greenber MCI: greenber CIS: 72461,3212 To subscribe, send mail to circ@utoday.UUCP with "Subject: Request" ------------------------------ Date: Sat, 27 Jan 90 10:47:00 -0500 From: Highland@DOCKMASTER.ARPA Subject: STONED Virus data (PC) Response to Dave Lovless at UWO and Peter Jaspers-Fayer at Guelph: Explanation of what STONED virus does and step-by-step instructions to remove that virus from a hard disk can be found in: [1] COMPUTERS & SECURITY - Volume 8, Number 1 on page 11 [2] CAS - Volume 8, Number 2 on page 97 [3] CAS - Colume 8, Number 5 on page 369 All are part of my "Bits & Bytes" column in the journal of IFIP TC 11. Received the first copy of that virus directly from John Beatson of Data Systems in Wellington, New Zealand in October 1988. Data Systems is similar to our Federal Reserve System, only run by the banks. John is a close friend and is Manager of Risk and Security. Bill Kinny of Digital Dispatch, Inc., producers of Data Physician [I ran a review of product in February 1988 issue] and Virhunt and VirRes [scan programs] wrote piece on how to remove STONED virus from hard disk. His code was checked in real-time by me; I infected one of our machines and used his "cure" program. Complete information about STONED, aka Marijuana, New Zealand, is contained on pages 61 through 70 of COMPUTER VIRUS HANDBOOK just published by Oxford Advanced Technology Press [publishers of COMPUTERS & SECURITY] located in Oxford, England. David Loveless at University of Western Ontario has copies of CAS as does Professor John Carroll at UWO. John should have a copy of COMPUTER VIRUS HANDBOOK within two to three weeks. If anyone cannot get their hands on CAS issues, contact David, John or me. Both CAS issues and COMPUTER VIRUS HANDBOOK contain step-by-step explanation of how virus code works. The HANDBOOK also has this data for some 20 additional common viruses plus other information about this subject. - ---------------------------------------------------------------------------- Dr. Harold Joseph Highland, FICS [FICS = Fellow of Irish Computer Society] Distinguished Professor Emeritus of SUNY Editor-in-Chief Emeritus of COMPUTERS & SECURITY Managing Director of International Institute for Information Security Education and Training Highland -at DOCKMASTER.NCSC.MIL MCI Mail 406-5012 Voice contact for emergency: 516-488-6868 EST - ---------------------------------------------------------------------------- ------------------------------ Date: Sat, 27 Jan 90 12:52:02 -0800 From: GCO0000@CALSTATE.BITNET Subject: WDEF Virus in California (Mac) One of our Macintosh microcomputer labs was target of the new WDEF virus despite intense daily anti-viral measures. This warning is posted especially for the other universities in Northern California. Our staff are developing measures against this new virus. Gerry Gray Academic Computing Department Humboldt State University Arcata, California 95521 (707)826-4206, 4207, 4208 ------------------------------ Date: Sun, 28 Jan 90 15:18:47 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: More about UVDs Can an Universal Virus Detector (UVD) be written ? In order to answer this question, we need to define just what is meant by the term "virus". We can start with the definition by Fred Cohen, from his "Computer Viruses: Theory and Experiments": "We define a computer virus as a program that can infect other programs by modifying them to include a slightly altered copy of itself" This definition is not perfect. "program" should also include boot sectors, INITs and all other forms of executable code. "include" must also cover cases like the 405 virus, that overwrite the victim, and may destroy it completely. "slightly altered" is much too inaccurate. It is easy to imagine a virus that would only include a small part of itself in the programs it infects. See note #1 at the end for details. But is this modified definition just what we want ? Consider the following program. Program P1 Display "This is a copy utility" Display "Name of input file ?" Input In-File Display "Name of output file ?" Input Out-File Copy In-File to Out-File End Is P1 a virus ? Well, according to our definition, it is. If we give it the name of itself as In-File and the name of some other existing program as Out-File, it will behave just like any other destructive overwriting virus. Since P1 is able to place a copy of itself within another program, it is (according to this definition) a virus. So, any UVD would classify the above program as a virus. In fact, it would classify most operating systems as viruses, since they can easily "infect" other programs in the same way - you just have to give them the right sequence of commands. Any compiler used to compile a copy of itself would also qualify. "COMMAND.COM is a virus" "csh is a virus" "C is a virus" "OS/2 is a virus" I like that one..... :-) :-) But is this what we want ? Well - hardly. The major reasons for not wanting to call P1 a virus are: 1) It asks the user for the name of source and target files. 2) It destroys the "victim", instead of executing it more or less normally, after executing the virus. Objection 2 is not valid - as mentioned before we already have some programs like 405 and the AIDS virus (not to be confused with the AIDS trojan), that work like that. They are labeled as "viruses" without hesitation. Let's change the program a bit: Program P2 Display "Name of output file ?" Input Out-File Copy P2 to Out-File End Program P3 Display "Name of input file ?" Input In-File Select Out-File at random Copy In-File to Out-File End Program P4 Select Out-File at random Copy P4 to Out-File End We probably want our UVD to tell us that P4 is a virus, but also that P2 and P3 might behave like viruses in some circumstances. But, and this is the all-important question, is it theoretically possible to write a UVD that will tell us if a program may behave as a virus under some circumstances ? The UVD must always return with a "Yes" or "No". The answer is Yes, if we make some assumptions: The program which is to be examined will be called P. The computer P runs on will be called C. The environment of P will be called E. E is assumed to contain the values of registers, memory and data in external storage. P is assumed to be of finite size. Writing a UVD for programs of infinite length is impossible. It is left as an exercise to he reader to determine the result if we have a multi-processing system, with an infinite number of processors, each running an UVD and throw an infinitely long program at it. :-) E is also assumed to be of finite size, with a specified maximum. This excludes Turing machines. Writing an UVD for a Turing Machine is impossible, just as solving the halting problem for it. We can, however, in theory determine if a program will halt on some input on some specific real-world computer. All I/O operations consist of the transfer of finite amount of data. The UVD program runs on a different machine, C*. This machine must be many orders of magnitude more powerful than C. In fact, if C is a simple machine like Sinclair ZX80, with 1K of memory, C* would need to be more powerful than all current supercomputers combined. However, we must not be distracted by small problems like that. :-) The proof itself is not included, since it is too lengthy, but if there is interest I'll make it available. Note #1 - Multi-Part viruses Let us imagine we have the following three program parts Part A contains the main program Part B contains procedures for locating programs and making a program memory resident. Part C contains a file I/O routines. Let us then create two programs, one containing A+B and one containing A+C. If we only look at one of them, it is unable to replicate and (by definition) not a virus. Now the fun begins. If we run a program containing A+B, it will not infect other programs. It will however, hide a part of itself, namely B, somewhere in memory. and then execute the original program. If we run a program containing A+C, it is also unable to infect other programs, but it can check if B is present in memory. If so, then we can combine A, B and C in memory and run the combined program. It will use B to find all programs not yet infected. They will the either be infected (using C) with parts A+B or parts A+C. Repeat this for all programs that can be found by B. Then The "virus" here is the program containing A, B and C, but as I said I would demonstrate, it does not just include a "slightly altered" copy of itself in other programs, but rather just an "inert" part. The virus will only activate when its parts are combined. - -frisk ------------------------------ Date: Sun, 28 Jan 90 15:23:56 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Three new viruses (PC) New virus: Devil's Dance. Even though the name sounds as if this is a complex and interesting virus, it is not so. This virus is a very simple direct-action .COM infector reported to be from Spain. It will add 941 bytes to the end of any file it infects and overwrite the first three bytes with a JMP to the viral code. The virus may infect the same file over and over, just as the original Jerusalem virus did. Those of you having a copy of F-PROT can add the following line to SIGN.TXT, in order to enable detection of this virus: Dance BEbjA5tjKtmmT5mX4Kurg8uIgum4J628UGYOVjk5LOeDVjimIp New virus: Virus101 This virus is written by the author of Virus90. According to the documentation file, some changes have been made. The virus is now supposed to infect .EXE files and the boot sector, as well as .COM files. From the documentation file: VIRUS101 is the "big brother" of VIRUS-90. VIRUS-90 was a true non-overwriting virus designed to operate under the PC-DOS/MS-DOS operating systems. VIRUS-90 was specifically designed to give both experienced programmers and novice computer enthusiasts experience in dealing with computer viruses. VIRUS101, like VIRUS-90, is designed to educate the public on computer viruses, but is aimed more towards the programming populace. The author also states that the virus is tamper-proof and disassembly resistant. This is of course absolute bullsh*t - it would probably take an experienced assembly language programmer less than an hour to create a harmful variant of it. At least it took me only a few minutes to examine Virus90 enough to be able to write a program to detect it and remove it from infected files. The copy I have is labeled as pre-distribution and does not work. Since I no not include non-working viruses (like Pentagon) in my anti-virus program, I will not include this one yet. The author states that Virus90 and Virus101 are harmless, and he even has the nerve to ask authors of virus detection programs to "mention that both VIRUS-90 and VIRUS101 are educational utilities and that I have designed them for the benefit of programmers" and "include a short description of the programs for the good of the programming public. Thanks for your help on this." But, the fact remains that this is a virus, and could very easily be turned into a very dangerous one. So, as soon as I get a working copy of it, I will update my programs to detect and remove it. Still, at least the author has agreed to stop selling the sources. New virus: 1260 There is no doubt about it - this is the most interesting virus to appear recently. It uses an encryption method similar to that used by Cascade (1701/1704), but there is one VERY important difference: It is not possible to use ordinary identification strings to find infected programs, since the longest sequence of bytes identical in all infected programs has a length of three! To demonstrate the problem, here are the first five instructions from three infected files: INC SI CLC MOV AX,86FA MOV AX,F69F MOV DI,0147 MOV DI,0147 NOP INC SI INC SI MOV CX,0550 CLD CLD CLC DEC BX DEC BX The first 39 bytes of the virus are not encrypted, but they only contain 8 instructions, with a length of 17 bytes, for doing the actual decoding. The rest is just garbage, mostly one-byte instructions like NOP, CLC, STC, CLD, INC SI, DEC BX etc, that have no effect on the program, but are only meant to confuse. The last "feature", which nobody had expected is that the eight encoding instructions are not always in the same order, but may be permuted in 24 different ways. My virus detection program was not able to handle that, so I will have to create a new version - expect it in a day or two. "1260" is a resident .COM infecting virus. Infective length is 1260 bytes. - -frisk ------------------------------ Date: 28 Jan 90 20:00:00 +0700 From: T762102%DM0LRZ01.BITNET@IBM1.CC.Lehigh.Edu Subject: The V651 virus (PC) The V651 Virus -------------- This virus can be considered as a teaching example (a state of the art) of how to construct viruses. It is only 651 bytes long (I have named it V651 or Eddie-2, you will see later why) but contains solutions of almost all problems which a virus designer may encounter. The virus attacks both .COM- and .EXE-files. They are infected when you start them and the .EXE-files are distinguished from the .COM- ones by the `MZ' marker in the first two bytes. So you cannot fool the virus by renaming your *.COM files to, say, *.CMD and *.EXE to *.EXX and fixing the default extensions in COMMAND.COM. To be infected, the files must have a length larger than 651 and smaller than 64372 bytes. The virus installs itself in the memory by manipulating the memory control blocks, so it cannot be seen with such utilities as the public-domain MAPMEM. However, by using PC Tools (F3, system Info), you can see that the amounts of available memory found by PC Tools and by PC-DOS differ by 1 K byte (e.g., 640 and 639). (WARNING! I know at least 3 computers which show the above difference but have no viruses --- maybe sometimes this difference may be caused by the strange firm/hardware.) The virus' marker is like the one of the VHP-648 (Vienna A, Austrian) --- 62 seconds in time-of-last-update field of the directory entry for the infected files. This makes possible to design a vaccine (just like for the VHP-648 virus). One has simply not to forget to vaccinate both the .COM- and the .EXE-files. I'm wondering why the virus author did not made his virus three bytes shorter (which is possible) --- just to make it look like the VHP-648 one. When in memory, this virus intercepts two PC-DOS functions --- find-first (FCB) and find-next (FCB). They return various information about the respective directory entry --- its name, size, date and time of last update and so on. When an entry for an infected file is encountered (which is recognized by the time-of-last-update field), the virus changes the information in the `size' field, by subtracting 651 (its own size) from it. So if you type DIR with the virus resident in memory, you will obtain a directory listing with the original (non-infected) file lengths. This reduces the chances to discover the virus. The virus has his own critical error handler, so you won't get the "Abort, Retry, Ignore? " message when it tries to infect a write- protected diskette. However, the virus' author has made two mistakes. First, the virus does not intercept the find-first/find-next functions which are using the file handle (instead of FCBs used by DIR) method. So, if you look at a directory with a file-manager utility, you will almost certainly notice the increased file lengths. Second, if you already have a small (under 651 bytes) .COM-file, which is vaccinated against the VHP-648 virus and the V651 virus is resident in memory, you will obtain a huge number for the file length when listing the directory with the DIR command. The virus has no destructive functions. In fact it does not have any effects at all. The string "Eddie lives" is contained in its body but is never displayed. (The string contained in the original Eddie or Dark Avenger virus is "Eddie lives...somewhere in time!".) Obviously, the author of the V651 virus was envious for the faith of the Dark Avenger. Of course, this reveals also the fact that this virus was created in Bulgaria (I do not know its author). Just like the Eddie (Dark Avenger) virus, this one saves the critical information from the infected files in the last 11 bytes of its code. They have the following layout: IP (2 bytes) - The contents of the IP field of the EXE-header CS (2 bytes) - The contents of the CS field of the EXE-header SP (2 bytes) - The contents of the SP field of the EXE-header SS (2 bytes) - The contents of the SS field of the EXE-header (3 bytes) - The first 3 bytes of the file The (IP, CS, SP, SS) fields are used when an infected .EXE- file is run and the last 3 bytes are for the .COM-files. So, if you want to disinfect (cure? I'm not sure for the right word) an infected file, you have to restore the original contents of the .EXE-header (resp. - the first 3 bytes of the .COM-file) from the last 11 bytes described above and then to shorten the file by 651 bytes. Sincerely, Vesselin Bontchev ------------------------------ Date: 29 Jan 90 05:40:13 +0000 From: spaf@cs.purdue.edu (Gene Spafford) Subject: Re: Virus vs. worm hp-sdd!hplred.HP.COM!perry@ucsd.edu (Jeff Perry) writes: > This is probably a simple question, but I haven't heard it asked (or >answered). What is the difference between a virus and a worm? Well, there are many differing definitions, with one extreme being that all worms are viruses. The definitions I think most people use are: A virus is code that cannot run on its own. It is inserted into another ("host") program, and cause that program to run the virus code when the host is run. The virus code, when run, will insert a copy of itself in another "host," then possibly do some other task (often known as the "manipulation" task), then possibly execute the original host code. Viruses are not self-contained programs. A worm is a program that can run by itself. It is self-contained in that it can run as an independent program. It may use system programs to propagate itself. Worms travel (and possibly multiply) over communications links. They do not necessarily do anything other than travel from machine to machine (or propagate around a network), but they may also perform manipulation tasks, carry viruses, etc. Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253