Lesson 3. Getting Your Code Executed.
This technique you use here defines how your virus spreads.
Some earlier viruses were more virulent than others; nVir needed an infected application
to boot for it to execute; WDEF required only that a disk be inserted. There are lots of
places for code to be "patched" so that your code can be executed. The trick is
finding them and recovering from them gracefully. Not every method can be discussed in
this note, but I will give some general examples and how to find your own 'hooks'.
One of the most popular methods amongst virii is infecting applications, since they, by
definition, have executable code built right into it. If you can get your code executed
along with the many other little segments in the application, the code could recover
undetected. When an application starts up, the resource CODE with ID=0 is loaded into
memory, and it's popularly known as the jump table. It keeps track of all of the
procedures or segments in an application. If part of an application needs to call another
procedure inside the application, it checks with the jump table for it's location. If it
sees that the procedure is not in memory, it will load it first, then execute it. This is
all taken care of by the compiler and the system software, so it's invisible to the
programmer (in most cases). The system loads the jump table and immediately executes the
first entry in the list when an application begins.
You can patch yourself into this list of procedures by modifying the jump table itself.
You can modify the first entry of the jump table to be your code, but save the original
entry so that you can call the actual application when you're done (destroying the first
entry in any CODE 0 resource renders the application totally useless). So, instead of the
system executing what it thinks is the application, it will run your code first, and then
run the application.
Another method by which virii get executed is by utilizing a wonderful feature of the
Resource Manager. As given in Inside Macintosh volume 1, the Resource Manager will look
for resources in the top-most resource file that is open (the one most recently opened in
most cases, unless UseResFile has been used). These searches also include searches for
basic system code resources, such as window definitions, control definitions, and even
international transliteration code. If you have a resource with the same type and ID as
one in the system, and this resource file is open, the system will execute your resource
instead of the system's. The catch again with this is that you should call the original
resource as well to make your code invisible to the naked eye. This, apparently, is how
the WDEF virus worked. When a disk was inserted, the desktop file was automatically opened
and put in the list of resource files. Within this time that the file was open, the WDEF
file which existed within was executed (the system needed to draw the window itself using
the standard WDEF resource). This method requires no patching of other code and makes it
very elegant. The thing that makes them easy to detect is that you find code resources in
very odd places. A WDEF resource is not usually found in the desktop file.
To find other hooks for code execution, look at all the executable code inside the system.
These pieces are executed at one time or another for certain calls. Things that might not
seem obvious right away may make good places for patching. Lots of applications use (maybe
indirectly) the International Utilities Package, for it has many good string manipulation
routines. A patch there might be possible. 'ptch' resources in the system are loaded
automatically at startup time to patch bits of ROM. A system could be infected there and
be loaded before all other extensions. Poke around the resources and find out which ones
are executable, and then find out when they are executed. You might be able to find a
great patch to live off of.