Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > Trojan horse Downloader.Generic.ML

Reply
Thread Tools

Trojan horse Downloader.Generic.ML

 
 
Zvi Netiv
Guest
Posts: n/a
 
      07-03-2005
"Roger Wilco" <> wrote:
> "Zvi Netiv" <support@replace_with_domain.com> wrote in message


[...]
> > > > Cohen's definition of virus: "A program that can 'infect' other programs by
> > > > modifying them to include a possibly evolved version of itself".
> > > >
> > > > The definition I use expands on what is implied in the above. Nothing was
> > > > omitted, nor added.
> > >
> > > The above implies nothing about the host's function still being intact.
> > > The 'inclusion' of something in a set does not imply that something else
> > > was not excluded - neither does it imply that it wasn't. You added that
> > > original host function must be retained in the resulting infected
> > > program thus further constraining the set of what you will call a virus.

> >
> > The subject was discussed at length in the thread below, in which you took part.
> >

> http://groups-beta.google.com/group/...2df4cd6947d7cc
> >
> > I see no new arguments worth discussing.

>
> With your obvious grasp of technical material it just surprised me that
> you use this as a definition for virus. Ay least this time I don't feel
> so all alone in my reluctance to agree with it.


I first used that definition in my presentation (and paper) to the NCSA
Conference of '91, in front of almost everyone in the field, at that date. I
don't remember any objection to my interpreted definition from the audience, not
then, nor later on, in endless discussions on generics vs classic AV. On the
contrary. Quite a few adopted my interpretation and based similar features upon
(Thunderbyte, Symantec, BRM - Fifth Generation, Eliashim).

> In any future
> discussions about viruses we'll just have to keep in mind that you use a
> rather unique definition.


From you it almost sounds like being excommunicated.

Regards, Zvi
--
NetZ Computing Ltd. ISRAEL www.invircible.com www.ivi.co.il (Hebrew)
InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
 
Reply With Quote
 
 
 
 
Roger Wilco
Guest
Posts: n/a
 
      07-05-2005

"Zvi Netiv" <support@replace_with_domain.com> wrote in message
news:...
> "Roger Wilco" <> wrote:

[snip]

> > With your obvious grasp of technical material it just surprised me

that
> > you use this as a definition for virus. Ay least this time I don't

feel
> > so all alone in my reluctance to agree with it.

>
> I first used that definition in my presentation (and paper) to the

NCSA
> Conference of '91, in front of almost everyone in the field, at that

date. I
> don't remember any objection to my interpreted definition from the

audience, not
> then, nor later on, in endless discussions on generics vs classic AV.

On the
> contrary. Quite a few adopted my interpretation and based similar

features upon
> (Thunderbyte, Symantec, BRM - Fifth Generation, Eliashim).


And yet the paper I quoted the definition from was titled "EICAR 2000
Best Paper Proceedings" and the author saw fit to explicitly state that
host functionality was not an issue instead of simply omitting any
mention of it. Probably to avoid another misinterpretation such as you
exhibit. In our previous discussion you also seemed to have
misinterpreted something about first generation viruses - just because
they are deemed not worthy of inclusion in test beds for AV comparatives
does not mean they fail to meet the definition of virus. Sure, some
can't be treated the same in the AV arena because they are not
"infected" per se but they do meet the definition. You were correct
about them being "best treated" as trojans - but that doesn't make them
trojans and not viruses.

> > In any future
> > discussions about viruses we'll just have to keep in mind that you

use a
> > rather unique definition.

>
> From you it almost sounds like being excommunicated.


Not so bad really - it's not like we're ever likely to to need to
discuss thoses viruses that don't preserve host functionality since most
of them do. But if one fails to achieve this in some spreading attempts
it (the corrupted host with added viable viral code) should still be
considerd a virus if the attempted execution of the host results in
execution of the virus code.


 
Reply With Quote
 
 
 
 
Zvi Netiv
Guest
Posts: n/a
 
      07-07-2005
"Roger Wilco" <> wrote:
> "Zvi Netiv" <support@replace_with_domain.com> wrote in message


[...]
> In our previous discussion you also seemed to have
> misinterpreted something about first generation viruses - just because
> they are deemed not worthy of inclusion in test beds for AV comparatives
> does not mean they fail to meet the definition of virus.


Our previous discussion was about whether overwriters should be considered
viruses or not. Gen 1 samples were introduced to the discussion from Bontchev's
paper on how to maintain a virus collection. I have no particular position in
regard of these samples. You may consider them as valid viruses according to
the definition, including my stringent one. Gen1 are actually a "do nothing"
executable to which the virus code was added. The only difference between a
gen1 file and a real infection is that the latter was created by a spontaneous
infection process, and the previous was created artificially, through
compilation. Note that spontaneity isn't required anywhere in the definition of
virus.

