home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / v / vl6-032.zip / VL6-032.TXT < prev   
Internet Message Format  |  1993-02-24  |  52KB
  1. Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5)
  2.     id AA26643; Wed, 24 Feb 1993 19:57:06 +0100
  3. Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA16951
  4.   (5.67a/IDA-1.5); Wed, 24 Feb 1993 09:09:57 -0500
  5. Date: Wed, 24 Feb 1993 09:09:57 -0500
  6. Message-Id: <9302231436.AA26498@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 #32
  16. Status: R
  17.  
  18. VIRUS-L Digest   Tuesday, 23 Feb 1993    Volume 6 : Issue 32
  19.  
  20. Today's Topics:
  21.  
  22. Virus Survey Results
  23. Re: How to measure polymorphism
  24. re: Tokyo Virus in NETCB or a false positive? (PC)
  25. Re: Scanning memory (PC)
  26. Rebuilding Partition Tables (PC)
  27. PC Magazine reviews virus scanners (PC)
  28. Michelangelo detect/removal instructions (PC)
  29. Re: Uruguay on PS/2 Ref disk (PC)
  30. Re: Virstop 2.07 & Lanworkplace = Windows Hangs. (PC)
  31. Viruses in March (PC)
  32. Identification (PC)
  33. Uruguay virus (PC)
  34. Virus Scanner for BBS (PC)
  35. Re: F-prot/FSP/bootsum problem. Help! (PC)
  36. re:waldo (PC)
  37. Re: FORM (again!) (PC)
  38. Re: Minimal virus scan? (PC)
  39. I-M141.ZIP - Integrity Master (PC)
  40. New files on risc (PC)
  41. Michelangelo discovery and naming (CVP)
  42. Re: Censorship
  43.  
  44. VIRUS-L is a moderated, digested mail forum for discussing computer
  45. virus issues; comp.virus is a non-digested Usenet counterpart.
  46. Discussions are not limited to any one hardware/software platform -
  47. diversity is welcomed.  Contributions should be relevant, concise,
  48. polite, etc.  (The complete set of posting guidelines is available by
  49. FTP on cert.org or upon request.) Please sign submissions with your
  50. real name.  Send contributions to VIRUS-L@LEHIGH.EDU.  Information on
  51. accessing anti-virus, documentation, and back-issue archives is
  52. distributed periodically on the list.  A FAQ (Frequently Asked
  53. Questions) document and all of the back-issues are available by
  54. anonymous FTP on cert.org (192.88.209.5).  Administrative mail
  55. (comments, suggestions, and so forth) should be sent to me at:
  56. <krvw@FIRST.ORG>.
  57.  
  58.    Ken van Wyk, krvw@first.org
  59.  
  60. ----------------------------------------------------------------------
  61.  
  62. Date:    20 Feb 93 03:35:43 +0000
  63. From:    jay@info.umd.edu (Jay Elvove)
  64. Subject: Virus Survey Results
  65.  
  66.  
  67. In November, I distributed a questionnaire to this group on the subject
  68. of computer viruses.  10 of you responded, and to those of you, I take
  69. this opportunity to thank you once again.  So many respondents
  70. requested that I share my findings with them, that I thought I'd simply
  71. send them to this list.  I am including the questionnaire itself for
  72. reference, since the culled results are fairly terse.  I have UUENCODED
  73. the results because, although it is straight text, the table is wider
  74. than 80 characters, which may be too much for some mailers.  I hope the
  75. UUENCODING causes no headaches for anyone.  The program is available on
  76. (nearly) all UNIX systems and on a great many PCs as well.  A PC
  77. version is available via anonymous FTP from info.umd.edu in the file
  78. /info/Computers/PC/Unix/uuexe520.zip.
  79.  
  80.  
  81. Jay Elvove                            email:     jay@info.umd.edu
  82. Academic Software
  83. Computer Science Center
  84. University of Maryland
  85.  
  86.                           -------------------
  87.  
  88.                          Virus Questionnaire
  89.  
  90. 1.   How many PCs do you use or oversee?
  91.  
  92.      1          2-4       5-9        10-19      20-49       50+
  93.  
  94. 2.   Which of the following best describes your PC computing environment?
  95.  
  96.      standalone   open lab   restricted lab   departmental LAN   combination
  97.  
  98. 3.   Approximately what percent of the above computers are used by each of
  99.      the following members of your organization?
  100.  
  101.      faculty      staff            grad students      undergraduates     other
  102.      clerical     technical        administrative     other       
  103.  
  104. 4.   In your opinion, how serious a threat do viruses pose to your computing
  105.      environment?
  106.  
  107.      extreme         very       moderate       little     none
  108.  
  109. 5.   Within the last six months, how many incidents of computer viruses have
  110.      you seen?
  111.  
  112.      1     2-4       5-9        10-19       20-49       50+       none
  113.  
  114.      If the answer to the previous question was one or more, please answer
  115.      the following four question:
  116.  
  117.      (a)   What virus(es) have you seen?
  118.  
  119.  
  120.  
  121.      (b)   What was the extent of the damage, if any?
  122.  
  123.  
  124.  
  125.      (c)   How long did it take to remove or otherwise recover from the
  126.            virus(es)
  127.  
  128.  
  129.  
  130.      (d)   Which of the following groups within your organization has
  131.            been the source of the greatest number of viruses?
  132.  
  133.      faculty      staff            grad students      undergraduates     other
  134.      clerical     technical        administrative     other       
  135.  
  136. 6.   Whether or not your computer environment has been exposed to viruses in
  137.      the past, in your opinion, which of the following groups is most likely
  138.      to be a source of viruses within your environment today?
  139.  
  140.      faculty      staff            grad students      undergraduates     other
  141.      clerical     technical        administrative     other       
  142.            
  143. 7.   In your opinion, how are computer viruses most likely to be transmitted?
  144.  
  145.  
  146.  
  147. 8.   Which regimen most closely approximates how often you scan your PC(s)
  148.      for viruses?
  149.  
  150.      boot-up       daily      weekly       monthly       rarely       never
  151.  
  152. 9.   How many of your PCs use TSR programs to detect viruses?
  153.  
  154.      1         2-4       5-9        10-19       20-49        50+     none
  155.  
  156. 10.  How often do you back up your files?
  157.  
  158.      daily      weekly          monthly        rarely          never
  159.  
  160. 11.  What procedures are in place in your environment to address the
  161.      threat of viruses (i.e., regular scanning, using TSR programs,
  162.      backing up files, user education, official policies, etc.)?  Please
  163.      list specific anti-virus products in use.
  164.  
  165.  
  166.  
  167.  
  168.  
  169. 12.  Which category best describes your role within your organization?
  170.  
  171.      faculty      staff            grad students      undergraduates     other
  172.      clerical     technical        administrative     other       
  173.  
  174.  
  175. - ---cut here------cut here------cut here------cut here------cut here---
  176.  
  177. begin 644 vresults.txt
  178. M("LM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
  179. M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
  180. M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2L*('P@
  181. M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
  182. M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
  183. M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @('P*('P@(" @
  184. M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @5FER=7,@4W5R
  185. M=F5Y(%)E<W5L=',@(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
  186. M(" @(" @(" @(" @(" @(" @(" @(" @("!43U1!3" @('P*('P@(" @(" @
  187. M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
  188. M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
  189. M(" @(" @(" @(" @(" @(" @(" @4D534$].4T53('P*("LM+2TM+2TM+2TM
  190. M+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM
  191. M+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM
  192. M+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2L*('P@(",@;V8@4$-S(" @
  193. M(" @?" @(" @,2 @(" @?" @(" R+30@(" @?" @(" U+3D@(" @('P@(" Q
  194. M,"TQ.2 @(" @?" @(#(P+30Y(" @('P@(" @-3 K(" @('P@("!N;VYE(" @
  195. M('P@(" @;B]A(" @('P@(" @(" @(" @('P*('PQ(" @(" @(" @(" @(" @
  196. M?" @(" @(" @(# @?" @(" @(" @(#$@?" @(" @(" @(# @('P@(" @(" @
  197. M(" Q(" @?" @(" @(" @,3$@('P@(" @(" @(#,Y('P@(" @(" @(" P('P@
  198. M(" @(" @(" P('P@(" @(" @(#4R('P*("LM+2TM+2TM+2TM+2TM+2TM*RTM
  199. M+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM
  200. M+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM
  201. M+2TM+2TM+2LM+2TM+2TM+2TM+2L*('Q00R!E;G9I<F]N;65N=" @?"!S;VQI
  202. M=&%R>2 @?"!O<&5N(&QA8B @?"!R97-T<B!L86(@('P@9&5P="!,04X@(" @
  203. M?&-O;6)I;F%T:6]N('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @
  204. M(" @('P@(" @(" @(" @('P*('PR(" @(" @(" @(" @(" @?" @(" @(" @
  205. M(# @?" @(" @(" @(#4@?" @(" @(" @(#$@('P@(" @(" @(#$W(" @?" @
  206. M(" @(" @,S @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" P
  207. M('P@(" @(" @(#4S('P*("LM+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM
  208. M*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM+2TM
  209. M+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM
  210. M+2TM+2TM+2TM+2L*('Q5<V%G92!3=&%T<R @(" @?" @9F%C=6QT>2 @?" @
  211. M('-T869F(" @?" @(&=R860@(" @('P@("!U;F1E<B @(" @?" @(&]T:&5R
  212. M(" @('P@;F]N+6%C860@('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @
  213. M(" @(" @('P*('PS(" @(" @(" @(" @(" @?" @(" @(#$S+C4E?" @(" @
  214. M(#(Y+C$E?" @(" @(" V+C8E('P@(" @(" Q-RXS)2 @?" @(" @(" Q+C,E
  215. M('P@(" @(" R,BXW)7P@(" @(" @(" @('P@(" @(" @.2XT)7P@(" @(#$P
  216. M,"XP)7P*("LM+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM
  217. M+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM
  218. M+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM
  219. M+2L*('Q097)C96EV960@5&AR96%T?" @97AT<F5M92 @?" @('9E<GD@(" @
  220. M?"!M;V1E<F%T92 @('P@(&QI='1L92 @(" @?" @(&YO;F4@(" @('P@(" @
  221. M(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P*
  222. M('PT(" @(" @(" @(" @(" @?" @(" @(" @(#(@?" @(" @(" @(#8@?" @
  223. M(" @(" @,S$@('P@(" @(" @(#$S(" @?" @(" @(" @(# @('P@(" @(" @
  224. M(" @('P@(" @(" @(" @('P@(" @(" @(" Q('P@(" @(" @(#4S('P*("LM
  225. M+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM
  226. M+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM
  227. M+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2L*('PC(&]F
  228. M(%9I<G5S97,@(" @?" @(" @,2 @(" @?" @(" R+30@(" @?" @(" U+3D@
  229. M(" @('P@(" Q,"TQ.2 @(" @?" @(#(P+30Y(" @('P@(" @-3 K(" @('P@
  230. M(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P*('PU(" @(" @
  231. M(" @(" @(" @?" @(" @(" @(#,@?" @(" @(" @,3@@?" @(" @(" @(#4@
  232. M('P@(" @(" @(" W(" @?" @(" @(" @(#4@('P@(" @(" @(" Q('P@(" @
  233. M(" @(#$T('P@(" @(" @(" P('P@(" @(" @(#4S('P*("LM+2TM+2TM+2TM
  234. M+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM
  235. M+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM
  236. M+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2L*('Q7:&%T(%9I<G5S97,@
  237. M(" @?" @4W1O;F5D(" @?"!*97)U<V%L96T@?$UI8VAE;&%N9V5L;WQ986YK
  238. M964@1&]O9&QE?" @($9O<FT@(" @('P@("!O=&AE<B @('P@(" @(" @(" @
  239. M('P@(" @(" @(" @('P@(" @(" @(" @('P*('PU82 @(" @(" @(" @(" @
  240. M?" @(" @(" @,S$@?" @(" @(" @(#@@?" @(" @(" @,3(@('P@(" @(" @
  241. M(" S(" @?" @(" @(" @(#,@('P@(" @(" @(#(T('P@(" @(" @(" @('P@
  242. M(" @(" @(" Q('P@(" @(" @(#@R('P*('P@("!$86UA9V4@(" @(" @?" @
  243. M(&9I;&5S(" @?"!D:7-K971T97,@?" @("!&050@(" @('P@("!D;W=N(" @
  244. M(" @?" @;&ET=&QE(" @('P@("!O=&AE<B @('P@(" @(" @(" @('P@(" @
  245. M(" @(" @('P@(" @(" @(" @('P*('PU8B @(" @(" @(" @(" @?" @(" @
  246. M(" @(#@@?" @(" @(" @(#0@?" @(" @(" @(#0@('P@(" @(" @(" U(" @
  247. M?" @(" @(" @(#D@('P@(" @(" @(" S('P@(" @(" @(" Y('P@(" @(" @
  248. M(#$U('P@(" @(" @(#4W('P*('Q4:6UE('1O(%)E;6]V92 @?" @(" \/34@
  249. M(" @?" @(#8M,34@(" @?" @(#$V+3,P(" @('P@(" S,2TV," @(" @?" @
  250. M,2TT:')S(" @('P@(" ^-&AR<R @('P@(" @(" @(" @('P@(" @(" @(" @
  251. M('P@(" @(" @(" @('P*('PU8R @(" @(" @(" @(" @?" @(" @(" @(#@@
  252. M?" @(" @(" @(#8@?" @(" @(" @(#,@('P@(" @(" @(" S(" @?" @(" @
  253. M(" @(#4@('P@(" @(" @(" W('P@(" @(" @(" @('P@(" @(" @(#(Q('P@
  254. M(" @(" @(#4S('P*('Q'<F5A=&5S="!3;W5R8V4@?" @9F%C=6QT>2 @?" @
  255. M('-T869F(" @?" @(&=R860@(" @('P@("!U;F1E<B @(" @?" @(&]T:&5R
  256. M(" @('QD;VXG="!K;F]W('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @
  257. M(" @(" @('P*('PU9" @(" @(" @(" @(" @?" @(" @(" @(#4@?" @(" @
  258. M(" @(#D@?" @(" @(" @(#@@('P@(" @(" @(#$T(" @?" @(" @(" @(#@@
  259. M('P@(" @(" @(" T('P@(" @(" @(" @('P@(" @(" @(#$T('P@(" @(" @
  260. M(#8R('P*("LM+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM
  261. M+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM
  262. M+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM
  263. M+2L*('Q,:6ME;&EE<W0@4V]U<F-E?" @9F%C=6QT>2 @?" @('-T869F(" @
  264. M?" @(&=R860@(" @('P@("!U;F1E<B @(" @?" @(&]T:&5R(" @('QD;VXG
  265. M="!K;F]W('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P*
  266. M('PV(" @(" @(" @(" @(" @?" @(" @(" @(#0@?" @(" @(" @(#D@?" @
  267. M(" @(" @(#,@('P@(" @(" @(#$Y(" @?" @(" @(" @,34@('P@(" @(" @
  268. M(" Q('P@(" @(" @(" @('P@(" @(" @(" R('P@(" @(" @(#4S('P*("LM
  269. M+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM
  270. M+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM
  271. M+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2L*('Q4<F%N
  272. M<RX@365D:75M(" @?" @9FQO<'!Y(" @?" @;F5T+T944" @?" @("!"0E,@
  273. M(" @('P@("!O=&AE<B @(" @?" @(" @(" @(" @('P@(" @(" @(" @('P@
  274. M(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P*('PW(" @(" @
  275. M(" @(" @(" @?" @(" @(" @-#0@?" @(" @(" @(#0@?" @(" @(" @(#0@
  276. M('P@(" @(" @(" V(" @?" @(" @(" @(" @('P@(" @(" @(" @('P@(" @
  277. M(" @(" @('P@(" @(" @(" R('P@(" @(" @(#8P('P*("LM+2TM+2TM+2TM
  278. M+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM
  279. M+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM
  280. M+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2L*('Q38V%N;FEN9R!&<F5Q
  281. M+BYN?" @(&)O;W0@(" @?" @(&1A:6QY(" @?" @=V5E:VQY(" @;GP@(&UO
  282. M;G1H;'D@(" @?" @<F%R96QY(" @('P@("!N979E<B @('P@(" @(" @(" @
  283. M('P@(" @(" @(" @('P@(" @(" @(" @('P*('PX(" @(" @(" @(" @(" @
  284. M?" @(" @(" @,3<@?" @(" @(" @(#0@?" @(" @(" @,3$@('P@(" @(" @
  285. M(" W(" @?" @(" @(" @,3(@('P@(" @(" @(" Q('P@(" @(" @(" @('P@
  286. M(" @(" @(" Q('P@(" @(" @(#4S('P*("LM+2TM+2TM+2TM+2TM+2TM*RTM
  287. M+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM
  288. M+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM
  289. M+2TM+2TM+2LM+2TM+2TM+2TM+2L*('P@4$-S('<O5%-2<R @(" @?" @(" @
  290. M,2 @(" @?" @(" R+30@(" @?" @(" U+3D@(" @('P@(" Q,"TQ.2 @(" @
  291. M?" @(#(P+30Y(" @('P@(" @-3 K(" @('P@(" @(" @(" @('P@(" @(" @
  292. M(" @('P@(" @(" @(" @('P*('PY(" @(" @(" @(" @(" @?" @(" @(" @
  293. M(# @?" @(" @(" @,3,@?" @(" @(" @(#$@('P@(" @(" @(" R(" @?" @
  294. M(" @(" @(#8@('P@(" @(" @(#$U('P@(" @(" @(#$U('P@(" @(" @(" Q
  295. M('P@(" @(" @(#4S('P*("LM+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM
  296. M*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM+2TM
  297. M+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM
  298. M+2TM+2TM+2TM+2L*('Q"86-K=7 @1G)E<2XN(" @?" @(&1A:6QY(" @?"!B
  299. M:2UW965K;'D@?" @=V5E:VQY(" @('P@('=E96ML>2 @(" @?" @=V5E:VQY
  300. M(" @('P@('=E96ML>2 @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @
  301. M(" @(" @('P*('PQ," @(" @(" @(" @(" @?" @(" @(" @,C,@?" @(" @
  302. M(" @(#$@?" @(" @(" @,3(@('P@(" @(" @(" W(" @?" @(" @(" @(#@@
  303. M('P@(" @(" @(" Q('P@(" @(" @(" @('P@(" @(" @(" Q('P@(" @(" @
  304. M(#4S('P*("LM+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM
  305. M+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM
  306. M+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM
  307. M+2L*('P@4')E=F5N=&EO;B @(" @?" @('1S<G,@(" @?"!S8V%N;FEN9R @
  308. M?" @=7-E<B!E9" @('P@<&]L:6-I97,@(" @?" @8F%C:W5P<R @('P@("!O
  309. M=&AE<B @('P@(&YO=&AI;F<@('P@(" @(" @(" @('P@(" @(" @(" @('P*
  310. M('PQ,6$@(" @(" @(" @(" @?" @(" @(" @,3D@?" @(" @(" @,S4@?" @
  311. M(" @(" @,30@('P@(" @(" @(#$R(" @?" @(" @(" @,3 @('P@(" @(" @
  312. M(" V('P@(" @(" @(" Q('P@(" @(" @(" S('P@(" @(" @,3 P('P*('Q!
  313. M5E!S(&EN(%5S92 @(" @?" @1BU0<F]T(" @?" @5G-H:65L9" @?" @(%-C
  314. M86X@(" @('P@(" @3D%6(" @(" @?&]T:&5R($UC069E97P@("!O=&AE<B @
  315. M('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P*('PQ,6(@
  316. M(" @(" @(" @(" @?" @(" @(" @,C$@?" @(" @(" @(#4@?" @(" @(" @
  317. M(#4@('P@(" @(" @(" S(" @?" @(" @(" @(#4@('P@(" @(" @(#$P('P@
  318. M(" @(" @(" @('P@(" @(" @(#(P('P@(" @(" @(#8Y('P*("LM+2TM+2TM
  319. M+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM
  320. M+2LM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM
  321. M+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2L*('Q!9F9I;&EA=&EO
  322. M;B @(" @?" @9F%C=6QT>2 @?" @('-T869F(" @?" @(&=R860@(" @('P@
  323. M("!U;F1E<B @(" @?" @(&]T:&5R(" @('P@;F]N+6%C860@('P@(" @(" @
  324. M(" @('P@(" @(" @(" @('P@(" @(" @(" @('P*('PQ,B @(" @(" @(" @
  325. M(" @?" @(" @(" @(#8@?" @(" @(" @,S @?" @(" @(" @(#$@('P@(" @
  326. M(" @(" R(" @?" @(" @(" @(#$@('P@(" @(" @(#$R('P@(" @(" @(" @
  327. M('P@(" @(" @(" Q('P@(" @(" @(#4S('P*("LM+2TM+2TM+2TM+2TM+2TM
  328. M*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM
  329. M+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM
  330. M+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2L*('P@("!3;W5R8V4@(" @(" @?" @
  331. M(%5-0U @(" @?" @3F]V96QL(" @?" @5DE255,M3" @('P@($4M;6%I;" @
  332. M(" @?" @(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @
  333. M(" @(" @('P@(" @(" @(" @('P*('P@(" @(" @(" @(" @(" @?" @(" @
  334. M(" @,34@?" @(" @(" @,C8@?" @(" @(" @,3 @('P@(" @(" @(" R(" @
  335. M?" @(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @
  336. M(" @('P@(" @(" @(#4S('P*("LM+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM
  337. M+2TM*RTM+2TM+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM
  338. M+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM
  339. M+2LM+2TM+2TM+2TM+2L*('P@4VET92!4>7!E(" @(" @?" @("!%1%4@(" @
  340. M?" @("!#3TT@(" @?" @(" @(" @(" @('P@(" @(" @(" @(" @?" @(" @
  341. M(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@
  342. M(" @(" @(" @('P*('QN+V$@(" @(" @(" @(" @?" @(" @(" @-#$@?" @
  343. M(" @(" @,3(@?" @(" @(" @(" @('P@(" @(" @(" @(" @?" @(" @(" @
  344. M(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @(" @(" @('P@(" @
  345. M(" @(#4S('P*("LM+2TM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM*RTM+2TM
  346. M+2TM+2TM*RTM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2TM*RTM+2TM+2TM+2TM
  347. M+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM+2TM+2LM+2TM+2TM
  348. &+2TM+2L*
  349.  
  350. end
  351. - -- 
  352.  
  353. Jay Elvove       jay@info.umd.edu
  354. c/o Academic Software
  355. Comp. Sci. Center, Univ. of Md., College Park
  356.  
  357. ------------------------------
  358.  
  359. Date:    Sun, 21 Feb 93 20:09:29 +0000
  360. From:    houle@nmt.edu (Paul Houle)
  361. Subject: Re: How to measure polymorphism
  362.  
  363. bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:
  364.  
  365. >Yes, that's a very good idea. And it can be implemented quite easily,
  366. >no need to have the "polymorphic compiler" you are talking about. Just
  367. >have some polymorphic engine in the intallation program and use it to
  368. >encrypt and prepend a random decryptor to the executable before
  369. >installing it. Of course, you could even use MtE for that purpose, but
  370. >this is not a wise idea, because then everybody's scanner will detect
  371. >your program as infected with an MtE-based virus... :-)
  372.  
  373.     I think that the polymorphic compiler approach is still
  374. stronger than that of the existing polymorphic engines.  It also has
  375. the advantage that it will work fine in operating systems and
  376. environents that don't like self-modifying code.  The compiler could
  377. even re-compile itself, so that there wouldn't be one speck of
  378. invariant code.  Although many of the simple approaches could waste a
  379. greal deal of space by adding randomized jumps, etc, an efficient
  380. polymorphic compiler could probably work about as well as a
  381. poorly-optimized conventional compiler, if not better.  Register
  382. allocations could be randomized, code could be spaghettied and one
  383. could store different implementations for primitive operations.
  384.  
  385. >Of course, the implementation of the polymorphic anti-virus program
  386. >should be strong enough - e.g. an integrity checker that shokes when a
  387. >virus deletes its dabases of checksums is not good, even if it is a
  388. >polymorphic one... :-)
  389.  
  390.     Definitely, the most advanced cryptography technology
  391. availible should be used.  The problem is that the keys have to be
  392. laying around somewhere, even if you are using a public key system --
  393. although in that case you might be able to store the private key
  394. offline except when the database for the program needs to be updated.
  395. Deleting a checksum database would probably be a bad idea for a virus
  396. - -- and having your integrity checker choke would certainly be a
  397. warning sign.  It would make more sense for a virus to alter the CRCs
  398. if it were possible for it to read the altered coefficients, keys, or
  399. whatever it needs to make validation data.
  400.  
  401. >Oh, yes, and it is enough to make the executable different each time.
  402. >You don't need to bother with the names of the data files, if you
  403. >provide the possibility to the user to use just -any- names...
  404. >
  405.  
  406.     I would agree that a program should allow the user to decide
  407. where to put important files and what their names should be, but a
  408. program that is going to be used by the general population is going to
  409. have to have some kind of defaults.  Anyone who is fairly computer
  410. literate won't have any problem thinking up creative names, but the
  411. majority of computer users out there know about word processing and
  412. games.  I've seen people "freeze up" while trying to do simpler things
  413. than just pick a couple of filenames.  As such, the program probably
  414. should ask the user if he wants to select names for the data base
  415. files, and if he doesn't, it should go around and hide them all
  416. automatically.
  417.  
  418.  
  419.  
  420. ------------------------------
  421.  
  422. Date:    Fri, 19 Feb 93 19:37:24 -0500
  423. From:    Ian Leitch <I.LEITCH@lshtm.ac.uk>
  424. Subject: re: Tokyo Virus in NETCB or a false positive? (PC)
  425.  
  426. In Virus-L Volume 6 Issue 26, I wrote:
  427. > I have recently downloaded NETCB v0.3b from the UK HENSA (Higher
  428. > Education National Software Archive) directory
  429. > micros/ibmpc/dos/h/h112. (NETCB is Chat box for Novell networks
  430. > and was written by Koos van den Hout.)
  431. >  (blah, blah)
  432. >           However, any attempt at execution is intercepted
  433. > by VIRSTOP which reports infection with Tokyo virus.
  434. >  (more blah, blah)
  435. > These and other indications lead me to think that I may have hit
  436. > a false positive. If so, how can I run it and retain protection
  437. > from VIRSTOP?
  438.  
  439. Frisk has confirmed that is was indeed a false positive indication,
  440. and has sent me an updated version of VIRSTOP which resolves the
  441. problem. Many thanks to frisk for such a swift response.
  442.  
  443. Ian Leitch
  444.  ----------------------------------------------------------------------------
  445. |   Ian Leitch                                 JANET: i.leitch@uk.ac.lshtm   |
  446. |   Information Technology Unit                          Tel: 071 927 2260   |
  447. |   London School of Hygiene and Tropical Medicine       FAX: 071 436 5389   |
  448. |   Keppel St., London WC1E 7HT                          Telex: 8 95 34 74   |
  449.  ----------------------------------------------------------------------------
  450.  
  451. ------------------------------
  452.  
  453. Date:    19 Feb 93 19:44:42 -0500
  454. From:    ac999512@umbc.edu (ac999512)
  455. Subject: Re: Scanning memory (PC)
  456.  
  457. >>Yup. This is called ghost positive. It can be easily avoided by the
  458. >>producer of the scanner with a little bit of intelligent programming.
  459. >>I suggest that people REFUSE to use anti-virus software that is so
  460. >>stupid.
  461. > 
  462. >Isn't it better to be conservative and look everywhere in memory for active
  463. >viruses?  I'd much rather see a false alarm than have something be missed
  464. >because a scanner was wrong about where viruses could lurk.  Also, this sort
  465. >of false alarm can only arise if you have scanned an infected floppy.  If a
  466. >user has an infected floppy, and doesn't know enough about viruses to
  467. >understand the ghosting problem, they should consider getting expert help.
  468.  
  469.   I agree that scanners shouldn't scream and yell when they detect a
  470. virus floating in RAM that isn't active. Yet on the other hand,
  471. nothing should be taken for granted as to where a virus is, as stated
  472. above.
  473.  
  474.   I think it best that scanners should check interrupt vectors and so
  475. forth to determine if the virus is active, then inform the user as to
  476. the presence of the virus, and whether or not it is active.
  477. Flexibility is the best policy.
  478.  
  479. +----------------------------------------------------+
  480. |  Ed T. Toton III, | "It's difficult to work in a   |
  481. |  Virus Researcher |  group when you're omnipotent" |
  482. +----------------------------------------------------+
  483.  
  484. ------------------------------
  485.  
  486. Date:    Fri, 19 Feb 93 22:35:51 -0500
  487. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  488. Subject: Rebuilding Partition Tables (PC)
  489.  
  490. >From:    chowes@sfu.ca (Charles Howes)
  491. >Subject: FDISK buggy? (PC)
  492.  
  493. >- -------ON ANOTHER TANGENT------
  494. >Has anyone written a program that will allow you to create a new
  495. >partition table sector from scratch, and if the numbers you give
  496. >correspond to the previous partition table's numbers, *poof*, you have
  497. >a working hard disk again?  (Fdisk /mbr didn't work in this case.)  And
  498. >then do the same thing for the boot sector if called for?
  499.  
  500. Well I have all of the pieces, just not ready for Prime Time but others are
  501. welcome. Basically all of the information is there (I include a write-up
  502. in the FixMBR.DOC that comes with the FixUTIL3.ZIP - incidently half of
  503. those are FREEWARE and the rest are on free trial until 7th March again
  504. this year).
  505.  
  506. First you have the BIOS information retrievable with Int 13 Fn 08. This will
  507. tell you what the CMOS thinks the whole disk is (tracks, heads sectors).
  508.  
  509. Next you have the Partition Table - this lists the logical drive information
  510. for each partiton (starting sector, number of sectors, partition type).
  511.  
  512. Then you have the Dos Boot Record which gives the same information as the
  513. partition table for each partition.
  514.  
  515. If there are multiple partitions, each will have its own DBR (and a recovery
  516. program could just "walk the disk" looking for them) since DOS 3.0 they
  517. *must* be in the same place.
  518.  
  519. Thus the information can be found in not one but *four* different places
  520. on a DOS disk (Unix or Novell are different but the info is still there -
  521. just keep fresh batteries in your TI Programmer 8*).
  522.  
  523. Right now I have other things to do, like painting my house 8*(
  524.  
  525.                         Warmly,
  526.                             Padgett
  527.  
  528.  
  529.  
  530.  
  531. ------------------------------
  532.  
  533. Date:    Sat, 20 Feb 93 04:44:26 +0000
  534. From:    Christopher Yoong-Meng Wong <cwong@cs.cornell.EDU>
  535. Subject: PC Magazine reviews virus scanners (PC)
  536.  
  537. Have others seen the March 16, 1993 issue of PC Magazine yet? Normally, I
  538. wouldn't expect this group to care much, but this magazine has tremendous
  539. influence in the industry. A summary:
  540.  
  541. 1.    Editors' choices are CPAV and NAV.
  542.  
  543. 2.    The great grandaddy of virus scanners, Mc Afee's Viruscan family, 
  544.     was not reviewed. Nor was F-prot (though the commercial version was
  545.     reviewed), except as an aside: "... for those comfortable with
  546.     command line operation ... original F-prot".
  547.     ^^^^^^^^^^^^
  548.     
  549. 3.    Scanning tests involved 11 -- count them -- 11 viruses.
  550.  
  551. 4.    Review emphasized completeness of package: disinfection,
  552.     comprehensiveness of service etc, not detection ability.
  553.  
  554. Somehow, this review seems out of sync with almost everything I've read
  555. here about virus scanners. Opinions? It seems to me a letter to the
  556. letters page signed by a major virus researcher (or ten :-) ) would carry
  557. a lot of weight.
  558.  
  559. Chris
  560.  
  561. ------------------------------
  562.  
  563. Date:    Fri, 19 Feb 93 21:06:46 -0800
  564. From:    greg@ideath.goldenbear.com (Greg Broiles)
  565. Subject: Michelangelo detect/removal instructions (PC)
  566.  
  567. Greetings - given we are again approaching March 6, I thought it might
  568. be useful to put together some instructions that would allow DOS-savvy
  569. users (yeah, both of them :) to look for Michelangelo without needing
  570. to spend time/dollars tracking down scanning software.
  571.  
  572. (And yes, I agree that it's important for folks to take further data
  573. protection measures - but it seems like some protection is better than
  574. none, especially given the wide distribution of Michelangelo.)
  575.  
  576. What I'd like to do is come up with a text-based description of how to
  577. detect and disinfect Michelangelo, and at no cost to users with access
  578. to DEBUG and other DOS utilities. Ideally, this could be handed out at
  579. user group meetings, posted on (cork :) bulletin boards, FAXed to
  580. folks who need it, and so forth.
  581.  
  582. Seems like the first check should be the amount of system memory
  583. reported by MEM or CHKDSK - which should be 655,360 on a 640K machine.
  584. If a machine has 640K, and MEM/CHKDSK reports system memory of 655,360
  585. - - the machine *as running* cannot be infected, since one of the first
  586. things Mich does is to subtract 2K from the total system memory
  587. reported.
  588.  
  589. Users whose machines have less common configurations (some amount of
  590. system memory used for other purposes, or with less than 640K of base
  591. RAM) or who want to check disk(s) without booting them, should be able
  592. to do this with DEBUG, like so:
  593.  
  594. DEBUG
  595.  
  596. l 0 0 0 1
  597. [to check a floppy in A: - should be 'l 0 2 0 1' to check C:]
  598.  
  599. s 0 1AC AD 3B 47 02 74 35 B8 01 03 B6 01 B1 03 80 7F 15 FD 74 02 B1 0E 89 
  600. 0E 08 00
  601.  
  602. [Moderator's note: the above debug command is a _single_ line of input
  603. to debug.]
  604.  
  605. [search for Michelangelo signature - signature string swiped out of
  606. Jan Terpstra's VIRSCAN.DAT, revision 930103]
  607.  
  608. If DEBUG returns an address, it's found the signature, and Michelangelo is
  609. present in the boot sector of the suspect disk - if not, the disk can be
  610. considered Mich-free.
  611.  
  612. Users who find Mich can overwrite it on floppies with the SYS command;
  613. users who find it on hard disks can overwrite it with FDISK /MBR, if their
  614. FDISK supports it. (If not, they can at least avoid using that machine on
  615. March 6 and pursue some other means of removal)
  616.  
  617. I see four potential problems with this approach:
  618.  
  619. 1.      It could create a false sense of security, as being Mich-free isn't
  620. the same as being virus-free.
  621.  
  622. 2.      It would be relatively easy to mistakenly generate a false negative
  623. by mistyping the signature string.
  624.  
  625. 3.      It could create stress/panic on the part of those folks for whom
  626. CHKDSK/MEM don't report 655,360, but are uninterested/unwilling to do
  627. further DEBUG diagnosis/detection.
  628.  
  629. 4.      It fails to address non-DOS users of PC architecture systems,
  630. though it ought to give those people a good kick in the right direction to
  631. check themselves with available tools.
  632.  
  633. However, I see some good features, as well:
  634.  
  635. 1.      It allows people without ready access to other means of detection to
  636. check their systems for infection. I'm relatively well off in that I have
  637. a modem and Internet access, and can pick up new versions of scanners on a
  638. more-or-less monthly basis; but there are folks in the world still chugging
  639. along without easy ways to get software, as well as folks who are put off
  640. by the high prices of commercially available antiviral products.
  641.  
  642. 2.      It might encourage people to take a more active and involved
  643. approach to security.
  644.  
  645. Anyway, I'm interested in hearing comments from the net about this approach.
  646. I've tested this on my own system with a captured copy of Mich from last year's
  647. follies, and I haven't encountered any anomalies. However .. it's a big world,
  648. potentially full of things I haven't thought of yet.
  649.  
  650. Ideas/comments/flames?
  651.  
  652.  
  653. - --
  654. Greg Broiles                            greg@goldenbear.com
  655. Golden Bear Consulting                  +1 503 465 0325
  656. Box 12005 Eugene OR 97440               BBS: +1 503 687 7764
  657.  
  658. ------------------------------
  659.  
  660. Date:    20 Feb 93 12:38:40 +0000
  661. From:    frisk@complex.is (Fridrik Skulason)
  662. Subject: Re: Uruguay on PS/2 Ref disk (PC)
  663.  
  664. pinman@magnus.acs.ohio-state.edu (Patricia C Inman) writes:
  665.  
  666. >Fprot 2.06 reports:  command.com "Infection: Uruguay" on all PS/2 
  667. >Model 70/80 Reference Disks Version 1.06.  Version 1.03 of the Ref 
  668. >Disk reports clean.  CPAV is current and reports nothing.
  669.  
  670. >I recently went through a scare and collected all disks in the
  671. >facility.  This is all I have left to cleanup.  Is this "normal"?
  672.  
  673. This is a false alarm that was corrected in 2.07 - it is also documented
  674. in the NEW.207 file, included with that version.
  675.  
  676. - -frisk
  677.  
  678.  
  679. - -- 
  680. Fridrik Skulason      Frisk Software International     phone: +354-1-694749
  681. Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801
  682.  
  683. ------------------------------
  684.  
  685. Date:    Sat, 20 Feb 93 16:40:01 +0000
  686. From:    beyer@Lise.Unit.NO (Paal Beyer)
  687. Subject: Re: Virstop 2.07 & Lanworkplace = Windows Hangs... (PC)
  688.  
  689. I too had the same problem. I mailed the author, but I have
  690. not received an answer. I had to install the old VIRSTOP.
  691. The new one seems to have some interesting options so I
  692. hope the author can fix this bug.
  693.  
  694. - ------------------------------------------------------------         
  695.     _/_/_/    _/_/_/  _/  _/  _/_/_/  _/_/_/
  696.    _/    _/  _/      _/  _/  _/      _/    _/
  697.   _/_/_/    _/_/_/  _/_/_/  _/_/_/  _/_/_/
  698.  _/    _/  _/        _/    _/      _/  _/
  699. _/_/_/    _/_/_/    _/    _/_/_/  _/    _/ @lise.unit.no
  700.  
  701. ------------------------------
  702.  
  703. Date:    19 Feb 93 21:17:00 +0000
  704. From:    bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
  705. Subject: Viruses in March (PC)
  706.  
  707. Here is an incomplete list of viruses that are scheduled to activate in 
  708. March. Please Use precautions.
  709.  
  710. 903 activates any day in March
  711. AH activates any Tuesday
  712. CARFIELD activates any Monday
  713. CD activates Thursday the 12th
  714. DAY10 activates the 30th of any month
  715. DAY10 activates the 20th of any month
  716. DAY10 activates the 10th of any month
  717. FLIP activates the 2nd of any month
  718. FORM (18) activates the 18th of any month
  719. FORM (24) activates the 24th of any month
  720. FRERE JACQUES activates any Friday
  721. FROG'S ALLEY activates the 5th of any month
  722. I-B (BadGuy 2) activates any Monday
  723. I-B (BadGuy) activates any Monday
  724. I-B (Demon) activates any Tuesday
  725. I-B (exterminator) activates any Monday
  726. ITALIAN PEST (Finger) activates any Saturday
  727. JERUSALEM (Payday) activates Fridays (not 13th)
  728. JERUSALEM (Skism-1) Fridays (after the 15th)
  729. JERUSALEM (Phenome) activates any Saturday
  730. KAMASYA activates any Tuesday
  731. MALTESE AMOEBA activates Mar 15th
  732. MICHELANGELO activates Mar 6th
  733. MIGRAM activates any Saturday
  734. MONXLA activates the 13th of any month
  735. PLASTIQUE (Cobol) activates Jan 1 - Sep 21
  736. SMACK activates any Friday
  737. SUNDAY activates any Sunday
  738. SUNDAY-2 activates any Sunday
  739. TAIWAN activates the 8th of any month
  740. VICTOR activates any Wednesday
  741.  
  742. Bill
  743.  
  744. - ---
  745.  * WinQwk 2.0 a#383 * KENEDY activates Jun 6th
  746.  
  747.  
  748. ------------------------------
  749.  
  750. Date:    Sun, 21 Feb 93 16:36:59 -0500
  751. From:    fergp@sytex.com (Paul Ferguson)
  752. Subject: Identification (PC)
  753.  
  754. On 17 Feb 93 (19:39:41 GMT),
  755.  <jimo@sun.computing.manchester-metropolitan-university.ac.u>
  756.  Jim O'Shea wrote -
  757.  
  758. JO> Could you recognise that a file had been infected by a virus
  759. JO> purely by inspecting a disassembled listing?  I do mean any
  760. JO> virus, including one you might not have met before. I accept
  761. JO> it might not be possible to be specific but answers like
  762. JO> "Yes, given unlimited time."  or " Seventy percent probability
  763. JO> of a correct answer after spending 6 hours on inspection" will
  764. JO> be useful.
  765.  
  766.  In a nutshell, yes. It really depends upon what you mean by a
  767.  "disassembled listing", however. One cannot simply run an
  768.  encrypted virus through a symbolic disassembler and expect
  769.  everything to come out in the wash.
  770.  
  771.  For more complex viruses, an interactive disassembling aid (SoftICE
  772.  or simply DEBUG) will allow one with enough skill to trace through
  773.  the code and unveil the tricks inside. Kind of like a box of Cracker
  774.  Jacks (tm).   ;-)
  775.  
  776.  For polymorphic "envelopes" (I dislike the term "engine"), a more
  777.  intensive analysis of the encryption algorithm is required, but
  778.  is being done by many developers on a semi-regular basis.
  779.  (Unfortunately.)
  780.  
  781. JO> I am interested in applying AI to virus detection and I would
  782. JO> like to know how effective "Natural" intelligence is first.
  783.  
  784.  Natural intelligence will never be completely replaced, but several
  785.  individuals have made great strides in their heuristic analysis
  786.  extensions of examining code. Fridrik Skulason's f-Prot does a
  787.  fantastic job of detecting virus-like code, but does not provide
  788.  as much detail concerning it's findings as the heuristic flags
  789.  logged in Frans Veldman's Thunderbyte AntiVirus. (Opinion, opinion.)
  790.  
  791. Paul Ferguson                     |
  792. Network Integration Consultant    |  "All of life's answers are
  793. Alexandria, Virginia USA          |   on TV."
  794. fergp@sytex.com     (Internet)    |           -- Homer Simpson
  795. sytex.com!fergp     (UUNet)       |
  796. 1:109/229           (FidoNet)     |
  797.          PGP public encryption key available upon request.
  798.  
  799. - ---
  800. fergp@sytex.com (Paul Ferguson)
  801. Access <=> Internet BBS, a public access internet site
  802. Sytex Communications, Arlington VA, 1-703-358-9022
  803.  
  804.  
  805. ------------------------------
  806.  
  807. Date:    Sun, 21 Feb 93 16:37:01 -0500
  808. From:    fergp@sytex.com (Paul Ferguson)
  809. Subject: Uruguay virus (PC)
  810.  
  811. On 17 Feb 93 (18:36:42 GMT),
  812.  < pinman@magnus.acs.ohio-state.edu> Patricia C Inman wrote -
  813.  
  814. PI> Fprot 2.06 reports:  command.com "Infection: Uruguay" on all
  815. PI> PS/2 Model 70/80 Reference Disks Version 1.06.  Version 1.03
  816. PI> of the Ref Disk reports clean.  CPAV is current and reports
  817. PI> nothing.
  818.  
  819.  It sounds like a false positive, but I'd hesitate to draw that
  820.  conclusion. Have you attempted to try a newer version of the product
  821.  or perhaps a current (bourne within the course of the past two
  822.  months) version of another virus detection utility?
  823.  
  824.  On another note, I am curious as to other what other particpants may
  825.  have experienced with the relationship between PS/2 reference
  826.  diskettes and a possible tendancy for PS/2 shops to have a higher
  827.  percentage of MBR infections (per capita). I have run across several
  828.  "Big Blue" organizations that seem to have a higher percentage of
  829.  MBR infections than non- "Blue" shops. Perhaps the reliance on the
  830.  reference diskettes and lack of safe computing practices at these
  831.  locations combine for a lower tolerance for STONED and FORM
  832.  infections? It would appear that way, at least at first glance,
  833.  but I'll readily admit that apathy in way, shape or form can
  834.  contribute to a tendancy for infection, whether IBM or clone.
  835.  
  836. Paul Ferguson                   |  "Making duplicate copies and computer
  837. Network Integration Consultant  |   printouts of things no one wanted
  838. Alexandria, Virginia USA        |   even one of in the first place is
  839. fergp@sytex.com   (Internet)    |   giving America a new sense of
  840. sytex.com!fergp   (UUNet)       |   purpose."  - Andy Rooney
  841. 1:109/229         (FidoNet)     |
  842.          PGP public encryption key available upon request.
  843.  
  844. - ---
  845. fergp@sytex.com (Paul Ferguson)
  846. Access <=> Internet BBS, a public access internet site
  847. Sytex Communications, Arlington VA, 1-703-358-9022
  848.  
  849.  
  850. ------------------------------
  851.  
  852. Date:    Sun, 21 Feb 93 14:31:21 -0500
  853. From:    sgt@lakes.trenton.sc.us (Sgt Rock)
  854. Subject: Virus Scanner for BBS (PC)
  855.  
  856. I am trying to locate a virus scanner for a GT Power BBS.
  857. Preferably I would like to have all file uploads scanned immediately 
  858. after they are uploaded. I know ZIPLAB+ does that but it won't work with 
  859. GT Power. If I can't automatically scan uploads when they are uploaded 
  860. then I'd like to scan uploads as a scheduled even once each day prior to 
  861. either placing the files in the approriate files area or removing them
  862. Can anyone help me with this? Thanks!
  863.  
  864.  
  865. ------------------------------
  866.  
  867. Date:    Sun, 21 Feb 93 22:49:19 -0500
  868. From:    Wolfgang Stiller <72571.3352@compuserve.com>
  869. Subject: Re: F-prot/FSP/bootsum problem. Help! (PC)
  870.  
  871.  jornj@colargol.edb.tih.no (jornj) writes:
  872.  
  873.  > I've experienced the same problem, using Integrity Master and Stacker
  874.  > 2.0. When I check the 'bootsector' of my stacked volume IM always
  875.  > claims it has changed...
  876.  
  877.  > Is this normal for Stacker? Or do I have a 'problem'?
  878.  > (I've scanned with scan v99, fprot 2.06 and IM doesn't report any
  879.  > other problems).
  880.  
  881. Yes, it's a "normal" Stacker function.  Stacker creates a pseudo boot
  882. sector on the simulated (compressed) Stacker volume.  For some reason
  883. Stacker insists on constantly changing this sector.  Since you can
  884. not boot from this sector, there's little reason to check its integrity.
  885. A future version of IM will recognize Stacker boot sectors and not
  886. bother to check them.
  887.  
  888. If you have a recent release of Integrity Master (The current release is
  889. V1.41b but I think I've had the documented since V1.22 or 1.23) the
  890. QUESTION.DOC file describes this and provides some other Stacker related
  891. tips.
  892.  
  893. Regards, Wolfgang        Wolfgang Stiller
  894.                          Stiller Research
  895.                          2625 Ridgeway St.
  896.                          Tallahassee, FL 32310
  897.                          U.S.A.
  898.  
  899.  
  900.  
  901. ------------------------------
  902.  
  903. Date:    Mon, 22 Feb 93 02:06:21 -0500
  904. From:    KARGRA@GBA930.ZAMG.AC.AT
  905. Subject: re:waldo (PC)
  906.  
  907. Hi all,
  908. we had this discussion on win3-l a year ago. When I read the subject I
  909. immediately remembered that. On my PC we regularly ran CorelDRAW 2.0.
  910. And sometimes the system crashed with an UAE and telling something like:
  911. Module Waldo caused a UAE at adress XXXX, or so. NO, WALDO IS NOT A
  912. VIRUS, it probably is a relict of some debugging-code in Corel Draw 2.0.
  913. I can't tell if it still exists in CorelDraw 3.0. I haven't seen it until
  914. now, despite regular GPFs (Win 3.1 was significantly improved, there are no
  915. more UAEs - Unrecoverable Application Errors, now they call them GPFs -
  916. General Protection Failures)
  917. It's not so much of a problem to find WALDO with a hexeditor in CORELDRW.EXE
  918. at offset 0x191 ;)
  919.  
  920. Hope to help, Alfred
  921.       o /                                                      \ o
  922. - ------ X ------------ Don't cut here! You damage the screen --- X -----------
  923.       o \                                                      / o
  924.  
  925.  
  926. ------------------------------
  927.  
  928. Date:    Mon, 22 Feb 93 07:00:24 -0500
  929. From:    Otto Stolz <RZOTTO@NYX.UNI-KONSTANZ.DE>
  930. Subject: Re: FORM (again!) (PC)
  931.  
  932. On 12 Feb 93 (14:53:29 GMT), <julianh@sni.co.uk> Julian Haddrill wrote:
  933. > I too have had the same problem, with the 'FORM' virus. [...]
  934.  
  935. On Mon, 15 Feb 93 16:23:41 -0500 Paul Ferguson <fergp@sytex.com> said:
  936. > [...] Your problem sounds as if you're either finding "ghost"
  937. > signatures in memory (or in the master boot sector, which was not
  938. > disinfected properly) or you somehow have managed to re-introduce the
  939. > virus into your system in some fashion.
  940.  
  941. On HDs, FORM does infect the DOS boot record, rather than the Master Boot
  942. Record, as Paul Ferguson seemed to imply.
  943.  
  944. This detail is important when you try to clean a HD by generic means: you
  945. eradicate a MBR infector (such as Brain, Stoned, and their descendants)
  946. by means of the "FDISK /MBR" command (after making sure that the
  947. partition table is still in place), while you eradicate DBR infectors
  948. (such as FORM) by means of the "SYS C:" command. Needless to say that you
  949. have to clean-boot first, in any case.
  950.  
  951. Best wishes,
  952.                     Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
  953.                                <RZOTTO@nyx.uni-konstanz.de>
  954.  
  955.  
  956. ------------------------------
  957.  
  958. Date:    Mon, 22 Feb 93 12:03:11 +0000
  959. From:    v922340@hildebrand.si.hhs.nl (Ivar Snaaijer)
  960. Subject: Re: Minimal virus scan? (PC)
  961.  
  962. swesterback@tne01.tele.nokia.fi writes:
  963. >We have an automatic virus-scan (in autoexec.bat) on all computers
  964. >here at work. As it slows down the boot process to much on some
  965. >computers i am planning to scan only parts of the files instead of the
  966. >whole disk.
  967. >
  968. >My question now is if these assumptions are correct:
  969. >- - viruses only infects:
  970. >        *.EXE and *.COM -files that has been used when a virus is in memory
  971. >        the boot sector
  972. >        command.com
  973. >- - it is enough to scan only memory, the boot sector and for example the 
  974. >  following files:
  975. >        command.com     smartdrv.exe    emm386.exe      keyb.com
  976. >        win.com         win386.exe      lat.exe         redir.exe
  977. >        
  978. You assumed right but checking only the last files, will only give you 
  979. a warning AFTER the system is infected, witch will only be detected while
  980. rebooting, so if there is an infection the program that carries the 
  981. virus inside the system will not be scanned just after some damage is
  982. done.
  983.  
  984. >Is that correct? If not please tell me why not! I can also think about
  985. >varying the scanned directories from day to day.
  986. >
  987. >Also is there really any need to scan DLL, DRV, OVL and SYS-files?
  988. >
  989. The so called overlayfiles are only infectable if they have real EXE
  990. header types. otherwise it is some kind of datafile witch hasn't
  991. got a regular beginning or end (just another binary).
  992. The sys files (like IO.SYS or IBMIO.SYS) are known files,
  993. someone who wants to know where it is executed form can ask it, so 
  994. it's rather easy to infect. 
  995.  
  996. #define EXECUTABLES "*.COM *.EXE *.SYS *.OV?"
  997.  
  998. If speed is the problem, you could try TBSCAN, (availeble on SIMTEL as
  999. TBAV503.ZIP) in quick mode it scans over 700 EXECUTABLES in 15 seconds (on a
  1000. 213MB harddisk in a 486 SX 25Mhz system), Scanning in normal mode
  1001. the same computer does it in 25 seconds, Also the program produses 
  1002. some highly active screen display so no one will be bored (colors and stuff)
  1003. the program also has a feature that stops it form scanning after every
  1004. boot-up (you can tell it to only scan once a day). 
  1005.  
  1006. >Sten
  1007.  
  1008. Ivar.
  1009.  
  1010.  
  1011. - -- 
  1012. - -----------------------------------------------------------------------------
  1013. Rule one in program optimization : Don't do it.
  1014. Rule two in program optimization (for experts only) : Don't do it yet.
  1015. Rule three in program optimization (for athlets only) : Just do it.
  1016.  
  1017. ------------------------------
  1018.  
  1019. Date:    Sat, 20 Feb 93 13:19:28 -0500
  1020. From:    krvw@first.org (Kenneth R. van Wyk)
  1021. Subject: I-M141.ZIP - Integrity Master (PC)
  1022.  
  1023. I have uploaded to WSMR-SIMTEL20.Army.Mil and OAK.Oakland.Edu:
  1024.  
  1025. pd1:<msdos.trojan-pro>
  1026. I-M141.ZIP      Integrity Master data integrity/anti-virus sys
  1027.  
  1028. This is the latest version of Stiller's Integrity Master, version 1.41,
  1029. that I received on floppy directly from Wolfgang Stiller.
  1030.  
  1031. Ken
  1032. - - -
  1033. Kenneth R. van Wyk
  1034. Moderator VIRUS-L/comp.virus
  1035. krvw@FIRST.ORG      (Moderator account)
  1036. ken@THANG.PGH.PA.US (home - until I've relocated to DC)
  1037.  
  1038. ------------------------------
  1039.  
  1040. Date:    Sun, 21 Feb 93 15:25:43 -0500
  1041. From:    James Ford <JFORD@UA1VM.UA.EDU>
  1042. Subject: New files on risc (PC)
  1043.  
  1044. The following files have been placed on risc.ua.edu (130.160.4.7) for
  1045. anonymous FTP in the directory /pub/ibm-antivirus:
  1046.  
  1047.              i-m141.zip - Integrity Master v1.41
  1048.            vsumx301.zip - Virus Summary Listing
  1049.             virx26d.zip - VIRx, Ross Greenberg's Virus
  1050.                           detection program
  1051.  
  1052. - ----------
  1053. A hypocrite is one who sets good examples when he has an audience.
  1054. - ----------
  1055. James Ford -  Consultant II, Seebeck Computer Center
  1056.               The University of Alabama (in Tuscaloosa, Alabama)
  1057.               jford@ua1vm.ua.edu, jford@seebeck.ua.edu
  1058.               Work (205)348-3968  fax (205)348-3993
  1059.  
  1060.  
  1061. ------------------------------
  1062.  
  1063. Date:    19 Feb 93 16:25:00 -0600
  1064. From:    "Rob Slade, DECrypt Editor, VARUG NLC rep, 604-984-4067" <roberts@decu
  1065.       s.arc.ab.ca>
  1066. Subject: Michelangelo discovery and naming (CVP)
  1067.  
  1068. HISVIRW.CVP   930210
  1069.  
  1070.                  Michelangelo Discovery and Naming
  1071.  
  1072. Michelangelo is widely reported (even by the CARO Computer Virus
  1073. Catalog) to have been discovered in Europe in the spring or summer
  1074. of 1991.  Roger Riordan, however, had reported and named the virus
  1075. in Australia in February of 1991.  He suspected that the virus had
  1076. been received by the company affected from disks of software from
  1077. Taiwan, but this could not be finally determined.
  1078.  
  1079. The date in February of 1991 is very telling.  This indicates the
  1080. existence of the virus prior to March 6 (the "trigger" date) of
  1081. 1991.  This further indicates that the virus, although it "destroys"
  1082. itself along with the system tracks of disks overwritten on that
  1083. date, can survive.  This is not really surprising: few computer
  1084. users understand that boot sector infecting viral programs can both
  1085. infect and infect from any disk, whether or not it is bootable,
  1086. contains any programs or, indeed, contains any files at all.
  1087.  
  1088. Riordan determined that March 6 was the trigger date.  He mentioned
  1089. this to a friend who remarked that it was his birthday, and who also
  1090. happened to know that it was the birthday of the renaissance
  1091. painter, sculptor and engineer Michelangelo Buonarotti, born March
  1092. 6, 1475 in Caprese, Italy.  The name thus comes from the coincidence
  1093. of dates.  There is no text in the body of the virus, and certainly
  1094. no reference to Michelangelo.  There is no evidence that the author
  1095. of the virus knew anything of this connection.
  1096.  
  1097. (As a piece of trivia, March 6 is also Ed McMahon's birthday,
  1098. leading to jokes about viral messages stating, "Congratulations! 
  1099. Your computer may already be infected!")
  1100.  
  1101. (Interestingly, in Taiwan the virus is widely known as the "Ninja
  1102. Turtle" virus.  Obviously, in the young and not highly cultured
  1103. world of "teenage mutant ninja hackers", comic book characters are
  1104. more familiar than renaissance artists, even though all of the
  1105. "Teenage Mutant Ninja Turtles" (TM, probably) are named after
  1106. painters of that ilk.  However the cartoon/comic/toy characters have
  1107. no known association with March 6, and this reference is obviously a
  1108. mistaken extension of the Michelangelo name.)
  1109.  
  1110. Given the reports of "discovery" of the virus in the summer of 1991,
  1111. Michelangelo was very rare in the first half of the year.  (Likely
  1112. even rarer on March 7 than it had been on March 5.)  However, it
  1113. spread extremely rapidly, and by the fall of the year was
  1114. sufficiently widespread that companies were beginning to ship out
  1115. products infected with the Michelangelo virus by the beginning of
  1116. 1992.  By the time the public became generally aware of the need to
  1117. check, in late February of 1992, it is likely that the number of
  1118. copies was in the millions, if not tens of millions.  Luckily, most
  1119. were caught before March 6.
  1120.  
  1121. copyright Robert M. Slade, 1992   HISVIRW.CVP   930210
  1122.  
  1123. (Upon consideration, maybe "tens of millions" is extreme.  Remember, however,
  1124. that I am talking about "copies" of the virus, not "machines destroyed".)
  1125.  
  1126. ==============
  1127. Vancouver      ROBERTS@decus.ca         | "virtual information"
  1128. Institute for  Robert_Slade@sfu.ca      |   - technical description of
  1129. Research into  rslade@cue.bc.ca         |     marketing info disguised
  1130. User           p1@CyberStore.ca         |     as technical description
  1131. Security       Canada V7K 2G6           |            - Greg Rose
  1132.  
  1133. ------------------------------
  1134.  
  1135. Date:    Tue, 23 Feb 93 09:08:36 -0500
  1136. From:    "Kenneth R. van Wyk" <krvw@first.org>
  1137. Subject: Re: Censorship
  1138.  
  1139. Donald G Peters <Peters@DOCKMASTER.NCSC.MIL> writes:
  1140. > With everyone making these decisions on their own, we will
  1141. > probably all be shortchanged. We should either have a
  1142. > guideline to decide by, or have one person make the decision
  1143. > for us (eg the moderator). I prefer the former idea because
  1144. > there is always the chance that the moderator could be a
  1145. > bad guy himself (no offense, moderator.)
  1146.  
  1147. We do have such a guideline, and it is publicly available for comment.
  1148. In fact, every new subscriber to VIRUS-L gets a copy of the guideline
  1149. document, and it is available by anonymous FTP from:
  1150.  
  1151. cert.org:pub/virus-l/virus-l.README
  1152.  
  1153. I will gladly e-mail the document to anyone without FTP access.
  1154. Should I be distributing it elsewhere?  I could perhaps add it to the
  1155. monthly automagic postings on comp.answers and news.answers...
  1156.  
  1157. The posting guidelines, as I said, are available for public comment.
  1158. If/when the majority of the group wishes to change or add to the
  1159. guidelines, I will gladly do so.  If the revisions are such that I
  1160. cannot ethically abide by them, then I will step down from being the
  1161. group's moderator.
  1162.  
  1163. > I would agree to censor raw virus code but would like to consider
  1164. > the value of censoring ANYTHING else.
  1165.  
  1166. The current guidelines prohibit very little other than raw virus code.
  1167. They do, however, prohibit the solicitation to copy or exchange raw
  1168. virus code.  Beyond that, there is little in the way of technical
  1169. discussions that I will not accept for posting.  (Other guidelines
  1170. include politeness, relevant to the subject of computer viruses, etc.
  1171. For the full list, please read the document.)
  1172.  
  1173. Cheers,
  1174.  
  1175. Ken
  1176.  
  1177. Kenneth R. van Wyk
  1178. Moderator VIRUS-L/comp.virus
  1179. krvw@FIRST.ORG      (Moderator account)
  1180. ken@THANG.PGH.PA.US (home - until I've relocated to DC)
  1181.  
  1182. ------------------------------
  1183.  
  1184. End of VIRUS-L Digest [Volume 6 Issue 32]
  1185. *****************************************
  1186.