alt.comp.virus Historical Hall of Fame, et al

[Bart Bailey]

Many of the known virus scanner companies tell us that we shouldn't
worry about the immediate time period. Their response is fast enough
to cover us.

Their response to what?

The wailing sounds from victim 0,
to indicated there's something needing a response?

Or is it as has been often suggested, that there's some collusion
between the respective AV/VX camps, if not a bit of overlap?

 

[kurt wismer]

["Followup-To:" header set to alt.comp.anti-virus.]
why?

[snip]
I have received a strong impression that standard AV scanners are
not useful as a primary line of defense. In other words, they don't
work as claimed.

claimed by whom? and how do you define "primary line of defense"?

 

[Bill]

claimed by whom? and how do you define "primary line of defense"?

As claimed by me, the end-all in antivirus knowledge. You should know
this, Kurt.

Bill
(ducking and running while Kurt wets his pants in laughter)

 

[kurt wismer]

Stuart Krivis wrote:
[snip]

Ok, so we've got two time periods here. Immediate is the time
between the release of a new threat and the response of the known
virus scanner companies.

Normal is the time after there is an effective response from the
known virus scanner companies.

Many of the known virus scanner companies tell us that we shouldn't
worry about the immediate time period. Their response is fast enough
to cover us.

ummm, no i don't think they tell you not to worry, they tell you to
stay as up to date as possible... that's why some of them have updates
available every day if not more frequently...

on the flip side, most 'new' viruses never actually make it into the
wild, and those that do are often not seen in the wild in sufficiently
high enough numbers to be significant to the population at large until
a much more substantial amount of time has passed... it's a couple
years ago now, but i seem to recall bpb did a study on this and found
most viruses seen in the wild were in the anti-virus signature
databases months before they got onto the wildlist (which only requires
a report from 2 wildlist participants)... i imagine that time frame has
diminished with the proliferation of worms but by how much? daily
updates seem like they should pretty much do as much as any update
frequency could do...

[snip]

Neither approach is optimal. The known virus scanner companies gloss
over the immediate threat.

Zvi requires us to support both him and the known virus scanner
companies. (I can hardly expect to rely on a known virus scanner
during the "normal" time period if I don't financially support
them.)

Am I wrong to want a complete solution?

if you are looking for a 'solution' then yes... you've been hoodwinked
by marketing people into thinking there is a 'solution' to the problem
and that's just not true... software companies provide *tools* that
help you solve discrete problems - the virus problem is not discrete
and there are no 'solution's (except for the draconian ones)...

 

[Sammi More]

"Green" not "Greene."

It really depends on whether you are talking about the recovery algorithm,
which did work in the cases I tested after accounting for the quirks and
screwups (I only tested MZ exes and COMs infected with simple appenders), or
the ToadAV program, which was so buggy and ill-designed as to be all but
non-functional.

Probably Raid could have made a useful utility if he'd kept at it, but I
imagine he was primarily interested in proving some point or other (I forget
what it was) and found little chores like writing a useful interface too
tedious to bother with.

Bob

I certainly agree, the interface and overall design did leave much to
be desired; I found the way it created .tav files for each file, and
didn't allow one for an edit.com and an edit.exe to exist at the same
time a poor design decision. But, I do remember that the documentation
accompanying the program did imply it was for internal use and never
really intended for outsiders. Again, I find myself in agreement with
you; I believe he could have turned it into a useful program had he
changed the design somewhat; The recovery algorithm itself worked as
he said it would, but the implementation was in dire need of work.

I did not mean to imply that you tainted the results of your testing,
It was raid's fault you weren't properly briefed on how to use the
program; And his fault the program was so... finicky as to be almost
impossible to use it.

 

[Stuart Krivis]

Their response to what?

The wailing sounds from victim 0,
to indicated there's something needing a response?



Or is it as has been often suggested, that there's some collusion
between the respective AV/VX camps, if not a bit of overlap?

AV wouldn't thrive without VX.

Still, I'm skeptical about claims of collusion or overlap. The AV
people don't really need to encourage or support the VX people;
there are enough social misfits around to stir things up as is.

 

