home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hacks & Cracks
/
Hacks_and_Cracks.iso
/
hackersguides-&-software
/
40hex-06.zip
/
40HEX-6.009
< prev
next >
Wrap
Text File
|
1992-03-28
|
20KB
|
603 lines
40Hex Number 6 Volume 2 Issue 2 File 009
-=[ The 'McAfee scan' viral footprint codes ]=-
-or-
/*******************************************/
/* A fool and his scanner, can part a user */
/* from his hard earned money. */
/*******************************************/
- written by -
GodNet Raider
- of -
The CyberUnderground
Thrown into 40Hex by DecimatoR
from Usenet alt.security
-=[ "Information is the greatest weapon of power to the modern wizard." ]=-
]----------------------------------------------------------------------------[
Introduction:
-------------
Recently I began to wonder about the usefulness of 'virus scanners'
and what if any difference do they have with a simple text/hex search
program (like nortons filefind/ts). An if there was no real DIFFERENCE,
how secure is the system that used them.
Problems with scanning:
-----------------------
The first question I had to ask was, What does a 'virus scanner' actually
look for? Does it only look for one string of codes or several at different
places in the file?
To answer this question I called a local BBS an dl'ed McAfee's
scan3.7v64 (to evaluate and after my tests, it was erased for its lack of
offering any real protection). Then I went to my archives to retrieve some
viruses I have experimented with in the past (of which where Jerusalem B and
Dark Avenger).
I ran scan to verify that the virus files where viruses (3 of which did
not set off any alarm even tho there was a listing in the documentation for
them, so I removed them from the test). Then using a sector editor looked at
the source for the McAfee asso. scan3.7v64 (here after know just as scan64)
to find that the footprint information was encoded. Needless to say this did
not stop me (for the sake of those who are into the tech aspects of things,
the actual method used to get the codes are included at the end of the
article with the codes found), It took less than an hour to get the codes I
was looking for (without disassembling the code but by looking into the
memory allocated to the program).
What I found out was scan was just a simple hex searcher (that kept
its data locked up till needed). It could also be fooled by any program
that contained the same hex string as a real virus (this was proved when
, using a sector editor, I added the scan64 footprint for the Jerusalem B
into the top of a text file (a place this code would never show up in a real
infection) then renamed it to *.com; scan64 reported it as infected).
Once the codes where obtained, using debug directly on a virus file,
I was able to mutate the virus to no longer be detectable by scan64 without
destroying the integrity of it. For the virus was still able to infect files,
and scan64 could no longer track it. I was still able to track and control it
using norton's filefind, diskmon, diskedit, and (of course) DOS erase.
So it seems my question was answered. Some 'virus scanners' just scan
for a single string of hex character. This is fine if viruses NEVER changed
or programs would NEVER use code similar to what a virus would (the smaller
the footprint string the bigger the chance of mistaken alarms). For if
a 'virus scanner' programer just keeps making a new release each time there
is a new virus (an I will not get into the morality of charging customers
the full price of an software upgrade rather than allowing them to buy/dl
new footprint data files as they become available) for the program will
eventually grow to unwealdable sizes. An it should be noted there are other
programs that may do the same job faster, more upward compatibility, and
you may already have them on hand.
a possible solution:
--------------------
One thing that I think is a good idea is when a program allows users
to add new footprint data to it (like nortons' virus package). For now
users don't need to buy new releases for detection of viruses they may not
get/be able to detect. Instead for the cost of a call to a support bbs (part
of the original software agreement?) the user can get new data as it becomes
available or when they fine a new one on their system they can immediately
add the new footprint rather than wait for the next version to be released.
Method used to obtain footprints:
---------------------------------
After finding the data I was looking for was encoded I thought, How can
I get the data I wanted for my tests?
Disassembling was out, not for any MORAL reason but, for the time
involved. So I thought it must have to decode the data for it's own use
and to save time it would do it all before the scan rather than slow the
process down by doing a full decode. So I needed to look at the memory
image of the running program. Thanks to DOS 5.0 and dosshell I was able to
do this.
After spawning the scan task under the dos shell I used alt-tab to
swap back to the shell. Once back in the shell I used the shell commands to
copy the