> Sure, some
> can't be treated the same in the AV arena because they are not
> "infected" per se but they do meet the definition. You were correct
> about them being "best treated" as trojans - but that doesn't make them
> trojans and not viruses.


You are confusing between droppers and genuine first generation virus samples.

> > > In any future
> > > discussions about viruses we'll just have to keep in mind that you use a
> > > rather unique definition.

> >
> > From you it almost sounds like being excommunicated.

>
> Not so bad really - it's not like we're ever likely to to need to
> discuss thoses viruses that don't preserve host functionality since most
> of them do.


Do you have a difficulty admitting that they all do? Taking it one step
further, can you formulate in words what that implies? Could it be that
preserving the host functionality is inherent to "virus" conduct? It's called
the scientific method, if you didn't know.

> But if one fails to achieve this in some spreading attempts
> it (the corrupted host with added viable viral code) should still be
> considerd a virus if the attempted execution of the host results in
> execution of the virus code.


If it systematically corrupts rather than infect, then it's not a virus. If it
exhibits irregular behavior, e.g. some instances fail to infect while others
succeed, then it's a buggy virus, and if the botched infection resumes normal
viral behavior when being executed, then it's a singularity and it's unimportant
what you call it.

Regards, Zvi
--
NetZ Computing Ltd. ISRAEL www.invircible.com www.ivi.co.il (Hebrew)
InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
 
Reply With Quote
 
Roger Wilco
Guest
Posts: n/a
 
      07-07-2005

"Zvi Netiv" <support@replace_with_domain.com> wrote in message
news:...
> "Roger Wilco" <> wrote:
> > "Zvi Netiv" <support@replace_with_domain.com> wrote in message

>
> [...]
> > In our previous discussion you also seemed to have
> > misinterpreted something about first generation viruses - just

because
> > they are deemed not worthy of inclusion in test beds for AV

comparatives
> > does not mean they fail to meet the definition of virus.

>
> Our previous discussion was about whether overwriters should be

considered
> viruses or not.


Specifically those overwriters that don't retain host functionaltiy. I
say that they should still be considered viruses because they still fit
the definition(s) - except for yours )

> Gen 1 samples were introduced to the discussion from Bontchev's
> paper on how to maintain a virus collection. I have no particular

position in
> regard of these samples.


IIRC you compared overwriters to the first generation viruses because
you felt that the overwriters were essentially first generation viruses
on each iteration - and hence are more akin to trojans than viruses.
Detectors don't generally find this sort of thing when they are geared
specifically to recognize "infected" files of the type that your
definition indicates, so I can see why you would want to exclude them
via your definition.

> You may consider them as valid viruses according to
> the definition, including my stringent one.


I suppose so, considering what you say below.

> Gen1 are actually a "do nothing"
> executable to which the virus code was added.


Since there was no functionality to be preserved in what is now the host
"file" your definition works well enough.

> The only difference between a
> gen1 file and a real infection is that the latter was created by a

spontaneous
> infection process, and the previous was created artificially, through
> compilation. Note that spontaneity isn't required anywhere in the

definition of
> virus.


Agreed.

> > Sure, some
> > can't be treated the same in the AV arena because they are not
> > "infected" per se but they do meet the definition. You were correct
> > about them being "best treated" as trojans - but that doesn't make

them
> > trojans and not viruses.

>
> You are confusing between droppers and genuine first generation virus

samples.

Even droppers are viruses if they create a copy of the viral code they
'contain' in another executable area.

Maybe I 'do' need some clarification of the terms "seed file", "germ
file", and "dropper file". But it seems to me that any of them would be
viruses if they contained the viral code and their execution resulted in
that code being replicated into another program. AV may well be best
applied to subsequent iterations (spontaneous infection process), but
changing the definition of virus so that failing to cover them is not
akin to failing to detect a "virus" only serves to confuse.

> > > > In any future
> > > > discussions about viruses we'll just have to keep in mind that

you use a
> > > > rather unique definition.
> > >
> > > From you it almost sounds like being excommunicated.

> >
> > Not so bad really - it's not like we're ever likely to to need to
> > discuss thoses viruses that don't preserve host functionality since

most
> > of them do.

>
> Do you have a difficulty admitting that they all do?


A batch file (.bat) that overwrites other batch files with itself does
exist - so I would have difficulty ignoring that fact. Without added
"host funtionality retention" programming it would not be a very
sophisticated virus, but it is still a virus.

