home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / v / vl6-030.zip / VL6-030.TXT < prev   
Internet Message Format  |  1993-02-21  |  32KB

  1. Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5)
  2.     id AA05893; Fri, 19 Feb 1993 22:20:09 +0100
  3. Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA46094
  4.   (5.67a/IDA-1.5 for <mikael@abacus.hgs.se>); Fri, 19 Feb 1993 15:39:59 -0500
  5. Date: Fri, 19 Feb 1993 15:39:59 -0500
  6. Message-Id: <9302191618.AA01441@first.org>
  7. Comment: Virus Discussion List
  8. Originator: virus-l@lehigh.edu
  9. Errors-To: krvw@first.org
  10. Reply-To: <virus-l@lehigh.edu>
  11. Sender: virus-l@lehigh.edu
  12. Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
  13. From: "Kenneth R. van Wyk" <krvw@first.org>
  14. To: Multiple recipients of list <virus-l@lehigh.edu>
  15. Subject: VIRUS-L Digest V6 #30
  16. Status: RO
  17.  
  18. VIRUS-L Digest   Friday, 19 Feb 1993    Volume 6 : Issue 30
  19.  
  20. Today's Topics:
  21.  
  22. Re: What is a virus ?
  23. What kind of people make viruses?
  24. Virus detection by code inspection
  25. Re: Virus education
  26. YOUR opinions on virus legality needed!
  27. Re: TIME Magazine on "Cyperpunk": How Not to Define a "Worm"
  28. Uruguay on PS/2 Ref disk (PC)
  29. 1757 virus (PC)
  30. Re: Scanning memory (PC)
  31. Michelangelo or STONED? (PC)
  32. Possible new Virus found. HELP! (PC)
  33. Re: New way of opening files??? (PC)
  34. Minimal virus scan? (PC)
  35. Re: windows virus (PC) - is WALDO one?
  36. Re: New Virus (PC)
  37. Re: Suggestion to the developers of resident scanners (PC)
  38. Re: MtE Infected... (PC)
  39. CLU-011.ZIP (PC)
  40. SCAN 101 (PC)
  41. FDISK buggy? (PC)
  42.  
  43. VIRUS-L is a moderated, digested mail forum for discussing computer
  44. virus issues; comp.virus is a non-digested Usenet counterpart.
  45. Discussions are not limited to any one hardware/software platform -
  46. diversity is welcomed.  Contributions should be relevant, concise,
  47. polite, etc.  (The complete set of posting guidelines is available by
  48. FTP on cert.org or upon request.) Please sign submissions with your
  49. real name.  Send contributions to VIRUS-L@LEHIGH.EDU.  Information on
  50. accessing anti-virus, documentation, and back-issue archives is
  51. distributed periodically on the list.  A FAQ (Frequently Asked
  52. Questions) document and all of the back-issues are available by
  53. anonymous FTP on cert.org (192.88.209.5).  Administrative mail
  54. (comments, suggestions, and so forth) should be sent to me at:
  55. <krvw@FIRST.ORG>.
  56.  
  57.    Ken van Wyk, krvw@first.org
  58.  
  59. ----------------------------------------------------------------------
  60.  
  61. Date:    11 Feb 93 19:59:10 +0000
  62. From:    ulogic!hartman (Richard M. Hartman)
  63. Subject: Re: What is a virus ?
  64.  
  65. bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
  66. >So, let's try again:
  67. >
  68. >"A computer virus is a sequence of symbols which, when interpreted
  69. >under certain conditions in certain environments, will make a possibly
  70. >evolved copy of itself. This is called `replication' and the copy
  71. >retains at least the capability to recursively replicate further."
  72.  
  73. This still does not include the charactistic that is, to me, the
  74. distinguishing characteristic between virii and worms.  That is
  75. that virii host themselves within other programs (a hard disk boot 
  76. sector program IS a program, even though it is not a "program file"), 
  77. altering their behavior, while worms merely propogate themselves 
  78. from system to system taking advantage of whatever mechanism the
  79. system provides.
  80.  
  81. By "merely propogate themselves" I am ignoring any potential
  82. side effects of the worm or virus, ranging from vandalism (trashing 
  83. files and hard disk sector indexes) to "useful worms" such as
  84. a (hypothetical) network file or e-mail address finder...  The
  85. "intelligent assistant" that (Apple? Microsoft?) proposed a while
  86. ago...
  87.  
  88.         -Richard Hartman
  89.         hartman@ulogic.COM
  90.  
  91. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  92. "Nobody has ever had a sexual fantasy about being tied
  93.  to a bed and ravished by somebody dressed as a liberal."    -P.J. O'Rourke
  94.  
  95. ------------------------------
  96.  
  97. Date:    Wed, 17 Feb 93 14:39:12 -0500
  98. From:    (Cameron D. Bunch) <rth1cdb@rth10.med.navy.mil>
  99. Subject: What kind of people make viruses?
  100.  
  101. I am trying to find information on whatever might be known about the
  102. personality profile of the 'typical' virus author.  Although there may
  103. not be much available in this area I would appreciate any references
  104. to either studies (if such exist) or case histories which would shed
  105. some light on what kind of person creates and releases viruses, what
  106. kinds of motivations are involved.  Cases known to readers of this list
  107. but not necessarily recorded else where would be of interest also.
  108. Material available via ftp would be of greatest interest as I do not
  109. have access to a university library.  Direct e-mail responses would
  110. probably be most appropriate.  I would be glad to summarize if there is
  111. interest.
  112.  
  113. - ----------------------------------------------------------------------
  114. Cameron D. Bunch
  115. Head, Management Information Systems Dept.
  116. U.S. Naval Hospital, Rota Spain
  117.  
  118. Internet:  rth1cdb@rota-bumed.navy.mil
  119.            cbunch@rota-measure.navy.mil
  120. DSN:       727-3672
  121. COMM:      +34-56-823672
  122.  
  123.  
  124. ------------------------------
  125.  
  126. Date:    Wed, 17 Feb 93 14:39:41 -0500
  127. From:    Jim O'Shea <jimo@sun.computing.manchester-metropolitan-university.ac.u
  128.       k>
  129. Subject: Virus detection by code inspection
  130.  
  131. A question for the virus experts.
  132.  
  133. Could you recognise that a file had been infected by a virus purely by
  134. inspecting a disassembled listing?  I do mean any virus, including one
  135. you might not have met before. I accept it might not be possible to be
  136. specific but answers like "Yes, given unlimited time."  or " Seventy
  137. percent probability of a correct answer after spending 6 hours on
  138. inspection" will be useful.  I am interested in applying AI to virus
  139. detection and I would like to know how effective "Natural"
  140. intelligence is first.
  141.  
  142. Jim O'Shea ( the Manchester Metropolitan University)
  143.  
  144. ------------------------------
  145.  
  146. Date:    18 Feb 93 09:53:24 +0000
  147. From:    phys169@csc.canterbury.ac.nz
  148. Subject: Re: Virus education
  149.  
  150. CHIP@BDSO.Prime.COM (Chip Seymour) writes:
  151. > I couldn't agree with Mr. Peters more, but I find that I am the one in
  152. > need of the education.
  153.  
  154. For PC's, the basic information you need is contained in Ralf Brown's
  155. interrupt list (plus various other lists of "inside" DOS information,
  156. like memory maps and BIOS listings).  The most I can say, without
  157. giving ideas to virus writers, would be...
  158.  
  159. (1) viruses have to modify something that may eventually be executed
  160. on another computer, such as a diskette's boot sector, a program's
  161. code, a program "fork" or whatever. You can detect a virus when it
  162. does this, via hardware or software (hardware is best), but they are
  163. sometimes changed for valid reasons, and false-alarms become annoying.
  164.  
  165. (2) viruses like to (but don't really need to) intercept the system's
  166. code once they are running so they can change programs or boot sectors
  167. or whatever that they come in contact with.  If they don't do that,
  168. they'd just modify the disks or files they see when they start up -
  169. usually making them more obvious to spot (by the longer time the
  170. computer takes then) and spread slower.  Virus detectors can look for
  171. viruses staying in memory, because available memory is reduced,
  172. interrupts are changed, or important bytes in system code get changed
  173. that should never be modified.
  174.  
  175. (3) Viruses also like to stay in memory to modify the way the system
  176. reports things that might give a clue to its presence, e.g.
  177. intercepting PC interrupt 13h to read the boot sector, and returning
  178. the original sector instead of the infected one. On the face of it,
  179. this seems to make viruses harder to detect, but a good virus detector
  180. can notice it is happening and by-pass it to see the real infection,
  181. or simply report software is doing something that only viruses tend to
  182. do. Personally, I like viruses doing this, since many "good guy"
  183. programs do things similar to (2) - the more unlike disk caches, etc a
  184. virus acts the better for detection in the long run.
  185.  
  186. (4) There is basically a race between viruses and anti-virus software;
  187. whoever gets control of the system first has enormous power over
  188. stopping what comes after it - although it could waste a lot of
  189. computer power doing so.  Viruses have the disadvantage that changes
  190. can be detected if you *know* what the various vectors & system
  191. routines should look like, either by running on a clean system and
  192. thereafter looking for differences, or by knowing where standard
  193. BIOSes (or whatever for non-PC's) store their important routines. The
  194. latter is becoming less relevant, with strange disk controllers and
  195. the ability of 386's to put RAM anywhere and make it look like ROM.
  196. But then it is very difficult for viruses to use the 386 to do this as
  197. it will probably conflict with the EMM386 running, and make the virus
  198. very obvious too early.
  199.  
  200. But you don't need to know a lot about how the various viruses work -
  201. the best system of all is hardware that rings alarm bells when
  202. something out of the ordinary happens - writing to an area that should
  203. be sacra sant, or a boot sector containing suspicious code.  If you
  204. know how your system normally behaves, and spot differences, you can
  205. detect new viruses, and be able to trace whatever disk or program
  206. caused the alarm to its source immediately, rather than a week later
  207. when a scan of the disk is made and the source long forgotten.
  208.  
  209. Hope this helps,
  210. Mark Aitchison, University of Canterbury, New Zealand.
  211.  
  212. ------------------------------
  213.  
  214. Date:    Thu, 18 Feb 93 13:56:08 -0500
  215. From:    Doug <JDG111@PSUVM.PSU.EDU>
  216. Subject: YOUR opinions on virus legality needed!
  217.  
  218. Greetings....
  219.  
  220.   Some of you may read the infamous 40-Hex Virus magazine, published
  221.   by us. If so, we'd like your opinions for a survery we're doing.
  222.   The results of this survey will be published in 40-hex #10.
  223.  
  224.   Here are the survey questions.  Please answer them, and respond via
  225.   email to me.  You may respond with simple Yes or No answers, or you
  226.   may be as wordy as you want.  Please note - ANY response given might
  227.   be published in 40-hex magazine.  Now, the questions:
  228.  
  229.   1) Should it be Federally illegal to write a computer virus?
  230.  
  231.   2) Should it be Federally illegal to distribute computer viruses,
  232.      to KNOWING individuals (ie on "virus" boards)? (This does NOT
  233.      mean infecting another person with a virus - it means giving
  234.      them a copy of a virus, and making sure they KNOW it is a virus)
  235.  
  236.   3) If executable virus code is illegal, then should the SOURCE code
  237.      to the viruses be illegal to copy, sell, or other wise distribute?
  238.  
  239.   Please mail me with YOUR opinions to the above, and feel free to
  240.   explain your views, or present other opinions you may have.  We are
  241.   attempting to get a general idea as to the thoughts of people,
  242.   therefore we are posting this to COMP.VIRUS, and ALT.SECURITY, and
  243.   any other appropriate newsgroups.
  244.  
  245.   Please note - we are NOT interested in the legallity of SPREADING
  246.   virus code by infection - that IS already illegal.  We are also not
  247.   interested in the ethic issues of viruses.  We want your opinions as
  248.   to what should be OUTLAWED, and what should be LEGAL.  Of course, any
  249.   other opinions you may wish to add are welcome.
  250.  
  251.                      Thanks for your time and consideration..
  252.  
  253.                              --JDG111@PSUVM.PSU.EDU
  254.  
  255.  
  256.  
  257.  
  258. ------------------------------
  259.  
  260. Date:    Thu, 18 Feb 93 22:41:46 +0000
  261. From:    ped@well.sf.ca.us (Philip Elmer-DeWitt)
  262. Subject: Re: TIME Magazine on "Cyperpunk": How Not to Define a "Worm"
  263.  
  264. cmcurtin@bluemoon.use.com (Matthew Curtin) writes:
  265.  
  266. >xrjdm@calvin.gsfc.nasa.gov (Joseph D. McMahon) writes:
  267.  
  268. >> In last week's TIME magazine (with the "Cyberpunk" lead article), RTM's
  269. >> worm is is described as "not a virus, but a worm, since the damage was
  270. >> unintentional". 
  271. >> 
  272. >> This is the most singular lack of grasp of the subject I have seen in
  273. >> a long time. 
  274.  
  275. >There were quite a few people posting on alt.folklore.computers about how 
  276. >many silly errors like that there were. I'd be interested in seeing people 
  277. >post their gripes about the article, so that I coulds summarize everything 
  278. >and write a letter to TIME's editor...
  279.  
  280. Not to defend the bogus worm definition, but it was taken straight from
  281. Ed Krol's "Whole Internet Catalog."
  282.  
  283. Please do write your letter to the editor. The mail on this story was pitiful.
  284.  
  285. ------------------------------
  286.  
  287. Date:    Wed, 17 Feb 93 18:36:42 +0000
  288. From:    pinman@magnus.acs.ohio-state.edu (Patricia C Inman)
  289. Subject: Uruguay on PS/2 Ref disk (PC)
  290.  
  291. Fprot 2.06 reports:  command.com "Infection: Uruguay" on all PS/2 
  292. Model 70/80 Reference Disks Version 1.06.  Version 1.03 of the Ref 
  293. Disk reports clean.  CPAV is current and reports nothing.
  294.  
  295. I recently went through a scare and collected all disks in the
  296. facility.  This is all I have left to cleanup.  Is this "normal"?
  297.  
  298. Thanks,
  299. - -Patty Inman      pinman+@osu.edu
  300.  MUCIA            614/291-9646
  301.  
  302. ------------------------------
  303.  
  304. Date:    17 Feb 93 17:21:11 -0600
  305. From:    acrosby@uafhp.uark.edu (Albert Crosby)
  306. Subject: 1757 virus (PC)
  307.  
  308. Today I found a variant of the 1575 'Green Caterpillar Virus' that was not
  309. detected by Scan v100.  It was detected by VIRX 2.6, and detected/removed by
  310. F-PROT, fortunately.  This variant never displayed the 'Green Caterpillar'
  311. described in F-PROT, but did take up _all_ of the UMB memory on some of the
  312. infected computers.
  313.  
  314. Just another point in favor of keeping several scanning tools available...
  315.  
  316. Albert
  317. - --
  318. Albert Crosby          | There are actually THREE things certain in this life:
  319. acrosby@uafhp.uark.edu |
  320.  or AL.CROSBY on GENIE |   Death, Taxes, and Parking Tickets.
  321. 1 501 575 4452         |     
  322. Microcomputer and Network Support-UA College of Agriculture and Home Economics
  323.  
  324. ------------------------------
  325.  
  326. Date:    Wed, 17 Feb 93 18:41:24 -0500
  327. From:    peprbv@cfa0.harvard.edu (Bob Babcock)
  328. Subject: Re: Scanning memory (PC)
  329.  
  330. >Yup. This is called ghost positive. It can be easily avoided by the
  331. >producer of the scanner with a little bit of intelligent programming.
  332. >I suggest that people REFUSE to use anti-virus software that is so
  333. >stupid.
  334.  
  335. Isn't it better to be conservative and look everywhere in memory for active
  336. viruses?  I'd much rather see a false alarm than have something be missed
  337. because a scanner was wrong about where viruses could lurk.  Also, this sort
  338. of false alarm can only arise if you have scanned an infected floppy.  If a
  339. user has an infected floppy, and doesn't know enough about viruses to
  340. understand the ghosting problem, they should consider getting expert help.
  341.  
  342.  
  343. ------------------------------
  344.  
  345. Date:    Thu, 18 Feb 93 00:01:41 +0000
  346. From:    imeslsl@trex.oscs.montana.edu (LEPRICAN~~~)
  347. Subject: Michelangelo or STONED? (PC)
  348.  
  349. The AUTOCAD lab at Montana State University has recently contracted
  350. a nasty virus, which we can't exactly identify.
  351. The older anti-virus programs we had would only see it some of the
  352. time.  We tried McAfee v100, which would recognise the virus, but
  353. would not remove it from hard drives.  It appears to be [Mich] when
  354. it is on a drive, but when it loads itself into memory, McAfee says
  355. it's [STONED].
  356. It seems to be easily removed from floppies, but the virus infects
  357. the partition table of hard drives, where McAfee cannot remove it.
  358. Reformatting it from a write-protected floppy didn't remove it, either.
  359. Does anyone have any suggestions on how to combat this virus?
  360. thanks,
  361.     Leprican~~~
  362.  
  363. ------------------------------
  364.  
  365. Date:    18 Feb 93 00:19:39 +0000
  366. From:    heathh@cco.caltech.edu (Heath Ian Hunnicutt)
  367. Subject: Possible new Virus found. HELP! (PC)
  368.  
  369. Hello,    
  370.     I've recently had the misfortune of experiencing what I believe
  371. was a virus infection.  Unfortunately, ver100 of McAfee's SCAN cannot
  372. identify the virus involved.  I have also tried older versions of Norton
  373. and Central Point Anti-Virus, to no avail.
  374.  
  375.     Here's what happenned:  At about 1am on the 15th, Windows crashed
  376. with a Severe Disk Error screen.  I rebooted into DOS, and found that 
  377. I would get many, many "Sector not Found" errors when I would try to
  378. access anything on my C: drive.  (I also have a D: drive.)  I tried
  379. to run Norton Disk Doctor, but it crashed.  Thinking that my FAT was
  380. messed up on the C: drive, I tried to switch to the D: drive, where
  381. I at least had some minimal disk-doctor type software, along with the
  382. unformat command.  (I was think of using unformat to restore my old FATs,
  383. and just taking a loss on work done that day...)
  384.  
  385.     Here comes the virus part:
  386.  
  387. C:\DOS>D:        (I typed this)
  388. Try that again and you'll die.    (Was the response, as near as I can recall.)
  389.  
  390. C:\DOS>DIR D:
  391. Try that again and you'll die.
  392.  
  393. I powered off the machine.
  394.  
  395. At this point, my partition table and boot records had been screwed up.
  396. I managed to fix the drive's woes using unformat, and my file system is
  397. now Ok.  However, SCAN cannot find a virus at all on my drive C:.  (I have
  398. removed drive D:, since it is very important to me, and I want to have this
  399. problem understood before I access that drive again.)
  400.  
  401.     I have even scanned every file that was installed in the last
  402. month or so for the word "die".  No joy -- I assume it must be encrypted.
  403. The message was along the lines of the one given above.  The only words
  404. that I am sure appear in it are: "[Tt]ry that again and you* die"  There
  405. may have been a period after the "die"  
  406.  
  407.     So, has anybody heard of a virus that does anything like this?
  408. I cannot believe that this is anything but an infection, since the 
  409. "error message" seems so much like what a virus-writer would do.
  410.  
  411.     Thanks for any help.
  412.  
  413. Heath
  414.  
  415. - -- 
  416. - --
  417. >From the Home for Amnesiac Computer Scientists....
  418.   heathh@cco.caltech.edu
  419.  
  420.  
  421. ------------------------------
  422.  
  423. Date:    18 Feb 93 11:24:18 +0000
  424. From:    phys169@csc.canterbury.ac.nz
  425. Subject: Re: New way of opening files??? (PC)
  426.  
  427. Amir_Netiv@f120.n9721.z9.virnet.bad.se (Amir Netiv) writes:
  428. >  >> More then that: A product like the one you described will only work on 38
  429. 6,
  430. >  >> or higher, in protected mode....
  431. >>  > Well, there are several ways to spot writing to the disk port directly.
  432. >  > Obviously, software-only methods would be limited in speed...
  433. > Isn't that what I said?...
  434.  
  435. Well, you don't need a 386 with protected mode, but it is nice of
  436. course. You can emulate or trace instructions, plus a few other sneaky
  437. hardware-dependent methods which I probably shouldn't mention.
  438.  
  439. > What you suggest is a bit too expensive for a user to get...
  440.  
  441. That's true.  I'm an advocate of relatively simple, cheap methods
  442. being used by virtually all computer users (I talked a lot last year
  443. about what could be built into DOS and BIOS, for example).  But I have
  444. to acknowledge that the level of protection you need to make a
  445. standard Mac or PC safe against the kinds of viruses that *could* be
  446. made is well beyond what average users can stand. Not just cost, but
  447. inconvenience in responses needed from users, time taken to scan, and
  448. the need for serious, consistent security considerations.  The whole
  449. beauty of the "openness" of the PC to getting at the works is also its
  450. greatest weakness. Although a lot can be done to tighten up the system
  451. (there are really stupid loopholes at the moment that could be fixed
  452. without bumping up the cost more than a few dollars), the whole
  453. popularity and philosophy of the PC (and Mac) makes them prone to
  454. virus writers. I really don't think water-tight security is what
  455. average users should be heading for (organisations, yes!), rather it
  456. is important to discourage virus writers.
  457.  
  458. >  > The big problem with viruses on PC's, at least, at the
  459. >  > moment is that there is
  460. >  > a large fuzzy area filled with programs (like Norton's
  461. >  > DS and sel...
  462. > I wish it were the only problem.
  463.  
  464. I think everybody realises the problems in relying on old fashioned
  465. fixed string scanners.  But going on from there is difficult.
  466. Heuristics for boot sector viruses are reasonably good (I could talk
  467. at length about this - email me if you want to chat about it), but
  468. file infectors are a nuisance.  If I said that using the "call next
  469. instruction" sequence was a pretty good detector of suspicious
  470. programs, all the virus writers would go out and change their code to
  471. "call next-plus-one instruction".  Similarly, anything that can be
  472. disassembled from present heuristic detectors can be used to the
  473. benefit of virus writers.  You could say that the fact that there are
  474. any viruses at all is the problem, but to really analyse what is
  475. stopping a truely good virus detector (not just 2nd
  476. generation/heuristics but 3rd generation), I think it would be the
  477. fact that so many "naughty" things that *should* identify viral
  478. activity have already been done in commercial software!
  479.  
  480. > Personally I prefer that they will just stop writing viruses, or better yet 
  481. > write usual ones that are easy to solve with generic methods like FDISK /MBR 
  482. > or SYS or...
  483. > and let the PC users work without fear. Are you among those that will 
  484. > sacrifice the user's benefit for an academic interest?
  485.  
  486. No, I wish they'd stop too, but that won't happen without effort -
  487. like making it so common to spot a new virus as soon as it gets on
  488. your system that the *source* of viruses can be tracked while the
  489. scent is warm. And stop giving them the glory of new virus names.
  490. Even before mutation engines, the rate of "new" viruses was alarming.
  491. The popularity of virus writing D-I-Y kits is a great nuisance, but at
  492. least it has delayed the next stage of virus developments.  I believe
  493. there are several more generations of virus detector left in the
  494. evolution process even for traditional "Personal" (insecure)
  495. computers. They would have to abandon looking for known viruses,
  496. unless you are interested in understanding what is there (which I, at
  497. least, am). To do better they have to distinguish between what is
  498. viral activity and what a common PC program might do.  If it is hard
  499. enough at the moment for a human to do that, think how hard it is for
  500. AI software.  I personally think there is reason to hope boot sector
  501. viruses can be eradicated - it is so obvious what you are supposed to
  502. have in a boot sector, and there's only 512 bytes to play with. But
  503. infected executables are difficult to tackle. I know of some "tricks"
  504. viruses tend to do, which makes the present generation of heuristics
  505. tick quite nicely.  But that won't last.  As virus writers and virus
  506. detectors play a game of cat and mouse, e.g. going to greater lengths
  507. to bypass DOS to open files to either infect, or to tell if they are
  508. infected, the code gets larger and less like conventional programs.
  509. That helps the average user - an infected file will grab a lot of
  510. extra disk space, and go slow, and it helps the 3rd generation of
  511. virus detector, simply because some virus writer who thinks he's
  512. clever is trying to bypass the 2nd generation of detector.  Those that
  513. get around the 1st generation of detector (string scanners) are
  514. difficult for humans to detect as well. That's why I take the radical
  515. stand of hoping virus writers will move onto the next generation
  516. (provided anti-virus writers are ready for them).
  517.  
  518. Mark Aitchison, Department of Physics & Astronomy, University of Canterbury, NZ
  519.  
  520. ------------------------------
  521.  
  522. Date:    Thu, 18 Feb 93 12:04:43 +0000
  523. From:    swesterback@tne01.tele.nokia.fi
  524. Subject: Minimal virus scan? (PC)
  525.  
  526. We have an automatic virus-scan (in autoexec.bat) on all computers
  527. here at work. As it slows down the boot process to much on some
  528. computers i am planning to scan only parts of the files instead of the
  529. whole disk.
  530.  
  531. My question now is if these assumptions are correct:
  532. - - viruses only infects:
  533.         *.EXE and *.COM -files that has been used when a virus is in memory
  534.         the boot sector
  535.         command.com
  536. - - it is enough to scan only memory, the boot sector and for example the 
  537.   following files:
  538.         command.com     smartdrv.exe    emm386.exe      keyb.com
  539.         win.com         win386.exe      lat.exe         redir.exe
  540.         
  541. Is that correct? If not please tell me why not! I can also think about
  542. varying the scanned directories from day to day.
  543.  
  544. Also is there really any need to scan DLL, DRV, OVL and SYS-files?
  545.  
  546. Sten
  547. ============================================================================
  548. Sten Westerback (BSc. electronics)          Telephone: +358+0 +5115891(work)
  549. X400      : c=fi, a=Elisa, p=Nokia Telecom, S=Westerback, G=Sten, (u=SWS)
  550. Internet  : Sten.Westerback@ntc.nokia.com   Time zone: EET (=GMT+3)
  551.  Test the utility at WSMR-SIMTEL20.Army.mil::pd1:<msdos.dirutl>swxd303d.zip
  552. ============================================================================
  553.  
  554. ------------------------------
  555.  
  556. Date:    Thu, 18 Feb 93 18:13:57 +0000
  557. From:    treeves@magnus.acs.ohio-state.edu (Terry)
  558. Subject: Re: windows virus (PC) - is WALDO one?
  559.  
  560. andywang@crown.berkeley.edu (Andrew Wang) writes:
  561. >chess@watson.ibm.com (David M. Chess) writes:
  562. >
  563. >We have been experiencing a problem with Windows that also may
  564. >be connected with a virus. Recently a couple machines have been
  565. >producing a "WALDO has caused a General Protection Fault" error,
  566. >and then crashing hard.
  567. ..
  568. >seriously. Here's some info: We run Word for Windows, Corel Draw, and Excel
  569.  
  570. I've seen his. Corel draw is sending the message. It's not a virus.  I
  571. think you need to update corel to make this go away.  Call them and
  572. ask - also tell them cute messages should be stoped or have an
  573. explanation attached!
  574.  
  575. ------------------------------
  576.  
  577. Date:    18 Feb 93 18:39:56 +0000
  578. From:    frisk@complex.is (Fridrik Skulason)
  579. Subject: Re: New Virus (PC)
  580.  
  581. ilfc826@vax2.concordia.ca (Tan Bui) writes:
  582.  
  583. >Well, from my point of view, the Whale virus is one of the better viruses
  584. >written by the virus authors.
  585.  
  586. Well, "better" only in the sense "more heavily armored" than other viruses.
  587. It has one flaw, however.  It doesn't work (well, most of the time, that is). 
  588.  
  589. - -frisk
  590. - -- 
  591. Fridrik Skulason      Frisk Software International     phone: +354-1-694749
  592. Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801
  593.  
  594. ------------------------------
  595.  
  596. Date:    18 Feb 93 19:23:23 +0000
  597. From:    frisk@complex.is (Fridrik Skulason)
  598. Subject: Re: Suggestion to the developers of resident scanners (PC)
  599.  
  600. bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
  601.  
  602. >Ah, yes, I forgot about that. Yes, the file should be scanned when
  603. >executed from a network drive too. BTW, one thing that Frisk really
  604. >*MUST* implement soon is an option to re-activate VirStop after the
  605. >network shell has been loaded...
  606.  
  607. Will be done in 2.08, or possibly earlier.
  608.  
  609. - -frisk
  610.  
  611. - -- 
  612. Fridrik Skulason      Frisk Software International     phone: +354-1-694749
  613. Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801
  614.  
  615. ------------------------------
  616.  
  617. Date:    Fri, 19 Feb 93 01:23:08 +0000
  618. From:    mdewaele@TrentU.CA (martin dewaele)
  619. Subject: Re: MtE Infected... (PC)
  620.  
  621. >However, what bothers me is that you are talking about a single file
  622. >(if I've understood you correctly). In this case, it is likely to be a
  623. >false positive alarm (for more information about that, please read the
  624. >FAQ). Thus, you are advised to try a couple of other scanners that are
  625. >able to detect MtE-based viruses reliably. Two general-purpose
  626. >scanners (shareware) that can do that are SCAN 100 and F-Prot 2.07. An
  627. >MtE-only detector, called CatchMtE is freeware and is available from
  628. >most anti-virus sites, including ours. If no other scanners reports
  629. >the file as infected, it is almost certainly a false positive. In this
  630. >case you are advised to contact your local Symantec tech support.
  631.  
  632. Yes you are correct, there are only three files on my system which NAV 
  633. states are infected.  In the last week I have tried other virus scanners, 
  634. such as SCAN99.  The result was that the system did not contain the virus, 
  635. so I am content that it is just a false positive.
  636.  
  637. Martin
  638.  
  639. ------------------------------
  640.  
  641. Date:    Thu, 18 Feb 93 21:35:11 -0500
  642. From:    HAYES@urvax.urich.edu
  643. Subject: CLU-011.ZIP (PC)
  644.  
  645. Hi fellows.
  646.  
  647. just received and made available for FTP processing CLU-011.ZIP.  This
  648. file contains a collection of utilities created by Andy Balog for use
  649. on his site.  Following is a short description written by Andy:
  650.  
  651.     These programs were written especially for use in batch files and for
  652.     use in campus computer labs; I think they can be a useful addition to
  653.     other software tools.
  654.  
  655. These programs are copyrighted freeware.
  656.  
  657. Please address questions and/or comments directly to Andy at one of the
  658. following addresses:
  659.  
  660.     Internet:                     |    U.S. Mail:
  661.     abalog@babbage.ecs.csus.edu   |    Andy Balog
  662.                                   |    P.O. Box 277341
  663.                                   |    Sacrament, CA  95827-7341
  664.  
  665. Thanks for the programs, Andy!
  666.  
  667. - ----------
  668. Site:       urvax.urich.edu,  [141.166.36.6]    (VAX/VMS using Multinet)
  669. Directory:  [anonymous.msdos.antivirus]
  670.  
  671. FTP to urvax.urich.edu with username anonymous and your email address
  672. as password.  You are in the [anonymous] directory when you connect.
  673. cd msdos.antivirus, and remember to use binary mode for the zip files.
  674. - ----------
  675.  
  676. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  677. Claude Bersano-Hayes     HAYES @ URVAX                 (Vanilla BITNET)
  678. University of Richmond   hayes@urvax.urich.edu     (Bitnet or Internet)
  679. Richmond, VA  23173
  680.  
  681.  
  682.  
  683. ------------------------------
  684.  
  685. Date:    Thu, 18 Feb 93 20:30:43 -0600
  686. From:    ST29701@vm.cc.latech.edu
  687. Subject: SCAN 101 (PC)
  688.  
  689. Anyone notice how slow SCAN 101 has become??  I like and use Scan but it
  690. has become extreamly slow.  I know people that at onetime put it in their
  691. AUTOEXEC.BAT file with /FAST /CF /CERTIFY parrameters.  Now SCAN is so
  692. slow  they have to break out unless they turn on the computer and go out
  693. for coffee.  This is under the fast mode.  Remember SCAN without /FAST
  694. is more reliable and /A is evem more reliable (/A looks at all files and
  695. more of the EXE and COM file's).  Thes parrameters make SCAN even SLOWER
  696.  
  697. Alan
  698.  
  699.  
  700.  
  701.  
  702. ------------------------------
  703.  
  704. Date:    Fri, 19 Feb 93 10:45:13 +0000
  705. From:    chowes@sfu.ca (Charles Howes)
  706. Subject: FDISK buggy? (PC)
  707.  
  708. Hi.  I recently had a hard disk failure.  A single 135Meg partition.
  709.  
  710. (I'd really like to find a program that would tell me what was corrupted..
  711. NDD wouldn't read it, nor NU, FORMAT, SYS, etc.  But I digress.)
  712.  
  713. So, after recovering the data, I used fdisk to try to create several
  714. smaller partitions.
  715.  
  716. Problem was, the #@#$ program refused to let me create a second partition!
  717. I either had to create a 135 meg partition, or leave part of my disk
  718. unused!
  719.  
  720. Is this a bug in fdisk, or what?
  721.  
  722. (Hardware notes: 135meg IDE drive, 80286 machine, no viruses, DOS 5.0)
  723. (Actually, scan99 refused to admit the existence of the drive, so that was
  724. kinda moot.)
  725.  
  726. - -------ON ANOTHER TANGENT------
  727. Has anyone written a program that will allow you to create a new
  728. partition table sector from scratch, and if the numbers you give
  729. correspond to the previous partition table's numbers, *poof*, you have
  730. a working hard disk again?  (Fdisk /mbr didn't work in this case.)  And
  731. then do the same thing for the boot sector if called for?
  732.  
  733. I actually found NDD 6.0 to be impotent with regards to this.  NDD 4.5,
  734. too.  NDD detects a problem, asks if you want it fixed, then fails to
  735. fix it.
  736.  
  737. ------------------------------
  738.  
  739. End of VIRUS-L Digest [Volume 6 Issue 30]
  740. *****************************************
  741.  
  742.