Lesson 6B. Virus Protection Programs: How To Bypass It.
Prev || Home || Next
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.
Prev || Home || Next