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

  1. VIRUS-L Digest              Monday, 30 Jan 1989         Volume 2 : Issue 30
  2.  
  3. Today's Topics:
  4. re: checksum protection
  5. Virus Terminology
  6. A detailed description of the INIT 29 Macintosh Virus (Mac)
  7. Apple Viruses? (NOT Mac)
  8. FRG Nazi virus? Huh?
  9.  
  10. ---------------------------------------------------------------------------
  11.  
  12. Date: 27 January 1989, 13:27:00 EST
  13. From: David M. Chess  <CHESS@YKTVMV.BITNET>
  14. Subject: re: checksum protection
  15.  
  16. Don Alvarez <boomer@space.mit.edu> writes:
  17.  
  18. > Checksums are good for checking the integrity of data if you have
  19. > reason to believe that it has been corrupted (ie did I just download a
  20. > bogus copy of VirusRX off the network).  They are not a good way to
  21. > handle everyday protection against viruses...
  22.  
  23. because, basically, it takes too long to run the checksum checks.
  24.  
  25. That's a matter of personal taste, I suppose.  I run a checksum
  26. program that takes about ten minutes, every couple of days.  Of
  27. course, if it really wasted ten minutes of *my* time, it wouldn't be
  28. worth it.  But I always have ten minutes of stuff to do that doesn't
  29. require the computer (reading journals, eating lunch, etc), and who
  30. cares if I waste the *computer's* time?  With multi-tasking operating
  31. systems becoming the norm, it'll be even less of a concern; just start
  32. the checker running in the background with a low priority.
  33.  
  34. If checksums (and related modification-detection schemes) aren't a
  35. good way to handle everyday protection against viruses, what is?  The
  36. only alternatives seem to be to check for the N viruses that you
  37. happen to have heard of (you'll still get bitten by virus N+1), or to
  38. hope somebody else gets bitten by a new virus before you do, so you'll
  39. be told about it.  Neither very satisfying!
  40.  
  41. The bit about rebooting the machine from a trusted floppy before
  42. running the check is, of course, more of a pain than I'm willing to go
  43. to.  I was just using it as an extreme example to argue against some
  44. claims that, for theoretical reasons, undefeatable checking is
  45. impossible.  I hope that future operating systems and technology will
  46. make possible undefeatable checking that *is* human-useable.  May not
  47. be soon, of course, but I just wanted to suggest that it was
  48. theoretically possible.
  49.  
  50. DC
  51.  
  52. P.S.
  53. > How am I going to know what the checksum for each of them should be?
  54. > Keep a list of checksums on my disk?
  55.  
  56. Yes, of course.  On the same disk that the checker program is on.
  57. Sorry I didn't make that clear.  The checksums that are stored are
  58. just the ones the checker found last time.  The checker doesn't tell
  59. you "this program is/isn't clean", just "this program is/isn't the
  60. same as it looked last time I saw it".  Imperfect, perhaps, but I
  61. haven't thought of anything really better...
  62.  
  63. ------------------------------
  64.  
  65. Date:         Fri, 27 Jan 89 11:32:46 PLT
  66. From:         Joshua Yeidel <YEIDEL@WSUVM1.BITNET>
  67. Subject:      Virus Terminology
  68.  
  69. In Virus-L V2 #28, Danny Schwendener writes:
  70.  
  71. < The 'INIT 29" virus is not a mutation of nVIR, even if it is very
  72. < similar. Its sole purpose is to replicate itself. Other than that, it
  73. < causes no harm to the system. However, it will copy itself to *every*
  74. < resource fork that has been opened by the System, an application or a
  75. < utility (CDEV, DA, etc). I'd classify it as extremely virulent.
  76.  
  77. This is not a flame, but just an attempt to clarify our terminology.
  78. My "American Heritage" Dictionary defines "virulent" as "extremely
  79. poiosonous or pathogenic".  I think we should reserve that word for
  80. viruses, worms, Torjan horses, and other slime ("virus" in Latin)
  81. which have known malignant effects.  In my opinion, the correct term
  82. for INIT 29 is "extremely contagious", since it spreads through so
  83. many mechanisms and so many infection sites (filetypes).
  84.  
  85. This may seem like a very small point of diction, but it is very
  86. important to use accurate terms and avoid giving misimpressions when
  87. conveying virus information to large numbers of people.  More damage
  88. at our site has been caused by virus panic than by the malignant
  89. effects of all viruses together.
  90.  
  91. By the same token, I would recommend against describing any virus as
  92. "benign".  There is no way of ensuring that a virus will do no harm in
  93. any hardware/system/application setting it might infect. This is
  94. especially true since copies of a virus have no way of being updated
  95. to reflect system software updates.  The "benign" virus of today might
  96. become a "bomber" tomorrow.  In this sense (at least), every virus is
  97. a threat.
  98.  
  99. - - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- -
  100. Joshua Yeidel                         YEIDEL@WSUVM1.BITNET
  101. Academic Computing Services           YEIDEL@WSUVMS1.WSU.EDU
  102. Washington State University           (509) 335-0441
  103. Pullman, WA 99164-1220
  104. DISCLAIMER: I'm speaking solely for myself here, not Washington State U.
  105. - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - --
  106.  
  107. ------------------------------
  108.  
  109. Date:     Fri, 27 Jan 89 16:31 EST
  110. From:     DEC P/N 90-09203-00, for all your baking needs. <JEN@VTCS1>
  111. Subject:  A detailed description of the INIT 29 Macintosh Virus (Mac)
  112.  
  113. Here's a detailed analysis of the INIT 29 Macintosh Virus from Thomas
  114. Bond.
  115.  
  116. - -Jeff E. Nelson
  117. - -Virginia Polytechnic Institute and State University
  118. - -INTERNET:  jen@vtcs1.cs.vt.edu
  119. - -BITNET:    jen@vtcs1.bitnet
  120.  
  121. begin forwarded message------------------------------------------------
  122.  
  123. 0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0
  124.  
  125. THE ELEVENTH WORD:
  126.  
  127. 0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0
  128.  
  129. An Investigation Into the 712-byte RINIT 29S Macintosh Virus
  130.  
  131. by Thomas Bond, Mac Consultant
  132. 11684 Ventura Blvd., #932  %  Studio City, CA 91604
  133. 818-843-0567
  134.  
  135. (C) 1989 by Thomas Bond.  Permission is hereby granted to distribute in whole
  136. part by any means, whether in print or electronic, as long as the name,
  137. address and phone of the author remain unchanged.  Publications may quote
  138. parts for use in education on computer virus problems.
  139.  
  140.      Code 0
  141.        /
  142.   Virus Segment
  143.        \
  144.       Application Segments
  145.         /
  146.       ????????
  147.  
  148. ACKNOWLEDGEMENTS: This research could not have been completed without
  149. the very valuable help received from Q Tom Pitts, Robert Wright and
  150. David Lagerson of the MacValley Macintosh Users Group, Mark Weems of
  151. Kinko's Studio City store, Ken Cary of PaperWorks in Burbank, Joe
  152. Niewe of California State University, Northridge, and many others who
  153. gave up their time and advice.
  154.  
  155. [MacValley membership is $30.00 per year, and provides access to the
  156. PD Library with 1000's of freeware and shareware programs, official
  157. releases of Apple System software, association with over 700 Mac
  158. users, and special presentations from software companies, covering new
  159. programs and developments in the industry.  For membership info, call
  160. Bob Campbell, 818-784-2666.]
  161.  
  162.  
  163. BACKGROUND:
  164.  
  165.  This report is being prepared on January 17, 1989, for distribution
  166. at the monthly meeting of MacValley Macintosh Users Group in Burbank,
  167. California.  It contains the most recent information available to the
  168. author at this time: How the new RINIT 29S 712 byte virus acts, how to
  169. detect it, how to prevent it, and how to repair the damage it may do,
  170. at least in the early stages of its infection.  Those who need
  171. immediate help because they know or strongly suspect that their disks
  172. or hard disk(s) are infected, please turn to the section below labeled
  173. FOR EMERGENCY ACTION.  Others may benefit from a more deliberate
  174. reading of this paper, learning how these kinds of viruses work and
  175. what to do about them.
  176.  
  177. The author, Thomas Bond, is a Mac Consultant working primarily in
  178. desktop publishing and graphics, for various companies in the San
  179. Fernando Valley and Greater Los Angeles area.  He is available for
  180. professional consultations regarding this or other Macintosh
  181. applications and problems by calling the number above, 24 hours.
  182.  
  183. Late in December, 1988, one of my clients, the Kinko's Copy Center at
  184. Fulton Boulevard & Burbank Boulevards in Van Nuys, reported an unusual
  185. problem: It's three rental computers, all with hard disks attached,
  186. were rejecting all locked disks inserted into them.  After unlocking
  187. and reinserting the disks, documents would open normally.  Sometimes
  188. documents created with several programs such as PageMaker 3.0,
  189. MacWrite 5.01, Ready,Set,Go! 4.0a, Microsoft Word 3.02, Aldus Freehand
  190. 2.0, Adobe Illustrator 88, and others, would fail to print.  The
  191. report from the program was either that Rthis document failed to
  192. printS or in some cases there would be a bomb, or no report at all,
  193. simply a failure to print.  On occasion, the hard disk would fail to
  194. boot properly.
  195.  
  196. Checks with Apple's Virus Rx 1.3 & later Virus Rx 1.4 showed only that
  197. almost all applications, the System and Finder (v. 6.0.2) were
  198. damaged.  Replacement of the damaged programs and system files was
  199. performed repeatedly over a week's period.  In the meanwhile, hundreds
  200. of customers used the machines and infected their diskettes.  In
  201. between my own efforts, employees of the store often replaced the
  202. system files and applications themselves, in an effort to fix the
  203. problem.  The hard disks were initialized several times over several
  204. days.  Never-the-less, the infection reappeared immediately each time,
  205. soon after it began to be used.
  206.  
  207. A few days later, similar problems began to be reported at the Kinko's
  208. Studio City store, on Ventura Boulevard near Laurel Canyon.  The same
  209. procedures were followed at that store.  Some of the same well-meaning
  210. but uninformed employees tried to solve the problem.  In spite of the
  211. best efforts of several staff members and my own frequent visits, the
  212. equipment failed to print roughly half the time.  Each store was
  213. losing 100's of dollars due to the problem, adding to $1000's.
  214.  
  215. On Tuesday, January 3, I began to seriously and scientifically
  216. investigate the nature of the problem.  Careful poking around in the
  217. files with ResEdit 1.2b2 had already revealed no infestation of either
  218. Scores or nVIR, with which we were sadly very familiar and expert at
  219. handling.
  220.  
  221. Using ResEdit, I opened up a RcleanS and RdirtyS copy of Teach Text.
  222. The infected copy was exactly 728 bytes larger than the clean one.
  223. The CODE resource list showed ID's 0 thru 3 in the infected copy, and
  224. 0 thru 2 in the clean copy.  The new resource, ID number 3, was
  225. exactly 712 bytes.  The CODE resource numbered 0 was exactly 16 bytes
  226. bigger in the dirty copy than the clean copy.
  227.  
  228. I became very, very concerned about the problem, as I found by using
  229. the Virus Detective* desk accessory to search for 712 byte CODE and
  230. INIT resources that there was also an INIT ID 29 installed in most
  231. documents, other INIT files such as Pyro* & Suitcase II, the System of
  232. course, the Desktop file, and all font and DA suitcase files, as well
  233. as font printer drivers such as the LaserWriter driver, and Adobe
  234. printer fonts.  Some applications such as PageMaker, Freehand and
  235. Illustrator, had literally dozens of extra 712-byte CODE resources
  236. added.  They grew bigger on each startup and during each boot, whether
  237. started up or not.
  238.  
  239.  
  240. HOW RINIT 29S WORKS:
  241.  
  242. After some 57 hours of research and virus fighting labor at Kinko's 2
  243. infected local stores, I have determined the following:
  244.  
  245. 1.  The INIT 29 Virus will not accept locked disks after it has been
  246. fully activated on an infected system.  This is the easiest way to
  247. find out if you are fully infected.  However, since this symptom does
  248. not occur immediately, you will also need to make further checks.
  249.  
  250. 2.  The virus first invades the Desktop file of a disk when a program
  251. is copied onto it, inserting the 712 byte INIT ID 29 resource into it.
  252. (Alternately, the INIT is added to a system file if an infected
  253. application is started up, even without being copied to the disk.)
  254.  
  255. 3.  On the next boot, the INIT is added to the System from the desktop
  256. file (or elsewhere, perhaps), and to every application (as a new code
  257. resource numbered one higher than the existing resource ID, and
  258. adjusted CODE ID 0 resource) that is used during that work session,
  259. and to most documents created by the infected applications during the
  260. session.
  261.  
  262. 4.  During the very next boot, the infected System will insert the
  263. INIT or CODE resources into every targeted file on the hard disk (or
  264. diskette), including:
  265.  
  266.         % The actual Desktop file of the operative system disk (hard
  267.           disk or not)
  268.  
  269.         %  INITs such as Suitcase II, Pyro*, etc.
  270.  
  271.         %  CDEVs, RDEVs, and other system folder files
  272.  
  273.         % All applications and programs containing CODE resources,
  274.           with Illustrator 88, Freehand 2.0 and PageMaker 3.0 getting
  275.           (2) new 712 byte resources per each use or boot.  Others
  276.           seem to stay content to keep only one extra CODE resource.
  277.  
  278.         % Most document files, including those created by MS Word,
  279.           MacWrite, Ready,Set,Go!, PageMaker, Illustrator, Freehand,
  280.           and MS Works.  Oddly, MacPaint files seemed to be free of
  281.           the INIT.
  282.  
  283.         % All Rscreen fontS files (whether for imagewriter or
  284.           laserwriter, new or old versions), all Desk Accessory files,
  285.           new or old, all LaserWriter printer drivers, including those
  286.           used by Cassidy, Adobe and Apple fonts, Laser Prep and Aldus
  287.           Prep files, etc.
  288.  
  289. 5.  During invasion of an application, the INIT 29 Virus makes itself
  290. a vital part of the application, by changing the applications
  291. "jump-table" or CODE ID = 0 resource to list it as the FIRST SEGMENT
  292. TO BE RUN ON LAUNCH.  The address of the next segment of CODE to be
  293. run is copied from the jump table into the virus itself.  This means
  294. that removing the virus will kill the application (very much like some
  295. protoplasmic viruses).  The title of this report is taken from the
  296. address of the order to run first, namely the eleventh word of the
  297. jump table, which is changed to read the new address of the virus
  298. instead of the first segment of the original program CODE.  It is this
  299. word that is changed by most Mac viruses, at least so far, to ensure
  300. that they are run before any other, possibly anti-viral, instructions.
  301.  
  302.  
  303. SYMPTOMS OF THE INFECTION INCLUDE:
  304.  
  305.         % After the infected system is rebooted with the INIT running,
  306. it will not accept locked disks.  It provides the alert saying that
  307. the disk suffers from minor damage and asks to repair it.  You say OK
  308. and then it ejects the disk saying, of course, that the Desktop file
  309. could not be rebuilt on it.
  310.  
  311.         % After the infection is mature, often several days old, it
  312. begins to interrupt printing and cause documents to fail to print.
  313. This has especially been noticed with MacWrite, MS Word, PageMaker,
  314. Illustrator and Ready,Set,Go!  This seems to be an intermittent
  315. problem, and can sometimes express itself very soon after infection.
  316. {Apple's own Virus Information Report says this is most likely due to
  317. the Vertical Screen Blanking Interval being used by the virus to do
  318. its work, and the work cycle of the virus running too long and
  319. interfering with the printing tasks.}
  320.  
  321.         % Also after a mature infection of several days, the system
  322. seems to of ten fail to boot from the infected disk, giving a System
  323. Error ID 02.  {Robert Wright tells me that that this is due to the
  324. Virus trying to use parts of the system which have not yet loaded into
  325. RAM.}
  326.  
  327.  
  328. FOR EMERGENCY ACTION:
  329.  
  330.         % Don't rely entirely on Vaccine 1.01 from CE Software, or
  331. Apple's own VirusRX 1.4a2, or any other currently available program
  332. other than Virus Detective* DA, version 2.0 (1.2 will do, but is not
  333. as flexible, and will sometimes give false reports of removing locked
  334. or protected viral resources).
  335.  
  336.         % You will need to type 3 new lines of search instructions
  337. into Virus Detective* 1.2: INIT ID 29, INIT Size 712, CODE Size 712.
  338. (Virus Detective* 2.0 comes setup for several viruses including INIT
  339. 29 already.)  So far, the only two programs I have found with
  340. legitimate CODE resources of 712 bytes are the fun PD programs
  341. Biorhythm and Geographic.  Others you may find are most likely
  342. infected and need to be removed from your hard disk.
  343.  
  344.         NOTE: Simply removing the INIT is good enough from the
  345. infected non-application files, but applications will bomb if they are
  346. restarted after only removing the 712 byte CODE sections.  Their
  347. jump-table, or CODE ID = 0 resource has been re-written by the virus
  348. to look for the VirusUs own CODE segment.  Since the segment will no
  349. longer be there after you remove it, the System will crash with a
  350. System Error ID 15 {Robert Wright tells me this is a "segment loader"
  351. failure}.  If you know how to use ResEdit, you can replace words 9,
  352. 10, 11 and 12 in Code Segment 0 with words 16, 17, 18 and 19 of the
  353. top-most viral code segment.  Then remove the viral code segment(s) by
  354. RclearingS them.  Remember that many applications may have received
  355. many, many segments of the 712 byte viral code.  The newest segment,
  356. or highest numbered one, will be the one containing the proper words
  357. for copying back into the code 0 segment.  Be certain to removed all
  358. viral segments.  If you are not willing or able to re-write the code
  359. using ResEdit as described here, rely on your original master disk
  360. (which should always, of course, be kept locked), and simply replace
  361. the damaged copy with another clean one.
  362.  
  363.         % Be sure that you do not miss a single infected file,
  364. especially the Desktop, System, Finder or INITs, CDEVs, or RDEVs.
  365. Also, check ALL your diskettes.  They can be infected, even if no
  366. programs have been copied from them or to them.  Simple insertion into
  367. an infected hard disk computer set-up infects them.  You can then run
  368. your system again.
  369.  
  370.         % The Virus Detective* 1.2 desk accessory will not remove
  371. certain INIT ID 29 resources from documents and other files, since
  372. they are locked or protected by the virus.  Sometimes it claims to
  373. have removed the infections EVEN THOUGH IT HAS NOT DONE SO, and
  374. sometimes it tells you it actually failed.  Don't trust it completely.
  375. (Version 2.0 of the DA may do this job better, and comes fixed to look
  376. for Peace, Scores, nVIR, hPAT, and INIT 29.)  Go into ResEdit and
  377. check all questionable files and clear out the locked INIT ID 29s.  To
  378. encourage great Mac-ers like the author of this program, Jeffry
  379. Shulman, be sure to send him his money Q $ 20.00 is a bargain!  His
  380. address is Q P.O. Box 521, Ridgefield, CT 06877-0521.
  381.  
  382. I understand from talking with people in the LAMG and elsewhere that
  383. this virus is as yet not well known around LA.  However, rumors of the
  384. virus have cropped up, evidently occurring some weeks ago in the Simi
  385. Valley.  Members of the Canejo-Ventura area Mac Users Group reported a
  386. new virus which added INIT ID 29 to various applications on hard
  387. disks.  As far as I know, no application has yet been written by their
  388. group to repair jump tables of infected applications.  Of course, this
  389. report is posted on several local BBS units and 100 copies were given
  390. away at the January MacValley meeting to interested members.
  391. Communication is also being performed with other regional BBS units
  392. and interested parties in an effort to fight the growing epidemic of
  393. INIT 29 and its associated problems.
  394.  
  395.  
  396. FUTURE EFFORTS:
  397.  
  398. We are now working on efforts to automatically detect the infection of
  399. the INIT 29 Virus and to prevent its operation.  MacValley members
  400. should expect to receive further information by the next meeting, in
  401. February.  Other efforts are being made to provide a program that will
  402. automatically repair infected documents, files, and applications.
  403.  
  404. Until such programs are available, you would be advised to avoid using
  405. public service bureau computers for laser printing or otherwise
  406. WITHOUT FIRST LOCKING YOUR DISKETTES, then copying the data onto their
  407. hard disks for revision or printing.  If your locked disk is rejected,
  408. DO NOT UNLOCK IT.  You may unlock it, and try to copy it, print it and
  409. or revise it on their hard disk.  DO NOT RECOPY THE REVISED VERSION OF
  410. YOUR FILE TO YOUR DISK unless you are willing to accept the
  411. consequences of an infection at home.  NOTE: Some document files after
  412. infection fail to copy, due apparently to their "protect" bit being
  413. set by the virus.  This is the cause of much frustration at such
  414. service bureaus.
  415.  
  416.  
  417. FURTHER REPORTS OF INFECTIONS,
  418. NEW VIRUS SYMPTOMS, ETC.:
  419.  
  420. Any further information, elaboration on the symptoms, or other virus
  421. reports would be appreciated .  Call Thomas Bond at 818-843-0567, or
  422. David Lagerson, MacValley President, at 818-882-4467.
  423.  
  424. end forwarded message-------------------------------------------------
  425.  
  426. ------------------------------
  427.  
  428. Date:         Sat, 28 Jan 89 09:59:55 EST
  429. From:         "John P. McNeely" <JMCNEELY@UTCVM.BITNET>
  430. Subject:      Apple Viruses? (NOT Mac)
  431.  
  432.     Does anyone know of ANY virus that infects Apple computers? It
  433. seems that all of the virus attacks you hear about affect PCs or MACs.
  434. There is certainly a substantial amount of Apples being used,
  435. especially in schools. Why have they not become a popular target for
  436. viruses?
  437.  
  438. Anyone ?
  439.  
  440. John P. McNeely
  441.  
  442. BITNET ADDRESS: JMCNEELY@UTCVM.BITNET
  443.  
  444. [Ed. I assume that you mean the Apple ][ series...]
  445.  
  446. ------------------------------
  447.  
  448. Date:     Sat, 28 Jan 89 15:43 EST
  449. From:     Dimitri Vulis <DLV@CUNYVMS1.BITNET>
  450. Subject:  FRG Nazi virus? Huh?
  451.  
  452. >From Newsweek, Jan 23, 1989, p. 32:
  453.  
  454. Nazi Software: The Ultimate Virus
  455.  
  456. West Germany has given new meaning to the term computer virus:
  457. infecting the electronic bulletin boards of the Federal Republic are a
  458. growing number of neo-Nazi computer games. They bear names like
  459. ``Aryan test'', and ``Concentration Camp Manager''. Players of
  460. ``Cleaning Up Germany'' score points by killing Jews, Turks,
  461. homosexuals and environmentalists to the strains of ``Deutschland
  462. \"uber Alles''. The ``Anti-Turks Test'' features the digitized voice
  463. of Nazi propaganda minister Joseph G\"obbels.
  464.  
  465. Though illegal in West Germany, the game disks are swapped in
  466. schoolyards and circulated though computer networks, making
  467. interdiction nearly impossible. The authorities know of at least 20
  468. games---but don't know who's designing them.  Last year a raid on
  469. apartments of suspected neo-Nazis netted copies of some of the games,
  470. but no proof they were produced on site. By the end of 1987, about 11
  471. percent of German households has a personal computer, and, warns
  472. Jurgen Lindenau of the Office for Youth Protection, ``One should
  473. assume that just about every youngster who owns a computer and uses it
  474. for playing games has come across the Nazi software sooner or later''.
  475. The hope is the games are too crude for anything beyond brief
  476. curiosity.
  477.  
  478. There's also a photo (captioned `Aryan Test') of an (apparently C64)
  479. screen showing assorted swastikas and magen Davids and the text:
  480.  
  481. ARIERTEST                                (Arian test)
  482.  
  483. ARIER ODER JUDE?                         (Arian or Jew?)
  484. DAS IST RIER DIE FRAGE                   (That is the question)
  485.  
  486. (C) 1986 BY ADOLF HITLER SOFTWARE LTD.
  487.  
  488. - ----
  489.  
  490. I must note that I find the idea of government censorship applied to
  491. the contents of computer games much more (disgusting, abhorrent,
  492. sickening) than the (disgusting, abhorrent, sickening) Nazi
  493. propaganda. If those Germans had any brains, they would leave these
  494. sickos alone, instead of encouraging them with the free publicity.
  495. Perhaps this is what they have in mind?
  496.  
  497. >From what I understand/heard before, we're just talking about
  498. programs being up/downloaded, to/from BBSs, not programs that infect
  499. other programs with Nazi messages. The article quoted above has
  500. nothing to do with viruses, except the headline. The author's/editor's
  501. stupidity and ignorance do not surprise me the least bit after the
  502. ``360 concentric circles of data'' (360K / 40 tracks confusion) in the
  503. Time article last fall. It seems however that the media (read:
  504. J-school morons) has now appropriated the term ``computer virus'' and
  505. uses it to designate ``any buggy, malicious, destructive or offensive
  506. program''. Perhaps we should start looking for another term to
  507. designate ``a program that can `infect' other programs by modifying
  508. them to include a possibly evolved copy of itself''. (This seems
  509. silly; but after 10 years I've stopped applying the term ``hacker'' to
  510. myself for similar reasons.)
  511.  
  512. Any comments or suggestions?
  513.  
  514. P.S. Our VAX has apparently been trashing mail lately. I will comment
  515. on the last 2 week's worth of this digest after I get it from a
  516. server.
  517.  
  518. ------------------------------
  519.  
  520. End of VIRUS-L Digest
  521. *********************
  522. Downloaded From P-80 International Information Systems 304-744-2253
  523.