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

  1. Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5)
  2.     id AA10457; Thu, 25 Feb 1993 16:29:14 +0100
  3. Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA16920
  4.   (5.67a/IDA-1.5 for <mikael@abacus.hgs.se>); Thu, 25 Feb 1993 09:51:46 -0500
  5. Date: Thu, 25 Feb 1993 09:51:46 -0500
  6. Message-Id: <9302251450.AA03674@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 #34
  16. Status: RO
  17.  
  18. VIRUS-L Digest   Thursday, 25 Feb 1993    Volume 6 : Issue 34
  19.  
  20. Today's Topics:
  21.  
  22. WARNING: Problem with CLEAN-UP V100 and Michelangelo (PC)
  23. WARNING: McAfee CLEAN & Michelangelo [Mich] (PC)
  24. Re: Scanners getting bigger and slower
  25. More on Education
  26. Re: Censorship
  27. A quick request for opinions
  28. Known viruses in a UNIX evvironment (UNIX)
  29. Re: Michelangelo or STONED? (PC)
  30. Re: standardization (PC)
  31. Re: New Virus (PC)
  32. Re: Michelangelo or STONED? (PC)
  33. PC Magazine on Anti-Virus Software (PC)
  34. Re: PC Magazine reviews virus scanners (PC)
  35. Request for virus tools (PC)
  36. Maybe a virus (PC)
  37. FPROT, Thunderbyte, & DataCrime II (PC)
  38. Re: F-prot/FSP/bootsum problem. Help! (PC)
  39. Problems w/ LAN Prrotect (PC)
  40. Anybody knows SHIRLEY or VIVALDI ? (PC)
  41. Shriley and Vivaldi Part II (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:    Wed, 24 Feb 93 11:18:57 -0800
  62. From:    aryeh@mcafee.com (McAfee Associates)
  63. Subject: WARNING: Problem with CLEAN-UP V100 and Michelangelo (PC)
  64.  
  65. [Moderator's note: This message was posted to VALERT-L last night.]
  66.  
  67. McAfee Associates has been made aware of a possible problem with
  68. removing the Michelangelo virus with Version 9.12V100 of CLEAN-UP:
  69.  
  70. When is CLEAN C: [MICH] is run to remove the Michelangelo virus on
  71. some computer systems, the original master boot record of the hard
  72. disk is restored to the wrong location, resulting in a non-accessable
  73. hard drive until repaired.
  74.  
  75. This problem does not occur consistently and we are investigating it
  76. now.  In the meantime, anyone wishing to remove the Michelangelo virus
  77. from a hard disk should use the [GENP] I.D. code with CLEAN-UP instead.
  78. For example:    
  79.         CLEAN C: [GENP]
  80.  
  81. This will remove the Michelangelo virus by replacing the infected
  82. portion of the master boot record with a clean piece of code from
  83. inside the CLEAN.EXE file.
  84.  
  85. Details will follow as I find out more.
  86.  
  87. Regards,
  88.  
  89. Aryeh Goretsky
  90. Technical Support
  91.  
  92. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  93. McAfee Associates, Inc.  | Voice (408) 988-3832 | INTERNET: aryeh@mcafee.COM
  94. 3350 Scott Blvd, Bldg 14 | FAX   (408) 970-9727 | IP# 192.187.128.1
  95. Santa Clara, California  | BBS   (408) 988-4004 | CompuServe ID: 76702,1714
  96. 95054-3107  USA          | USR HST Courier DS   | or GO MCAFEE
  97.  
  98. ------------------------------
  99.  
  100. Date:    Sat, 20 Feb 93 22:32:29 -0500
  101. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  102. Subject: WARNING: McAfee CLEAN & Michelangelo [Mich] (PC)
  103.  
  104. [Moderator's note: This message was posted to VALERT-L last night.]
  105.  
  106. Dangerous Bug in CLEAN.EXE v100 (& possibly earlier)
  107.  
  108. For some time now I have been receiving reports of a problem between
  109. McAfee's CLEAN utility & the Michelangelo virus (yes, it is that time
  110. again). In this case the cure may be worse than the problem.
  111.  
  112. First, about a week ago I suggested to Aryeh that someone should look
  113. into the reports, he said that they would look into it & meanwhile to
  114. use CLEAN [GENP] instead of CLEAN [MICH].
  115.  
  116. The calls I have been getting indicated that after CLEANing, the disk
  117. would become unaccessable. The last report was lucid enough to
  118. indicate that the Dos Boot Record was being replaced by a Master Boot
  119. Record (not a good). Tonight I finally backed up the trusty Columbia
  120. VP-1600 for some testing using the [Mich] and SCAN/CLEAN version 100
  121. (current).
  122.  
  123. Note: the VP is a 4.77 Mhz "luggable" equipped with a WD controller and
  124.       an ST-225 20 Mb fixed disk with MS-DOS 5.0 loaded.
  125.  
  126. Following a deliberate infection but with a clean boot SCAN had no
  127. problem finding the [Mich] (boy howdy, you could go watch Ren & Stimpy
  128. while waiting on a 4.77 Mhz PC to run SCAN C: /M with v100).
  129.  
  130. Running CLEAN C: produced the following:
  131. - ---------------------------------------------------
  132. (header skipped)
  133.  
  134. Cleaning [Mich]
  135.  
  136. Scanning Volume: TESTDISK
  137. Scanning partition table of disk C:
  138.   Found the Michaelangelo [Mich] Virus in partition table.
  139. Scanning partition table of disk C:
  140.   Found the Michaelangelo [Mich] Virus in partition table.
  141.   Virus cannot be safely removed from partition table.
  142.  
  143. Found 1 file containing viruses.
  144. 1 virus was removed.
  145.  
  146. (remainder deleted)
  147. - ------------------------------------------------------------
  148.  
  149. On reboot, not only was the disk unbootable, but access from floppy
  150. resulted in "Invalid media type reading drive C:"
  151.  
  152. Examination of the disk revealed the [Mich] still in sector 1 and the
  153. original MBR code/partition table now residing in the Dos Boot Record.
  154.  
  155. Running CLEAN a second time had no effect again on the MBR (where the
  156. Mich was still residing) but a replacement of the DBR with DBR code
  157. id'ed as IBM PC-DOS version 3.3 and an empty Boot Parameter Block.
  158. Again access attempt generated an "Invalid..." (well, the BPB was
  159. empty).
  160.  
  161. Replacement of the MBR & DBR with the originals restored the disk to
  162. operation with no loss of files, however without these replacement is
  163. possible though difficult (move 0,0,7 to sector 1, pop fresh batteries
  164. in TI Programmer and generate a new BPB for the proper OS Boot Record
  165. code, iterate mistakes until it works). I would not recommend this for
  166. recreational use.
  167.  
  168. Meanwhile, until McAfee can come up with a fix, I would strongly
  169. recommend reaching for FDISK /MBR (DOS 5.0 undocumented feature)
  170. rather than CLEAN if the Michaelangelo is present.
  171.  
  172.                     Warmly,
  173.  
  174.                         Padgett
  175.  
  176. ------------------------------
  177.  
  178. Date:    23 Feb 93 09:54:58 +0000
  179. From:    frisk@complex.is (Fridrik Skulason)
  180. Subject: Re: Scanners getting bigger and slower
  181.  
  182. phys169@csc.canterbury.ac.nz writes:
  183.  
  184. >I wonder how Frisk, McAfee, and the rest survive the work load.
  185.  
  186. I wonder too.... :-)
  187.  
  188. - -frisk
  189. - -- 
  190. Fridrik Skulason      Frisk Software International     phone: +354-1-694749
  191. Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801
  192.  
  193. ------------------------------
  194.  
  195. Date:    Tue, 23 Feb 93 08:53:10 -0500
  196. From:    Chip Seymour <CHIP@BDSO.Prime.COM>
  197. Subject: More on Education
  198.  
  199. Thanks for the reply from:
  200. > phys169@csc.canterbury.ac.nz
  201. > Mark Aitchison, University of Canterbury, New Zealand.
  202. > Subject: Re: Virus education
  203.  
  204. I guess I was speaking in the more generic sense about needing an education.
  205.  
  206. I've found that, for almost every new technology, there are one or
  207. more new risks. Someone invents PC's, many people invent viruses.
  208. Someone invents a PBX, someone else figures out how to manipulate it
  209. illicitly. Who would have figured that there are ways to exploit
  210. weaknesses in SNMP?
  211.  
  212. As close to the leading crevasse of technology as we are, I'm finding
  213. there are always those with little regard for personal integrity who
  214. have tread the area before and found a number of means toward personal
  215. profit and/or malicious mischief.
  216.  
  217. Many times I find they've known how to perpetrate crimes using
  218. technology I've not yet heard of. I am not at all comfortable with not
  219. knowing what they know about my computing resources. That's the
  220. education I'm after.
  221.  
  222.  
  223. ------------------------------
  224.  
  225. Date:    Tue, 23 Feb 93 15:00:22 +0000
  226. From:    antkow@sis.uucp (Chris Antkow)
  227. Subject: Re: Censorship
  228.  
  229.  As far as I know, In Canada at least, it IS NOT illegal to post viruses
  230. on BBS'. It IS illegal however to spread virus (could be counted as
  231. conspiracy). The BBS does not actually spread the viruses but it's
  232. charged to the individual who downloads it and spread's the virus
  233. maliciously.
  234.  
  235.  If I am wrong, please rebute this as I am curious myself and am allways
  236. getting conflicting messages.
  237.  
  238.  Thanx... Chris                      
  239.  antkow@eclipse.sheridanc.on.ca
  240.  
  241. ------------------------------
  242.  
  243. Date:    Tue, 23 Feb 93 20:15:43 -0500
  244. From:    fc@turing.duq.edu (Fred Cohen)
  245. Subject: A quick request for opinions
  246.  
  247. I am writing a book about artificial life, and have some examples of
  248. programs that automate distribution of software in LANs, implement
  249. distributed databases, etc.  They are all written in the Unix shell,
  250. and involve a few lines of code that automatically copy the programs
  251. between machines to automate the distribution process.  It has come to
  252. my attention that there may be substantial objection to this idea and
  253. I am asking people in this forum for their opinion.
  254.  
  255.     Each program includes explicit safeties to prevent copying to
  256. machines where operation is not authorized by the root, and they are
  257. designed not to spread outside of particular directories.  The code is
  258. very obvious (only a few lines of shell script after all), and the
  259. book includes explicit warnings not to remove safeties or use on any
  260. machine where you don't have permission.
  261.  
  262. Questions:
  263.  
  264. 1 - why not provide this in the book?
  265. 2 - what risks do you see in it?
  266. 3 - are you an admin or a user?
  267. 4 - do you think there is value in including these examples?
  268. 5 - do you think the advantages of examples outweigh any risks?
  269. 6 - do you think that the versions that optimize their own behavior by
  270.       `evolving' improved forms should not be included - if not why not?
  271.  
  272. Please Email me your responses ASAP, as the book goes to press in a few
  273. weeks.  Also, if you DO NOT want your comments included in the book
  274. (no names will be used) tell me.  Otherwise, I will feel free to include
  275. any comments I find particularly enlightening.
  276. FC
  277.  
  278. ------------------------------
  279.  
  280. Date:    Wed, 24 Feb 93 17:12:12 -0500
  281. From:    Fish@DOCKMASTER.NCSC.MIL
  282. Subject: Known viruses in a UNIX evvironment (UNIX)
  283.  
  284. I'm looking for information on any known UNIX viruses, as well as any
  285. anti-viral software than runs on UNIX.  I've never heard of either,
  286. but some people who should know keep telling me they "think" they've
  287. heard of such things, so I asking for help from the Virus community.
  288.  
  289. ------------------------------
  290.  
  291. Date:    22 Feb 93 19:03:27 +0000
  292. From:    bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  293. Subject: Re: Michelangelo or STONED? (PC)
  294.  
  295. imeslsl@trex.oscs.montana.edu (LEPRICAN~~~) writes:
  296.  
  297. > time.  We tried McAfee v100, which would recognise the virus, but
  298. > would not remove it from hard drives.  It appears to be [Mich] when
  299. > it is on a drive, but when it loads itself into memory, McAfee says
  300. > it's [STONED].
  301.  
  302. This is a known bug in SCAN. It reports the Michelangelo virus in
  303. memory are Stoned, while on the disk the virus is reported correctly.
  304.  
  305. > It seems to be easily removed from floppies, but the virus infects
  306. > the partition table of hard drives, where McAfee cannot remove it.
  307.  
  308. This could be either due to a new variant of the virus, or due to a
  309. bug in CLEAN.
  310.  
  311. > Reformatting it from a write-protected floppy didn't remove it, either.
  312.  
  313. Sure, because the virus is in the MBR and FORMAT only rewrites the
  314. FAT, the root directory, and the DOS boot sector.
  315.  
  316. > Does anyone have any suggestions on how to combat this virus?
  317.  
  318. Sometimes CLEAN is able to remove new variants of MBR infectors, if
  319. you tell it to remove the [genp] virus. Another solution is to boot
  320. from a write-protected DOS 5.0 (the version is important) system
  321. diskette and to run the command FDISK/MBR.
  322.  
  323. Regards,
  324. Vesselin
  325. - -- 
  326. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  327. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  328. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  329. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  330.  
  331. ------------------------------
  332.  
  333. Date:    23 Feb 93 09:53:18 +0000
  334. From:    frisk@complex.is (Fridrik Skulason)
  335. Subject: Re: standardization (PC)
  336.  
  337. sbonds@jarthur.Claremont.EDU (007) writes:
  338.  
  339. >(Hey frisk, how about "f-prot /CARO"  as a command line switch?? ;-)
  340.  
  341. Well, the reason I cannot provide that (yet) is that I don't to exact
  342. identification...I do what I call "almost exact identification".  That
  343. is, I don't genaerate a map for each virus and calculate a checksum
  344. for the constant areas, but instead I just check a number of bytes
  345. located at various locations, to make sure I have the size correct,
  346. and know how to disinfect the file.
  347.  
  348. The problem is that if somebody makes a *very small* change to the
  349. virus, like changing a single byte, I may fail to detect it as a new
  350. variant, although I will be able to remove it, just like the original
  351. variant.  When I have implemented exact checksum-based identification
  352. of file viruses (something which I have started to implement), I will
  353. be able to stick 100% to the CARO names.
  354.  
  355. - -frisk
  356.  
  357. - -- 
  358. Fridrik Skulason      Frisk Software International     phone: +354-1-694749
  359. Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801
  360.  
  361. ------------------------------
  362.  
  363. Date:    Tue, 23 Feb 93 14:48:36 +0000
  364. From:    antkow@sis.uucp (Chris Antkow)
  365. Subject: Re: New Virus (PC)
  366.  
  367.  Actually, The Whale source code is posted on a few Canadian VX
  368. boards, however, it is in German, making any modifications by a
  369. "wannabe" virus writer a bit difficult. This is just an FYI, stating
  370. that it IS available to those who know where to look.
  371.  
  372.  Chris
  373.  antkow@eclipse.sheridanc.on.ca
  374.  
  375.  
  376. ------------------------------
  377.  
  378. Date:    Tue, 23 Feb 93 17:39:51 +0000
  379. From:    imeslsl@trex.oscs.montana.edu (LEPRICAN~~~)
  380. Subject: Re: Michelangelo or STONED? (PC)
  381.  
  382. Thanks, all of you who have given me suggestions...
  383. The latest release of Central Point Anti Virus seems to
  384. work the best, but a few others worked as well.
  385.     Until the next strain...
  386.     Leprican~~~
  387.  
  388. ------------------------------
  389.  
  390. Date:    Wed, 24 Feb 93 02:05:24 +0000
  391. From:    Joe.George@nd.edu
  392. Subject: PC Magazine on Anti-Virus Software (PC)
  393.  
  394. Hello:
  395.  
  396. Do people in this group support Pc Mag's Editor's Choice Awards to
  397. Central Point Anti-Virus and Norton's Anti-Virus?  I thought the best
  398. protection was McAfee's SCAN backed up by F-PROT or vice-versa.
  399.  
  400. In the review, F-PROT received a honorable mention because it
  401. correctly removed all of the virus's it found.  The review did not
  402. test McAfee's SCAN.
  403.  
  404. Joe George
  405. - ----------------------------------------------------------------------------
  406.  
  407. Joe George                | 
  408. University of Notre Dame  |           A cute quote goes here 
  409. joseph.m.george.4@nd.edu  |            
  410.  
  411. - ----------------------------------------------------------------------------
  412.  
  413.  
  414. ------------------------------
  415.  
  416. Date:    Wed, 24 Feb 93 03:21:10 +0000
  417. From:    Christopher Yoong-Meng Wong <cwong@cs.cornell.EDU>
  418. Subject: Re: PC Magazine reviews virus scanners (PC)
  419.  
  420. cwong@cs.cornell.EDU (Christopher Yoong-Meng Wong) writes:
  421. >influence in the industry. A summary:
  422. >
  423. >1.    Editors' choices are CPAV and NAV.
  424. >
  425. >2.    The great grandaddy of virus scanners, Mc Afee's Viruscan family, 
  426. >    was not reviewed. Nor was F-prot (though the commercial version was
  427. >    reviewed), except as an aside: "... for those comfortable with
  428. >    command line operation ... original F-prot".
  429. >    ^^^^^^^^^^^^
  430. >3.    Scanning tests involved 11 -- count them -- 11 viruses.
  431. >
  432. >4.    Review emphasized completeness of package: disinfection,
  433. >    comprehensiveness of service etc, not detection ability.
  434.  
  435. I am embarassed. Some of you might jump on me for this, so I should
  436. clarify this before others do. I should have been more thorough with
  437. my reading before posting the above. The PC Magazine article does
  438. indeed review the Mc Afee products, under the name of "Pro-Scan", a
  439. commercial product. Also, F-prot's engine was present in 3 of the
  440. products reviewed.  So, I have no complaints about the presence of
  441. those 2 products.
  442.  
  443. My main concern was their emphasis on features (interface etc) rather
  444. than actual performance. Their testing was also quite inadequate.
  445. Finally, when I said "summary", I meant "summary of what this group
  446. (and myself) might object to".
  447.  
  448. Hope this clarifies things.
  449.  
  450. Chris
  451.  
  452. ------------------------------
  453.  
  454. Date:    Wed, 24 Feb 93 08:49:31 -0500
  455. From:    G J Scobie <gscobie@castle.edinburgh.ac.uk>
  456. Subject: Request for virus tools (PC)
  457.  
  458. Hi there,
  459.  
  460. Over the years I have collected a wide range of tools to use when
  461. dealing with PC viruses.  However, I'm interested in what other readers
  462. of this board use for disassembling code, inspecting memory, protection,
  463. eradication etc etc.  I'm particularly interested in shareware/public
  464. domain software but all replies welcome.  If you could mail me direct
  465. and indicate if the product is avaliable via ftp I'll summarise for the
  466. list. The main anti-virus products are often quoted here so no need to
  467. mention these, but I'm sure there are little known utilities we would
  468. all love to hear about.
  469.  
  470. As always thanks in advance to any replies.
  471.  
  472. Cheers
  473.  
  474. Garry Scobie Edinburgh University Computing Service Scotland 
  475. e-mail: g.j.scobie@uk.ac.ed
  476.  
  477. ------------------------------
  478.  
  479. Date:    Wed, 24 Feb 93 12:16:30 -0500
  480. From:    occ@mailbox.syr.edu (Holtz John F)
  481. Subject: Maybe a virus (PC)
  482.  
  483.   I have been having problems with my hard drive recently.  About a
  484. month ago my drive was a stacked drive(Stacker 2.0).  I never had a
  485. problem with the files on the stacked part only the files on the
  486. unstacked part.  When I try to use my .exe files an error message
  487. "Unable to read drive. abort retry etc.".  I try to use norton(6.0)
  488. for a disk problem which none was found.  I also tried norton NAV(2.0)
  489. and still no problems were found.  
  490.  
  491. Currently I'm unable to boot from my harddrive.  (try sys, but no help)
  492.           All my *.exe files are not usable. 
  493.           When I try to use dos .exe files (like mem.exe) error
  494.                message "can't execute mem.exe"
  495.    
  496. I have tried formating the drive, and it worked one time, after the
  497. second time I booted the newly formated drive the same errors resulted.
  498.  
  499. Does this sound like Hardware or virus problems???
  500. John Holtz  (occ@rodan.acs.syr.edy)
  501.  
  502. system
  503. 386/25  
  504. 5.0 dos
  505. 102 meg drive (ids)
  506. (currently not using stacker)
  507.  
  508. ------------------------------
  509.  
  510. Date:    Wed, 24 Feb 93 18:36:34 +0000
  511. From:    mharlos@ccu.umanitoba.ca (Michael Harlos)
  512. Subject: FPROT, Thunderbyte, & DataCrime II (PC)
  513.  
  514. I've just run FPROT 2.07 for the first time, in a "real DOS" (not OS/2
  515. DOS) session, with several Thunderbyte TSR's loaded. One of the
  516. Thunderbyte TSR checks for suspiciuos activity.
  517. FPROT warned me that "DataCrime II virus search activity was found in memory".
  518. This warning did not occur if I ran FPROT from a clean floppy boot, or if
  519. I remmed out the lines in the autoexec.bat & config.sys files that loaded
  520. the Thunderbyte TSR's. It also doesn't occur in OS/2 DOS, in which I don't
  521. load the Tbyte programs.
  522.  
  523. I think that FPROT is giving me a false alarm on the Thunderbyte TSR
  524. (TBCHECK).
  525. No problems were noted with Scan100, OScan100 (McAfee OS/2), or
  526. Thunderbyte TBSCAN. All checked the memory as OK.
  527.  
  528. Any comments or advice would be appreciated.
  529.  
  530. Thanks,
  531. Mike Harlos    mharlos@ccu.umanitoba.ca
  532.  
  533. ------------------------------
  534.  
  535. Date:    Wed, 24 Feb 93 20:33:23 -0500
  536. From:    Anthony Naggs <AMN@vms.brighton.ac.uk>
  537. Subject: Re: F-prot/FSP/bootsum problem. Help! (PC)
  538.  
  539. Wolfgang Stiller, <72571.3352@compuserve.com>, writes
  540. >  jornj@colargol.edb.tih.no (jornj) writes:
  541. >
  542. >  > I've experienced the same problem, using Integrity Master and Stacker
  543. >  > 2.0. When I check the 'bootsector' of my stacked volume IM always
  544. >  > claims it has changed...
  545. >
  546. >  > Is this normal for Stacker? Or do I have a 'problem'?
  547. >  > (I've scanned with scan v99, fprot 2.06 and IM doesn't report any
  548. >  > other problems).
  549. >
  550. > Yes, it's a "normal" Stacker function.  Stacker creates a pseudo boot
  551. > sector on the simulated (compressed) Stacker volume.  For some reason
  552. > Stacker insists on constantly changing this sector.  ...
  553.  
  554. Stacker, (and all similar disk compression products, such as SuperStor),
  555. - -must- change the drive size informtion in the boot sector after all
  556. writes to the drive.   When the software is set up it is given a fixed
  557. amount of the physical disk to use, and making an assumption about
  558. expected compression will typically tell DOS that the compressed drive
  559. has twice the capacity of the reserved area.
  560.  
  561. As data is placed in the compressed drive the disk size must be updated,
  562. to reflect the actual compression of the portion used and the anticipated
  563. compression of the remainder.  (Compression depends significantly on
  564. file content).  The frequent updates of the disk size are important to
  565. the user, to indicate compress effectiveness, and for DOS to accurately
  566. recognise when the compressed volume is full.
  567.  
  568.  
  569. > ...  Since you can
  570. > not boot from this sector, there's little reason to check its integrity.
  571.  
  572. Yes, but there is little reason to trouble users with such details,
  573. they expect the s/w to 'know' what it should check.
  574.  
  575. > A future version of IM will recognize Stacker boot sectors and not
  576. > bother to check them.
  577.  
  578. Soon, I hope, :-)
  579.  
  580.  
  581. Hope this helps,
  582. Anthony Naggs
  583. Software/Electronics Engineer                   P O Box 1080, Peacehaven
  584. (and virus researcher)                          East Sussex  BN10 8PZ
  585. Phone: +44 273 589701                           Great Britain
  586. Email: (c/o Univ of Brighton) amn@vms.brighton.ac.uk  or  xa329@city.ac.uk
  587.  
  588. ------------------------------
  589.  
  590. Date:    Wed, 24 Feb 93 17:12:09 -0500
  591. From:    fergp@sytex.com (Paul Ferguson)
  592. Subject: Problems w/ LAN Prrotect (PC)
  593.  
  594. A question for the pundits:
  595.  
  596. Within the past two months, one of our clients has implemented INTEL
  597. Corp's LAN Protect across their LAN topology. LAN Protect was selected
  598. because of several factors, namely managability and low overhead for
  599. the server and the memory and disk requirements on the individual
  600. workstation (only a whopping 3k TSR, actually). The managability issue
  601. was critical -- this is no small LAN with 70+ Novell 3.11 servers and
  602. approximately 2500 users (and growing). We did evaluate several other
  603. NLM based antivirus products, but LAN protect fit nicely into the 
  604. scenario,
  605. based on the client's needs and technical constraints.
  606.  
  607. Additional note: All servers are IBM PS/2 Model 80's or Model 95's and
  608. the LAN topology is Token Ring currently running at 4 Mb per sec.
  609.  
  610. The initial verion was v1.50 and has since been upgraded (maintenance
  611. release) to v1.54, which we received a couple of days ago and have now
  612. installed on an isolated server to ensure that the previous problems that
  613. we experienced have been corrected. (The documemntation accompanying
  614. the maintenance disk mentioned several problems that were corrected,
  615. but did not specifically address the one that bothers me most.)
  616.  
  617. Our initial problem was that on servers that were heavily used and
  618. operated with a high degree of throughput, the server would occasionally
  619. crash. This is not a "minor" bug. The low volume servers plodded along
  620. happily. Our first suspicions were that the FRYE Utilities Management
  621. NLM (FRYESERV.NLM) and the LAN Protect NLM (LPROTECT.NLM) were somehow
  622. conflicting, but after unloading all non-Novell NLMs (and subsystem
  623. drivers), the problem would reoccur.
  624.  
  625. We have loaded the v1.54  onto a test server for a short period in order
  626. to test it (or at least simulate a real-time environment) before a mass
  627. upgrade.
  628.  
  629. Has anyone else experienced this problem? We have worked with INTEL
  630. extensively on this (and other minor) problems and their last action
  631. was to FedEx this maintenance release.
  632.  
  633. Replys welcome from anyone who has experience this or other problems
  634. with this product.
  635.  
  636. Cheers.
  637.  
  638. Paul Ferguson                     |
  639. Network Integration Consultant    |  "All of life's answers are
  640. Alexandria, Virginia USA          |   on TV."
  641. fergp@sytex.com     (Internet)    |           -- Homer Simpson
  642. sytex.com!fergp     (UUNet)       |
  643. 1:109/229           (FidoNet)     |
  644.          PGP public encryption key available upon request.
  645.  
  646. ------------------------------
  647.  
  648. Date:    Wed, 24 Feb 93 01:22:03 +0100
  649. From:    heinz@tpki.toppoint.de (Heinz Wagner)
  650. Subject: Anybody knows SHIRLEY or VIVALDI ? (PC)
  651.  
  652. Hello folks,
  653.  
  654. I think this is the right place for questions on virusses.
  655.  
  656. So please, if anyone of the readers do know something about the
  657. SHIRLEY and/or VIVALDI virus, please drop me a line.
  658.  
  659. Thi0s virus infects only .EXE files under DOS and produces a batch
  660. file with a ps+eudovariable name like 189acdfg.bat with the length of
  661. 18 ... 28 bytes in m0ost cases.  + The .bat files contain only one
  662. line like @dosshell *qDP -- Heinz
  663. Wagner        heinz@tpki.toppoint.de 2300 Kiel
  664.  
  665. ------------------------------
  666.  
  667. Date:    Wed, 24 Feb 93 01:27:32 +0100
  668. From:    heinz@tpki.toppoint.de (Heinz Wagner)
  669. Subject: Shriley and Vivaldi Part II (PC)
  670.  
  671. Sorry my computer plays tricks on me...
  672.  
  673. Last Posting continued:
  674.  
  675. This batch files contian only one line like 
  676. @dosshell %df98s/
  677.  
  678. AND I find some of these files yesterday on a computer of a friend of mine ,
  679. but all virusscanners failed.
  680.  
  681. So if there are other experiences made out there, please drop me a line,
  682. because I do not read this board regulary. Thanks a lot.
  683.  
  684. Heinz Wagner        heinz@tpki.toppoint.de
  685. 2300 Kiel
  686.  
  687. ------------------------------
  688.  
  689. End of VIRUS-L Digest [Volume 6 Issue 34]
  690. *****************************************
  691.  
  692.