Lesson 6B. Virus Protection Programs: How To Bypass It.
Though virus protection is great in most cases, there are still 'back doors' which haven't
been explored at the time of this writing. Here are some ideas for getting around the
checks that most virus protection software uses.
A trap is still a trap. It is not the real code; it is a dispatcher. It stops you on the
way there, but it doesn't stop you from doing what those basic calls do on your own. This
does require a fair amount of assembly language and ROM copying, but it gets you around
the catch of using operating system traps at all. Simply copy the code that is contained
in the trap itself and use that code. To never get caught, never use traps. But we know
how nearly impossible that is. However, things are gained and lost in good code writing.
A drawback of virus protection in general is that the software has to be continually
updated for each new virus and identified by name in most cases. One ingenious idea (mine?
I don't know) is to make the name and/or type of the virus variable. It doesn't always
have to be called 'nVir' or 'WDEF' (unless the mechanism depends on the name or type).
Make the type change from permutation to permutation. This makes it much more difficult to
catch.
One feature of the File Manager is it's automatic updating of the modification dates.
Every time a file is updated or modified in any way, the modification date is changed. You
can find and modify the date with a fairly simple low-level File Manager call. This is
really a frivolous precaution, but it makes it easy to find the source of a virus attack.
Changing the dates to something fairly feasible (NOT Jan. 1, 1904) may bypass such checks.
The application checks can be overridden with good code-writing as well. If the virus is
to add a resource to a file (as it usually has to), why not delete one in it's place?
You've got to be sure that the type is the same as another type (this is where the
variable types come in handy), and you may even want to vary the size of it to make it
match the one it replaced (hopefully a larger size). Simply modifying a resource (like
CODE 0) with the same amount of bytes will usually not be detectable. This way, the
applications still counts and finds nothing unusual. However, in the process, the
application is permanently damaged in some way.