[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[exelist] Re: sdw386 v. 1.71



A serious problem with Protectors are that virus can lie dormant below
them avoiding scanners all together making chances that the original
source of an infection remains unlocated even after scanning. Virus
authors have been aware of such techniques for quite a while now - look
for instance at old issues of 40-hex - where it's "recommend" to ship
your new viriis in pklited MZ-exe's to avoid detection.

FS-hooks used for detection is nothing new - infact it's an old
technique - I could however use a FS-hook program which displayed a
messagebox each time a EXE-file was opened by programs not supposed to
open exe-files. This would be a very good indication for the advanced
user that something was wrong - all though such a program would be a
source of many scared newbie users due to false alarms.

However Protectors are not all bad in terms of viral infection - many
protectors come with Viral-infection detection interfaces. PE-LOCK is
one such example. Programs protected by this protector will alert the
user to the presence of viruses and thus can be seen as a service to the
end-user when used by serious developers. In the dos days I at one point
used such techniques with success on key dos-files. This appeared to be
a great way of detecting viral activity on my computer without having to
go thru the agony of waiting for scanners. The AV community has been
blissfully ignorant about exploring such methods.

In terms of false positives by heurestic scanners, it's a common problem
for both Protectorcoders, AV-coders and consumers alike. The sad thing
about heurestic scanners is that they by nature will trigger false
positives on protectors, packagers etc. and this is a fault in the
concept of their technology - not a fault in protectors which are made
to protect - a goal they furfill. The problem however does not present
itself to be without solutions. Traceing and simulation of "dangerous"
(Such as Call CreateFileA(OpenTargetExeFile) instructions if used
properly will  provide evidence on observed behaviour that will very
clearly make it possible to distinguish between viral and protector
code. Unfortunately the AV-community has so far seem blisfully ignorant
on the use of such methodlogy in heurestic scanners. 

To make the discussion a little less academic imagine an unpacker like
ProcDump with the abillity emulate and circumvent opening of EXE-files.
If the target opens an exe-file it's a virus if not then it could very
well be a protector. If the protector/unpacker does not decrypt objects
in the PE-file then it's not a Protector. This could very well be
implemented by use of among other things a  FS-hook. 

Tracing and emulation techniques could not only help in detecting viral
activity but also help in removal of viral code from files. Again the
AV-community has been blissfully ignorant to the possibillities which is
presents itself here.

The bottom line here is that protectors and packagers are a fact of life
as well as virii's. This is the challenge the AV-community face and
methods exist to avoid false detections on protectors and they have not
yet been exploided. And personally I believe that lazyness and/or
ignorance is never a valid execuse for professionals selling a product.

Stone

>----------
>From: 	Andreas Lange[SMTP:iceman42@...]
>Sent: 	12. marts 1999 10:56
>To: 	exelist@egroups.com
>Subject: 	[exelist] Re: sdw386 v. 1.71
>
>>
>>People maybe it's better to fix _ALL_ false positives from virus
>>scanners
>>before posting your stuff here. We AV plz have to fix your False
>>Positives which consumes a lot of unnecessary time. On the other hand
>>your stuff won't be distributed at all if there's a "virus" inside!
>>
>>Please fix the following FP:
>>
>
>Hi!
>
>Is it really a problem of us to write protectors in a way that
>every stupid AV scanner doesn't recognize it as a virus?
>I don't think so. I know how hard or maybe impossible it is to
>write a heuristic virus scanner which doesn't give false alarms.
>
>But look at the definition of a virus:
>It's not some code which is defined as being polymorph, encrypted
>or something like that; ok most viruses are; they are also not 
>defined as being destructive, although most viruses destroy.
>What i want to say is that a virus is defined as SPREADING ITSELF
>by infecting other files etc. ... Protectors don't act like this,
>so i don't think it's the problem of the protector that it is 
>recognized as suspicious virus. Indeed, it's a fault of a bad
>designed Scanner.
>
>Regards,
>iceman
>
>ps: Maybe i'm announcing a new way of virus scanning here; i'm not
>very familiar with AV stuff, but i think one safe way would be
>to create a so called "Sandbox" or "Container", which is the 
>environment in which we run the "maybe-infected file" and call,
>open, read, etc. another dummy files there.
>If we hooked the filesystem on the lowest layer (to avoid 
>manipulating this by a virus, do it polymorphically), we know that
>something modified the dummy file and can be SURE that it's a virus.
>I've never seen this technique, but i think as an add-on it beats
>a lot of other techniques like string-scan, heuristic scan, code 
>analysis, correlation scanning, etc. etc.
>
>pps: The AV technology described in this mail is patent pending in
>the United States of America and Europe. 
>
>
>------------------------------------------------------------------------
>For easy online travel reservations, go to Internet Travel Network:
>http://www.itn.net
>
>eGroup home: http://www.eGroups.com/list/exelist
>Free Web-based e-mail groups by eGroups.com
>
>
>

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/exelist
Free Web-based e-mail groups by eGroups.com