[Stuart Krivis]

["Followup-To:" header set to alt.comp.anti-virus.]

why?

Probably hit the wrong key in slrn.

[snip]

I have received a strong impression that standard AV scanners are
not useful as a primary line of defense. In other words, they don't
work as claimed.

claimed by whom? and how do you define "primary line of defense"?

Claimed by the companies selling the product. I haven't seen any of
them telling you that you also need to buy a copy of IV along with
their scanner. Their advertisements lead you to believe that you'll
be protected if you buy their scanner.

IV would seem to be a better primary line of defense because it
alerts you to virus activity. Scanners simply alert you to the
presence of a known virus, and you're exposed during the critical
first few hours.

There have been a number of recent cases where new malware brings
your network to its knees, so you may not even be able to _get_
updates to your scanner.

 

[kurt wismer]

Stuart Krivis wrote: [snip]

I have received a strong impression that standard AV scanners are
not useful as a primary line of defense. In other words, they don't
work as claimed.

claimed by whom? and how do you define "primary line of defense"?

Claimed by the companies selling the product. I haven't seen any of
them telling you that you also need to buy a copy of IV along with
their scanner.

frankly they don't tell you you have to do anything... they just tell
you how to use their product and that's it...

Their advertisements lead you to believe that you'll
be protected if you buy their scanner.

and? soft drink companies lead you to believe you'll be cool if you
drink their product... surely no one takes marketing literally...

IV would seem to be a better primary line of defense because it
alerts you to virus activity.

??? this primary line of defense, then, would not be the same as the
first line of defense - since the first line of defense should try to
stop things before there is any 'activity' to alert on...

Scanners simply alert you to the
presence of a known virus, and you're exposed during the critical
first few hours.

i think you're blowing that window of exposure a little out of
proportion...

 

[Ant]

That's not true; ToadAV was entirely blind as to the internal
structure of the file in question. Or did you not know that? It was a
very generic file restoration tool. Nothing more, Nothing less; In
fact, it was designed very similiar to yours; only it held more data
in it's checksum files then your product.
[snip]

I have it's source code, Would that suffice? I can post it, I don't
require permission; It's an abandoned program from yesteryear.

Perhaps you could put the source on a web page. I'd be interested to
see how an overwritten file could be restored from a checksum, which
presumably will be much shorter than the original file.

 

[Robert Green]

That's not true; ToadAV was entirely blind as to the internal
structure of the file in question. Or did you not know that? It was a
very generic file restoration tool. Nothing more, Nothing less; In
fact, it was designed very similiar to yours; only it held more data
in it's checksum files then your product.
[snip]

I have it's source code, Would that suffice? I can post it, I don't
require permission; It's an abandoned program from yesteryear.

Perhaps you could put the source on a web page. I'd be interested to
see how an overwritten file could be restored from a checksum, which
presumably will be much shorter than the original file.

Don't need the source to answer that. Raid's integrity record for a single
file was 8Kb in length (for comparison, an IVB file record is 66 bytes).
Overwriters are 1) usually pretty small and 2) overwrite the front of the
file, so there is plenty of room in the integrity record to save the actual
code that is likely to be overwritten. Simple process, doesn't involve using
the file checksum except for verification.

Bob

 

[Guillermito]

Don't need the source to answer that. Raid's integrity record for a single
file was 8Kb in length (for comparison, an IVB file record is 66 bytes).

Sounds more like a backup program than a cheksum restorer

To restore executables from a checksum or a small integrity database is
basically a trade-off, a sort of difficult balance to find between the
size of the database and the percentage of files you will be able to
restore.

If you save the whole executable, you will be able to restore all
infected files. Sounds obvious, and that's called a backup If you
save the first 8 kb, you will be able to restore from a whole lot of
overwriters, but not from modern win32 infectors. If you just save 66
bytes, I guess you will have to choose them very well to restore most
files.

