The classical mechanism of importing an external function from or to ELF files in its most general form appears as follows : At the first stage of the call to the imported function from the .text section, the "stub" is called, which is located in the .plt (procedure linkable table) section. This, in turn , refers to the pointer to the printf function located in the .got (global offset table) section associated with the strings table containing the names of called functions (or their hashes).
Listing 20.1 provides the method of calling the printf function by the ls utility from the Red Hat 5.0 distribution set.
.text:08000E2D call _printf ... .plt:08000A58 _printf proc near .plt:08000A58 .plt:08000A58 jmp ds:off_800628C .plt:08000A58 _printf endp ... .got:0800628C off_800628C dd offset printf ... extern:8006580 extrn printf:near ; weak ... 0000065B: FF 00 6C 69-62 63 2E 73-6F 2E 35 00-73 74 70 63 y libc.so.5 stpc 0000066B: 70 79 00 73-74 72 63 70-79 00 69 6F-63 74 6C 00 py strcpy ioctl 0000067B: 70 72 69 6E-74 66 00 73-74 72 65 72-72 6F 72 00 printf strerror
Which point of this chain can be chosen for insertion? First, the virus can create a fictitious strings table by trapping the calls of all functions of interest to it. The most popular targets for infection are the printf, fprintf, and sprintf functions (because practically no program can do without them) and the file input and output functions. This automatically ensures a transparent mechanism for searching new targets for infection.
Satellite viruses can create a special trapping library in all infected files. Because IDA Pro doesn't display the name of the imported library when disassembling ELF files, it is difficult to suspect anything wrong in this situation. Fortunately, there are HEX editors. Some viruses tend to manipulate the fields of the global offset table by resetting them to point at the virus body.