home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.173 < prev    next >
Text File  |  1995-01-03  |  6KB  |  139 lines
  1. VIRUS-L Digest   Friday, 11 Aug 1989    Volume 2 : Issue 173
  2.  
  3.  
  4. VIRUS-L is a moderated, digested mail forum for discussing computer
  5. virus issues; comp.virus is a non-digested Usenet counterpart.
  6. Discussions are not limited to any one hardware/software platform -
  7. diversity is welcomed.  Contributions should be relevant, concise,
  8. polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU.  Information on
  9. accessing anti-virus, document, and back-issue archives is distributed
  10. periodically on the list.  Administrative mail (comments, suggestions,
  11. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  12.  - Ken van Wyk
  13.  
  14.  
  15. Today's Topics:
  16.  
  17.  
  18. Re: LaserWriter (Mac)
  19. Re: DataCrime II - tiny clarification (PC)
  20. Re: Memory Resident ViruScan (PC)
  21. DATACRIME-2 (PC)
  22.  
  23.  
  24. ---------------------------------------------------------------------------
  25.  
  26.  
  27. Date:    Thu, 10 Aug 89 09:13:59 -0400
  28. From:    Tom Coradeschi <tcora@PICA.ARMY.MIL>
  29. Subject: Re: LaserWriter (Mac)
  30.  
  31. >Is there such a thing as a LaserWriter virus on an AppleTalk net?  We
  32. >printed out a directory listing from a MacII hooked to a net and on
  33. >two of the pages got these large black lock-like looking things in the
  34. >middle of the page.  The funny thing is, they were different sizes,
  35. >one was big, one was small.
  36.  
  37. If the lock looking things were next to files or folders, (assuming
  38. you sorted the directory by name, type, size or date, of course) that
  39. means that the files they were adjacent to are locked. Select those
  40. files under the Finder and to a "Get Info..." (CMD-I), and you should
  41. see the locked file checkbox marked. If the locks _aren't_ next to any
  42. files... you got me swingin'.
  43.  
  44. tom c
  45.                Electromagnetic Armament Technology Branch
  46.       US Army Armament Research, Development and Engineering Center
  47.                     Picatinny Arsenal, NJ 07806-5000
  48.                         ARPA: tcora@pica.army.mil
  49.   UUCP: ...!{uunet,rutgers}!pica.army.mil!tcora BITNET: Tcora@DACTH01.BITNET
  50.  
  51. ------------------------------
  52.  
  53. Date:    10 Aug 89 20:52:18 +0000
  54. From:    kelly@uts.amdahl.com (Kelly Goen)
  55. Subject: Re: DataCrime II - tiny clarification (PC)
  56.  
  57. The comments about the cache usage on datacrime2 is somewhat
  58. fallacious... while there is most certainly the 6 byte instruction on
  59. board the chip and its status is relayed via signal pins to external
  60. devices... that is not the reason why CV and debug lose control during
  61. the jmp to loc 124(1 byte into a multibyte instruction...the actual
  62. reason is that while tracing under cv a set of internal simulation
  63. registers are continually utilized, the jump into the middle of an
  64. instruction causes them to lose synchronization with the program
  65. running...these simulation registers are what allow the debugger to
  66. disassemble code correctly... TurboDebug's ability to merely handle
  67. the the situation without error merely means that more robust code is
  68. executing than codeview...(I have the latest for both and have tested
  69. both) datacrime2 code was more unique than most viruses in this regard
  70. but hardly very sophisticated...
  71.                                   cheers
  72.                                   kelly
  73. p.s. before suspecting true skulduggery exmine the tool for fallacious
  74. results!!  disclaimer I do not represent Amdahl Corp...or Onsite
  75. consulting I represent me(myself only)
  76.  
  77.  
  78. ------------------------------
  79.  
  80. Date:    Thu, 10 Aug 89 09:14:56 -0400
  81. From:    bnr-vpa!bnr-fos!bnr-public!mlord@gpu.utcs.toronto.edu (Mark Lord)
  82. Subject: Re: Memory Resident ViruScan (PC)
  83.  
  84. Would you consider perhaps someday posting VIRUSCAN to
  85. comp.binaries.ibm.pc ?
  86.  
  87. I know I would love to have a copy, and there are probably thousands
  88. of other interested onlookers as well.  I know there are archive
  89. sites, but that doesn't help those of us who lack BITNET and FTP
  90. access.
  91.  
  92. Cheers,
  93.  
  94. - -Mark
  95.  
  96. ------------------------------
  97.  
  98. Date:    Thu, 10 Aug 89 22:20:31 -0700
  99. From:    portal!cup.portal.com!Alan_J_Roberts@Sun.COM
  100. Subject: DATACRIME-2 (PC)
  101.  
  102.     I just caught David Chess's posting about the Datacrime-2 virus.
  103. He's absolutely correct about the ease in bypassing the virus's
  104. de-garbling code.  Not that I had a chance to find out for myself.  As
  105. I was psyching myself up to the disassembly challenge, John McAfee
  106. sent me two very good and well commented disassemblies, one of which,
  107. I believe, was from David Chess himself.  It's not very satisfying to
  108. settle for someone else's disassembly, no matter how well done, but
  109. it's even harder to do your own when at least two are in front of your
  110. face.  Which leads me to a question.  Why do three or four dozen
  111. people (at least) disassemble every new virus that pops up?  I'm not
  112. complaining in the least.  Just wondering if some of us are redundant.
  113. Should we maybe draw straws to see who gets to do the next one, and
  114. the rest of us go see a movie or something instead?  I don't know.
  115. But back to the Datacrime-2.  Even though, as I was shown, you can set
  116. a breakpoint at 124H, it is still unnerving not to be able to single
  117. step a virus.  I like to take my time - do one instruction and
  118. contemplate it.  Savor the meaning of a single branch instruction; the
  119. simplicity of an XOR; the power of a multiply.  To be forced to submit
  120. to the brutal pace of two to three hundred operations per millisecond
  121. - - even for a short loop - is not my idea of a good time.  And as to
  122. Dave's comment about adding 90 seconds to his disassembly time, he can
  123. only speak for himself.  When MY debugger kicked out to DOS, I spent
  124. at least a half hour trying to figure out which virus had infected my
  125. debugger, and how could I have been so stupid as to let it happen.  I
  126. spent the next half hour complaining about the bug in Codeview, and
  127. the half hour after that I watched a 1963 Andy Griffith Show on
  128. television to try and calm down.  So I'm not so sure the virus
  129. designer was just showing off.  He/she/it nearly off'd one of us.
  130.  
  131. Alan Roberts
  132.  
  133. ------------------------------
  134.  
  135. End of VIRUS-L Digest
  136. *********************
  137.  
  138. Downloaded From P-80 International Information Systems 304-744-2253
  139.