smith@aic.nrl.navy.mil (Russ Smith) (02/14/89)
[this note sent to the generic Internet address "amiga-relay"] I just FTPed over to xanth and grabbed the AmigaUUCP files (two arc files containing individually two WARP files. Contained in file 2 was a readme and an executable, warp, as well). Well, I just did a "strings" command (UNIX machine) of the warp executable and saw: . . . \ORm T@2- TON]NuSCA!SCA! Virus by Byte LSD!LSD! Byte Bandit %sWARP v1.2A: %s A floppy disk %stracker%s and %scompressor%s.%s ---------------------------------------%s READ Bad arguments for READ. . . . Pardon, but I know little about Warp. Does it contain the above "SCA!..." stuff on purpose (like for pattern matching)? I noticed that later on it has a string that says something like "Sorry Bud, but this disk is infected..." or something. Anywho, I won't be dewarping those files til I get a good answer... Thanks for any response. =========================================================== ...uunet!mimsy!nrl-aic!hengeema!smith / ^^^^^^^^ Russ Smith - a.k.a. | \ |--- Amiga! smith@aic.nrl.navy.mil
akl@mentor.cc.purdue.edu (Rob Tillotson) (02/14/89)
In article <8677@louie.udel.EDU> smith@aic.nrl.navy.mil (Russ Smith) writes: >Pardon, but I know little about Warp. Does it contain the above "SCA!..." >stuff on purpose (like for pattern matching)? I noticed that later on >it has a string that says something like "Sorry Bud, but this disk is >infected..." or something. As far as I know it is supposed to be there. I have used Warp both for compression and decompression a number of times, and on several occasions it has warned me that the disk was infected with a virus, and identified what type of virus. Presumably, that's what the strings are for... checking the boot block for such strings seems like a convenient way of detecting specific virus types... In any event, I've never known Warp to *introduce* a virus onto any disk I've un-Warped to, so my opinion is that you shouldn't worry about it. G'day, eh? --TS -- Rob Tillotson Usenet: akl@mace.cc.purdue.edu 320 Brown St. #406 BITNET: ROBT@PURCCVM West Lafayette, IN 47906 Fido: 1:201/40.302
tadguy@cs.odu.edu (Tad Guy) (02/14/89)
In article <8677@louie.udel.EDU> smith@aic.nrl.navy.mil (Russ Smith) writes: >[ finds virus-like strings in the warp executable on xanth.cs.odu.edu ] In article <1316@mentor.cc.purdue.edu>, akl@mentor (Rob Tillotson) writes: > As far as I know it is supposed to be there. I don't care how useful this is, this kind of functionality just isn't appropriate. I turned off access to the AmigaUUCP files on xanth when I saw the first message showing the virus strings in the warp on xanth. It has since been turned back on, but with a warning README in that directory. I wonder how many other observant people noticed those strings, and ended up discarding the software? They probably did the right thing. ...tad -- Tad Guy <tadguy@cs.odu.edu> Old Dominion University, Norfolk, VA
akl@mentor.cc.purdue.edu (Rob Tillotson) (02/15/89)
In article <7630@xanth.cs.odu.edu> tadguy@cs.odu.edu (Tad Guy) writes: >In article <8677@louie.udel.EDU> smith@aic.nrl.navy.mil (Russ Smith) writes: >>[ finds virus-like strings in the warp executable on xanth.cs.odu.edu ] > >In article <1316@mentor.cc.purdue.edu>, akl@mentor (Rob Tillotson) writes: >> As far as I know it is supposed to be there. > >I don't care how useful this is, this kind of functionality just isn't >appropriate. Why isn't it appropriate? Warp's purpose is to compress entire disks for transit, preserving all data including the boot block. It seems to me that checking the boot block for known viruses when it is transferred is a very appropriate idea. In fact, *not* checking for viruses in a program such as Warp would be highly irresponsible given its function. Remember, not everyone uses a standard virus checking program, and those who do are not necessarily going to be using it at the moment they unwarp or boot a recently unwarped disk. >I wonder how many other observant people noticed those strings, and >ended up discarding the software? They probably did the right thing. I would certainly be suspicious of such strings in a program that had nothing to do with boot blocks, but Warp does. Considering that Warp does have a reason to be checking for viruses, I would try to find out whether that was indeed their function, rather than discarding the program entirely. I figure it is always better to give such a program the benefit of the doubt and figure out *why* it looks like it has a virus, rather than throwing possibly harmless code out the window because it looks a little bit suspicious. G'day, eh? --TS Disclaimer: I didn't write Warp, I just use it every now and then. And Purdue probably doesn't care. -- Rob Tillotson Usenet: akl@mace.cc.purdue.edu 320 Brown St. #406 BITNET: ROBT@PURCCVM West Lafayette, IN 47906 Fido: 1:201/40.302
tadguy@cs.odu.edu (Tad Guy) (02/15/89)
In article <7630@xanth.cs.odu.edu> tadguy@cs.odu.edu (Tad Guy) writes: >I don't care how useful this is, this kind of functionality just isn't >appropriate. and in article <1323@mentor.cc.purdue.edu>, akl@mentor (Rob Tillotson) writes: > Why isn't it appropriate? Warp's purpose is to compress entire disks >for transit, preserving all data including the boot block. It seems to me >that checking the boot block for known viruses when it is transferred is a >very appropriate idea. It's just the UNIX programmer in me showing -- a utility should do one thing well (and do it quietly). If I want an image of a disk, I use a utility to get an image of a disk. If I want to look for viruses, I use a utility to look for viruses. I don't want comments from the first utility about my disk unless it is directly related to copying the disk (``Can't read cyl'', etc.) > I would certainly be suspicious of such strings in a program that had >nothing to do with boot blocks, but Warp does. Why is a boot block special? Doesn't warp check for viruses throughout the disk (it might catch itself)? I'm being facetious, of course. My point is that I think it should just make the copy of the disk and be done with it. Philosophy. There is no right answer. ...tad -- Tad Guy <tadguy@cs.odu.edu> Old Dominion University, Norfolk, VA