Just for the curious mind interested about how some products can restore
infected files without doing a whole backup, a generic anti-virus
product I won't cite for legal reasons (let's just say that it's not
Invircible) saved, for PE, the whole PE header and sections headers, and
the 16 first bytes of each sections (and a few other cheksums, size,
etc). For DOS exe, the whole MZ header, the 16 first bytes of code, and
some other bytes (the last 6 bytes I think), and again a few checksums
and sizes.

So, of course, the database files were kind of big, this program could
recover from most classical viruses that change the entry point, put a
"jump virus code" (it's less than 16 bytes) in the first section, and/or
add a new section, but obviously, it could not recover from all. I
remember that win32.Parvo by Griyo/29A, for example, sometimes modified
the 256 first bytes of the executable section, and so, with just 16
bytes saved, the anti-virus couldn't recover the file.

It's not a criticism (please hold back the lawyers!). It's just to show
that it's difficult to find a good balance between how many bytes you
save and how many executables you will be able to recover. It's
obviously easier to repair more files with 8 Kb saved than just 66
bytes.

 

[Sammi More]

Sounds more like a backup program than a cheksum restorer

To restore executables from a checksum or a small integrity database is
basically a trade-off, a sort of difficult balance to find between the
size of the database and the percentage of files you will be able to
restore.

If you save the whole executable, you will be able to restore all
infected files. Sounds obvious, and that's called a backup If you
save the first 8 kb, you will be able to restore from a whole lot of
overwriters, but not from modern win32 infectors. If you just save 66
bytes, I guess you will have to choose them very well to restore most
files.

Just for the curious mind interested about how some products can restore
infected files without doing a whole backup, a generic anti-virus
product I won't cite for legal reasons (let's just say that it's not
Invircible) saved, for PE, the whole PE header and sections headers, and
the 16 first bytes of each sections (and a few other cheksums, size,
etc). For DOS exe, the whole MZ header, the 16 first bytes of code, and
some other bytes (the last 6 bytes I think), and again a few checksums
and sizes.

