-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Virus said:
If it's the policy of any given AV company/software to be selective
when it comes to malware detection (ie to specifically NOT protect
against malware that is associated with hack/crack files) then they
should advertise that policy - and let that be a factor in how
consumers choose AV software.
I wouldn't say they would be selective, but rather prioritising. If there
is a lot of work due to variants of a fast-spreading worm to be detected
then the likes of crack viruses would probably be put down the "to-do list".
Or do you think that AV vendors should NOT publicize their decision to
not protect against rogue cracks and key-gens, thereby keeping
consumers in the dark about the true compentency or capability of
their AV software?
A computer's security measures (not just AV) are only as good as the user
behind them, as the user has the power to bring in all manner of infected
goods despite the fact they know the dangers.
The way I see it, any AV vendor can certainly choose whether to
include or exclude malware detection within known hack/crack/key-gen
files, but there is no coherent argument that can be raised (other
than pure pettiness or malice) for not making end-users aware of such
a corporate-level decision.
I suppose one would have to investigate the nature of crack viruses. I
can't say from experience but suppose that the vast majority are unique
"one-off" viruses - what's the point in protecting against them? The
chances are by the time someone who gives a monkey's and sends in a sample,
a considerable number of other users have already been exposed, and in a
year's time the crack will be obsolete due to a new version of the program
coming out, or the crack being repackaged with a new unique virus.
If this /is/ the case then it's a pointless cat-and-mouse game...well,
moreso than it currently is in the non-crack virus world
This raises another point: The use of rogue hacks and cracks would
drop if they were detected as trojan/viral/what-ever.
I think you'll find that the viruses are put into cracks for a good reason,
and just because some AV vendors were really hot on detections for them
wouldn't give the infecters a reason to stop - especially if the above
assumption that most people using cracks aren't likely to submit a nasty
one to an AV vendor, thus increasing the time to detection,
You could argue that anyone who seeks out and installs a keygen or crack
(which does what it's advertized to do) deserves the (possible)
infection they get. I could argue that the internet-at-large has become
more "polluted" because of the infected user, and the vendor for which
the hack/crack was used against has experienced some (perhaps small)
tangible loss because of the crack - so an AV policy of
detection-avoidance has accomplished nothing in this case, and arguably
it has led to the worse of two possible outcomes.
I think that you/we are going off a tangent here, especially on one of the
points that I was trying to put across - it's not that the AV vendors would
especially /not/ try to protect crack users because they're stealing, but
rather because there are more pressing viruses to attend to that are more
important and widespread. As the AV vendors have a finite staff and length
of time they have to prioritise tightly.
Besides, the incorporation of a given piece of mal-ware into a
hack/crack file doesn't mean that same mal-ware won't migrate to other
types of delivery mechanisms or payloads. For this reason, good AV
software should be blind to the source (or intention) of a piece
mal-ware and just focus on (and protect against) the threat.
That's very true indeed - I did mention that in my reply, but with the
prevalence of virus-writing tools it's not hard for a script kiddie to
generate their own new virus for every crack they release and protecting
against this (via detections rather than heuristics) would be polluting the
databases IMO.
Thanks for an interesting discussion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFEBvWO7uRVdtPsXDkRAtdEAJ9qYgf0lopYmg5G4Ey9uEevtO7kbACfXGxf
ffy2B3cQENMKJhyNE/drWwU=
=zPDl
-----END PGP SIGNATURE-----