> Taking it one step
> further, can you formulate in words what that implies? Could it be

that
> preserving the host functionality is inherent to "virus" conduct?


One could argue that other "virus conduct" such as avoiding multiple
infections of the same program should be included in a definition. Just
because it is a great advantage to have that conduct does not mean that
conduct should become a part of the definition.

> It's called
> the scientific method, if you didn't know.


It is bad science to ignore existing things just because they aren't
often seen.

> > But if one fails to achieve this in some spreading attempts
> > it (the corrupted host with added viable viral code) should still be
> > considerd a virus if the attempted execution of the host results in
> > execution of the virus code.

>
> If it systematically corrupts rather than infect, then it's not a

virus.

If the corruption prevents the execution of the viral code, then it is
not a virus. If the corruption only negatively affects the original host
programs functionality and yet still correctly executes the viral code,
then it 'is' a virus.

Incidently, it is also not a virus (TM) if it corrupts the parent and
only produces one offspring. Kurt mentioned in an earlier thread that he
doesn't think this "non-overlapping" requirement was entirely
necessary - but in a CA program (Life) you could have "sliders' that
repositioned themselves (one unit diagonally?) and that would differ
from a somewhat richer CA that replicated itself to another area of the
2D tape without the new position overlapping the old position.

> If it
> exhibits irregular behavior, e.g. some instances fail to infect while

others
> succeed, then it's a buggy virus,


Some programmatically and intentionally (the writers intention) exhibit
such behavior to make emulation based detection more problematic.
Something being "buggy" implies it was not what the author intended.

Or do you have a unique definition for "buggy" as well. )

> and if the botched infection resumes normal
> viral behavior when being executed, then it's a singularity and it's

unimportant
> what you call it.


Interesting, could you explain this more? It seems that "botched
infection" implies that it isn't a viable offspring and yet you say
execution yields viral behavior which seems to indicate it 'was' viable.
Is it this 'host functionality retention' that is "botched" in your
above statement? If so, the "infection" wasn't botched - only the
attempt to retain host functionality was botched. So I would call it a
virus because I don't use your definition of virus.


 
Reply With Quote
 
kurt wismer
Guest
Posts: n/a
 
      07-08-2005
Zvi Netiv wrote:
> "Roger Wilco" <> wrote:

[snip]
>>Not so bad really - it's not like we're ever likely to to need to
>>discuss thoses viruses that don't preserve host functionality since most
>>of them do.

>
>
> Do you have a difficulty admitting that they all do?


people generally do have difficulty admitting that which they know to be
false...

> Taking it one step
> further, can you formulate in words what that implies? Could it be that
> preserving the host functionality is inherent to "virus" conduct? It's called
> the scientific method, if you didn't know.


the scientific method calls for needlessly injecting further constraints
into existing definitions?

>>But if one fails to achieve this in some spreading attempts
>>it (the corrupted host with added viable viral code) should still be
>>considerd a virus if the attempted execution of the host results in
>>execution of the virus code.

>
> If it systematically corrupts rather than infect, then it's not a virus.


it is only by your definition that corruption of the host and infection
are mutually exclusive... the real world is rarely so black and white...

--
"they threw a rope around yer neck to watch you dance the jig of death
then left ya for the starvin' crows, hoverin' like hungry whores
one flew down plucked out yer eye, the other he had in his sights
ya snarled at him, said leave me be - i need the bugger so i can see"
 
Reply With Quote
 
Zvi Netiv
Guest
Posts: n/a
 
      07-09-2005
"Roger Wilco" <> wrote:
> "Zvi Netiv" <support@replace_with_domain.com> wrote in message


> > Our previous discussion was about whether overwriters should be considered
> > viruses or not.

>
> Specifically those overwriters that don't retain host functionaltiy. I
> say that they should still be considered viruses because they still fit
> the definition(s) - except for yours )


Sorry, but I don't find it interesting to discuss that subject again.

Regards, Zvi
--
NetZ Computing Ltd. ISRAEL www.invircible.com www.ivi.co.il (Hebrew)
InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Trojan Horse in javaw.exe? Ken Java 3 01-27-2005 12:46 PM
Trojan Horse Jim Chapman Computer Support 1 08-15-2003 06:26 PM
Re: AVG can't eliminate Trojan Horse virus PhilGreg Computer Support 0 08-08-2003 11:30 PM
Re: AVG can't eliminate Trojan Horse virus bb3 Computer Support 0 08-08-2003 09:56 PM
Trojan Horse cannot be put in vault by AVG free version Jim Chapman Computer Support 1 08-07-2003 10:41 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57