So, of course, the database files were kind of big, this program could
recover from most classical viruses that change the entry point, put a
"jump virus code" (it's less than 16 bytes) in the first section, and/or
add a new section, but obviously, it could not recover from all. I
remember that win32.Parvo by Griyo/29A, for example, sometimes modified
the 256 first bytes of the executable section, and so, with just 16
bytes saved, the anti-virus couldn't recover the file.

It's not a criticism (please hold back the lawyers!). It's just to show
that it's difficult to find a good balance between how many bytes you
save and how many executables you will be able to recover. It's
obviously easier to repair more files with 8 Kb saved than just 66
bytes.

The program does not store the entire contents of the file; unless
said file is under 8k; then I think? it's all stored in the .tav file.
Raid mentioned in the documentation that cavity infectors? Would not
be removable with ToadAV due to the infection method they use. Is this
what you mean with headers? ToadAV (paraphrasing from poor
documentation) was designed to remove some overwriters, prependers and
appender based viruses only. The documentation stated this restoration
would work with those class of viruses on almost any executable
format; As long as you weren't dealing with something larger then 8k.

I merely pointed ToadAV as an option for some limited usage, when Zvi
Netiv? suggested nothing existed for PE based executables; Which
caused him to mislead? or attempt to do so, imho readers of this
forum. While I admit I'm not a programmer, I'm not blind either. I've
seen ToadAV in action when I mangled some of my windows executables;
What I saw happen and what Zvi claims are not one in the same. My
apologies for making this thread longer over abandoned software then
it needed to be. I'm sure I'm not the first to respond to mr Netiv's
bogus claims.

As it were!

 

[Zvi Netiv]

This is where the ingenuity of the BRM patent lies (the one that was at the core
of Untouchable).

Saving 8 kb per file is dumb and shows total misunderstanding of executable
files structure and how they work. The point Raid tried to make was that he
could restore from his own overwriting "virus", which was one of a kind and a
dead end. Overwriters had no real presence in the wild, and shouldn't be
considered as virus at all since they do not preserve the host's functionality.

The purpose of the integrity signature is not necessarily to restore infected
files, but mostly to provide a means to discriminate between viral changes and
benign ones (like the replacement of a program with a newer version, for
example). The selection of 66 bytes per file in IV's design was driven by the
above consideration, and not from recovery ones.

It's worth to mention here that the original method is still used in IV for the
detection of viral changes in PE objects, which is at the base of IV's
Interceptor real-time integrity monitoring - see
www.invircible.com/news/item/81.

The method was plagiarized by Eyal Dotan from my early V-Guard product,
pretending that he invented it (he was an eleven years old kid when his father's
company, Tegam, started selling our product in France). Even the product's name
was stolen from ours. See www.invircible.com/download/tegam/

There are more infection schemes that the above method cannot recover.
Personally, I think that generic recovery of infected PE isn't worth the effort,
only detection.

Oversimplified and plain incorrect. FWIW, even 16 bit infectors aren't pure
prependers nor appenders. A simple example are COM infectors derived from
'Jerusalem' (there are well over a hundred strains, of which almost all became
common and were in the wild at one time or another) do both prepend and append.

The program does not store the entire contents of the file; unless
said file is under 8k; then I think? it's all stored in the .tav file.
Raid mentioned in the documentation that cavity infectors? Would not
be removable with ToadAV due to the infection method they use. Is this
what you mean with headers?

Raid demonstrated remarkable ignorance when making his claims. Cavity infectors
are all about the EXE header and are disinfected by header oriented recovery
methods (like in IV, and also implemented in NAV, Thunderbyte, and eSafe). Raid
proved to have no clue on the subject which is why he needed eight kbytes of
"database" per file.

ToadAV (paraphrasing from poor
documentation) was designed to remove some overwriters, prependers and
appender based viruses only. The documentation stated this restoration
would work with those class of viruses on almost any executable
format; As long as you weren't dealing with something larger then 8k.

ToadAV had no potential to evolve into a useful utility for the simple reason
that it used brute force where brain is required. The huge eight kbyte database
per secured file is useless and was less potent than the 36 significant bytes
per file used in IV (that's correct, of the 66 bytes per file, only 36 are
significant to restore an EXE object from infection, the rest are overhead like
the filename and spare.

A simple example will clarify how senseless Raid's choices were: MPLAYER.EXE is
a simple PE file of 156 kbytes in size. Its code entry point is at offset
92,000, roughly, with PE sections scattered from the end of the 16 bit stub to
the code section entry point. How do you cater for changes in several sections
with just 8 kbytes, and senselessly selected?

I merely pointed ToadAV as an option for some limited usage, when Zvi
Netiv? suggested nothing existed for PE based executables; Which
caused him to mislead? or attempt to do so, imho readers of this
forum.

ToadAV had no potential to handle genuinely infected PE files. PE infectors
apply complex transformations by modifying sections and sometimes rearranging
them. Which is why the detection of viral changes in a PE object requires a
different algorithm from the one required to process 16 bit objects, not to
mention to restore them. ToadAV had nothing of the sort nor the potential to
evolve into.

While I admit I'm not a programmer, I'm not blind either.
I've seen ToadAV in action when I mangled some of my windows executables;
What I saw happen and what Zvi claims are not one in the same.

If testing generic recovery was as simple as "mangling", then the NCSA wouldn't
ask for a sum with four zeros to develop a test protocol required to certify
generic AV products like ours, when I asked them to in the mid nineties.

What you saw happen is trivial and one must be quite some ignorant to accept
primitive mangling as a valid test of generic recovery.

My apologies for making this thread longer over abandoned software then
it needed to be. I'm sure I'm not the first to respond to mr Netiv's
bogus claims.

Before yelling foul, please learn the correct use of "then" and "than".

Regards, Zvi

 

[Roger Wilco]

Overwriters had no real presence in the wild, and shouldn't be
considered as virus at all since they do not preserve the host's functionality.

Ha ha ha. So if it is not parasitic, you don't consider it a virus? What definition of virus are you using?

 

[Zvi Netiv]

Ha ha ha. So if it is not parasitic, you don't consider it a virus? What definition of virus are you using?

"Virus: Parasitic computer code that replicates by producing functional copies
of itself into host files. The infected hosts inherit the replication ability of
the affecting virus, in addition to maintaining the original functionality of
the host program or file."

Regards

 

[Roger Wilco]

"Virus: Parasitic computer code that replicates by producing functional copies
of itself into host files. The infected hosts inherit the replication ability of
the affecting virus, in addition to maintaining the original functionality of
the host program or file."

That looks more like a good definition for "parasitic file infector virus" than "virus".

 

[Zvi Netiv]

That looks more like a good definition for "parasitic file infector virus" than "virus".

Not only. It's also the proper definition of a macro virus. Are there viruses
(in the context of this thread) that aren't covered by the above definition?
Frankly, I don't see your point!

If you have a difficulty understanding my previous posts, and how they connect
to the above definition, then let me remind you that the discussion was about
the recovery of infected files of various sorts. The recoverability of infected
files is entirely based on the last part of the definition, as formulated above.

Is there need to explain you why?

 

[Roger Wilco]

Not only. It's also the proper definition of a macro virus. Are there viruses
(in the context of this thread) that aren't covered by the above definition?
Frankly, I don't see your point!

Your claim that overwriters shouldn't be considered viruses was wrong, and saying that overwriters shouldn't be considered
parasitic file infectors (reference to sub-thread) is a given and so wouldn't have been necessary to state.

If you have a difficulty understanding my previous posts, and how they connect
to the above definition, then let me remind you that the discussion was about
the recovery of infected files of various sorts.

True, but when talking about a 'parasitic file infector' virus subtype you should state it as such and not add confusion by
calling other subtypes like 'overwriters', non-viruses.

The recoverability of infected
files is entirely based on the last part of the definition, as formulated above.

Is there need to explain you why?

No, I understand retaining the original function of a program (or set of programs) while adding new functionality constitutes
a parasitic modification. This is an aid to the success of virally modified program files, but it is not a 'must do' thing for a
program to be considered a virus. I'm beginning to feel as though you are the kind of person who is never wrong - only
misunderstood.

 

[ScaredyKat]

At least that crap about me not liking dogs has been edited out of there.

 

[Zvi Netiv]

Your claim that overwriters shouldn't be considered viruses was wrong, and Saying that overwriters shouldn't be considered parasitic file infectors (reference to sub-thread) is a given and so wouldn't have been necessary to state.

There is no parasitic file infector "subtype", all file infectors are parasitic
by definition. Secondly, I didn't say that overwriters shouldn't be considered
as parasitic file infectors, but that they aren't viruses at all, by definition,
since they do not satisfy the very basic requirement of replicability.

True, but when talking about a 'parasitic file infector' virus subtype you should state it as such and not add confusion by calling other subtypes like 'overwriters', non-viruses.

As stated, all file infectors are parasitic, and overwriters aren't a virus
sub-type. They are just overwriters, or virus wannabe, if you prefer.

BTW, where from do you take the pretence to tell others what they should say or
not say, and how?

No, I understand retaining the original function of a program (or set of programs) while adding new functionality constitutes a parasitic modification. This is an aid to the success of virally modified program files, but it is not a 'must do' thing for a program to be considered a virus.

Wrong. Replication is the one requirement from which the "virus" definition
stems. That definition says nothing about the requirement on how many
generations replicability should persist in order to be considered a virus. Yet
general acceptance is that replicability should be maintained regardless of the
generation order. This is why "the infected hosts inherit the replication
ability of the affecting virus, in addition to maintaining the original
functionality of the host program or file", stems directly from the strict
definition of virus, and excludes overwiters and other virus-wannabe since they
hinder replicability.

The last part of the above is also the foundation to that virus infected files
are (theoretically) recoverable all. Which is not the case for files that were
modified by destructive code, like overwriters.

I'm beginning to feel as though you are the kind of person who is never wrong - only misunderstood.

This is just an appearance. Maybe because unlike yourself, I do not insist
on posting when I have nothing worth saying, or contribute to the discussion.

Regards, Zvi