Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA13772; Fri, 1 Jun 90 11:25:49 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA20515; Fri, 1 Jun 90 11:25:45 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA00252; Fri, 1 Jun 90 11:24:59 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa22987; 1 Jun 90 15:58 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Fri, 01 Jun 90 16:05:16 BST Message-Id: <$TGTWCZCFFBQF at UMPA> Subject: Virus-L vol 0 issue #0428 Virus-L Digest Thu, 28 Apr 88 Volume 0 : Issue #0428 Today's Topics ** no subject, date = Thu, 28 Apr 88 07:42:08 EDT virus in Aldus Freehand self-training disks Purpose of this list. A description of computer virus epidemic at Miami U. Re: Purpose of this list. MAC VIRUS info -- relayed from INFO-MAC RE: A description of computer virus epidemic at Miami U. Core Wars -------------------- Date: Thu, 28 Apr 88 07:42:08 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" In-Reply-To: Message of Mon, 25 Apr 88 17:49:20 EDT from > Which brings up my third point: I read your comment, Ken, about > ten times, and I still don't understand it. I don't believe > public domain programs are the answer at all. I believe we should > use commercially available fixes. But, likewise, you mention > that public domain virus-fixes should be given with source code. > If we want to make the perfect fix... one that will take the > virus writer infinitely long to break, then we do NOT want source > code EVER given out, or even the details of how the system works! I guess I didn't phrase myself very clearly. I didn't mean that people should not use commercial packages; quite the contrary. I have little faith in the public domain anti-viral packages because of things like FLUSHOT - it's too easy to put a virus in one. That, and I believe that all public domain software should be distributed with source code. Not because they're anti-viral programs, but because they're in the public domain. I feel that most of the commercial packages are more thorough than any of the public domain packages at this time. They should *NOT* be distributed with source code. A user should be safer using a commercial package - yes, we all know about Aldus... I don't think that *ANY* software solution to the virus problem can be 100% effective, though. I hope that clears things up a bit... Which brings me to my next point. I've just been out of town for a couple days on a business trip. When I read my mail last night, I was very surprised about all the traffic that we've gotten on VIRUS-L - thanks to *ALL* who submitted! Let's keep it going! I wasn't too happy to see flames and commercial plugs, though. As the listowner, I will tolerate none of either. Differences of opinion are one thing, but flames are not acceptable or proper. If anyone *REALLY* feels the need to flame someone, then reply to that person directly - NOT TO THE LIST! That way, I won't have to read it, unless it's me getting flamed; but, hey, I can purge a message as fast as the next guy... :-) Commercial plugs are against BITNET policy. 'Nuff said. Anyone sending a flame or a commercial plug to the list does so knowing that it is his/her final submission to the list - you *WILL* be removed permanently. Which leaves only melodrama - there's no official BITNET policy against melodrama unfortunately. I just hope that all of our readers have a grain or two of salt handy... :-) Oh yeah, one general guideline - when intending to be "tongue in cheek" or anything like that, please bear in mind that it is difficult to interpret something as tongue in cheek. A shortcoming of computer mail I'm afraid. It's easy enough to *EMPHASIZE* something, but how do we put inflection into it? How about @tongue_in_cheek(this is tongue in cheek)? :-) Thanks for the info on La Salle, Loren. Hope someone out there will be making use of it. And thanks to everyone who has submitted! 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! = - ---------------------------------------------------------------------- -------------------- Date: Thu, 28 Apr 88 08:11:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: J_CERNY@UNHH Subject: virus in Aldus Freehand self-training disks I just received my copy of the Aldus Freehand demo disk. As I understand it, this runs a muscial script to show off what Freehand can do. Just before I got around to putting it in my hard-disk SE system for the first time, however, I read in the March 15, 1988 issue of MacWEEK that the Aldus Freehand training disk is infected with a virus!! I'd previously heard that some copies of the actual program were infected, but this was the first I'd heard about the training disk. Does anyone know more about this, specifically: (1) Is what the article calls the "training disk" the same thing as this scripted, musical demo disk? Or is the training disk something you get when you order the full-blown program? (2) Are ALL copies of the training disk believed to be infected? Jim Cerny, University Computing, University of N.H. J_CERNY@UNHH -------------------- Date: Thu, 28 Apr 88 15:59:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Purpose of this list. I am about to send a description of the computer virus epidemic that surfaced at Miami University to this list. I hope this is an appropriate place to distribute the information. I subscribed to the list three days ago and am a little confused about the purpose of virus-l. My interest is in obtaining information about active viruses discovered in the computing community and in recommendations for combating/defending/managing. If this is not appropriate would someone direct me to the appropriate forum? Thank You Joe Simpson -------------------- Date: Thu, 28 Apr 88 16:02:55 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: A description of computer virus epidemic at Miami U. 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 (OR IN SOME CASES POSSIBLY FIVE) CONTIGUOUS SECTORS MARKED BAD IN THE FAT. THE THREE SECTOR VERSION INSTALLS IN HIGH RAM AND CAN BE DETECTED THERE USING STANDARD DOS CALLS. IF THERE IS A FIVE SECTOR VERSION (THIS MAY BE DAMAGE AND NOT VIRUS), IF IT IS A VIRUS, IT DOESN'T PERMANENTLY INSTALL IN HIGH RAM. THE THREE SECTOR VERSION APPEARS TO INSTALL BOOTSTRAP CODE INTO AT LEAST THE FOLLOWING FILES: COMMAND.COM, PRINT.COM, FORMAT.COM. FRED HAS A CHECKSUM PROGRAM THAT WE USED TO DIAGNOSE THIS BEHAVIOR. THE THREE SECTOR 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: Thu, 28 Apr 88 16:16:02 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Purpose of this list. In-Reply-To: Message of Thu, 28 Apr 88 15:59:00 EST from >I am about to send a description of the computer virus epidemic that >surfaced at Miami University to this list. I hope this is an >appropriate place to distribute the information. This list is definitely an appropriate place for that discussion! >I subscribed to the list three days ago and am a little confused about >the purpose of virus-l. My interest is in obtaining information >about active viruses discovered in the computing community and in >recommendations for combating/defending/managing. If this is not >appropriate would someone direct me to the appropriate forum? While the list is less than a week old, I think that you're definitely on target with what you expect. I'd like to see the same things, and a bit more. Discussing existing viruses alone is somewhat limiting, and probably an uphill battle. While information on them should definitely be available here, we shouldn't limit ourselves to that. Some theoretical discussions on future virus possibilities, and how to prevent them, should also be found. Hope that clears it up... 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! = - ---------------------------------------------------------------------- -------------------- Date: Thu, 28 Apr 88 16:54:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Loren Miller, Senior Large-Systems Consultant" Subject: MAC VIRUS info -- relayed from INFO-MAC Date: Tue 26 Apr 88 03:36:16-EDT From: "Vin McLellan" Subject: Virus Sores and Scores Relayed from: INFO-MAC Digest Saturday, 23 Apr 1988 Volume 6 : Issue 40 >From jpd@eecs.nwu.edu Mon Apr 18 10:11:09 1988 Subject: The Scores Virus Date: 18 Apr 88 16:11:09 GMT My colleague Bob Hablutzel got a copy of the Scores virus last Thursday and disassembled it, and I've been studying and testing it ever since. So far I've reverse-engineered about half the code and have a thorough understanding of how it works. This note is a preliminary report on what I know so far, after four days of research. It also outlines plans for a disinfectant program. The virus is definitely targeted against applications with signatures VULT and ERIC. I don't know if any applications with these signatures exist or are planned to be released. The virus infects your system folder when you run an infected program. The virus lies dormant for two days after your system folder is first infected. After two, four, and seven days various parts wake up and begin doing their dirty work. Two days after the initial infection the virus begins to spread to other applications. I haven't completely finished figuring out this mechanism, but it appears that only applications that are actually run are candidates for infection. After four days the second part of the virus wakes up. It begins to watch for the VULT and ERIC applications. Whenever VULT or ERIC is run it bombs after 25 minutes of use. If you don't have a debugger installed you'll get a system bomb with ID=12. If you have MacsBug installed you'll get a user break. After seven days the third part of the virus wakes up. Whenever VULT is run the virus waits for 15 minutes, then causes any attempt to write a disk file to bomb. If you don't do any writes for another 10 minutes the application will bomb anyway, as described in the previous paragraph. There's also more code to force a bomb after 45 minutes, but I can't see any way that this code can be reached, given the forced bomb after 25 minutes. The virus identifies VULT and ERIC by checking to see if the application contains any resources of type VULT or ERIC. Applications with signatures VULT and ERIC normally contain these resources, but other applications normally don't. I verified the behaviour of the virus by using ResEdit to add empty resources of types VULT and ERIC to the TeachText application. TeachText bombed as described above on an infected system, even though TeachText itself was not infected! While running my experiments I was in ResEdit on the infected system and heard the disk whir. Sure enough, ResEdit was infected. I've been running on an infected system with an infected ResEdit for three days. I reset the system clock to fool the various parts of the virus into thinking it was time for them to wake up. The Finder has also become infected. ResEdit, Finder, and the rest of the system seem to be functioning normally. Only my version of TeachText modified to look like VULT or ERIC has been affected by the virus. If you repeat any of these experiments be very careful to isolate the virus. I'm using a separate dual floppy SE to perform my experiments, and I've carefully labelled and isolated all the floppies I'm using. My main machine is an SE with a hard drive, where I have MPW and my other tools installed. It's OK to look at infected files on the main machine (e.g. with ResEqual, DumpCode, etc.), but don't run any infected applications on the main machine - that's how it installs itself and spreads. Children should not attempt this without adult supervision :-) An infected application contains an extra CODE resource of size 7026, numbered two higher than the previous highest numbered CODE resource. Bytes 16-23 of CODE resource number 0 are changed to the following: 0008 3F3C nnnn A9F0 where nnnn is the number of the new CODE resource. You can repair an infected application by replacing bytes 16-23 of CODE 0 by bytes 2-9 of CODE nnnn, then deleting CODE nnnn. I've tried this using ResEdit on an infected version of itself, and it works. The MPW utility ResEqual reports that the result is identical to the original uninfected version. The virus creates two new invisible files named Desktop (type INIT) and Scores (type RDEV) in your system folder, and adds resources to the files System, Note Pad File, and Scrapbook File. Note Pad File and Scrapbook File are created if they don't already exist. Note Pad File is changed to type INIT, and Scrapbook File is changed to type RDEV. Both of these files normally have file type ZSYS. The icons for these two files change from the usual little Macintosh to the generic plain document icon. Checking your system folder for this change is the easiest way to detect that you're infected. Copies of the following five resources are created: Type ID Size Files ----- ----- ----- ------------------------------------- INIT 6 772 System, Note Pad File, Scrapbook File INIT 10 1020 System, Desktop, Scores INIT 17 480 System, Scrapbook File atpl 128 2410 System, Desktop, Scores DATA -4001 7026 System, Desktop, Scores A disinfectant program would have to repair all infected applications and clean up the system folder, undoing the damage described above. I don't yet know exactly which files can be infected, but I know for sure that Finder (file type FNDR) can get infected, and that applications (file type APPL) can get infected. For safest results the disinfectant should examine and disinfect the resource forks of all the files on the disk. I recommend the following algorithm: Scan the entire file hierarchy on the disk, and for each file on the disk check it's resource fork. Delete any and all resources whose type, ID, and size match the table above. Delete all files whose resorce forks become empty after this operation. If the resource fork's highest numbered CODE resource is numbered two more than the next highest numbered CODE resource, and if it's size is 7026, then patch the CODE 0 resource as described above, and delete the highest numbered CODE resource. Also examine all files named Note Pad File and Scrapbook File. If their file type is INIT or RDEV, change it to ZSYS. I'm fairly confident that a disinfectant program implemented using the algorithm above would sucessfully eradicate the virus from a disk, restore all applications to their original uninfected state, and not harm any non-viral software on the disk. It should work even on disks with multiple infected system folders. I also believe that it should work even if run on an infected system, and even if the disinfectant program becomes infected itself! There's a small chance that it could delete too many resources, and hence damage some other application, but that's a small price to pay for a clean system. Getting rid of a virus is tricky, even with a disinfectant program. The disinfectant program should be placed on a floppy disk along with a system folder. Make a backup copy of this disk. The machine should be booted using the startup disk you just made, and then the disinfectant should be run on all the hard drives and floppies in your collection, including the backup copy of the startup disk you just made. Don't run any other programs or boot from any other disks while disinfecting - you might get reinfected. When you're all done, reboot from some other (disinfected) disk and immediately erase the startup disk you used to do the disinfecting, which may be (and probably is) infected itself. This should absolutely, positively get rid of all traces of the virus. The backup disk you made and disinfected should contain an uninfected copy of the disinfectant program in case you need to use it again. There are at least two red herrings in the virus. It uses a resource of type 'atpl', which is usually some sort of AppleTalk resource. As far as I can tell, however, the virus does not attempt to spread itself over networks. The 'atpl' resource is used for something else entirely. This is not a bug. Also, the virus creates the file Desktop in your system folder. This is done on purpose. It is not a failed attempt to modify the Finder's Desktop file in the root directory. The file is used by the virus, and has nothing to do with the Finder. I don't know why the virus seems to cause reported problems with MacDraw, printing, etc. Perhaps it's a memory problem - the virus permanently allocates 16,874 bytes of memory at system startup (four blocks in the system heap of sizes 772, 40, 8, and 334, and one bock at BufPtr of size 15360). I've only found one possible bug in the virus code, and it looks pretty harmless. The code is very sophisticated, however, and I can easily understand how I might have overlooked a bug, or how it might interact in strange unintended ways with other applications and parts of the system. When we've finished completely cracking this virus we'll probably distribute another report. I've posted these preliminary results now to get the information out as quickly as possible. We also hope to write the disinfectant program, if someone else doesn't write it first. I've decided not to distribute detailed information on how this virus works. I'll distribute detailed technical information about what it does and how to get rid of it, but not internal details. This was a very difficult decision to make, because normally I firmly believe in the enormous benifit of the free exchange of code and information. The Scores virus is a very interesting and complicated piece of code, I've learned a great deal about the Mac by studying it, and I'm sure other people could learn a great deal from it too. But I don't want to teach twisted minds how to write these incredibly nasty bits of code. If I write the disinfectant program, however, I will distribute its source, because I do want to teach untwisted minds how to get rid of them. So please don't bombard me with requests for more information. You may be the nicest, most honest, incredibly important person, but I won't tell you how it works. I'll make only two exceptions, and that's for a very few of my colleagues at Northwestern University, and for qualified representatives of Apple Computer. Thanks to Howard Upchurch for giving us a copy of the virus, and to Bob Hablutzel for helping me crack it. John Norstad Northwestern University Academic Computing and Network Services 2129 Sheridan Road Evanston, IL 60208 Bitnet: JLN@NUACC Internet: JLN@NUACC.ACNS.NWU.EDU Monday morning, April 18, 1988. - ---------------------------- -------------------- Date: Thu, 28 Apr 88 20:12:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: UJWSIEC@VAX1.CC.LEHIGH.EDU Subject: RE: A description of computer virus epidemic at Miami U. >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. > Be very careful here... Suppose you follow steps 1, 2, & 3, if you miss even one disk, you could be back where you started in a week. After you analyze the assmembly, I would suggest the you implement a screening proceedure and vaccination procedure in a program. Install that program in the autoexec of every bootable disk, so that on bootup you automatically check whether or not the disk is infected and if it is infected you kill the virus. This way your disks become "vaccinated" against that particular strain. This is what we did at Lehigh. Of course, write protecting all disks (maybe even notch-less) is probably a better solution, but sometimes that isn't appropriate. >MORE WRITE PROTECTION AT DOS ATTRIB LEVEL AND HARDWARE LEVEL. DOS Attribing doesn't do much and its very easy for a virus to by-pass this. I'm unfamiliar with any attrib at the HARDWARE level. It's hard to say much more without knowing specifically how the virus comunicates itself, how it finds its hiding spot, and so forth. Decipering the assembly is very important, otherwise you might miss something. Good Luck - ---------------------------------------------------------------------------- ujwsiec@vax1.cc.lehigh.edu Joe Sieczkowski {ihnp4}!c11ux!lehi3b15!joes AI Lab, CSEE Department jws5@lehigh.bitnet Lehigh University Packard Lab #19 Bethlehem, PA 18015 -------------------------------------------------------------------- "Yes...It was a dark and stormy night that a party of three and myself found, tracked, and destroyed the Lehigh Virus." --------------------------------------------------------- -------------------- Date: Thu, 28 Apr 88 21:10:50 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: -=*REB*=- Subject: Core Wars Someone asked about Core Wars. The idea for Core Wars appeared in Scientific American in May of 1984. It is a rudimentary mathematical game based on writing small programs whose mission is to survive while annihilating other similar programs in the same workspace. The programs are written in a language called "redcode." They are in memory at random positions, and neither knows the location of the other. They take turns at executing instructions. Methods of operation are described whereby programs "bomb" certain areas of memory, copy themselves around to give the other program "the slip", etc. The article is definitely worth checking out. The entire game has many similarities to the current virus problem. There was also a IBM PC based public domain program floating around which played the game. I think I have a copy of it somewhere. Richard Baum _______________________________________________________________ / From: -=*REB*=- ", /FoneNet: (0010 0001 0101) 1000 0110 0111-1000 0100 0011 0011 BCD ", /InterNet: kREBaum@Vax1.CC.Lehigh.EDU BitNet: RB00@Lehigh.Bitnet ", / SlowNet: 508 E 4th St. (positively) Suite #1, Bethlehem, PA 18015 ", !----------------------------------------------------------------------! ! The Brent Z*ne! ! "----------------------------------------------------------------------"