========================================================================= Date: Mon, 2 May 88 08:05:15 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-From: "Kenneth R. van Wyk" Comments: Originally-From: WHMurray@DOCKMASTER.ARPA From: "Kenneth R. van Wyk" Subject: Viruses: another perspective Here's a VIRUS-L submission that was forwarded to me: Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = If found wandering aimlessly, = = User Services Senior Consultant = please feed and return... = = Lehigh University Computing Center =-------------------------------= = Internet: = This just in: = = BITNET: = Humptey Dumptey was pushed! = ------------------------------------------------------------------------ ----------------------------Original message---------------------------- One should not be surprised that the discussion of viruses by computer users should focus on how to protect their own systems. However, as I read RISKS I become concerned that is how the problem is perceived. A virus is a special case. It is a social disease. It attacks not only a target system, but a population of systems, and social order all at the same time. I am sure that if you have imported one into your system and if it does something destructive, you will see primarily in terms of the destruction that it does. However, similar damage could have been done by any Trojan Horse or even by your own error. The problem with the virus is not in the damage that it does to one system, but with the damage that it does to a population and to the fabric of trust that is essential to the sharing of programs and other data and to commerce in general. Suppose that viruses become so pervasive that even those who have never seen one become afraid to use any program that they did not write themselves. Suppose that because of the publicity received by viruses, the public at large were to loose confidence in all computers, in the information they generate, and in information in general. If you think that that is far-fetched, then I ask you to think back to the panic that followed the Tylenol contamination. In a society in which 1500 hundred people a year die early because of the use of asbestos, another 15000 from the use of fossil fuels, 40,000 from the use of the automobile and 200,000 from the use of tobacco, the level of concern was out of any realistic proportion to the number of deaths. But it was not out of proportion to the effect of the loss of confidence in the medicine supply or even of the food supply. I suggest that it was the unconscious concern for the effects of the potential loss of confidence that caused the panic. The perpetrators of the virus know very well how it will behave in the target system, but they have no idea how it will behave in the population. The XMASCARD program did not do any damage in the user's machine, but it brought a multi-million dollar network to its knees. The scope and sensitivity of that network was not only beyond the perpetrator's knowledge, but it was beyond his comprehension. The perpetrators of these toys are, like the sorcerors apprentice, playing with powers far beyond their knowledge or control. The potential for damage is far beyond their puny powers to predict, skills, motives, or their intent. They are toying with the mechanisms of cooperation and coordination that characterize humanity. They are to be pitied for their ignorance, but they are not to be tolerated, much less admired or emulated. A society that depends for its own proper functioning upon any mechanism, dare not tolerate any interference with the intended operation of that mechanism. Bill Murray WHMurray at DOCKMASTER ========================================================================= Date: Mon, 2 May 88 08:05:47 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-From: "Kenneth R. van Wyk" Comments: Originally-From: WHMurray@DOCKMASTER.ARPA From: "Kenneth R. van Wyk" Subject: "Write-protection" for hard disks And another forwarded submission: Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = If found wandering aimlessly, = = User Services Senior Consultant = please feed and return... = = Lehigh University Computing Center =-------------------------------= = Internet: = This just in: = = BITNET: = Humptey Dumptey was pushed! = ------------------------------------------------------------------------ ----------------------------Original message---------------------------- On April 22, 1988 I received two back issues of a newsletter entitled "Computer Virology" along with a product description for the Disk Defender (tm). "Computer Virology is published in Evanston, Illinois by Director Technologies, Inc. Director Technologies is the manufacturer of DISK DEFENDER, a product which write protects in hardware all or part of a personal computer hard disk. It is our belief that hardware write protection is the only 100% reliable virus protection for the operating system and commonly used programs." If you have any comments, questions, suggestions or article submissions, please address them to:" Director Technologies, Inc. Technology Innovation Center 906 University Place Evanston, IL 60201 312-491-2334 [Quoted without permission from the masthead of the newsletter. I am in no way associated with this firm. This is not a recommendation or endorsement of their product.] The product appears to be a half-card that installs between the drive and the hard disk drive controller card. It can make a portion of the or all the hard disk "write-protected." It has an outboard component with a 3-position switch which permits you to select between "full|zone|none." The outboard switch can be removed in order to remove the discretion from the user. In other words, it is a hardware write-protect tab for a hard drive zone. The size of the zone appears to be chosen by setting dip-switches on the card itself. To suggest that it is 100% effective against a virus is to overstate. Studies in biology suggest that a virus can thrive even in a population in which a large percentage of the members are immune, if a there is sufficient commerce among the non-immune members. This is not an argument against vaccines but only a caution about the limits of their effectiveness. Depending upon design of the virus, the target system and population, and the chosen distribution vector, the effectiveness of this mechanism against the spread of the virus might vary from high to none at all. Good hygiene is the general defense against viruses, but there are limits to how effective it can be. Nonetheless, the individual can and should protect himself within those limits. Page 1 ========================================================================= Date: Mon, 2 May 88 09:32:17 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Eshleman >Date: Tue, 26 Apr 88 09:39:51 CDT >From: Frank Peters >Subject: MacIntosh Virus Information Request >To: Hello, We are interested in obtaining information about virus programs (both causes and cures) on the Apple MacIntosh. There seems to be information available on IBM PC problems but very information about the Mac. Is this because there are fewer virus programs for the Mac or because of smaller interest in the mac? Thanks Frank Peters Mississippi State Computer Center Jim Eshleman Lehigh University Computing Center ========================================================================= Date: Mon, 2 May 88 09:34:43 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Eshleman >From: "John D. Abolins" >To: Virus Discussion List Subject: LaSalle talk of 288 April 88 concerning the "viruses" I did go to the lecture at LaSalle yesterday. I am still working on translating my quick notes into readable text. This should ready some time next week. Overall, the lecture was excellent and thourough without giving too much detail (to any unscruplous people in the audience.) After the talks by the panalists, MS-DOS anti-virus program disks were made available to the public. The disks contain public domsain and share ware software plus general virus text files. Three of the panalists work with companies which produce virus detection software. More on this later. Incidentally, if anyone on this forum is interested in any printed items from the forum or elsewhere, please leave me note. I can arrange for copies of much of these items. J. D. Abolins Jim Eshleman Lehigh University Computing Center ========================================================================= Date: Mon, 2 May 88 15:12:41 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: (old) Amiga virus information, for what it's worth... I just found some information that I had sitting around concerning an Amiga virus. It's kind of old, but it could be interesting to some people, so here it is: --------- From: bill@cbmvax.UUCP (Bill Koester CATS) Newsgroups: comp.sys.amiga Subject: Amiga VIRUS Date: 13 Nov 87 19:32:05 GMT Organization: Commodore Technology, West Chester, PA THE AMIGA VIRUS - Bill Koester (CATS) When I first got a copy of the Amiga VIRUS I was interested to see how such a program worked. I dissassembled the code to a disk file and hand commented it. This article will try to pass on some of the things I have learned through my efforts. 1) Definition. 2) Dangers. 3) Mechanics 4) Prevention 1. - Definition. The Amiga VIRUS is simply a modification of the boot block of an existing DOS boot disk. Any disk that can be used to boot the Amiga (ie workbench) has a reserved area called the boot block. On an Amiga floppy the bootblock consists of the first two sectors on the disk. Each sector is 512 bytes long so the boot block contains 1024 bytes. When KickStart is bringing up the system the disk in drive 0 is checked to see if it is a valid DOS boot disk. If it is, the first two sectors on the disk are loaded into memory and executed. The boot block normally contains a small bit of code that loads and initializes the DOS. If not for this BOOT CODE you would never see the initial CLI. The normal BOOT CODE is very small and does nothing but call the DOS initialization. Therefore, on a normal DOS boot disk there is plenty of room left unused in the BOOT BLOCK. The VIRUS is a replacement for the normal DOS BOOT CODE. In addition to performing the normal DOS startup the VIRUS contains code for displaying the VIRUS message and infecting other disks. Once the machine is booted from an infected disk the VIRUS remains in memory even after a warm start. Once the VIRUS is memory resident the warm start routine is affected, instead of going through the normal startup the VIRUS checks the boot disk in drive 0 for itself. If the VIRUS in memory sees that the boot block is not infected it copies itself into the boot block overwriting any code that was there before. It is in this manner that the VIRUS propagates from one disk to another. After a certain number of disks have been infected the VIRUS will print a message telling you that Something wonderful has happened. 2. - Dangers. When the VIRUS infects a disk the existing boot block is overwritten. Since some commercial software packages and especially games store special information in the boot block the VIRUS could damage these disks. When the boot block is written with the VIRUS, any special information is lost forever. If it was your only copy of the game then you are out of luck and probably quite angry!! 3. - Mechanics. Here is a more detailed description of what the virus does. This is intended to be used for learning and understanding ONLY!! It is not the authors intention that this description be used to create any new strains of the VIRUS. What may have once been an innocent hack has turned into a destructive pain in the #$@ for many people. Lets not make it any worse!! a.) Infiltration. This is the first stage of viral infection. The machine is brought up normally by reading the boot block into memory. When control is transferred to the boot block code, the virus code immediately copies the entire boot block to $7EC00, it then JSR's to the copied code to wedge into the CoolCapture vector. Once wedged in, control returns to the loaded boot block which performs the normal dos initialization. Control is then returned to the system. b.) Hiding Out. At this point the system CoolCapture vector has been replaced and points to code within the virus. When control is routed through the CoolCapture vector the virus first checks for the left mouse button, if it is down the virus clears the CoolCapture wedge and returns to the system. If the left mouse button is not pressed the virus replaces the DoIO code with its own version of DoIO and returns to the system. c.) Spreading. The code so far has been concerned only with making sure that at any given time the DoIO vector points to virus code. This is where the real action takes place. On every call to DoIO the virus checks the io_Length field of the IOB if this length is equal to 1024 bytes then it could possibly be a request to read the boot block. If the io_Data field and A4 point to the same address then we know we are in the strap code and this is a boot block read request. If this is not a boot block read the normal DoIO vector is executed as if the virus was not installed. If we are reading the boot block we JSR to the old DoIO code to read the boot block and then control returns to us. After reading, the checksum for the virus boot block is compared to the checksum for the block just read in. If they are equal this disk is already infected so just return. If they are not equal a counter is incremented and the copy of the virus at $7EC00 is written to the boot block on the disk. If the counter ANDed with $F is equal to 0 then a rastport and bitmap are constructed and the message is displayed. d.) Ha Ha. < Something wonderful has happened > < Your AMIGA is alive!!! > < and even better > < Some of your disks are infected by a VIRUS > < Another masterpiece of the Mega-Mighty SCA > 4. - Prevention. How do you protect yourself from the virus? 1) Never warm start the machine, always power down first. (works but not to practical!) 2) Always hold down the left mouse button when rebooting. (Also works, but only because the VIRUS code checks for this special case. Future VIRUS's may not!) 3) Obtain a copy of VCheck1.1 and check all disks before use. If any new virus's appear this program will be updated and released into the public domain. VCheck1.1 was posted to usnet and will also be posted to BIX. ( Just like the real thing the best course of action is education and prevention!) Bill Koester -- CBM >>Amiga Technical Support<< UUCP ...{allegra|burdvax|rutgers|ihnp4}!cbmvax!bill PHONE (215) 431-9355 ------------------------------------------------------------------------ = Kenneth R. van Wyk = If found wandering aimlessly, = = User Services Senior Consultant = please feed and return... = = Lehigh University Computing Center =-------------------------------= = Internet: = This just in: = = BITNET: = Humptey Dumptey was pushed! = ------------------------------------------------------------------------ ========================================================================= Date: Mon, 2 May 88 16:19:14 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim <15360JIM@MSU> Subject: anti-virus program request procedures I tried to get the lastest version of FLUSHOT, the anti-Virus/anti-Trojan progr an for MSDOS. If anyone knows the exact procedures to download that, please write to me at 15360jim@msu. Thank you! ========================================================================= Date: Mon, 2 May 88 17:23:14 +0300 Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Y. Radai" Subject: The Israeli viruses Loren Keim writes (25 Apr): > Israeli Virus: Not much is known. It apparently attaches itself > to all executable files, appending itself to the end of the file. > Watch for growing files. I must admit I find Loren's first sentence rather surprising. The one thing that spreads faster than a virus is news *about* the virus. And since the rather detailed report which I wrote on the Israeli virus for the Info-IBMPC digest has apparently been reprinted in about a dozen other digests and news- letters, I thought that as much was known about our virus as about others. But I guess I was wrong, so here are the details: It works in two stages: When you execute an infected EXE or COM file the first time after booting, the virus captures interrupt 21h and inserts its own code. After this has been done, every time any EXE file is executed, the virus code is written to the end of that file, increasing its size by 1808 bytes. COM files are also affected, but the 1808 bytes are written to the beginning of the file, another 5 bytes (the string "MsDos") are written to the end, and this extension occurs only once. Symptoms: (1) Because of this continual increase in the size of EXE files (apparently a bug), such programs eventually become too large to be loaded into memory or there is insufficient room on the disk (hard disk or diskette) for further extension. (2) After a certain interval of time (apparently 30 minutes after infection of memory), delays are inserted so that execution of programs takes up to 5 times as long. Also, some weird things happen on the screen. (3) If memory becomes infected when the date is set to a Friday the 13th (the next such date being May 13, 1988), any program file which is subsequently executed on that date (without rebooting first) gets deleted. (Other files may also be affected.) Note that this virus infects even read-only files, that it does not change the date and time of the files which it infects, and that while the virus cannot infect a write-protected diskette, you get no clue that an attempt has been made by a "Write protect error" message since the possibility of writing is checked before an actual attempt to write is made. Actually, this is only one of four viruses which have been discovered by us so far, although the others are apparently only annoying, not destructive. One of them is but a slight variant of the above virus; it behaves the same with respect to (1), the 30 minutes in (2) is only 30 seconds, and the erasure in (3) does not succeed, due to a bug. It is probably an earlier version of the above virus. There are several things you can do to detect, prevent, and/or eradicate this virus even without any special software. Detection: Choose one of your EXE files (preferably your most frequently executed one), note its length, and execute it twice. If it does not grow, it is not infected by this virus. If it does, the present file is infected, and so, probably, are some of your other files. (Another way of detecting this virus is to look for the string "sUMsDos" starting in the 4th byte of COM files or about 1800 bytes before the end of EXE files; however, this method is less reliable since this string can be altered without attenuating the virus. In the variant, the corresponding string is "sURIV 3.00".) Prevention: In addition to the usual general precautions, avoid running programs on any Friday the 13th. Of course, you can fake the date. But if your computer has been set to Friday the 13th by a clock-calendar card and one of the programs in your AUTOEXEC.BAT file is infected, it will be too late to change the date after completion of AUTOEXEC. Cure for infected files: Replace each infected file by a healthy copy (if you have one). However, note that even if you succeed in replacing all infected files, the virus will recur if memory remains infected, so re-boot immediately after replacement. The two other viruses have April 1 as their target date. One of them affects only COM files while the other affects only EXE files. If the date has been set to April 1, they display the message "APRIL 1ST HA HA HA YOU HAVE A VIRUS". In the EXE version this happens as soon as any infected EXE file is executed, whereas in the COM version it happens only after (1) an infected COM file is executed, thereby infecting memory, and (2) any other COM file is executed. In either case they lock up, forcing you to cold boot. Moreover in the EXE version there is also a lockup, without any message, one hour after infection of memory on any day on which you use the default date of 1-1-80. However, to the best of our knowledge they do not destroy any information. In both versions the file is extended only once. The main identifying string (corresponding to "sUMsDos" in the Friday the 13th virus) is "sURIV 1.01" in the COM version and "sURIV 2.01" in the EXE version. As a curiosity, all three viruses which attack EXE files write the year "1984" into the 19th and 20th bytes of each EXE file which they infect (in the form 84h 19h), replacing the checksum which normally appears there. I hadn't heard of any occurrence of these four viruses outside of Israel until I read (in Joseph Beckman's message of 29 April) that Fred Cohen stated that the Hebrew U. virus (presumably meaning the original Friday the 13th virus) has spread to the U. S. Automatic detection, prevention and cure: A pair of programs has been developed for these viruses by Yuval Rakavy, a student in our Computer Science Dept., and Omri Mann. One of them, UNVIRUS, cures already infected files by removing the virus code; it is specific to these four viruses. The other one, IMMUNE (a RAM-resident program), prevents future infection of memory and dis- plays a message when there is any attempt to infect it; it may also be useful against some other viruses. There are, of course, general-purpose programs which prevent file infection by preventing writing and formatting of disks when such protection is desired. I guess BOMBSQAD is sufficiently well known that I don't have to describe it. Another program, PROTECT, prevents writing onto specific drives (e.g. C:). (I have a slightly improved version of the program which first appeared in the Jan. 13, 1987 issue of PC Magazine.) The protection is easily toggled on and off (even when you're not on the DOS command level if you've got something like HOT-DOS available). The weakness of programs such as these is that a virus or Trojan horse could issue a write or format command directly to the controller of a hard disk. A more secure protection would be a hardware device placed between the controller and the drive. I am familiar with one such device, called Disk Defender. It involves dividing the hard disk into two logical drives in any desired size ratio, one of which is protected against *all* writes, while the other is unprotected. (You can easily unprotect the protected drive temporarily in order to transfer files to it.) The trouble with this system is its initial incon- venience: it requires a complete reorganization of your hard disk (moving all files and subdirectories into two separate directories according to whether they are to be protected or not), followed (and preferably also preceded) by a complete backup of the disk, followed by a re-format of the disk and restoration of its contents. * * * * * The above-mentioned authors of the Israeli anti-viral software have now developed a program which can detect infection of a file by *any* virus. Probably most of you don't believe that such a thing is possible. But this report is already getting too long, so I'll leave the description of that program to a subsequent report. Y. Radai Computation Center Hebrew Univ. of Jerusalem RADAI1@HBUNOS.BITNET ========================================================================= Date: Mon, 2 May 88 16:48:11 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: The Israeli viruses > (Other files may also be affected.) Do you have anything in particular in mind when you say that? I've heard from people who have done quite a bit of work disassembling the creature that only EXE and COM files are altered. Have you heard of it changing any others? DC ========================================================================= Date: Mon, 2 May 88 15:34:39 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Miami computer virus infection THIS IS A FIRST DRAFT OF A POSTING TO THE VIRUS-L LISTSERV GROUP. PLEASE RESPOND WITH EDITORIAL COMMENTS. MIAMI UNIVERSITY WAS HIT BY AN OUTBREAK OF MS-DOS AND MACINTOSH VIRUS APPROXIMATELY 10 DAYS BEFORE THE END OF SEMESTER. VIRUS APPEARED IN VIRTUALLY EVERY MICRO LAB ON CAMPUS WITHIN 2 DAYS OF FIRST NOTICE. THE IBM VIRUS APPEARED TO BE A VARIANT OF BRAIN. THE MAC VIRUSES APPEARED TO BE IDIOT AND SCORES. SCREENING PROCEDURES WERE INSTITUTED IN THE LABS TO DETECT AND QUASH VIRUS INFECTED DISKETTES. DETECTION BECAME MORE ACCURATE OVER TIME. THE PROCEDURE USED TO DISINFECT DISKETTES IS: 1) COPY DATA FILES (WP, SPREADSHEET, DATABASE) TO "CLEAN MEDIA" 2) FORMAT INFECTED DISKETTE ABANDONING ANY DOS AND OTHER EXECUTABLE FILES. 3) COPY DATA FILES BACK ONTO THE USER DISKETTE. THERE IS SOME REASON TO BELIEVE THAT THIS PROCEDURE IS OVERLY CAUTIOUS. IN THE MS-DOS WORLD: SCREENING PROCEDURES STARTED WITH LOOKING FOR THE WORD "BRAIN" IN THE DISKETTE LABEL. NOW WE LOOK FOR THREE OR MORE CONTIGUOUS BAD SECTORS USING SOMETHING LIKE THE NORTON UTILITIES. A STUDENT HAS WRITTEN A PROGRAM TO LOOK FOR VIRUS IN RAM. THE SAME STUDENT IS ATTEMPTING TO REVERSE ENGINEER A SOLUTION. FRED COHEN FROM UNIV. CINN. HAS BEEN UP TO ASSIST US AND WOULD PROBABLY HAVE GOOD INFORMATION ON THE VIRUS IF HE HADN'T CONTRACTED ONE OF THE HUMAN VARIETY LAST NIGHT. INFECTED DISKETTES HAVE BEEN POSTED TO BOWLING GREEN FOR STUDY (AND OF COURSE TO FRED). AT THIS POINT WE ARE NOT SURE HOW LONG THE DORMANT PHASE OF THIS VIRUS WAS. IT MAY HAVE BEEN SEVERAL MONTHS. SUBJECT TO FRED'S AND THE STUDENT'S NEW INFORMATION HERE IS WHAT WE BELIEVE ABOUT THE MS-DOS VIRUS. IT IS A VERSION OF PAKISTANI BRAIN. IT PROBABLY CANNOT INFECT A HARD DISK. MORE ON THIS WHEN WE REALLY KNOW. PROPERLY INSTALLED LAN'S APPEAR TO OFFER PROTECTION(BECASE OF THE ABOVE?) IT LIVES IN THREE CONTIGUOUS CLUSTERS (FIVE SECTORS) MARKED BAD IN THE FAT. THE VIRUS INSTALLS IN HIGH RAM AND CAN BE DETECTED THERE USING STANDARD DOS CALLS. WE HAVE DISASSEMBLED APPROXIMATELY 1/3RD OF THE CODE. IT MAY INFECT THE FOLLOWING FILES: COMMAND.COM, PRINT.COM, FORMAT.COM. FRED HAS A CHECKSUM PROGRAM THAT WE USED TO DIAGNOSE THIS BEHAVIOR. WE HAVEN'T FOUND THE CODE THAT DOES THIS. IT DOES ALTER THE BOOT RECORD ON BOTH SYSTEM DISKETTES AND DATA DISKETTES. BOOTING, EVEN WITH A DATA DISKETTE! LOADS BRAIN INTO RAM TO SPREAD INFECTION. DAVID KARIPEDES HAS DISASSEMBLED APPROXIMATELY ONE THIRD OF THE VIRUS AND HAS COME TO THE FOLLOWING CONCLUSIONS: 1. WHEN AN INFECTED BOOT SECTOR IS PROCESSED, BRAIN LOADS IN TO 7 K AT HIGH RAM. 3K OF PROGRAM, THE BRAIN BOOT BLOCK, AND THE ORIGIONAL BOOT BLOCK ARE LOADED WITH 2 I/O BUFFERS. 2. BRAIN POINTS THE $13 DISK INTERRUPT TO ITSELF AND MEDIATES ALL DISK I/O VIA AN INTERRUPT IT INSTALLS AT $6D. BRAIN ONLY ACTS AGAINST DISK READS. PROBABLY USING A COUNTDOWN TIMER IT CHECKS THE BOOT RECORD OF THE DISKETTE WITH POSTED I/O FOR INFECTION IF NOT INFECTED IT INFECTS FLOPPIES. 3. BRAIN CHECKS THE DL REGISTER ON READS AND ONLY INTERVENES IF 0,1, OR 2. THUS, IT PROBABLY CANNOT INFECT A HARD DISK. 4. THE INFECTED BOOT RECORD LOADS BRAIN FROM THREE CONSECUTIVE SECTORS THAT ARE MARKED BAD IN THE FAT. FIVE SECTORS ARE ACTUALLY USED, 3 FOR THE EXECUTABLE CODE, ONE FOR BRAINS BOOT RECORD, AND ONE FOR THE ORIGIONAL BOOT RECORD. 5. IF RAM IS INFECTED, EVEN USING LOW LEVEL DISK UTILITIES BRAIN WILL FEED YOU THE FALSE (ORIGONAL) BOOT RECORD! 6. AT PRESENT YOU MUST COMMUNICATE WITH DAVID VIA MY BITNET ACCOUNT. 7. A STAFF MEMBER IS WRITING A DISKETTE SANITIZING PROGRAM WHICH WE WILL POST TO VIRUS-L. THE VIRUS WILL PLACE BRAIN IN THE DISKETTE VOLUME LABEL AND REMOVE IT PERIODICALLY. THUS, ABSCENCE OF BRAIN IS NOT ASSURANCE OF A CLEAN DISKETTE. SOME OF THE THINGS THAT THE PRUDENT COMPUTER USER SHOULD DO IN THE COMPUTER AGE (SAGE WISDOM SUBJECT TO FREQUENT REVISION): USE ATTRIB TO MAKE COMMAND.COM AND MANY OTHER FILES READ ONLY. THIS LIST SHOULD PROBABLY INCLUDE PROGRAMS. BACKUP, BACKUP, BACKUP, BACKUP. I KEEP A 3 WEEK ROLLING BACKUP TO PROTECT MYSELF FROM DORMANT PHASE VIRUSES AS OBSERVED IN THE MAC WORLD. WRITE PROTECT ALL ORIGIONAL DISKETTES WITHIN SECONDS OF OPENING THE SHRINK WRAP. WHEN TRANSFERRING INFORMATION BETWEEN COMPUTERS USE DISKETTES THAT CONTAIN NO EXECUTABLES (SYSTEM AND APPLICATIONS SOFTWARE). WHERE POSSIBLE BOOT FLOPPIES SHOULD BE WRITE PROTECTED. IT IS NOT KNOWN AT THIS TIME WHETHER WRITE PROTECTION IS HARDWARE OR SOFTWARE MEDIATED. WE ARE FOLLOWING UP WITH IBM. IN THE MACINTOSH WORLD WE SUSPECT THAT WE WERE INFECTED BY SCORES AND IDIOT. MAC USERS ARE MUCH MORE ATONOMOUS AND OUR INFORMATION IS NOT AS GOOD. WE ARE STILL TRYING TO OBTAIN COPIES OF INFECTED MACINTOSH DISKETTES. IN THE MEAN TIME WE ARE DISTRIBUTING KILLVIRUS, VACCINE, AND FERRET 1.1. DIAGNOSIS RELIES UPON FINDING CHARACTERISTIC SIGNATURE FILES. PRESENT RECOMMENDATIONS FOR PREVENTION INCLUDE ALL OF THE ABOVE RECOMMENDATIONS FOR THE MS-DOS WORLD PLUS RUNNING KILLVIRUS OR VACCINE. SOME THINGS WE ARE CONSIDERING FOR NEXT YEAR. ENCOURAGE STUDENTS TO EXCHANGE INFORMATION ON DATA DISKETTES THAT DO NOT INCLUDE EXECUTABLES. MORE WRITE PROTECTION AT DOS ATTRIB LEVEL AND HARDWARE LEVEL. INVESTIGATE VIRUS PROTECTION SOFTWARE. IN THE MAC WORLD WE ARE USING VACCINE AND LOOKING AT VIRUSDETECTIVE AND KILLVIRUS. INVESTIGATE VIRUS PROTECTION IN THE MS-DOS WORLD? USE LOCAL HACKS TO PERIODICALLY LOOK FOR RAM RESIDENT SOFTWARE THAT SHOULDN'T BE THERE? ========================================================================= Date: Mon, 2 May 88 16:54:24 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Peter G. Neumann" Subject: Re: (old) Amiga virus information, for what it's worth... In-Reply-To: <8805022025.AA21543@csl.sri.com> Gee, That was in RISKS-5.71, 7 December 1987! But thanks anyway. And many thanks for VIRUS-L. Should be lively for you to keep track of everything. Should I mention it in RISKS, or would that FLOOD YOU with overhead? Maintaining mailing lists is a bear, even with LISTSERVE! P. ------- ========================================================================= Date: Mon, 2 May 88 17:16:32 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: OJA@NCCIBM1 Subject: A request for virus info In a recent issue of RISKS, a Congressional aide asked for information concerning computer viruses and their possible impact on national security. If you have input concerning this subject, you can contact- Herb Lin House Armed Services Committee 2120 Rayburn House Office Building Washington, DC 20515 (215) 951-1255 J.D. Abolins ========================================================================= Date: Mon, 2 May 88 17:18:35 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Peter G. Neumann" Subject: Re: (old) Amiga virus information, for what it's worth... In-Reply-To: <8805022025.AA21543@csl.sri.com> Terrrific. I have your contribution about VIRUS-L and will post it. By the way, is it not Humpty Dumpty? P. ------- ========================================================================= Date: Tue, 3 May 88 07:06:26 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Vin McLellan Subject: The Fate of PD Code PD need not die -- despite the virus plague; and despite the obituaries the virus threat has led so many vendor-supported publications to so (gleefully?) publish. "Public Domain" software may, however, tend to lean more into "shareware" and away from "freeware." Freeware, of course, is inherently cheapest... but now we have the problem of never really being certain that the code is clean and free of hidden danger (not in itself a new problem.) Shareware -- which circulates through the same public domain/freeware channels -- is copyrighted and typically accompanied by a request from its author for a (usually minimal) payment for licensed user rights. And, more than in the past, a shareware license will likely be accompanied by a disk with a clean copy of the purchased program. Nothing is likely to ever displace the PD circuit on the nets and bulletin boards as the cheapest and easiest way to both circulate new code and check out what's the newest. Even with infected code circulating, this can be done safely and intelligently on an isolated machine without a hard disk. Obviously, no responsible institution or group (or even an individual) is going to mix freeware code with working disks or files. The best defense against infected code is to obtain a legitimate shareware license -- and a guarranteed clean copy of the code, directly from the author. For a corporation or institution, that *contractual* link becomes essential for its internal security and ease of mind.(This may be lead to some strange scenes. More than a few programmers who just tossed out a now-popular freeware program onto a BBS system years ago may be surprised to find firms or institutions insisting on the right to pay them -- to establish a contractual relationship -- but they'll probably survive the shock.) Site or corporate licenses, now scorned by the industry, may be widely used here. In an institutional or user community, it will be up to local management to either buy enough guarranteed clean copies on disks... or arrange for trusted reproduction of an original received directly from the author. But the contract must and should be the foundation of safe software distribution. So freeware will inevitably be transformed into shareware; a craft cult into an profit-making industry sector; hackers into capitalists -- willy-nilly. (Some skateboard champs may have to open banks accounts, pay taxes, etc.) With that, Freeware/Shareware is likely to continue for the benefit of us all...and to bedevil a software industry whose pricing policies are more akin to Merlin's mumbled incantations than to any objective economic factors. Vin McLellan The Privacy Guild (Sidney.g.vin%Oz.AI.MIT.EDU@XX.LCS.MIT.EDU) Boston, Ma. 02111 (617) 426 2487 ------- ========================================================================= Date: Tue, 3 May 88 08:17:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: J_CERNY@UNHH Subject: Question related to Macs. At the risk of exposing my ignorance, I'll ask the following question. In reading about methods to disinfect or vaccinate an infected (or suspected) system, people talk about either throwing away infected files or running code (macrophage?!) to gobble up the infected parts. In thinking of the Macintosh, I'm wondering if there is yet another place where a virus could lurk -- the parameter RAM?? I don't even know if it is possible to write into that RAM, except that I have the impression that is where date/time is stored and the fact that the CHOOSER can update/set date/time implies it can be written to. Jim Cerny, University Computing, University of N.H. ========================================================================= Date: Tue, 3 May 88 08:59:28 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: LISTSERV options A couple people have asked me why they don't get a copy of their own submissions to the VIRUS-L list. Well, that's the default way that LISTSERV is set up. There's two ways around it; I can set up the entire list such that everyone receives their own messages, or each user can set their own LISTSERV options, at their discretion. I prefer the latter. To tell the LISTSERV program to send you your own submissions, send the following mail message to LISTSERV@LEHIIBM1: SET VIRUS-L REPRO Ok, it's a bit cryptic, but that's the way it works... :-) Note: Please do not send the above message to the list itself!!! Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: = Lone Star! = = BITNET: = = ------------------------------------------------------------------------ ========================================================================= Date: Tue, 3 May 88 10:42:49 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim <15360JIM@MSU> Subject: download FSP UUEARC to Micros I have the anti-virus file call FSP UUEARC at my IBM 3090 minidisk. I try to download it to micros. Please tell what additional UNARC file(s) I need, where to get it, and procedures to actually download it. I knew the way to download regular files through KERMIT. Thank You All! /Jim ========================================================================= Date: Tue, 3 May 88 10:50:23 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: download FSP UUEARC to Micros In-Reply-To: Message of Tue, 3 May 88 10:42:49 EDT from <15360JIM@MSU> >I have the anti-virus file call FSP UUEARC at my IBM 3090 minidisk. >I try to download it to micros. Please tell what additional UNARC file(s) I >need, where to get it, and procedures to actually download it. I knew the way >to download regular files through KERMIT. Thank You All! /Jim Just a guess, but it sounds as if the file is a uuencoded arc file. Uuencode/uudecode are two programs for converting a binary file into an ascii file and then back; thus making it easier to transfer binary files over networks. Once the uuencoded file has been uudecoded, it should be a standard arc file extractable by PKXARC or ARC. You can get a copy of uudecode from SIMTEL20.ARPA if you have Internet access, or I can send you a Turbo Pascal source code version. Please reply by direct e-mail if you want the Turbo source. I assume that FSP is Flu_Shot+? I'd be happy to make copies of Flu_Shot+, uuencode & uudecode, etc. available via this LISTSERV if there's sufficient interest. Comments anyone? That's not an endorsement of public domain anti-virus programs; rather, it'd be providing a place where people on this list could download these programs with a reasonable degree of certainty as to the integrity of the program. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: = Lone Star! = = BITNET: = = ------------------------------------------------------------------------ ========================================================================= Date: Tue, 3 May 88 13:37:56 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: BRAIN virus We have completely disassembled virus. It behaves as previously discussed. In the absence of programming bugs it only installs itself. It definately lives in the boot block plus 3 bad sectors. It does not infect any "normal" dos files. I specifically checks for and infects 5.25 inch floppies, no 3.5 , no hard disk. We have a simple brain remover program. Source will be posted to the list (assembly language) when the author thinks it is pretty enough. Disassembly and program work done by David Karipedes, a Miami student. To contact him use my bitnet mailbox. P.S. Since we have some diskettes with evenly spaced bad clusters in them, the search is on for the existance of another virus at M.U. We really don't have useful info one way or another at this time. ========================================================================= Date: Wed, 4 May 88 09:46:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: European viruses") from(forum) ========================================================================= Date: Wed, 4 May 88 09:57:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: European viruses Hi folks, I am working on computer viruses (and protection) for 2 years now, so I hope that I can contribute some interesting facts on viruses to this list. Although the description of known computer viruses should not be the only topic of this list, I like to start with a quick summary on the viruses I know that are not mentioned here before. We here in Europe have our own "virus" culture :-) so it may be of interest for you to have a look across the atlantic: The first viruses I heard of two years ago are written to show the THREAT of computer viruses. The first one, VIRDEM.COM is a non-replacing (not overwriting), not memory-residend MS-DOS virus. It infects all .COM files on drive A: only. The damage ias to ask a user for a number between 0 and n (n is the generation of the virus) if he starts an infected program. If he was wrong, the program terminates, if he was right, the program starts its work. This program was distributed to all interested computer users, especially computer and software manufactures. The second one was written by myself. It only infects the file KEYBGR.COM (the device driver for a german keyboard of the MS-DOS version 2.11, loaded every time you boot your computer). After 15 min. it drives the internal speaker do emit noise every time a character is send to the screen (Therefore I called this virus RUSH HOUR :-) ). It was easily to be detected and removed - because it was for demonstration only. This two viruses were written in Summer 1986. Ralf Burger (the author of the first virus VIRDEM.COM) and I get contact in Aug. 1986 and we decided that it is time to inform the public (and not only professional computer users) of the *threatening* possibilities of computer viruses. In collaboration with the Hamburger CHAOS COMPUTER CLUB we organized a public forum on computer viruses on Dec. 27, 1986. That was the first time the topic of computer viruses was discussed in an open event here in Europe. We earned a lot of consolation from the press and all the people there. Four month later we had a meeting with all the folks again to see how the things are going. In the meantime the topic of viruses was discussed in nearly all german computer magazines. One magazine published a computer virus and a protection program for a 680x0 machine (Atari) called MILZBRAND. I dont know if it is good to publish a virus source code but it was not my decision. Ralf Burger started to write a virus protection program (that is available now, further comments on it see below) which should not be able *find* virus programs but to hinder the propagation of viruses on MS-DOS machines. I think he has done good work. In spring 1987 I started to think about viruses on mainframes. The result was a replacing virus for IBM/370 mainframes called VP/370 (No, I dont send you a copy of this exept you can state a *REAL* interest in it, e.g. you are a OWNER of such a machine! I dont want to be the one who is responsible for a damage I cant figure out.) Since that time I am working (nearly) exclusivly on virus protection methods. But now lets return to the viruses I know. The next virus was a virus written in high level language (TURBO PASCAL 3.xx) called NUMBER ONE. It only infects compiled Pascal programs because it needs the Pascal run time library. It is only 100 lines in size. In winter 1987 I heared of a new virus in Vienna(Austria) and has the possibility to analyse it. I wrote a flow chart generator for .COM files and was able to see how it works. Nothing special on it. Thats all I can say definitly, although a lot of rumors are out here. But I dont want to talk about rumors. Ralf edited a book about computer viruses ("Das grosse Computer- Viren Buch", will be available in English in the near future). He wrote a lot of demonstration viruses in different languages (MS-DOS Batch Language, Basic). The Internation Standard Book Number is ISBN 3-89011-200-5 for the first edition, but you better ask for the revised second edition. My next point is on protection methods. I think it is a unsatisfying work to write programs that can *detect* ALL kind of viruses. So I think it will be the best to catch viruses (that means hindering their propagation) by looking at their principles. All viruses have to *change* program code (in a file or on the disk) if they want to work the way they are designed. A straight forward method is to detect changes on files. Take a good checksum algorithm that cant be forged in a simple way. Run this program on all your files (and/or entire disk) every time you boot your machine. Make sure that the checking program is on a write protected disk (TAB!) and you can detect all changes in .COM and .EXE files. If a program has changed try to find out why. This is the method Ralf uses for his software- based protection program. An other method is to keep ALL executable files encipherd on mass storage devices, but make sure the ciphering algorithm is GOOD. GOOD means that it should be an algorithm that allows a quick decipher but a complicated encipher (trapdoor in the opposite direction, come on mathematicians: Find a good one!). Write a new program loader that deciphers loaded programs before execution. So the executable file only exists in RAM but never on storage devices. A virus program has to write its *executable* code to files on disk but this code cant be executed because it is *destroyed* by the program loader during deciphering. If the ciphering method is good (see above) a virus cant encipher itself before writing its own code to a file on disk. This method is just an idea of mine. A test version for MS-DOS machines works quite well, but I think my ciphering algorithm is not GOOD in the above sence. Of course the perfomance of loading programs slows down, so this will be satisfactory only on fast machines. The last method I want to mention is a hardware protection. It is based on optical disks (WORMs). Files on such a device cant be "overwritten" in common sence, you have to mark the old program "erased" or "unvalid" and have to store the new version somewhere else on the disk. If you have a (ROM-)program that checks where an executable file on the disk is located you are able to detect infections (or *other* changes in the software -> software revision!) because the forged program is located at the wrong place. This method is implemented in Ralf's last project and the results are encouraging. That's all for today. I hope all of you find it intersting to hear about the facts here in good ol' germany. If you are intersted in more you can have a look in a book on computer viruses (ed. by Ralf, with lot of programs and further information and a lot of articals from virus programmers, software and security managers and so on.) Its great to have a forum where the topic of computer viruses can be discussed in such an open way. Keep on the good work. All the best for you, Bernd Fix. ========================================================================= Date: Wed, 4 May 88 08:04:55 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-From: "Kenneth R. van Wyk" Comments: Originally-From: WHMurray@DOCKMASTER.ARPA From: "Kenneth R. van Wyk" Subject: ERIC and VULT identified Here's a forwarded submission: Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: = Lone Star! = = BITNET: = = ------------------------------------------------------------------------ ----------------------------Original message---------------------------- "ERIC" and "VULT" Identified ERIC and VULT, the specific targets of the SCORES Apple MacIntosh virus, were internal projects at EDS in Dallas according to EDS spokesman Bill Wright. These labels identify proprietary trade secret programs that were once, but no longer used at EDS. While SCORES was specifically designed to destroy these applications, it would infect anything. All the above was gleaned from "Macintosh Today," May 2, 1988 which also contained a highly speculative article entitiled "Viruses: Nothing to sneeze at." If you believe this article, computers have seen their day. In the future, viruses will make them unuseable. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ========================================================================= Date: Wed, 4 May 88 08:46:38 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: LaSalle talk A few people have asked me about obtaining any written information on last week's virus talk at LaSalle College. I'm afraid that I don't have any written summaries; does anyone out there have anything more than what's already been sent to the list? If so, please forward it to the list - it'd be much appreciated! Thanks! Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: = Lone Star! = = BITNET: = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 4 May 88 09:33:44 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: files are now available Well, after saying that I'd make uuencode/uudecode and Flu_Shot+ available, I got a whole lot of requests for them, so I've placed them here on the LISTSERV for public copying. The filenames are: UUENCODE PAS (note the space, *NOT* a period! This is CMS!) UUDECODE PAS FSP UUE PKX35A35 UUE FSP UUE is a uuencoded ARC file. PKX35A35 UUE is the PKARC package. PKXARC is required to unARC the files in FSP.ARC. The uuencode and uudecode files are in Turbo Pascal v 3.x. Both of these files are *shareware* and you are encouraged to send the authors the money that they request for the use of their programs - see the license agreements of each package for more information. Ok, now you probably want to try to get these files... Well, it's similar to signing onto or off of a LISTSERV group; you send a message to LISTSERV@LEHIIBM1. The message should say: GET filename filetype listname For example: GET PKX35A35 UUE VIRUS-L This would send you the PKARC package. Once you've gotten all the files that you want, you would do the following to uudecode and extract FSP: compile uudecode into a .COM file. UUDECODE PKX35A35 PKX35A35 (this step unarcs the self-extracting PKARC package.) UUDECODE FSP PKXARC FSP And after all that, you *should* have a working copy of Flu_Shot+ and PKARC. If you already have PKARC, this can be a whole lot simpler... I hope I haven't overly confused everyone. :-) By the way, you can always get a current list of all files available on VIRUS-L by sending an INDEX VIRUS-L command to LISTSERV@LEHIIBM1. Finally, please don't send any of these commands to the list itself! Enjoy, Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: = Lone Star! = = BITNET: = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 4 May 88 10:46:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: PC security programs Here's another forwarded submission to the list: From: "Scott D. Green, Classroom Services" Return-path: GREEN@wharton.upenn.EDU Date: Wed, 4 May 88 10:10 EST From: "Scott D. Green, Classroom Services" Does anyone have any experience with hard disk security software? Two that we have for evaluation are "DiskManager PC" and "PC/DACS." Both claim to be able to prevent a drive or just directories and files from being tampered with. Out goal is to try to minimize software maintenance on public lab machines by limiting students' write privileges to the hard dirve, protecting batch files, etx. Both packages claim to superced DOS attrib commands and foil Norton Utilities. They also provide "boot lock": if you boot from a floppy, the hard drive does not exist for you. Though they don't specifically mention virus protection, it seems a reasonable side effect. [I've been evaluating PC/DACS, and it looks pretty nice, although it's not specifically targetted as being an anti-virus program. It gives a PC security much like on, for example, a VAX, whereby you can have separate users - each with different access to different drives/directories/files/resources. It includes boot protection and full disk encryption. If you don't install all the boot protection and encryption features, it's *VERY* easy to get around. This is not an endorsement of this product - merely a statement of its features. - Ken ] ------------------------------------------------------------------------ = Kenneth R. van Wyk = = = User Services Senior Consultant = I can't believe you fell for = = Lehigh University Computing Center = the oldest trick in the book = = Internet: = Lone Star! = = BITNET: = = ------------------------------------------------------------------------ ========================================================================= Date: Wed, 4 May 88 10:10:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: GREENY Subject: Viral Code Hi all.... I have recently been given the task of making sure that all of the software and/or data that we have in my department is clean and free of viruses. Due to the fact that I feel that I can't really trust anyone's outside applications anymore without source code (that I'm able to comprehend as well..), I ahve decided to write my own stuff. But what I need is the means to test it out. Copies of the SCORES and/or IDIOT viruses for the macintosh would be very helpful as we have a number of Macs here, viruses for the IBM PC would also be helpful as there are even more IBM's in the dept (much to my chagrin! :-> ) At any rate, I am willing to get copies of the virus(es) via EMAIL, US Mail, tape, or whatever, and once written I will post copies of my disinfectioon programs to the net -- along with the source code. Any help would be greatly appreciated. bye for now but not for long... David S. "Greeny" Greenberg Departmental Technician Department of Learning Resources Western Illinois University Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: My department takes no responsibility for what I say....it's all supposed to be my opinions.... ========================================================================= Date: Wed, 4 May 88 12:12:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Dr. Woody" Subject: COREWARS, the Scientific American game implemented on a macintosh Greetings everyone, There was some inquiry into the Scientific American game "CoreWars". I've a version for the macintosh. The help manual gives a pretty good feel for what the game is about. The program is shareware, and the manual includes the authors name and address - I don't know if it is still current, but the author says he will send you the source code (in C) for $15. The file is a trifle long, so I will send it to the list moderator - he can then put in on the list or in the archives (or throw it away :-) ) as he sees fit. woody WWEAVER@DREW * This is not an endorsement of the product - I've never played it, except to verify that it ran (on a 512K mac with an old system). But if we ever succeed in getting viruses off of disk storage and force them to live in RAM, COREWARS is an interesting metaphor. * ========================================================================= Date: Wed, 4 May 88 18:10:15 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joseph Sieczkowski Subject: Brain Virus info I have some specific information on the brain virus. I'd though that I'd share it with you by forwarding it to the list. Also, I'm sending the source code to programs called "nobrain.c" and "checkmem.c" to the owner of the list so he can make them publically avalible. Nobrain supposedly finds and kills the brain virus if present (memory and floppy). And checkmem is just a utility to see if its resident. Hope this is helpful, ------------------------------------------------------------------------------ Comments on the "(c) Brain" Virus The virus is benign. All it does is propogate itself. The only way it can spread is by booting an infected diskette. Once booted, the virus installs itself in memory and will proceed to infect an DSDD floppies it can "find". Diskettes When infecting a diskette, the virus replaces the boot record (trk 0, side 0, sect 1) with its own boot record. This is the code that actually installs the virus into memory. It then locates 3 "free" clusters from the FAT, loads the actual virus code into those clusters along with a copy of the "real" boot record, and then marks those 3 clusters as "bad". Finally, it installs a diskette volume label of "(c) Brain" on the infected diskette. However, the volume label format isn't 100% correct so utilities such as Norton's will show it as a "bogus" directory entry format but DOS will display it. In the 3 custers (6 sectors), the "good" boot record is in the first sector and the virus itself is in sectors 2-6 of the 3 clusters. (Actually, the virus doesn't apprear to need all that space). Operation - looks to see if infected (1234H will be in 0004 & 0005 of record) - it will load itself into the last 7K of ram and then set the DOS available ram value down by 7... eg 640 will become 633, so that the virus in memory will be "safe". - changes the disk read/write vector (13 Hex) to point to his virus - stores the original 13H vector at a new vector (6D hex) which he invokes when a "real" read or write is needed. - the original boot record is moved to the 1st sector of the 3 bad clusters he as marked (so he can still boot the PC after he has done his "dirty work") - his boot code is installed in original boot record location (Trk Hd Sct = 0 0 1). - 3 free clusters found, virus and boot rec place here, and marked as bad. - while checking FAT, he checks ID byte to insure that this is a DSDD diskette... won't infect any other kind (which also precludes hard drives) - His "(c) Brain" label is written but he allows for the 2 hidden bios (he doesn't check if they are present). The result is, if a completely empty diskette is infected, the label doesn't show up until at least 2 files are on the diskette. At this point diskette is completely infected. His infection of new diskettes is sort of random or "haphazard". - If a disk write occurs, he allows it to proceed as usual. - After 32 disk reads, he will infect a diskette and then every 4 reads there after... UNLESS, it is a read of trk 0 side 0 (ie directory area, FAT, etc.). Then he immediately checks if infection is needed and does so if not already infected. He resets the 4-counter at this point. This results in the virus spreading rather quickly while somewhat reducing the noticable degradation from the virus' overhead... tho' it can be seen if you are looking for it) That's about it. If you are reading this, I hope it was of some use. Carl Fussell ------------------------------------------------------------------------------ ========================================================================= Date: Thu, 5 May 88 08:25:29 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: new files available I just posted three new files to VIRUS-L. They are: DIRTY DOZEN NOBRAIN C CHECKMEM C Thanks to James Ford for sending in the Dirty Dozen list, and to Joe Sieczkowski for sending in the anti-Brain programs. The Dirty Dozen is the "standard" listing of known trojan/virus programs. The two C files are as Joe described - Brain killers. I don't have a Brain damaged :-) disk to test these with, so I'd appreciate any comments (e-mail them to me please) from anyone who tries them out. Thanks again guys! Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: = U = = BITNET: = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Thu, 5 May 88 10:52:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: J_CERNY@UNHH Subject: The Shockwave Rider. As a "literary" note on viruses, I thought some readers might be interested in a few quoted fragments from John Brunner's science fiction novel THE SHOCKWAVE RIDER. TSR was published wayyyy-back in 1975! One of the interwoven, though somewhat obscure, themes is of computer worms and viruses used to protect and attack computer data. [p. 24] "Then the answer dawned on him, and he almost laughed. Fluckner had resorted to one of the oldest tricks in the store and turned loose in the continental net a self-perpetuating tapeworm ... . It could take days to kill a worm like that, and sometimes weeks." [p. 25] "Promptly he sent a retaliatory worm chasing Fluckner's. ... According to recent report, there were so many worms and counterworms loose in the data-net now, the machines had been instructed to give them low priority unless they related to a medical emergency." [p. 173] " ... I'd have written the worm as an explosive scrambler, probably about half a million bits long, with a backup virus facility and a last-ditch infinitely replicating tail." [p. 174] "What you need is a worm with a completely different structure. The type they call a replicating phage. And the first thing you must give it to eat is your original worm." Jim Cerny, University Computing, University of N.H. ========================================================================= Date: Thu, 5 May 88 10:45:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: GREENY Subject: A thought... Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: #include What with all of the recent discussions on how giving out viral code and copies of viruses being dangerous, it occured to me that this could be true. An unscrupulous person could very well pervert such code for his/ her/it's own purposes. The solution that most of netland has seemed to arrived at is to not distribute such code, but to distribute the techniques for removing viruses from systems, as well as source code for such removal. Now stop and think about this for a minute, if I am given the technique for removing some infection, it also tells me HOW TO INFECT the system in a similar manner by exposing weak points in the OS. This is as good as releasing the virus in question, and any unscrupulous persons out there with a modicum of intelligence will be able to engineer a virus (which may or may not be even more potent than the one being destroyed...) from the provided information. Therefore, it makes just as much sense not to release any techniques on how to kill the viruses as well as programs that do the actual removal (they could be disassembled and perverted as well). Of course, this is all not possible, since we all must work together in the eradication of these beasties, and as such viral code and viruses should be released to the general public if we are to be able to work on a cure to this problem. You don't see the US government saying "well AIDS is pretty nasty stuff, no one can touch it but us, and we'll get back to ya with our results later..." --- EVERYONE IS WORKING TOGETHER on the eradication of that deadly disease and it should also be such with computer viruses.... * flame off * Bye for now but not for long Greeny Bitnet: MISS026@ECNCDC ========================================================================= Date: Thu, 5 May 88 13:03:14 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: In-Reply-To: Message of Thu, 05 May 88 12:04:28 EDT from From: "David M. Chess 862-2245" Subject: A thought... That's probably a good philosophical point, but the practical point behind it isn't quite true. Since the only "weaknesses" that a virus needs to exploit are things like "it's possible for a program to alter another program" and "it's possible to start a process that can intercept I/O calls to the OS", and since those are things that most programmers already know, anti-virus programs don't have to "give away" anything that would help a virus writer. One typical kind of virus-detector just notices (by a checksum or whatever) what executable files have changed since the last time it was run. All that reveals about viruses is that some of them change executable files. More specific anti-virus programs look for certain (meaningless-in-isolation) data in certain places in executable files, and tell you that the file is infected with Virus X if it finds it. All that reveals is that, for instance, "some virus puts the bytes F1 02 97 BC 00 90 at offset 011E in infected COM files" (no, that's not a real example). So it is possible to distribute a certain amount of anti-virus information without spreading any how-to-write-a-virus information. (Note that I have carefully avoided giving any opinion about whether any of the latter sort of information ought to be spread!) Dave Chess Watson Research * Nothing in this posting is an Official Statement of anybody, * whether I work for them or not. ========================================================================= Date: Thu, 5 May 88 16:04:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Another file available I've posted another file here on VIRUS-L. The filename is: RISKS LOG It contains a complete set of all of the computer virus discussions that have taken place on the RISKS forum over the past year or so. The file is very large, so it was not a good idea to send it to the entire list. Because of the file size, please only retrieve this file if you *really* want it, just to keep unnecessary network traffic to a minimum. For the benifit of newcomers to the list, you can retrieve a file on the list by sending a message to LISTSERV@LEHIIBM1 containing: GET filename filetype For the above file, RISKS LOG, you would send: GET RISKS LOG To get a list of available files, send, also to LISTSERV@LEHIIBM1: INDEX VIRUS-L The available files include a per month log of all of the messages sent to VIRUS-L. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: = U = = BITNET: = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Thu, 5 May 88 16:07:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: EAE114@URIMVS Subject: DISSEMINATING SOURCE CODE Greeny comments that it is possible to analyze the code for a virus hunter, and thereby develope another, more virulant virus. By way of analogy, he comments that the US government has not declared a monopoly on AIDS research. - - Initial Reaction: Good point. However, while there is no monopoly on the virus, there IS a definate effort to restric access to samples of the virus itself, and rightly so. In terms of distributing source-code of viruses (Virae?) If I have the source code to a virus-killer, I can reverse engineer it, and get a virus; OR i can run it, as is, to hunt viruses. If I have the source code for a VIRUS, I can reverse-engineer it, to make a virus-killer; OR i can run it as is, to infect other systems. - Since I can distribute code that makes it EASY to hunt viruses, and HARD to create them, why distribute code that does the reverse? The only reason I can see for wanting a virus is to test your virus killer, and it seems as if, if you're good enough to write the killer, you ought to be able to write the virus from the description. (PRose: EAE114@URIMVS) ------------------------------------------------------- Disclaimer: My opinions are supported, dictated, and ghost- written by the University, the state, the federal government, The CIA, and the POPE. If you don't like it, sue them. ========================================================================= Date: Thu, 5 May 88 16:44:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Virus source code I suppose we can argue until our fingers bleed as to why or why not distribute source code to viruses; and there are probably valid arguments for both sides. But, as a matter of somewhat arbitrary policy, I don't think that virus source code should be distributed to the list. Discussion of *how* a particular virus works is great, but distributing the source code is, in my opinion, not a good idea. Distributing source code to a program which "hunts and kills" viruses, however, could be benificial because it is for the common good. So, that's the official standpoint. Comments/suggestions/flames are invited *IF* you e-mail them to me directly and not to the list; it *is* possible to change policy. But, I feel that we've had enough discussion on this matter on the list already. Everyone made good valid points... Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: = U = = BITNET: = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Thu, 5 May 88 09:35:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: Virus Construction Set Hi folks, bad news from Germany. I have forgotten to tell you something in my last message: Not all people concerned with computer viruses (esp. virus programmers) over here are aware of what they are doing. In April this year a unbelievable program called "VIRUS CONSTRUCTION SET (VCS)" was released at the Hannover computer faire CeBIT. The VCS is a program written for the Atari ST series and allows *EVERY* Atari user to create his "own" virus. The program is menue driven - you can select different infection methods, damage initialisers, damages, and target files. You dont have no know how a virus work to create one, you just have to know how to turn on your Atari and how to start the VCS program!!! No further comments -- All the best to you all, Bernd. ========================================================================= Date: Thu, 5 May 88 12:32:36 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Ethics and information I'd like to respond to three thoughts posted to virus-l. 1. The virus that kills the virus. At first thought seems anathema, but I see no problem with it if it follows the ethical restraint: It must not write to a disk without the explicit permission of the disk operator. This includes, of course, "virus removal." 2. There has been a lot of discussion about the need to hide information, and especially code, permitting easy development of viruses. My personal opinion is that it requires little imagination and readily available information to write a virus. Say $30 in manuals and some simple hacking around. If this opinion is accurate, hiding information has little benefit. 3. There is an opinion that no one should download code from bulletin boards. Only source code should be distributed. For most people a virus hidden in source code is just as undetectable as a virus hidden in a machine image. I hope that this opinion will not prevent virus-l from storing useful machine images. If computing society becomes overly protective in response to this anti-social behavior, then we all loose. The analogy with radical revolutionary doctrine is straigforward. ========================================================================= Date: Fri, 6 May 88 12:31:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner new! +49 228 8199645 Subject: Re: A thought... A number of things were said in this posting that were addressed by others, so I won't repeat it, but one bears comment still: > From: GREENY > > ...we all must work together in the eradication of ...(viruses)... > You don't see the US government saying "well AIDS is pretty nasty > stuff, no one can touch it but us, and we'll get back to ya with > our results later..." Actually, that is exactly what I saw the US government doing for the longest time. In fact, for several years, the government solution to AIDS was 'a hope and a prayer'. Stop promiscuity and AIDS will go away by itself. And besides, AIDS only strikes people who are non-white, or homosexual or drug abusers. Nothing there for decent people to worry about. Why should we research the thing? Why should we provide care for the afflicted? Nobody we care about is affected! > --- EVERYONE IS WORKING TOGETHER on the eradication of that deadly > disease and it should also be such with computer viruses.... This is a relatively new phenomenon that real research is being done on AIDS, and recent studies have shown that the delay will be responsible for untold deaths. The stakes are clearly different with computers, but the idea isn't much different. Work done now to understand and limit virus spread will save much pain later. Michael ========================================================================= Date: Fri, 6 May 88 08:42:58 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: A reader's description of LaSalle talk. I just got this description of the LaSalle virus seminar from J.D. Abolins - thanks J.D.! Ken ----------------- Computer Virus Seminar at La Salle University reported by J.D. Abolins OVERVIEW (Philadelphia,PA) On Thursday, 28 April 1988, the Philadelphia Area Computer Society (PACS) and La Salle University Academic Computing presented a seminar on computer viruses. The panelists for the seminar were- - John Hagman, a Personal Computer (PC) Support Analyst with the Phildelphia Electric Company (PEC) - Donald Montabana, a MacIntosh and PC support specialist at the University of Pennsylvania - Steve Weissman, vice-president of PACS and a systems operator (sysop) for one of PACS bulletin borard system's (BBS) sections. - Raymond Glath, president of RG Software Systems, Inc. - Pam Kane and Andy Hopkins, both from Panda Systems. Steve Longo, the president of PACS and the director of La Salle University Academic Computing, moderated the seminar. The panelists took turns speaking, Instead of using a rigid, subject-based outline for the presentations, the presentations focused on the speakers' own experiences and viewpoints. At certain points, the audience was given a chance to ask questions and to make comments. The audience participation was lively. (15 minutes before the seminar began, there were only a few people in the audience but by the time the seminar got under way, the room was filled.) After the seminar, copies of virus literature was distributed. PACS had an anti-virus/anti-Trojan programs disk available for purchase. THE PRESENTATIONS RAY GLATH: Ray Glath, the first speaker, told how when he started working with computers over 20 years ago, there were some cases of malicious programs. But in those days, those programs did not go far. Today, several factors have contributed to the ability of such programs to move rapidly. First is the proliferation of the microcomputers; in short, there are far more computers than in 1964. The other factor is the "pass around" attitude towards software along with a casual attitude towards software piracy. Mr. Glath described shareware and freeware as good marketing approaches but warned that there are some nasty people who modify good programs, making harmful copies of them. A virus, as defined by Mr. Glath, is "a nasty" that replicates itself. But whether the nasty program is a virus or a Trojan Horse, it all boils down to computer sabotage. He outlined the types of nasty programs- - MASSIVE DESTRUCTIVE which destroy the whole computer system. - PARTIAL DESTRUCTIVE which may attack the File Allocation Table (FAT) or the boot sector of a hard disk. - SELECTIVE ATTACK which attacks specific files (eg.; COMMAND.COM or .EXE files.) - RANDOM ATTACK which are elusive. They have no easily discerned mode of attack and, thus, escape detection for a long time. - NON_DESTRUCTIVE which are annoyances. They usually produce messages or modify disk labels. Mr. Glath closed his presentation by noting that the virus proliferation is a real trend that is getting considerable attention, but one will be quite safe if one takes precautions. DONALD MONTABANA: Mr. Montabana reviewed his experiences with computer viruses at the University of Pennsylvania. Since January 1988, the number of virus incidents had not been severe. On average day, he would get five to seven calls about possible virus attacks; most of them were false alarms. On the University's campus, only 10% or less of the calls are actual virus attacks. Most of the recent cases involve ASHAR, BRAIN, or their variants. These types have been prevalent on several other campus as well. These programs will modify disk volume labels; some of them are quite destructive. They get their names from the names they will put into the volume labels. Mr. Montabana noted that the BRAIN virus will infect only the 360K format disks. Other formats, such as the 720K and 1.44M, are immune to the current version of BRAIN. He noted that BRAIN, unfortunately, can eat away at the FAT and that it resides on the boot sector of a hard disk. Mr. Montabana also described some of the precautions used at the University for "safe computing". Certain of the Local Area Networks (LAN's) are isolated. Their users are restricted in what diskettes they can use on these systems. Even blank, formatted diskettes are off-limits. Only unformatted diskettes are allowed to be brought in; they are formatted on these "clean" computers. The arrogance of some virus writers was noted by Mr. Montabana when he told about the threats by virus writers aimed at Tom Brown, the author of VACCINE for the MacIntosh. The virus writers threaten to unleash nastier programs that will circumvent VACCINE's defenses if Tom Brown continues developing anti- virus programs. He noted that the National Computer Security division of the National Security Agency (NSA) is tracking down the perpetrators, intending to prosecute them. Mr. Montabana, along with the other panelists, hope that the sucessful prosecution of virus writers will deter future virus makers. Also, he forsees specific anti-virus legislation down the line. JOHN HAGMAN: Mr. Hagman explained how he became interested in malicious programs after several "hard cards" (hard disks mounted on a card) crashed within weeks of installation at his office. The disks had their boot sectors wiped out. Although the cause of these crashes is still unknown, the incidents perked his curiousity. PEC asked Mr. Hagman to research available defenses against viruses and other malicious programs. So he looked into the various commercial and non-commercial programs. He commented, "There is no piece of software that is going to be the answer." The most popular of these program protect the operating system by checking it periodically against a backup or by using numeric checksum methods. Others look for direct reads and writes to disks. Besides anti-virus software, Mr. Hagman mentioned several other safeguards. Write-protect one's original DOS diskette. Periodically, re- install the systems files on one's hard disk. Computer installations may consider the policy used by PEC- no unauthorized software on the company's machines. STEVE WEISSMAN: He started his presentation by saying that he himself has not seen a virus and that he is somewhat of a "doubting Thomas". He proceeded to describe his experience as a computer systems administrator for a large company and as one of the sysops for the PACS BBS. In both areas, he has not encountered a virus. Mr. Weissman described several factors that has kept his section of the PACS BBS virus-free. The first safeguard is that PACS gets its public domain/shareware software from large software distributors which, for their own protection, check the software. Second, the PAC BBS is a closed BBS; only PACS members can get access. Each uploaded file can be traced back to the person who uploaded it. During the seminar, Mr. Weissman emphasized, "Backup. Backup. Backup," ones data. Regarding the future of the viruses, he said that he does not know but he hopes that well-publicized prosecutions will stop the trend. PAM KANE: The two represenatives from Panda Systems covered separate aspects of the virus problems. Ms. Kane dealt with them from the human resources aspect while Mr. Hopkins covered the technical aspects. Ms. Kane expressed her concern that "BBS's and shareware are getting the image of being the 'public baths' of the computer world." She admonished computerists not to panic but, rather, to take wise precautions. Comparing the viruses to the AIDS situation, she advised that if one is "monogamous" with one's computer, one will be quite safe. She also noted that main mode of virus infection is through innocent spreading by people who are unaware of the viruses. Two of the most prominant categories of innocent carriers are 1) the people who take computer work home with them, and 2) the people who do not have a computer at home and are using their office computers for computer course homework. Both of these categories represent some of the most valuable workers in a corporation. Ms. Kane mentioned some of the precautions to prevent virus spread. One of these methods is to boot from floppy when preparing to call a BBS to download files. The files should be downloaded to a floppy, not to the hard disk. If one does get a virus, remember to use low-level format when cleaning up the hard disk. She emphasized the importance of keeping aware of the files on one's hard disk- "Be in touch with your hard drive." ANDY HOPKINS: Mr. Hopkins told how the popular Trojan Horse and virus detctor programs CHK4BOMB and BOMBSQAD were both unauthorized releases of software developed by Panda Systems. Some versions of these programs, he warns, have been modified and made into destructive programs. He explained how the Doctor Panda Utilities ultilize the methods similar to the two programs, but with additional features. The Utilities have a three-part approach- - PHYSICAL which creates a "clean model" of the computer system and uses the "model" to check for abnormal alterations of systems files and any other files specified by the user. - LABTEST which reads a specified file, checks for commands bypassing DOS, and displays any embedded ASCII characters. - MONITOR which loads into the memory and monitors for specified types of disk activity, stopping the system if any are encountered. CONCLUSION From the presentations and the discussions, one could glean much information about computer viruses. While the speakers agreed that nobody can be sure about the future, they agreed that computerists are reasonably safe if they take reasonable precautions. The seminar was well worth the time and effort to get there. As I am writing the finish to this article, I am reminded of a concern expressed by many of the panelists. They were alarmed by the irresponsible computer journalists who have gone beyond informing the public about the viruses by giving "how-to" guides for writing viruses. It is a phenomenon that is especially prevalent in the MacIntosh field. (Perhaps because it appears to be easier to write a MacIntosh virus than a MSDOS one.) This is valid one, since it is important to inform computerists but there is no need to give aspiring virus writers their start. ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: = U = = BITNET: = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 6 May 88 08:24:05 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Frost Subject: Re: The Shockwave Rider. |As a "literary" note on viruses [...] Intrepid readers might like the book "P1" which is probably the first book dealing withh the topic ofviruses/worms. I've also read "Valentina" but the former is much better. Now back to your regularly scheduled virus reports.... jim frost madd@bu-it.bu.edu ========================================================================= Date: Fri, 6 May 88 08:32:11 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Frost Subject: Re: Virus Construction Set |bad news from Germany. I have forgotten to tell you something in my |last message: Not all people concerned with computer viruses (esp. |virus programmers) over here are aware of what they are doing. In April |this year a unbelievable program called "VIRUS CONSTRUCTION SET (VCS)" |was released at the Hannover computer faire CeBIT. I don't know about in Germany, but it's my bet that anyone releasing such a beast in the United States would get a handful of lawsuits. I'd be in on sueing the hell out of them! What would prompt someone to write such a damaging "utility"? jim frost madd@bu-it.bu.edu ========================================================================= Date: Fri, 6 May 88 09:37:19 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: files A couple people have made some great suggestions for improving the uuencoding/uudecoding process here on VIRUS-L. So, I've included a BASIC version of uudecode (filename UUDECODE BAS) as well as a new improved uuencode/uudecode package called uu213 (filename UU213 UUE). The BASIC uudecoder will work with any GW-BASIC compatible BASIC interpreter...slowly. It is *not* ...er...shall I say, fast. But, for those of you who don't have Turbo Pascal, you can get the BASIC uudecoder, and the UU213 package. UU213, by the way, is a uuencoded ARC file containing a very fast uuencode and uudecode in executable form. Both of these files were obtained from the MS-DOS archives on SIMTEL20.ARPA. Thanks to all who sent in these suggestions and files! Hopefully, this will be the uuencode/uudecode to end all uuencode/uudecode's. :-) Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: = U = = BITNET: = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 6 May 88 14:12:40 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: OJA@NCCIBM1 One of the things mentioned in the discussions during the La Salle virus seminar was the existence of malicious program that would rewrite or erase firmware but rapid reads and writes which would heat up the EPROMs and erase them. I haven't heard of this before so I am putting out for comments, etc. The only form of hardward damage from a malicious program that I know of is an old Trojan Horse for the early Commodore PETs. It would burn out their monitors if allowed to run for a while. Just a quirk of the beastie. J. D. Abolins ========================================================================= Date: Fri, 6 May 88 13:59:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Mitchel Ludwig Subject: RE: Re: Virus Construction Set >|bad news from Germany. I have forgotten to tell you something in my >|last message: Not all people concerned with computer viruses (esp. >|virus programmers) over here are aware of what they are doing. In April >|this year a unbelievable program called "VIRUS CONSTRUCTION SET (VCS)" >|was released at the Hannover computer faire CeBIT. > >I don't know about in Germany, but it's my bet that anyone releasing >such a beast in the United States would get a handful of lawsuits. >I'd be in on sueing the hell out of them! > >What would prompt someone to write such a damaging "utility"? Jim, Not that you (or anyone for that matter) will want to hear this, but chances are good that anyone wishing to market such a program in the U.S. will have no problem doing so. It's probably comparable to those selling the copy boards and such which would seem to be in direct violation of the shrink wrap laws (are those the correct laws?) Unfortunately, as I see it, the free speech laws (of the press... etc) allow such programs to be sold... We don't have to like it... But we do have to deal with it... Mitch Tag... You're it ____________ ____/--\____ //-n-\\ \______ ___) ( _ ____) _____---=======---_____ __\ \____/ / `--' ====____\ /.. ..\ /____==== ) `|=(- - - - - - - - - - -*// ---\__O__/--- \\ \------------' \_\ /_/ BITnet : MFL1@lehigh.bitnet Phonet : 215-758-1381 INTnet : KMFLUDW@vax1.cc.lehigh.edu Slonet : Box 72 Lehigh Univ. Bethlehem, PA 18015 ========================================================================= Date: Fri, 6 May 88 13:30:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: GREENY Subject: re: hardware damage > The only form of hardward [sic] damage from a malicious program that I know of > is an old Trojan Horse for the early Commodore PETs... Hmmm....I seem to remember a program for the Commodore VIC 20's that would fry out a ROM or two. Also the old tale from the days of core memory, of a nutty programmer that continually accessed a location in memory until the core that represented this memory location heated up. The core was directly over an overheat sensor. When the core got hot enuf, the sensor tripped, and the machine shut down. Good thing we don't use core memory anymore! Bye for now but not for long... Greeny Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: What?? Who? Me? Nope...not me! It's that guy over there! ========================================================================= Date: Fri, 6 May 88 14:28:03 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Frost Subject: Re: |The only form of hardward damage from a malicious program that I know of | is an old Trojan Horse for the early Commodore PETs. It would burn out |their monitors if allowed to run for a while. Another such problem exists with the old monochrome boards for PC's. I haven't heard of any trojan horses/viruses which take advantage of it, but it exists. jim ========================================================================= Date: Fri, 6 May 88 14:39:22 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Frost Subject: RE: Re: Virus Construction Set |>What would prompt someone to write such a damaging "utility"? | Not that you (or anyone for that matter) will want to hear |this, but chances are good that anyone wishing to market such a |program in the U.S. will have no problem doing so. It's probably |comparable to those selling the copy boards and such which would seem |to be in direct violation of the shrink wrap laws (are those the |correct laws?) It's not the same thing. You have a right to archive programs for your own use, which is why the copy people haven't been knocked out of business. Copying something does no harm to another person, unless it's illegal copying and there are laws against that. A virus can (is supposed to?) cause harm. The question isn't whether or not someone can be sued for it, but rather who gets sued. Should it be the person that sent out the virus, or should it be the company that made the virus creation program? In any case, the company has aided in the crime and may be at fault (although it might be possible to use a "people kill with guns but gun companies aren't held responsible" argument to get around this). I guess we'll never know until it happens. jim ========================================================================= Date: Fri, 6 May 88 14:52:38 edt Reply-To: Virus Discussion List Sender: Virus Discussion List From: Travis Lee Winfrey In-Reply-To: OJA%NCCIBM1.BITNET@cuvma.columbia.edu's message of Fri, 6 May 88 14:12:40 EDT <8805061822.AA00632@columbia.edu> Hi all; I'm new to this list. A few questions which may have been answered before: Is there a list anywhere of known viruses, malicious or otherwise? or of hardware/software combinations for which virus programs exist? Also, is there a list of antibody- and immunization-type programs, including those like chk4bomb that have been tampered with and re-released? it would be useful to have checksums published with these programs, although I suppose a virus writer wouldn't be too troubled to make a checksum balance out. perhaps multiple checksums could be used to foil simple padding. based on what has been discovered so far, does anyone have any feel for the percentages of malicious vs. nonmalicious/humorous/political viruses out there? can anyone recommend a beginning text on epidemiological analysis? :-), but I would really be interested in such a book. t ========================================================================= Date: Fri, 6 May 88 14:56:50 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" In-Reply-To: Message of Fri, 6 May 88 14:52:38 edt from >Is there a list anywhere of known viruses, malicious or otherwise? or of >hardware/software combinations for which virus programs exist? Wouldn't be too bad to start with DIRTY DOZEN, available here on VIRUS-L. It seems to be *reasonably* thorough. If you don't know how to get files from here, e-mail me directly and I'll let you know. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: = U = = BITNET: = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Fri, 6 May 88 13:10:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: LOWEY@SASK Subject: How can we protect programs from viruses? Hi, I have written a number of utilities and programs which I put into the public domain. Usually they are written in Turbo Pascal, and the source code is distributed as well. One thought I had was include a CRC check in the program. Randomly throughout the code, the program would do a CRC check on its .EXE or .COM file (or optionally the executing image). If it didn't pass the test, then it would display a message that the program was tampered with and exit. I think Lotus 1-2-3 does this as part of its copy protection scheme. If something like this was added to the MS-DOS utilities and public domain programs, it could stop the spread of some viruses. For instance, if COMMAND.COM had such a check, it would be much harder for a hacker to patch a virus into it. Does anyone know of any method that protects your programs even if the hacker knows the method used to do the protection? In otherwords, a hacker can know how it was done, but not how to defeat it? Thanks, Kevin Lowey -- University of Saskatchewan Computing Services ========================================================================= Date: Fri, 6 May 88 19:38:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Warning -- original Sender: tag was KPETERSEN@SIMTEL20.ARPA From: Keith Petersen Subject: Flushot-Plus version 1.2 now available from SIMTEL20 The latest version of FLUSHOT, the anti-Virus/anti-Trojan program for MSDOS, is available via standard anonymous FTP from SIMTEL20 as... Filename Type Bytes CRC Directory PD1: FSP_12.ARC.1 BINARY 45646 2AD5H This is Flushot-Plus, version 1.2. It was obtained directly from the author, Ross Greenberg, to assure its validity. --Keith Petersen Maintainer of the MSDOS archives at SIMTEL20.ARPA ========================================================================= Date: Mon, 9 May 88 16:05:00 CET Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Karl-L. Noell" Subject: hunting up infected files Now we have come to the point where it's even possible to infect files without altering their size or their time date stamps. So I'd like to recall the well known, efficient and approved cyclic redundancy check (CRC). It should be good practice, to compute the CRC remainder every week for all files on harddisk drives. For this purpose I'm using the very helpful tool FILECRC written by Ted H. Emigh. It's in SIMTEL20 / RPICICGE FILECRC.ARC . Running FILECRC computes the individual checksums and leads over to compare them with the CRCs obtained from the previous run. This will uncover all files which have been altered since the last run, especially those modified in a 'non-DOS-manner'. And all *new* files are shown, revealing unwanted descendants born by trojanic creatures or hatched out of any cuckoo egg. Karl Noell fhw (Wiesbaden, W.Germany) ========================================================================= Date: Mon, 9 May 88 10:52:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: CRC's for detecting viruses Unfortunately, it is very easy to modify a file so that any given CRC remains unaltered. The protection you get by using a CRC is thus quite limited - it stops those virus-writers who aren't clever enough to work around it. Stepping back a bit and looking at the bigger picture: Given a program P, viewed as a bitstring (or a very large number or a polynomial over Z mod 2 or whatever is convenient), we want to compute a signature S(P) which is (a) fairly small; (b) chosen so that it is "highly likely" that, if Q != P, S(Q) != S(P). An example of a simple signature function is "number of bits (bytes, blocks) in P" - the size of the file. This simple function also points out the weak- ness that a given S may have: "Highly likely" must refer to a given set of ways of chosing Q != P. Virus makers at first did not go out of their way to chose Q's the same size as P, so this S worked fine. Now they know better, and this S is useless. There are many other possible S functions: Sum of the bytes of P, XOR of P viewed as a vector of 16-bit words, various weighted sums (given by something like S[0] = 0; S[i+1] = k*S[i] + P[i], where P[i] is the i'th byte/word of P and S = S[size(P)]), and so on. CRC is yet another possibility. All these choices of S have uses given particular ways of chosing Q. CRC is good if Q is what comes out after sending P over a noisy telephone line - the kinds of changes that that process induces to form Q from P are "highly likely" (in a very precise sense) to change the CRC. However, when you are talking about a change due to an intelligent opponent, the story is very different. There exist "cryptographically strong" S functions, in the sense that, given P and S(P), it is "very difficult" - as hard as breaking some code - to find ANY Q != P with S(Q) = S(P). DES, the Data Encryption Standard, provides a mode of use, called CKS (checksum) mode, in which you chose a secret key K, then compute S(P) = DES_CKS(P,K). This is cryptographically strong - it is as hard to break as DES itself. Unfortunately, it requires that K be kept secret - given K, it is no more secure than, say, XOR. What this means is that an individual can chose a secret K and use this technique to checksum his own files - but there is no way to publish a list of (P,S(P)) values that would do anyone any good in determining whether a program they received was intact, since to test it they would need to know K - and then the bad guys would know K, too. DES requires fairly slow computation. It turns out that CRC CAN be used this way, if you chose a random, secret CRC polynomial. There's a paper by Michael Rabin called "Fingerprinting by Random Polynomials" - sorry, I don't have a handy reference - that shows how to do this, and proves that the result is cryptographically strong - as long as the polynomial is kept secret. It is also possible to construct cryptographically strong signatures that do NOT require that a secret be kept. These are essentially one-way functions that are thought, for good reason, to be hard to invert. It isn't hard to build one of these using DES, or any good encryption function. Unfortunately, they tend to require a LOT of slow computation - what happens is that pieces of P get fed in to the encryption function, not as data, but as keys. Encryption algorithms are designed for reasonable implementation for a FIXED key and VARIABLE data - changing the key all the time is hard, since fast implementa- tions usually rely on munging on the key for a while to set things up just right. (BTW, the security of such schemes comes from the difficulty, in a good encryption system, of learning the key, even given a lot of plaintext/ ciphertext pairs.) I would suggest a compromise: A mechanism that, while not completely secure, makes things very hard on a virus-maker while not requiring huge amounts of computation. When a program is published, a large number of random polynomials (say, 100 or 1000) are chosen, using the techniques of Rabin's paper. The CRC of the program with ALL the polynomials is published. To check a program, you chose any two of the polynomials - also published - compute the CRC's, and compare. (You must, of course, chose those two at random.) The virus maker must make his program have the same CRC with respect to ALL the 100 or 1000 polynomials - which is possible, but requires (I believe, this would need to be studied) a LOT of computation. (The length should probably be checked - it's going to be a lot easier on the virus maker if he can add extra stuff to the end of the program to make the CRC's come out right.) -- Jerry ========================================================================= Date: Mon, 9 May 88 12:50:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Atul Butte Subject: Preventing public domain software contamination With all the problems with virus infected public domain and shareware software, I propose the following solution (for the Macintosh): There exists a shareware program called StuffIt 1.4 which was designed to group multiple files into one file which can then be uploaded. StuffIt 1.4 is for the Macintosh, and is turning into a sort of standard for packing. StuffIt 1.4, in addition to grouping files can compress them and can encrypt them. The proposal: How about adding a new feature to StuffIt that encrypts files, but in such a way that they can only be decrypted and not encrypted again? This can be done with the following method. StuffIt could prompt the uploading user to enter an encrypting code which is used to encrypt the files. Along with the files, another code is included. This code is the decrypting code, which downloading users can use to decrypt the file. The decrypting code could be hashed by some secret function into the original encrypting code. This method is similar to the "trapdoor" functions used for Public-Key Cryptosystems with one-way functions. The advantage of this is that the original author of a program can encrypt his or her software and place it in the public domain without the fear of others downloading the file, contaminating it with a virus, and then uploading the file as the original. Atul Butte /----------\ /----------\ Brown University ! OK ! ! CANCEL ! ST602397@BROWNVM.BITNET \----------/ \----------/ ========================================================================= Date: Mon, 9 May 88 13:31:33 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: file confusion There appears to be quite some confusion as to how to get files from the VIRUS-L archives - I've gotten a *lot* of requests to better explain myself. Everyone on this list subscribed to the list by sending a message to LISTSERV@LEHIIBM1 stating SUB VIRUS-L your name. Well, retrieving files is very similar to this. Specifically, you will once again be sending a message to LISTSERV@LEHIIBM1, but instead of SUBscribing, you will be GETting a specific file. So, to get a particular file, like DIRTY DOZEN, send mail to LISTSERV@LEHIIBM1 containing: GET DIRTY DOZEN VIRUS-L That's all. You'll get the file DIRTY DOZEN in your mail shortly afterwards. If you want to *see* what files are available, send INDEX VIRUS-L Also to LISTSERV@LEHIIBM1. Care should be taken to *NOT* send the message to VIRUS-L@LEHIIBM1 since it will go out to the entire list and not reflect favorably upon yourself... :-) Hope this clears things up. Sorry for the repetition to those who already know all about this. Ken ------------------------------------------------------------------------ = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: = U = = BITNET: = Bill 'n Opus in '88! = ------------------------------------------------------------------------ ========================================================================= Date: Mon, 9 May 88 17:19:52 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim <15360JIM@MSU> Subject: Request FSP_12.ARC.1 (Newest Flushot-Plus Program) I tried to get a lastest copy of fsp_12.arc.1 I read a message that I can get a clear copy from simtel20.arpa. But I don't know how to access to simtel20.arpa directly. By the way, I checked listserv at rpicicge and couldn't find any fsp_12.arc.1 there. Please help me out! ========================================================================= Date: Mon, 9 May 88 17:30:34 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: OJA@NCCIBM1 In-Reply-To: Travis Lee Winfrey's message of 6 May 88 Regarding the inquiry of a list of known viruses, malicious, or otherwise.... first check the dirty dozen listing available as a file from VIRUS-L. In a few weeks or earlier, I can get a quick amalgam of couple of articles listing many of the viruses. In a month or so, I hope to make a "VIRLOG" patterned after the "dirty dozen" listings. It will be helpful but I can't gaurantee it will 100% comprehensive. But I will be seeking to compile whatever info I get here, from RISKS, and elsewhere that can be published. With that listing will be a list of anti-virus/bomb programs. BOMBSQAD and CHK4BOMB have been mentioned. On the files areas, there are several good programs. As for tampered programs, well... it is hard to keep up with that. However, I can warn you about FLUSHOT4. It is a tampered version; that is why Ross Greenberg calls his program FLUSHOT+ or (FSP). But the DOS REName command makes tracking these nasties impossible. Whatever the name of the FLUSHOT type program, watch for ones with executable text files (ie.; COM or EXE files to run so the documentation will be displayed.) Ross Greenberg uses ASCII files for the documentation. Other than that and the suspect NOTROJ program (another story in itself), I don't know of other tampered "cures". Regarding books, I have heard of a "Hacker's Manual" but I haven't seen it. There is no major book yet that I know of which deals specifically and in detail about malicious programs. J.D. Abolins ========================================================================= Date: Mon, 9 May 88 18:25:27 edt Reply-To: Virus Discussion List Sender: Virus Discussion List From: Travis Lee Winfrey In-Reply-To: OJA%NCCIBM1.BITNET@cuvma.columbia.edu's message of Mon, 9 May 88 17:30:34 EDT <8805092142.AA17475@columbia.edu> Regarding books, I have heard of a "Hacker's Manual" but I haven't seen it. There is no major book yet that I know of which deals specifically and in detail about malicious programs. yes, I've seen the hacker's manual at a bookstore nearby. it pre-dates viruses, and is more for breaking into computers over networks or dialup lines. it was surprisingly accurate, listing for each os: the login procedure, how to find out user ids, what the privileged ids are (root, system, operator). I didn't see any lists of security bugs, but I was just glancing through it. there was also a lot of phone-phreaking information in it. the techniques are mostly for game-seeking kids playing around with modems, but they do good job of stripping away any security-by-ignorance schemes. t ========================================================================= Date: Mon, 9 May 88 15:40:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Joseph M. Beckman" Subject: Re: hunting up infected files In-Reply-To: Message of 9 May 88 11:05 EDT from "Karl-L. Noell" As an employee of the National Computer Security Center, I must point out that we do *NOT* attempt to track perpetrators for prosecution or for *ANY* other reason! We are not a law enforcement Agency, and are prohibited by law to take any such action. We are interested in tracking the viruses (or ordinary Trojan Horses) as they infect different sites. As a matter of professional interest, I would be curious as to the motivations of perpetrators of malicious code, or whether they are members of "Hacker Clubs;" but that is information that may be conveyed without identifying the people/organizations involved. Joseph ========================================================================= Date: Tue, 10 May 88 11:35:32 edt Reply-To: Virus Discussion List Sender: Virus Discussion List From: Travis Lee Winfrey From: LOWEY%SASK.BITNET@cuvma.columbia.edu Subject: How can we protect programs from viruses? If something like this was added to the MS-DOS utilities and public domain programs, it could stop the spread of some viruses. For instance, if COMMAND.COM had such a check, it would be much harder for a hacker to patch a virus into it. yes, but as with all checks built in to programs, if the test(s) can be found in the code, executable or source, it can be patched and circumvented. however, such checks would be very useful in slowing the spread of a virus. t ========================================================================= Date: Tue, 10 May 88 17:41:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner new! +49 228 8199645 Subject: Re: Virus Construction Set > I don't know about in Germany, but it's my bet that anyone > releasing such a beast in the United States would get a handful of > lawsuits. I'd be in on sueing the hell out of them! You'd have a hard time even finding a ground. The fact that a crowbar can be used for burglary doesn't make it illegal to make crowbars. Similarly, selling copy protection defeaters isn't illegal nor key making machines. So it isn't per se illegal In terms of suing, you'd have to show that the manufacturer made something so unsafe that the owner of the program could not handle it safely. I don't know how you'd go about doing that. So suing the manufacturer is likely to be unprofitable. There are certain tools, the mere possession of which is a crime. The law justifies this by saying that there is no legitimate use for the tool, only the illegal one. However, I think these must be explicitely listed, and I bet virus makers aren't on the list Perhaps you could them added. Michael ========================================================================= Date: Tue, 10 May 88 17:19:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner new! +49 228 8199645 Subject: Re: Virus Construction Set > bad news from Germany. ... In April this year a unbelievable > program called "VIRUS CONSTRUCTION SET (VCS)" was released at the > Hannover computer faire CeBIT. Actually, at least on a certain philosophical plane, I see this as a good thing. I have grown sick and tired of hearing, for most of the past decade, that security exposures are 'no problem' because no one except a real expert will be able to find them, let alone exploit them. "No one will discover that back door and so we are safe". This innocent, cute approach to a real problem is really a disservice to the community. Babies are innocent and naive. They start out their lives shoving anything that fits in their mouth into their mouth. They have to be taught to only put food into their mouths, and to accept food only from trustable sources. If not, they can get very sick, and perhaps die. Basically, for the last few years, we computer people been living in a dream world. It seems that we, as adults, still have to learn that, just because something fits, you don't *have* to try sticking it in (we can skip the obvious sexual parallels) and doing so might just be dangerous. If VCS does nothing else, it will demonstrate: > You dont have no know how a virus work to create one, you just > have to know how to turn on your Atari and how to start the VCS > program!!! Maybe, as a result, manufacturers (hardware and software) will no longer be able to rely on the principle that complexity and secrecy are adequate protection. When the consumer population understands the implications of 'toys' like VCS, even little kids will laugh at manufacturers who are silly enough to continue to tell their consumers such nonsense. Michael ========================================================================= Date: Tue, 10 May 88 12:47:26 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim Frost Subject: software self-checks | If something like [a self-integrity check] was added to the | MS-DOS utilities and public domain programs, it could stop the | spread of some viruses. For instance, if COMMAND.COM had such a | check, it would be much harder for a hacker to patch a virus into | it. | |yes, but as with all checks built in to programs, if the test(s) can be found |in the code, executable or source, it can be patched and circumvented. |however, such checks would be very useful in slowing the spread of a virus. A couple of comments to this. Yes, it'd slow the spread of viruses, but it would also make you less paranoid about them (and thus less likely to catch them), make viruses more likely to be obnoxious (what kind of person would spend the time to work around the protections?), and slow the system down as well. This is a classic argument about security. The advent of a "secure" system will make users forget about security. When security is breached, the breach may never be found because no one is looking for it. Also, a word about intermittent security. Users of the PClone utility FLUSHOT (or its relatives) should be aware that just because a program doesn't do anything while you're running with protection doesn't mean it won't while you're not. It is trivial to add code to check to see if the FLUSHOT program is resident in your machine and just sit there if it is, but wreck things if it is not. Just when you trust a program enough to not use the protection, you'll get burned. jim frost madd@bu-it.bu.edu =================================================================