home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.216 < prev    next >
Text File  |  1995-01-03  |  28KB  |  569 lines

  1. VIRUS-L Digest   Monday, 23 Oct 1989    Volume 2 : Issue 216
  2.  
  3. VIRUS-L is a moderated, digested mail forum for discussing computer
  4. virus issues; comp.virus is a non-digested Usenet counterpart.
  5. Discussions are not limited to any one hardware/software platform -
  6. diversity is welcomed.  Contributions should be relevant, concise,
  7. polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's
  8. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  9. anti-virus, document, and back-issue archives is distributed
  10. periodically on the list.  Administrative mail (comments, suggestions,
  11. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  12.  - Ken van Wyk
  13.  
  14. Today's Topics:
  15.  
  16. Protection in Operating Systems
  17. GateKeeper vs. SAM Intercept (Mac)
  18. A new version of nVIR A (mac)
  19. I'm New - What do I do with all of this? (PC)
  20. SuperClock 3.5 Virus? (Mac)
  21. Virus Information on VAX/VMS?
  22. 1701/1704 Infection report - Switzerland (PC)
  23. New Virus From the Philippines (system unknown)
  24. Equivirulence Map ?
  25. Lode Runner Virus (Apple)
  26.  
  27. ---------------------------------------------------------------------------
  28.  
  29. Date:    Fri, 06 Oct 89 22:17:00 -0400
  30. From:    WHMurray@DOCKMASTER.ARPA
  31. Subject: Protection in Operating Systems
  32.  
  33. >I wouldn't say UNIX is virus-proof (I posted a hoax article about a
  34. >UNIX virus over a year ago, just before the Internet Worm incident),
  35. >but it's sure a hell of a lot more virus-resistant than DOS.
  36.  
  37. It may be useful to compare UNIX with DOS.  However, if you are
  38. going to do it, you should be a little more complete.
  39.  
  40. In most implementations, UNIX is a multi-user multi-tasking
  41. system requiring a system manager or operator.  Media is not in
  42. the hands of the end-user.  It gets whatever storage it requires.
  43. DOS is a single-user single-tasking system designed to be
  44. operated by the user.  Media is normally in his hands.  DOS was
  45. originally designed to run, with an application, in under 64K.
  46. (Had it not been, we would not have a virus problem; we would not
  47. even have an industry.)   It is not reasonable to expect them to
  48. manifest the same vulnerability to viruses, any more than they
  49. exhibit the same functionality.
  50.  
  51. However, as it relates to viruses, the big difference between them
  52. today is the number and nature of uses and users.  If UNIX were being
  53. used for the same things and by the same number of users as DOS, it
  54. would be just as vulnerable.
  55.  
  56. >Better than changing OS to get better virus "resistance", why not
  57. >encourage the systems designers at Apple and IBM to implement
  58. >protection in their respective operating systems?
  59.  
  60. Be careful what you ask for; you might get it.  The vulnerability
  61. to viruses arises from our ability to write and share
  62. programs;  All complete strategies for dealing with them must
  63. ultimately involve some restriction on those capabilities.  While
  64. operating system functionality may be useful, I would rather
  65. reserve the decision over such fundamental choices to the end-
  66. user.
  67.  
  68. Much of what appears to be vulnerabilities to viruses in DOS,
  69. e.g., the bootblock,  are simply the virus designer exploiting a
  70. feature in the way that it was intended to be used.  The
  71. bootblock is intended to give control to the program on the
  72. media.  It operates the way that it was intended.  It contains no
  73. surprises.  The virus designer uses it as the obvious solution to
  74. the problem which confronts  every virus designer, i.e., how to
  75. get control, how to get his program executed.
  76.  
  77. In the absence of malice the mechanism would be beneath the users
  78. level of notice.  In the presence of viruses, he must be careful
  79. what media he boots from and must avoid putting his media in
  80. machines already booted.  In the absence of the feature, the
  81. virus designer would get his program executed in some other way.
  82. As a last resort, he would simply dupe users.
  83.  
  84. We may decide that being able to switch programs by switching
  85. media is too dangerous a feature to have, but I am not ready to
  86. concede it yet.
  87.  
  88. >I am sure that there are many complex issues facing a
  89. >company such as Apple, with regards to this problem, and changes at
  90. >the OS level to deal with viruses will, and probably should, be slow.
  91.  
  92. Here we are clearly in agreement.
  93.  
  94. >What users should be doing, is overtly pressuring computer
  95. >manufacturers to address this need at the OS level, and start buying
  96. >equipment from vendors who move in that direction.
  97.  
  98. The only machines that fully address this problem at the OS level
  99. are "application machines" which do not present any ability to
  100. modify or install programs.  Fred Cohen suggests that in a world
  101. of such machines we would still enjoy many, but not all, of the
  102. benefits of computers.  I would assert that we would enjoy many,
  103. but not most, of those benefits.
  104.  
  105. Indeed, the advantages of user programmability are so great that
  106. there is no chance that the readers will follow your advice, or
  107. that manufacturers would yield to any such pressure.
  108.  
  109. In the end, it is not an operating system issue; it is an
  110. application issue.  No matter what you do at the system layer, if
  111. you include user-programming at the application layer, then you
  112. are vulnerable to viruses.  Even interpreted languages, such as
  113. REXX, BASIC, or key-board macro languages, which need not even
  114. know what system they will run in,  can be used to implement
  115. viruses.
  116.  
  117. William Hugh Murray, Fellow, Information System Security, Ernst & Young
  118. 2000 National City Center Cleveland, Ohio 44114
  119. 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
  120.  
  121. ------------------------------
  122.  
  123. Date:    06 Oct 89 18:52:50 +0000
  124. From:    chinet!henry@att.att.com
  125. Subject: GateKeeper vs. SAM Intercept (Mac)
  126.  
  127. In article <0002.8910051142.AA12544@ge.sei.cmu.edu> ut-emx!chrisj@cs.utexas.edu
  128.  (Chris Johnson) writes:
  129. [Stuff Deleted]
  130. >Furthermore, I gather that GateKeeper is significantly more
  131. >configurable than SAM insofar as it maintains a privilege list which
  132. >can be easily viewed and edited (I've never used SAM, so I don't speak
  133. >from first-hand experience on this point, but people assure me that
  134. >it's a *very* important difference in practice).
  135.  
  136. I have used both GateKeeper and SAM Intercept and I prefer the
  137. latter.  The main reason?  When "something suspicious" happens,
  138. GateKeeper says "you can't do that!" then if you want to override,
  139. you must open the Control Panel select GateKeeper and set up the
  140. permission; with SAM Intercept, at the time of the happening you can
  141. allow the action once or LEARN the action then and there!
  142.  
  143. >GateKeeper doesn't provide a virus-scanner, but with Disinfectant
  144. >available (also for free) it's not much of a problem.
  145.  
  146. Agreed.  But it is handy to be able to scan as soon as you pop in a
  147. floppy.  VirusDetective DA is a good way to do this.
  148.  
  149. >One other thing that makes GateKeeper unique in the world of Macintosh
  150. >anti- virus systems is that it keeps a log file that details exactly
  151. >what virus related operations have been attempted, when, by whom and
  152. >against whom.
  153.  
  154. I only see this as being useful if you're trying to track the
  155. propagation of a virus, but then you have to allow the "suspicious
  156. action" which GateKeeper doesn't do (unless you gave permission, in
  157. which case it isn't logged!)
  158.  
  159. >- ----Chris (Johnson)
  160. >- ----Author of GateKeeper
  161.  
  162. I'm not trying to put down GateKeeper, if you want to fight viruses
  163. cheaply, it's a must!  Keep up the good work Chris!
  164.  
  165.                         Henry C. Schmitt
  166.                         Author of Virus Encyclopdeia
  167.                         Latest Version dated 6/8/89
  168.   H3nry C. Schmitt     | CompuServe: 72275,1456  (Rarely)
  169.                        | GEnie: H.Schmitt  (Occasionally)
  170.  Royal Inn of Yoruba   | UUCP: Henry@chinet.chi.il.us  (Best Bet)
  171.  
  172. ------------------------------
  173.  
  174. Date:    07 Oct 89 03:10:03 +0000
  175. From:    prieto@gem.mps.ohio-state.edu (Juan Pablo Prieto-Cox)
  176. Subject: A new version of nVIR A (mac)
  177.  
  178. It seems that there is a new version of nVIR A, or at least that's
  179. what the program Disinfectant reported. I will try to explain what it
  180. did to my system. Unfortunately before I noticed that it didn't behave
  181. as the well known nVIR A I erradicated it with Disinfectant.  After I
  182. run the infected program (a THINK C program) it changed the type of
  183. the files in the same folder (and folders therein) into a seemingly
  184. random type, taken from another file. That is, if you list the files
  185. by KIND under normal circumstances you would get THINK C as the kind,
  186. but after I run the infected program it changed the type to "vamos.c"
  187. that was just a file in the same folder. Upon further explorations
  188. with ResEdit I found in the Desktop file in the APPL resource a
  189. repetition. With Creator KAHL (as for all THINK C programs) but
  190. Application "vamos.c".  I also found a resource of type =/VIR (for
  191. typographical reasons by =/ I mean the symbol for not equal). Remember
  192. that I had already ran Disinfectant.  Does anyone have a clue? or a
  193. similar problem?
  194.  
  195. Juan Pablo Prieto-Cox
  196.  
  197. ------------------------------
  198.  
  199. Date:    06 Oct 89 14:56:54 +0000
  200. From:    eschner@mdcbbs.com
  201. Subject: I'm New - What do I do with all of this? (PC)
  202.  
  203.  
  204. I have a question that maybe others want to ask too:
  205.  
  206. I am new to BBS'es. This is my first other than our company one, so I don't
  207. think that my PC at home is "bugged" (though I have bought some shareware
  208. disks). I find all of this talk about viruses facinating - and frightning.
  209.  
  210. 1) How do I make sure I don't have any viruses on my machine, and
  211. 2) How do I remove any found viruses? Do I have to by programs, or are there
  212.    some in public domain? Can they only be obtained from PC BBS'es, or over
  213.    this network?
  214.  
  215. Brian Eschner     eschner@mdcbbs.COM
  216.  
  217. ------------------------------
  218.  
  219. Date:    Sat, 07 Oct 89 11:10:00 -0800
  220. From:    JOHN LOUCH <LOUCHA%CLARGRAD.BITNET@VMA.CC.CMU.EDU>
  221. Subject: SuperClock 3.5 Virus? (Mac)
  222.  
  223. Is there a virus on superclock 3.5 for the macintosh.  I would like to
  224. no since I own that program.
  225.                                         Thanks, John Louch
  226.                                                 Loucha@clargrad.bitnet
  227.  
  228. ------------------------------
  229.  
  230. Date:    Sun, 08 Oct 89 12:18:00 -0400
  231. From:    The one and only RED MENACE!!! <CCSST%SEMASSU.BITNET@VMA.CC.CMU.EDU>
  232. Subject: Virus Information on VAX/VMS?
  233.  
  234. To whom it may concern:
  235.  
  236. I have been following the discussion on the possibility of a virus on
  237. the VAX/VMS.  I am wondering if there is any more word on this
  238. particular topic?
  239.  
  240. The reason I ask is because I am one of many users at Southeastern
  241. Massachusetts University that are concerned about the welfare of our
  242. VAX systems.  As it turns out, I have submitted the information on
  243. possible VAX/VMS viruses to our SYSTEM MANAGER to inform him of the
  244. possible threat.
  245.  
  246. If there is anynmore information, could you please send me the
  247. information?
  248.  
  249.                                         Thanks in advance,
  250.  
  251.                                         Scott Turbiner
  252.  
  253. ------------------------------
  254.  
  255. Date:    Mon, 09 Oct 89 03:40:00 +0100
  256. From:    Markus Fischer <FISHER%CGEUGE52.BITNET@VMA.CC.CMU.EDU>
  257. Subject: 1701/1704 Infection report - Switzerland (PC)
  258.  
  259. Infection report from Geneva - Switzerland.
  260. ===========================================
  261.  
  262. The Cascade 1701/1704 -B virus has been found in Geneva (Switzerland)
  263. this week. It is the first time I see infected machines in that city.
  264.  
  265. At least two machines are infected. The diagnosis was made with
  266. VIRUSCAN V35. There is no doubt.
  267.  
  268. It is possible that the infection is going outside the infected computer
  269. club, but we are not sure at the moment.
  270.  
  271. I'll publish every interesting news.
  272.  
  273.                                 Fred Demole
  274. Disclaimer:
  275. ^^^^^^^^^^
  276. "I am posting this through a friend's account.  His consent to my use of his
  277. account in no way implies his consent to responsibility for the opinions
  278. expressed herein."
  279.  
  280.    /---------------- Fred Demole - Geneva (Switzerland) ----------------\
  281.  /                   ----------------------------------                   \
  282.  | "I know my english is very bad...            |  fisher@sc2a.unige.ch   |
  283.  |  Remarks are appreciated.                    |  fisher@CGEUGE52.BITNET |
  284.  |  Congratulations too."                       |  ---------------------  |
  285.  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  286.  
  287.  
  288. ------------------------------
  289.  
  290. Date:    09 Oct 89 10:01:00 -0400
  291. From:    <USADS%EMUVM1.BITNET@VMA.CC.CMU.EDU>
  292. Subject: New Virus From the Philippines (system unknown)
  293.  
  294. I have a user on campus who brought back a few disks from the
  295. Philippines and is now having problems with all of his disks. (hard
  296. and floppy) He states that all of his disks have bad tracks at the end
  297. of the disks, and he receives "can not load" messages when trying to
  298. load files from these disks.
  299.  
  300. I know very little about viruses and would like to know where I can
  301. send a disk that I suspect might have a virus. I only have one copy of
  302. the disk that I believe is infected, and I don't want to send it to
  303. just anyone.
  304.  
  305. Thank you
  306. Al Shelton
  307. Emory University
  308. MicroComputer Support
  309. 404-727-0816
  310.  
  311. ------------------------------
  312.  
  313. Date:    10 Oct 89 03:29:46 +0000
  314. From:    edvvie!eliza!johnny@relay.EU.net (Johann Schweigl)
  315. Subject: Equivirulence Map ?
  316.  
  317. Has it ever been tried to verify the center of 'epidemic' virus attacks?
  318. What's in my mind is a map of the (PC)known world, splitted into
  319. area codes.
  320. Whoever catches a virus reports the type (if known), symptoms and number
  321. of occurences on the PC's he takes care of. One for the late night home
  322. hacker, lots for a company's support staff or universities.
  323. If a virus begins to spread, USENET data exchange should be faster than
  324. PD or pirated software exchange.
  325. Data could be collected at one site in a relational database, with reports
  326. sent every week (or so) to a new newsgroup (comp.virusmap)?
  327. Some questions arise: Do you think, that
  328.   -     the typical infection paths could be analyzed?
  329.   -     this information would be useful to us?
  330.   -     hyperproductive virus developers could be tracked down?
  331.   -     virus avoidance could be made more effective?
  332.   -     this would make any sense at all?
  333. If the answer is yes, any ideas how to deal with
  334.   -     the amount of data that should be expected?
  335.   -     the world could be organized into areas (no problem within a town,
  336.         but I talk about something a little larger)?
  337.  
  338. In my opinion future Virus defence has to be active and aggressive, not
  339. the passive sit-down-and-wait-for-somebody-developing-a-serum. There's
  340. lot of infomation in this group, but it has to be cross-referenced to be
  341. really useful and can be given to persons not in the USENET family.
  342. By the way, has anybody read Michael Crichton's 'The Andromeda Strain'?
  343. It's a evil book about a virus, just nothing to do with computers.
  344.  
  345. Shoot the viruses to Pluto. Then, never trust software from there. Johnny
  346. - --
  347. This does not reflect the   | Johann  Schweigl | DOS?
  348. opinions of my employer.    | johnny@edvvie.at | Kind of complicated
  349. I am busy enough by talking |                  | bootstrap loader ...
  350. about my own ...            |   EDVG  Vienna   |
  351.  
  352. ------------------------------
  353.  
  354. Date:    Mon, 09 Oct 89 12:33:43 -0500
  355. From:    davidbrierley@lynx.northeastern.edu
  356. Subject: Lode Runner Virus (Apple)
  357.  
  358.      Here is a copy of a virus report posted on Info-Apple.  The
  359. report, I believe, originally was posted on Compuserve by
  360. Brian McCaig.
  361.      I would like to point out that subsequent messages on Info-Apple
  362. have indicated that Speedy Smith is not the primary carrier of the
  363. virus.
  364.      I also have some questions.  (1) Does any reader of VIRUS-L
  365. know if the French expression "non-destructeur" means
  366. "non-destructive" or "indestructible?"  (2)Could anyone post a
  367. version of VIRUS.KILLER (source code follows the report) written
  368. in BASIC?  (It could be posted here or to Info-apple@brl.mil)
  369. (3)  Because the university does not import VIRUS ALERT I
  370. have not posted this report to it, for fear of replication.  Could
  371. someone post this message to VIRUS ALERT if it has not appeared there
  372. already?
  373.  
  374. - -------------------------------------------------------------------------
  375.  
  376.         Well folks, here it is...installment number 3 in the Saga of the virus
  377. for the Apple II.  First it was CyberAids, which wasn't all that great and was
  378. quickly defused.  It was followed in June of 1988 by Festering Hate, a more
  379. sophisticated and deadly evolutionary offspring of CyberAids.  F.H. spread
  380. rapidly throughout the Apple II world and was particularly insidious as it;
  381. infected (usually) the first .SYSTEM file in the root directory, usually
  382. Basic.System, would infect more than one file per disk, would infect files in
  383. sub-directories, and when it 'went off' would destroy all volumes currently
  384. on-line at the time.  This included RAM disks and Hard Drives!
  385.  
  386.         By now, most of you are aware of Festering Hate and that there are
  387. several good virus detecting/protecting programs available that have virtually
  388. eradicated the FH virus.  It is to the credit of the Apple II community in
  389. general, and selfless people like Glen Bredon that FH was halted before it got
  390. too out of hand.  As a matter of fact it was the very vehicle that spread the
  391. virus so rapidly that was also responsible for its quick demise.  After I did
  392. my initial research on FH last year I wrote a brief study of it and uploaded
  393. the study to most of the active BBS's in Canada and the U.S.  I also sent
  394. copies to Glen Bredon and others who acted very quickly to develop the 'cures'.
  395.  But it was the massive telecommunications network of Apple II users that
  396. spread the details so quickly and stopped FH.
  397.         Now, number 3 virus has just appeared.  Called, rather nostalgically,
  398. "LODE RUNNER", it is not quite as destructive as its predecessors but its a
  399. virus nonetheless.  Here's what I've been able to pull together so far:
  400.  
  401. SOURCE
  402.  
  403.         - Although we're not 100% positive it appears that the program called
  404. SPEEDY SMITH is the culprit.  A recent import from France, Speedy Smith is one
  405. of the fastest copy programs for the IIgs.  A full 800K disk copy takes about
  406. 50 seconds (without verification) to 70 seconds (with) using SS.  It has an
  407. excellent SHR screen with 'thermometers' that indicate the copy's progress.
  408. Unfortunately the reason we cannot either convict or acquit SS is that its
  409. creators have seen fit to invent their own DOS.  This DOS is not readable by
  410. standard Apple II sector editors such as the one in Copy II Plus.  There are
  411. several reasons, however, for suspecting Speedy Smith.  First SS's displays are
  412. in French and the virus's text screens are as well.  When catalogued Copy II+
  413. indicates that there are 292 used Prodos blocks, but adding up the individual
  414. files' blocks only totals 148.  And lastly, what better vehicle for the spread
  415. of a virus than a copy program?
  416.  
  417. HOW WAS IT DISCOVERED?
  418.  
  419.         - Lode Runner was discovered almost by accident by several members of
  420. the Apples BC Computer Society.  Shortly after receiving several new disks of
  421. IIgs software, including Speedy Smith, one member found that his Test Drive II
  422. refused to run.  This was followed by backups and originals of Space Quest I
  423. and Police Quest.  At first it was thought that the member's IIgs was having
  424. hardware problems.  But at the same time another friend from Eugene, Oregon
  425. contacted us about having seen a French hi-res screen appear on his monitor
  426. just before his Copy II+ disk was trashed.  Not being Canadian he was only able
  427. to pick out the word "virus".  Armed with this info and the 'damaged' Space
  428. Quest disks I spent a weekend checking things out.  At the same time other
  429. friends in Oregon & California were independently analyzing infected disks.
  430.  
  431. HOW DO YOU KNOW IF YOUR DISKS ARE 'INFECTED'
  432.  
  433.         - There are 4 ways of detecting Lode Runner:
  434. 1) When the virus "goes off" and erases your disk...not exactly the most
  435.    desirable way,
  436. 2) If you have a copy of Space Quest I then you can use it to check all your
  437.    disks.  Boot any suspect disk and wait until the drive stops.  Replace the
  438.    disk with Space Quest and do the 3 or 4 fingered salute (OA-CTRL-RESET).
  439.    NOTE: Keep Space Quest write protected so that it dosn't get screwed up. If
  440.    Space Quest boots to the point where it asks you to press a joystick button
  441.    then you can be pretty sure that the previous disk is OK.  If Space Quest
  442.    trashes with an error message (#206) then the previous disk is likely
  443.    infected.
  444.    If you DO get an infected disk then you MUST either power down your IIgs or
  445.    run the self-test before continuing with your testing to clear the RAM as
  446.    the virus seems to install itself there.
  447. 3) A better check (and much faster) is to boot Copy II+ and run the 3.5" Sector
  448.    Editor.  Do a read of Block 0000 (Track 00, sector 00, side 01).  If the
  449.    first 3 bytes are   01  A9  50  then the disk is infected.  Those 3 bytes
  450.    aren't the only bytes that are different but they are all that is necessary
  451.    to identify the virus.
  452. 4) If you recall, last year during the Festering Hate panic it was noted that
  453.    one of the best ways to have an Apple II virus was in BLOCK (0) on any
  454.    Prodos disk.  At that point, anticipating another virus, Guy T. Rice wrote a
  455.    small virus detector/fixer.  If you put this program into the
  456.    SYSTEM/SYSTEM.SETUP folder on IIgs disks then it would automatically detect
  457.    and correct modifications to Block (0).  Now for LODE RUNNER this will also
  458.    work.. that is, it WILL detect LODE RUNNER and it will try to correct Block
  459.    (0).  BUT, it appears that due to the method of spreading of LR Guy's
  460.    program cannot correct it.  Every time you boot the disk it'll give you the
  461.    virus detect error.  I think the reason for this is that LR installs itself
  462.    in RAM upon bootup in preparation for infecting a new disk.. and the only
  463.    way you can be sure that its gone is to either power down or run the
  464.    self-test.. and since Guy Rice's program does an auto-reboot and corrects
  465.    the block (0) all in one step then the RAM never really clears and the virus
  466.    re-infects the disk.  And since you cannot write-protect the disk it becomes
  467.    a vicious circle.  I am going to try to get these observations to Guy Rice
  468.    in the hopes that he can modify his program.  NOTE: Three other problems
  469.    with using Guy's program: its no good for 5.25" disks, it only works with a
  470.    IIgs and it only works with disks that are bootable.  LODE RUNNER can infect
  471.    ANY Prodos disk because it resides in one of the blocks created when a disk
  472.    is formatted.
  473.  
  474.         There is a 5th way.. the friends in Eugene, Ore  have written a Binary
  475. program to detect and disarm the virus and I will try to include it in this
  476. file when I upload it.  The reason theirs is successful is that the detector is
  477. not part of the disk being checked and thus the "circle" is broken.
  478.  
  479. METHOD OF SPREADING
  480.  
  481.         - As far as we can tell the virus is spread two ways: by being copied
  482. with a copy program and by booting an uninfected disk (using OA-CTRL-RESET)
  483. immediately after running an infected disk.  NOTE: For a disk to be infected it
  484. must not be write-protected.  The virus does NOT infect actual files so none of
  485. your files will look modified in either their file length or their modified
  486. date.  The virus also does not search all drives, as did Festering Hate, so
  487. cannot be detected that way.  Because it doesn't infect files it only infects
  488. one spot per disk and cannot destroy any sub-directories.  Therefore your
  489. cannot get rid of the virus just by re-copying the files...the virus is
  490. actually part of the Prodos kernel created when the disk is formatted.
  491.  
  492.  
  493. WHAT HAPPENS WHEN IT "GOES OFF"?
  494.  
  495.         - To get Lode Runner to "go off" you must set your Control Panel's
  496. clock to the following:  the MONTH must be October,  the DAY must be an odd
  497. numbered day and the minute must be a number divisable by 8.  Next you must
  498. boot an infected disk then boot (using OA-CTRL-RESET) any other disk.  This
  499. second disk must NOT be write-protected or the virus won't activate.
  500.  
  501.         - Once the second disk is booted the virus will appear.  Its a red
  502. screen with text characters as follows:
  503.  
  504.                      +++  SYSTEM  FAILURE  in :  +++
  505.                                   08
  506.  
  507. and proceeds to count down  to zero where the screen changes to another with a
  508. multi-colored scrolling background and the following text;
  509.  
  510.                000E   Copies.      Distr:Artistes Associes
  511.  
  512.                      ===  L O A D  R U N N E R  ===
  513.  
  514.                 Premier virus NON-DESTRUCTEUR sur IIGS
  515.  
  516.                    par    SUPER HACKER  &  SHYRKAN
  517.               du  MASTERS CRACKING SERVICE    1988 Lyon
  518.  
  519.         By the time you've read the first screen the disk that you just booted
  520. has been rendered useless.  LR does not appear to erase more than the current
  521. disk and doesn't seem to affect 5.25" disks.  Not being an expert in French I
  522. am unable to determine whether the phrase below the title means: "The first
  523. non-destructIVE virus for the IIgs" or "The first non-destructIBLE virus for
  524. the IIgs".  This is a 'moot' point however as it DOES destroy one disk when it
  525. goes off.  In addition, and I believe that the writers of LR didn't plan this,
  526. LR will destroy Space Quest 1 and Police Quest for the IIgs if they are booted
  527. AT ANY TIME after an infected disk.. and if they are not write-protected.  It
  528. is not necessary for LR to "go off" for these programs to be rendered useless.
  529. I have only found these two that behave in this fashion but I am sure there are
  530. more.. likely most of the Sierra programs for the IIgs.
  531.  
  532.  
  533. ACKNOWLEDGEMENTS
  534.  
  535.         - As with the studies on Festering Hate there are many people who
  536.           collaborated on the research for this virus.  Many thanks go out to:
  537.  
  538. APPLES BC members,
  539.         Ross Woodhouse - for being so insistant that something WAS wrong.
  540.         Pat Daley - for gathering data, programs and relaying info.
  541.  
  542. EUGENE, OREGON users,
  543.         Jack Stalcup - for accidentally setting the virus off because the
  544.         battery in his IIgs was dead.  And for sending the programs and
  545.         keeping the communications alive.
  546.  
  547.         Neil Parker and Mike Suiter (sp?) - for analyzing LR and writing the
  548.                                             detection/correction program.
  549.  
  550.         PLEASE upload this file and Virus.killer to all bulletin boards. Please
  551. tell everyone you know about this virus so that we can wipe it out as fast as
  552. Festering Hate.  PLEASE.. if you find out any more information that is either
  553. not in these notes or that refutes any of these observations then let me know.
  554. I can be reached at (604)294-4471, 8:30am to 4:30pm Pacific time, Monday thru
  555. Friday up until September 30, 1989.  I can also be either reached by answering
  556. machine or in person at home (604)947-9722 anytime.  I will also be in
  557. attendance at Applefest in San Francisco Sept.22, 23, & 24th.  Messages can
  558. also be left on Compuserve...to 76475,642 (>>>---Brian--->).
  559.  
  560.                                 >>>---Brian--->  (Brian McCaig, Virus Busters)
  561.  
  562. [Ed. Program deleted - please contact message author for copy.]
  563.  
  564. ------------------------------
  565.  
  566. End of VIRUS-L Digest
  567. *********************
  568. Downloaded From P-80 International Information Systems 304-744-2253
  569.