VIRUS-L Digest Thursday, 7 Nov 1991 Volume 4 : Issue 213

VIRUS-L Digest Thursday, 7 Nov 1991 Volume 4 : Issue 213

Today's Topics:

Re: Hardware forever!
Re: Zipped files (PC)
Re: Clipper demo disk (PC)
Re: VShield problem with DOS 5.0 & QEMM? (PC
VSHIELD w/ MODEMS (PC)
Re: Disk Compression (PC)
Re: UNIX anti-virus program (UNIX)
Re: Hardware forever!
Virusproof systems; hardware
Re: where can I get a copy of "When Harlie Was One"?
help with INDIA Virus (PC)
Efforts
re: computer virus ^2 (PC)
Stinkfoot...malignee speaks out! (PC)
Re: Zipped files (PC)
Re: Scanning inside ZIPPED files (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to [email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [email protected].

Ken van Wyk

----------------------------------------------------------------------

Date: Tue, 05 Nov 91 16:20:56 -0500
>From: "Mike Gore" <[email protected]>
Subject: Re: Hardware forever!

Hi,

[email protected] (Fred Waller) writes:

>Writes [email protected] (Arthur Gutowski):
> > Hardware isn't absolutely necessary to solve the problem,

> Hardware is not _absolutely_ necessary, but I hold that it is the
> most practical, least expensive and most effective solution. It
> is also one that will not require updating.

Adding to this point it should be stated that there is a good
reason that a partial hardware solution is required(see below),
however regarding your very last point it should be noted that
hardware will likely have to change as system requirements change
also.

[ What follows are not comments aimed at your article but are my
2 cents on this issue ]

Software MUST have at least some minimal trusted basis from
which to work from in order to offer any long term ( read reasonable )
degree of protection. Also a system is only as good as it's weakest
link so the FULL system design must be considered. BOTH hardware and
software working together has a better chance then a collection of
after the fact patches - that indeed simply obscure the original
problem... At some point more effort will be spent trying to patch a
badly designed system then starting from scratch would...

Regarding this debate in general - One often sees the argument
that ANY system can be broken in regards to the question of fixing
this problem - but why is it that, in the REAL world, we don't leave
our money in paper bags on park benches but still use vaults
_because_of_this_fact? The lesson here is there will be a point were
some degree of protection will reduce crime to a reasonable degree
given it will cost the offender too much to be of interest. The PC
with it's hardware and software, as it stands now, is this "paper bag"
of the analogy in question...

# Mike Gore, Technical Support, Institute for Computer Research
# Internet: [email protected] or [email protected]
# UUCP: uunet!watmath!watserv1!magore
# These ideas/concepts do *not* imply views held by the University of Waterloo.

------------------------------

Date: Tue, 05 Nov 91 16:57:18 -0600
>From: [email protected] (Jeffrey Alan Licquia)
Subject: Re: Zipped files (PC)

>Are there any programs which will scan inside of Zipped files?
>Thanks in advance.

There is an archiver "front end" program called SHEZ which will do
that. Basically, it runs your favorite scan program on files you
unarchive (using ZIP, ZOO, LZH, ARC, PAK, and maybe a few others I'm
forgetting) automatically as you unarchive them. It also provides a
GUI for unarchiving, selective viewing of text files with your
favorite lister, etc.

The latest version can be found at various MS-DOS archive sites
(garbo.uwasa.fi was one, I remember) as SHEZ64.ZIP.

- --
Jeff Licquia | By His stripes YOU are healed!!!
uunet!tellab5!wheaton!jalicqui | - see Isaiah 53 -
jalicqui%[email protected] |
[email protected] | cat *.disclaimers > /dev/null

------------------------------

Date: Tue, 05 Nov 91 20:19:05 -0600
>From: Brian McGraw <[email protected]>
Subject: Re: Clipper demo disk (PC)

You said the Form virus was found on a demo diskette of Clipper.
Out of curiousity, would that be the one that was offered on TV? I had
thought about calling.
Brian
[email protected]

------------------------------

Date: Tue, 05 Nov 91 21:40:37 -0500
>From: [email protected] (Robert Yung)
Subject: Re: VShield problem with DOS 5.0 & QEMM? (PC

Huh?????
I have MS-DOS 5 and QEMM 6.0 and VSHIELD/LH works fine for me. Are
you sure QEMM does not work with VSHIELD? I don't want to have set off
a time bomb...
BTW, when I use the /LH parameter, VSHIELD left a 0.4K stub in
conventional memory. Is that normal? Can I not have it???
How about making VSHIELD device loadable so it gets to memory
first. How about packaging a dummy virus w/ the VIRUSCAN products to
test if everything is working. I'm not all that confident about VSHIELD
since I can never tell if it's working or not. The PC-MAG virus
seems nice... it fooled SCAN v70 (I think).
THANKS!

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\
| Robert 'Bobby' Yung | | That is about as effective as trying |
(| [email protected] | | to melt an iceberg with a warm stream |
| "THE MACHINE!" | | of piss. -Armmstrong |
\~~~~~~~~~~~~~~~~~~~~~~~~ |_______________________________________/

------------------------------

Date: Tue, 05 Nov 91 21:51:39 -0500
>From: [email protected] (Robert Yung)
Subject: VSHIELD w/ MODEMS (PC)

Is it possible to get a virus by just connecting to a BBS? How about
when I download? Can Vshield check stuff as it downloads as with the /V
parameter (check copying for virus)? THANKS.

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\
| Robert 'Bobby' Yung | | That is about as effective as trying |
(| [email protected] | | to melt an iceberg with a warm stream |
| "THE MACHINE!" | | of piss. -Armmstrong |
\~~~~~~~~~~~~~~~~~~~~~~~~ |_______________________________________/

------------------------------

Date: Wed, 06 Nov 91 17:15:00 +1300
>From: "Mark Aitchison, U of Canty; Physics" <[email protected]>
Subject: Re: Disk Compression (PC)

padgett%[email protected] (A. Padgett Peterson) writes:
>>... Stacker/SuperStore/DoubleDisk, etc. formats!
>
> They may not have a choice - I see this as the next real "must have"
> utilitiy as no-one ever has enough disk space.

I agree that compressed partitions are likely to VERY popular; already
I've saved the cost of the software simply by disk savings. Also, it
makes scanning for conventional viruses easier since the disks look
normal (certainly under SuperStore).

Now (dare I say it?) for the question of the next generation of
viruses that "know" about Stacker and SuperStore, etc. I presume that
such viruses would have to be big, and they're hardly likely to handle
all the brands and versions of compression software out there. The
down side is that virus scanners are going to have to understand a lot
about compressed disks (in conjunction with all sorts of other drivers
and hardware) to ensure there isn't a "super virus" there. Not too
much of a disadvantage, IMHO.

Now, has anyone tried a combination of software read-only partition
(e.g. by DMDRVR.BIN or DISKGARD) plus Stacker/SSTOR/etc (and maybe
plus DRDOS's password protection)? Thanks Frisk for the comment about
DRDOS passwords by themselves, and thanks to others for the discussion
about viruses still being in RAM, even if they can't spread to the
hard disk. The gap in the security left, apart from BSI's, is where
people bring an infected program to the system - and hopefully
compressed disks will reduce the need for programs like LZEXE, which
then mean scanners will be able to spot a higher percentage of
infected files.

I, then, see compressed partitions as a glimmer of hope (not that they
stops lots of viruses by themselves, but their contribution is
positive, overall).

Comments welcomed, as usual,
Mark Aitchison, Physics, University of Canterbury, New Zealand.

------------------------------

Date: 06 Nov 91 06:03:21 +0000
>From: [email protected] (Tommy Pedersen)
Subject: Re: UNIX anti-virus program (UNIX)

I wrote:

>[email protected] (Brian Schieber) writes:

>>I'm looking for sources for virus checking for UNIX boxes. Whats available ?

>TCell is a commercial UNIX virus checking program that the company I
>work for has developed. It uses cryptographic checksums to check for
>unexpected changes in the file system. Contact me and I'll tell you
>more about it.

[email protected] (Peter da Silva) writes:

>Are there any viruses on UNIX to actually *check* for?

[email protected] (Brian D. Howard (CS)) writes:

>No. But that never stopped nobody from selling.

No, there are no virus to check for on UNIX systems around today, so I
admit that the antiviral software TCell we are selling for UNIX
systems are a little ahead of time. There is however no doubt that
UNIX viruses can be written and also has been written. I can give you
references on at least two articles where researchers has developed
UNIX viruses. One of these articles discusses unix viruses in a B
level (according to the Orange Book) security system.

As you see above, the program we sell makes an integrity check on
files by calculating cryptograpic checksums on files. This makes it
not only usable for detecting viruses but also for detecting other
kinds of unexpected changes to files. Thus also misstakes by the
system administrator is dicovered and can be corrcted. Another usage
is to check against changes to data files and text files. When the
UNIX system is a server to a PC network, also the files the PCs use
can be checked and therefore also PC virues can be detected.

I therefore feel good about selling TCell, and besides that: The
customer always has the choise not to buy it, we live in a free
world...

Regards,

/Tommy Pedersen
______________________________________________________________________
|E-mail: [email protected] /\ |
|S-mail: Tommy Pedersen / / Telephone: +46 13 235200 |
| SECTRA-Secure Transmission AB | | FAX: +46 13 212185 |
| Teknikringen 2 |.> |
| S-583 30 Linkoping |/ |
|_______ SWEDEN ______________________________________________________|

------------------------------

Date: 06 Nov 91 09:55:38 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: Hardware forever!

[email protected] (Henk de Groot) writes:

> Incorrect, exchange your BIOS to include the following
> processor-start-up *software* (though its as drastic as the "off
> switch" but it is software :-) ):

> 1) Disable all interrupts.
> 2) Redirect NMI vector to a "reti" instruction.
> 2) Execute a "Halt" instruction which stops the processor.

Oh, there are other, less drastic software-only methods, which are
just as secure, and just as useless... :-)

> I don't know any Hardware protection boards but I assume that a board
> like the "Thunderbyte" board will contain *software* (are there
> (E)PROM's on it?), and I guess its the *software* on that board that
> prevents from viruses, not the hardware! (but like I said, I don't
> know the board).

There is a card, called Disk Defender, with which you can select a
range of cylinders on the hard disk, that are physically write
protected by switching another switch.

> I think the power in these applications is that its a *combination* of
> hardware and software. Think of what software can do if I had a very
> fast RISC processor with 80486 emulating software. This emuation

Oh, you don't need all this... Just a CPU which has protected mode
implemented (80286 will do the job, but 80386 is better) and an OS,
which effectively -uses- this mode. You can get the same state of
protection. Of virus resistence, if we use Fred Waller's term. But it
doesn't help at all to achiev virus proofness... :-( Whther you want
the latter or not, is nother story.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54

------------------------------

Date: Wed, 06 Nov 91 16:45:00 +0200
>From: Y. Radai <[email protected]>
Subject: Virusproof systems; hardware

In an earlier posting, I wrote:
>> ... if we could design a system
>>which could never be infected, this would be preferable to detection
>>after infection.

Fred Waller replies:
> I feel that it's really unnecessary to invent systems that could
> *never* be infected. A virus-resistant system is quite enough.
> We don't really need a totally virusproof approach. Some head-
> banging-against-the-wall seen here is (as always) self-inflicted
> and caused by the search for such absolutely foolproof protection
..
> So what if we allow a small leak? If the leak is small enough, it
> will be easy to monitor. Much easier than monitoring an entire
> system!

So far I haven't had the dubious pleasure of locking horns with you,
mainly because until now I hadn't had the time to read all of last
month's postings, but I guess the time has finally come. I must
admit, though, that I have considerable difficulty in deciding how to
reply to you, partly because in some of your claims you don't state
whether you are talking of prevention or of detection, and partly
because you often use terms without defining them.
Examples of such terms are "totally virusproof", "absolutely fool-
proof", "leak" and many others. In my posting, I distinguished bet-
ween two criteria:
(A) No false negatives and no false positives;
(B) No false negatives and few false positives.
The distinction between the two is especially important in the case
of detection programs, since for them *(B) is attainable*.
Now what do you mean by "totally virusproof" and "absolutely fool-
proof"? (A)? (B)? something else? Offhand, I would suppose you
mean (A). But then why criticize me when I *agree* that (A) is unat-
tainable? So maybe you mean (B). But I claim that goal is achievable
by using detection methods. You haven't said that you disagree with
that statement.

Now for your first sentence. I was certainly not trying to "invent
systems that could never be infected". I was merely prefacing my
following remarks by saying that it would be ideal if there were such
a thing. I guess you agree that it can't be done. The difference
between our approaches is that you seem to be content with preventing
what you can (I guess that's what you mean by "virus-resistant"),
whereas my emphasis is on *detection* of infection *after* files have
been infected. This is not because I am opposed to partial preven-
tion, but simply because even with this, one should (imho) have a
"second line of defense" in case a virus has managed to circumvent the
prevention mechanism. You seem to disagree with this when you say
that a virus-*resistant* system with "leaks" is enough. Well, that
depends on the price you have to pay in order to block the leaks. If
one can do this for a small price, why not do so? (At present, I'm
merely speaking in principle; I'll discuss the actual price below.)

I also don't understand this talk about "banging heads against
walls". *Precisely who* do you claim is doing this? If we assume
interpretation (A), then as Cohen showed, there's no point in trying
to achieve that goal. So if there really are people trying to do so,
maybe they would be "head bangers", but I've never heard of any. The
same would be true for goal (B) if you depend solely on prevention
programs. On the other hand, goal (B) is achievable without the
slightest need for head banging, provided you use generic detection
(which means, roughly, modification detection).

Which reminds me of a previous statement of yours:
> I've seen this claim of a "perfect antiviral detector" over and
> over here. Many people make this claim, and many have announced it
> - but NOBODY is able to produce such marvel.

Well, again I have to ask you: What do you mean by "perfect"? If you
mean in sense (A), I have never seen or heard of such claims, and I
invite you to quote a few. If, on the other hand, you mean sense (B),
then I can produce "such marvel". I mentioned it in my last posting:
V-Analyst.

Another example:
> Even though `detection' has failed, they
> still cling to it and continue searching for the Holy Grail.

Once again you don't define your terms. *What kind* of detection has
failed: virus-specific? generic? both? And again you give no argu-
ments whatsoever for your claim that detection has "failed".

We now come to the question of "leaks" (whatever *that* may mean).
You claim that we should be satisfied with a boat with a small leak
instead of one with no leak at all. Here, at long last, you give a
reason! -- namely, that a small leak is easy to monitor whereas an
entire system is not. As for the first part, all I can say is that
it's not necessarily true. As for "monitoring an entire system", it
depends on what you mean by that phrase. One can monitor each program
as it is about to be executed, either by checking for suspicious be-
havior, for known viruses, or for modifications. But I guess that's
not what you mean by "an entire system". Alternatively, one can scan
all (executable) files at once, looking either for specific viruses or
for files which have been modified.
Let's assume you mean the latter. Is your complaint that scanning
is time-consuming? I can only say that I don't find this to be the
case at all. I checksum my files all at once after cold-booting from
a clean system diskette. To checksum about 650 files takes the
checksum program which I use 4 minutes on my 12-MHz AT. On a 386, it
would go faster. And if one uses the quickcheck option to be made
available in the next version of the program, it'll probably take
considerably less than a minute.
You might also consider booting from a diskette to be difficult.
But it's essential if you don't want to be fooled by a stealth virus.
Besides, if one combines detection with (partial) prevention, as I
suggested above, then in most cases one can limit this booting from a
diskette to once a week or two.
In conclusion, I don't see any good reason for settling for a leaky
boat when the price of fixing it is small.

> Finally, the best way to achieve very high security (and stil have a
> functioning machine) is with the help of hardware. While even this
> may not yield a totally virus-proof system, it doesn't really have
> to, since we don't really need virus-proof systems.

Well, I'm not against hardware. Certainly it's the most secure of the
*prevention* techniques. I would even agree that hardware seems like
an effective technique in general. However, I have two reservations.
One is that I have never heard of an inexpensive hardware solution.
You keep *saying* that there is (you even claimed that some hardware
protection may cost much less than $70), but you have never given us
the name of a single "true" hardware product with such a price (or,
for that matter, even without such a price). Does this hardware solu-
tion of yours exist outside of your imagination?

I think if you had ever used an actual hardware device, you would
never have written, as you did in another posting of yours:
> ... assuming it has first become TSR, which in turn means that
> hardware protection was removed, ....

Becoming TSR means that hardware protection has been removed??? TSRs
reside in RAM. Have you ever heard of hardware protection of RAM?
I haven't, and from your comparison of hardware protection to a write-
protect tab, you shouldn't even be expecting such a thing.

My other reservation is based on the fact that I have personal
experience with one hardware product, Disk Defender, and even aside
from its price of $240, my experience was rather negative. When
activating the accompanying installation software, one could specify
what cylinders one wanted to be write protected, but it had to be the
trailing cylinders (i.e. from a given cylinder to the end of the
disk). And since the Master Boot Record has to be on Cylinder 0, it
couldn't be protected. Neither would the DD software (which called
FDISK) allow me to make drive C: protected. Only by using Disk
Manager instead, were we able to put C: at the end of the disk, and
thus to protect it. But I still wasn't able to protect the MBR. This
was apparently deliberate because there was an accompanying device
driver which modified the MBR at boot time. But this left the MBR
wide open to infections by Stoned, etc. I'm not claiming that DD is
your idea of true hardware protection (btw, does anyone know if DD is
still being sold?), but if you ever get around to naming any flesh-
and-blood product for us, just make sure that it doesn't suffer from
the same weakness ... and that it's inexpensive. Maybe *then* we'll
have something to talk about.

Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]

------------------------------

Date: 06 Nov 91 15:37:00 +0000
>From: [email protected] (Barry T. Drake)
Subject: Re: where can I get a copy of "When Harlie Was One"?

This is for Eqix ([email protected]). My mailer can't figure out
how to get to you. Anyway... on with the message:

I have a copy of _When_Harlie_Was_One_ which I am willing to give to you.
Send me your postal address, and I will mail it within the next couple of
days (as soon as I finish it; probably tonight).

- --Barry ([email protected])
4053 W. Ave. 42, Los Angeles, CA 90065-4604, USA

------------------------------

Date: Wed, 06 Nov 91 11:39:20 -0600
>From: "Mitch Cottrell, Sr. Research Technician" <[email protected]>
Subject: help with INDIA Virus (PC)

I am seeking information in the India virus.

The PCtools virus utility has identified the india virus as being the
virus currently infecting about 20 machines in a student lab. The
problem is easily cleared up on those machines, but will likly
reoccure due to the wid spread contamination expected on student
disks.

I am looking for informaion on what it does, and how it propogates,
and how it may be easily cleaned up on student disks.

Imediate response can be set to
[email protected]

------------------------------

Date: Wed, 06 Nov 91 13:25:41 -0500
>From: padgett%[email protected] (A. Padgett Peterson)
Subject: Efforts

>From: [email protected] (Fred Waller)

Wrote I:
>> the effort required to breach a software defense is greater
>> than that required to erect it. This comes about because the
>> defender has the advantage of being on home ground & has a
>> "world view" of the system.

Wrote Fred:
>I believe this is not true. As said earlier, virus-writing is not a
>cost-conscious activity, while antivirus protection most definitely
>is. Virus authors have the luxury of spending hours, days, weeks or
>months probing and testing until they find a weakness. Antivirus
>authors work to earn a living, sell their products and must perforce
>be cost-effective. It's really just the reverse of what Padgett
>claims.

We seem to be discussing two different things here: my comment
referred to what is *possible* for a knowlegable user to do to his/her
personal machine or those within his/her control. Fred seems to be
talking about commercial products that are as available to the
malicious software authors as to the users. I agree that in Fred's
worldview he may be right however this is not my worldview.

As I have mentioned before, my *personal* pcs are protected by a
layered mix of products, some of which I wrote and are not commercial.
As I stated, it would be very difficult for a virus to penetrate *my*
PC since the writer would have no way (short of physical B & E) to
determine exactly what is in use. (besides it changes)

For the same reason, the plethora of anti-virus products available
today are a major protection since it would be difficult for a virus
to cope with ALL of them. Now if some malefactor was targetting a
particular installation and knew exactly what they were using, and was
able to gain physical access, then I agree that any software can be
broken (some just not in a *reasonable* timeframe).

Companion viruses ? - one of my layers handles that. Stealth viruses -
another layer, and so on, and so on. Manually, I can disable all of
them in a monent but to do it in software would be *very* difficult
(and then you would also have to target the separate programs that
just verify that the other layers are still working (and can be
stored/protected on the server).

Just as an example: how does software get around an PC that does not
recognize (or have) any .EXE .COM or .BAT files ? (no, I am not going
to say what the real executable extensions are - if it is possible,
you tell me 8*) It runs all my DOS applications just fine (after
automated "fixing").

The point is that if you are at PHYSICAL risk, I will agree that
hardware (preferally encrypting the whole disk with an off-system key)
is necessary. However IMHO if the only risk is from software & the
protection scheme is unknown (or just different on every PC), then
software is GOOD ENOUGH (quantum economics (C))

Padgett

Untested product: for all the people trying to write to write-
protected floppies to see if the have the DIR-2, I have this to
say: CD 24 CD 20.

------------------------------

Date: Wed, 06 Nov 91 12:45:18 -0800
>From: [email protected] (Karyn Pichnarczyk)
Subject: re: computer virus ^2 (PC)

About the Weekly World News article about a demon-pc which killed
workers...a "hideous horned demon" appeared on the screen? Isn't
there a virus named somthing like "Posessed" which displays a low-res
picture of a demon on the screen? If I remember correctly it was a
EXE and .COM infector,and it may add a line saying something like
"Your computer is Possessed".

Karyn Pichnarczyk
CIAC Group - LLNL

------------------------------

Date: Wed, 06 Nov 91 19:51:23 +0000
>From: [email protected] (Paul Ducklin)
Subject: Stinkfoot...malignee speaks out! (PC)

StinkFoot...analysis.

I, as the person maligned in the virus, and as the author of a South
African antivirus package, had double reason to look at this stuff.
Whoever wrote it has fairly poor assembler coding skills, but it does
(sort of) work. Unfortunately, the versions I've got print their
messages in Black on Black; apart from that, nice one Cyril.

There were two versions out of the Rhodes University ftp repository;
the author of the "Paul Ducklin" one seems to have been the author (or
to have had the original source) of the other. Code reordering;
arbitrary shifts in data item offsets etc. point to this.

Version 1: Infection adds 1254 bytes.
Message is "StinkFoot has arrived on your PC !".
Message displayed (black on black) if infected
file is executed when DOS time minutes==seconds.

Version 2: Infection adds 1273 bytes.
Message is "StinkFoot: '(Eat this Paul Ducklin)'"
Displayed if hours==minutes.

The virus tries to adjust INT 24h (Critical Error Handler) to
its own code. Not only did the author fail to understand pointers
in CS100, he (no, I'm not a chauvinist -- surely no woman would
bother to write such cruddy code) wrote non-working INt 24h code
anyway. Any critical errors *after* the virus has had a go bring
down the system.

The infection mechanism is broken, too. When the virus runs, the
current directory is examined for .COM files; the first uninfected
one over 512 bytes is hit. Alas, if the target .COM is the first
one in its directory, StinkFoot hits it regardless of its size.
If it was too small, it will no longer run. Trying to run it will
hang the PC.

Anyway, it's just another virus. Unfortunately, the South African
media rather love it. What I've seen written so far in the local
press is inane..and suggests that the whole affair is so daunting
that we shall have to wait for overseas "experts" to fill us in
on the heavy news. Jawellnofine.

Paul Ducklin
Non-Surfer Extraordinaire

PS: my feet are clean and wholesome (esp. considering it's 33 degrees).

[Ed. What a coincidence - it is also about 33 degrees here in
Pittsburgh, Pennsylvania; we're even expecting some snow today. :-)]

------------------------------

Date: Tue, 05 Nov 91 10:19:50 +0000
>From: [email protected] (-= WAD =-)
Subject: Re: Zipped files (PC)

[email protected] (Jeffry Johnson) writes:
>Are there any programs which will scan inside of Zipped files?
>Thanks in advance.

Yep theres one called VIRZIP in the pdsoft.lancs in england..
But I'm not to sure of the full address..

=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
| Fleshy : -= WAD =- E-mail : csh060%[email protected] |
| Voice : (0203) 449274 Quote : 386 owners do it in windows |
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=

------------------------------

Date: Wed, 06 Nov 91 14:52:14 +0000
>From: [email protected] (-= WAD =-)
Subject: Re: Scanning inside ZIPPED files (PC)

[email protected] writes:
>In #208, Jeff Johnson asks:
>
>>>Are there any programs which will scan inside of Zipped files?<<
>
>Sure are, Jeff. MacAfee's SCAN is useable (and callable) from inside a
>program I've been trying called SHEZ. SHEZ will allow you to look
>inside any format you like; ARC, ZIP ARJ, PAK, or what have you.
>
>It won't look inside self extractors, but then you knew that I'd guess.

By the way.... where can I get the latest copy of SHEZ...

If its in Simtel-20 ... whats the ftp address !?

Cheers

=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
| Fleshy : -= WAD =- E-mail : csh060%[email protected] |
| Voice : (0203) 449274 Quote : Nano Cray, one lump or two >? |
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 213]
******************************************

Downloaded From P-80 International Information Systems 304-744-2253