Shulou(Shulou.com)06/01 Report--

1 introduction to basic knowledge

Runtime compressor is a common topic in software reverse engineering; to understand runtime compression, we need to master the basic PE file format, the basic knowledge of the operating system and so on.

To understand the content of this article, it is best to have basic knowledge of PE files and some knowledge of PE file loaders. This article will be interspersed with an introduction to the basics of PE files, but that's not the point.

The following figure shows the structure of the PE file and its comparison on disk and loaded into memory. The overall structure of the file has not changed, but the relative offset of the file in disk and memory has changed.

1.1 Runtime Compressor definition

The runtime compressor is for the executable file, which contains the decompression code inside the executable file, and the file is executed after it is decompressed in memory at the moment of running.

Comparison between normal compression and runtime compression

Project runtime compression ordinary compressed object PE file (exe,dll,sys) all file compression results PE file (exe,dll,sys) compressed file (rar,zip) internal self-extracting program whether the special decompression program can be executed itself can not be executed without special decompression program can directly compress all files

The compressor of an executable file is called a run-time compressor, and it is a dedicated compressor for PE files.

1.2 usage and types of runtime compressors

The purpose of using PE compressors is mainly focused on two aspects:

Reduce the size of PE files

Hide the internal code and resources of PE files

Type of PE Compressor:

Simply used to compress ordinary PE files, such as UPX,ASPack, etc.

Large deformation of the source file (PE file), serious damage to the PE header, impure intention of the compressor, such as for malicious programs (virtus,Trojan,worm, etc.), such as UPack,PESpin and so on.

2 A preliminary study of UPack compressed files

The makers of UPack have a deep understanding of PE heads, and UPack is famous for its unique deformation techniques for PE heads. When UPack first appeared, many PE utilities did not work properly. Causes many malicious code makers to use UPack to compress malicious code distribution.

Taking notepad.exe compressed by UPack 0.39 as an example, this paper introduces in detail the compression process of PE files by UPack, especially the key technologies of PE header and code reset.

UPack does runtime compression of notepad.exe, as shown in the following figure

From the above picture, we can see that the notepad.exe program has changed from 66560 bytes to 44908 bytes, and the file size has changed. at the same time, the input table and resource information of the file have also changed from the output information in the diagram.

2.1 compressed file detection

Compressed by UPack files, file headers and file contents have changed, leading to many security software that compressed files may contain virus features, will directly report virus, the following picture is the use of QQ to transfer the original notepad files and compressed notepad files, QQ self-test will think that UPack compressed files contain virus features.

The following figure shows the tips given by the IE plug-in for downloading compressed and normal files using IE browsers.

The following picture shows the use of multiple scanning engines to detect compressed files. The virus engines of many domestic security manufacturers believe that files compressed by UPack contain virus characteristics.

2.2 Utility identification

As a result of UPack on the PE file header to do a special treatment, so that some PE utilities can not run properly, PEView use tools to load compressed notepad files and the original notepad file, the file recognition is also different; because UPack on the notepad header has been deformed, resulting in PEView in the compressed notepad parsing can not find the normal file structure and loading failure.

3 in-depth analysis of UPack compression principle

After UPack compression, the contents of the header and section of the file have changed, and it no longer seems to meet the requirements of PE file format.

3.1 comparison of binaries

A typical PE header in which the data is arranged in IMAGE_DOS_HEADER, DOS Stub, IMAGE_NT_HEADERS, and IMAGE_SECTION_HEADER order.

Comparing the individual binary files, it is found that the size and content of the file have changed, and the compressed file no longer conforms to the PE file specification. As shown in the following figure, in a more intuitive comparison, many fields of the file structure have changed, and it is difficult to identify the compressed file structure for general utilities or debugging tools.

3.2 hardest hit areas-compressed file header

UPack is famous for its head compression, which changes the head of PE files beyond recognition, just like going to South Korea for a facelift.

The PE structure shows that the PE head consists of five parts: IMAGE_DOS_HEADER, DOS Stub, IMAGE_NT_HEADERS and IMAGE_SECTION_ header, and IMAGE_NT_HEADERS is composed of magic, IMAGE_FILE_HEADER and IMAGE_OPTIONAL_HEADER.

3.2.1 overlap of DOS heads in hard-hit areas

The overlapping file header skillfully overlaps the MZ file header (IMAGE_DOS_HEADER) with the PE file header (IMAGE_NT_HEADERS) to save file header space.

From the PE file header structure (need to know the PE file header infrastructure), IMAGE_DOS_HEADER structure of two important fields e_magic and e_lfanew, the first field is generally "MZ" is the beginning of the PE file logo, the second field marks the removal of the IMAGE_DOS_HEADER header and DOS Stub part after the start of the IMAGE_FILE_HEADER structure.

In general, e_lfanew = IMAGE_DOS_HEADER (40) + DOS Stub (A0 under vc) = 0XE0, that is, the value of the general e_lfanew field is 0XE0, and the value of the e_lfanew field of the UPack compressed file becomes 0X10, as shown below

The following figure shows how the DOS header of a schematic file changes before and after compression. After the file is compressed, the DOS Stub part has disappeared and is occupied by the IMAGE_FILE_HEADER structure.

3.2.2 IMAGE_FILE_HEADER deformation in hardest-hit areas

An important field in IMAGE_FILE_HEADER is that SizeOfOptionHeader;SizeOfOptionHeader represents the size of the IMAGE_OPTIONAL_HEADER; modify this value, change the size of the IMAGE_OPTIONAL_HEADER header, insert decoding code, and so on.

In a general PE file, the size of the IMAGE_OPTIONAL_HEADER structure is fixed, so the value of the SizeOfOptionHeader field is also fixed, which is 0XE0, as shown in the following figure notepad_origin.exe

After being compressed by UPack, the SizeOfOptionHeader of the file header becomes 0x148, as shown in the following figure

Much larger than the normal 0XE0. Another meaning of SizeOfOptionHeader is to determine the starting offset of the IMAGE_SECTION_HEADER. Expanding the value of this field from 0XE0 to 0x148 undoubtedly increases the size of the IMAGE_OPTIONAL_HEADER structure.

The basic feature of UPack is to deform the PE header, twist the twist like African hair, and properly insert the code needed for decoding into the header. After increasing the value of SizeOfOptionHeader, additional space is added between IMAGE_OPTIONAL_HEADER and IMAGE_SECTION_HEADER. Adding decoding code to this extra area is an ingenious way to go beyond the usual understanding of file headers.

The binary looks at the data for this extra area, which starts at the end of the IMAGE_OPTIONAL_HEADER, 0XD7 (why D7, as described later), and the end of the region is 0x170.

Use the debugger to view some of the disassembly code in this area as shown in the following figure

The following picture shows the format comparison before and after IMAGE_FILE_HEADER compression, and the compressed file header is enlarged.

3.2.3 IMAGE_OPTIONAL_HEADER deformation in hardest-hit areas

Comparing the files before and after compression, we can see that the value of the NumberOfRvaAndSizes field in the IMAGE_OPTIONAL_HEADER structure has also changed. this field represents the size of the data directory, and the value is also changed to insert its own code into the header. The size of this field in a normal file is 0x10, that is, there are 0x10 IMAGE_DATA_DIRECTORY arrays in the last part of the IMAGE_OPTIONAL_HEADER structure, but this value becomes 0x0A in UPack compression, that is, 6 IMAGE_DATA_DIRECTORY structure arrays are missing, each accounting for 8 bytes. You can see from the following figure that the second half of the IMAGE_OPTIONAL_HEADER structure, the IMAGE_DATA_DIRECTORY structure, is exactly where the 0Xd7 is, which means that the code is inserted as a free area from 0XD8 to 0x170.

The following figure shows the format comparison before and after IMAGE_FILE_HEADER compression, and the compressed DATA_DIRECTORY structure becomes smaller.

3.2.4 IMAGE_SECTION_HEADER overlap deformation in hardest-hit areas

The previous introduction of the file diagram of IMAGE_DOS_HEADER, DOS Stub, IMAGE_FILE_HEADER, IMAGE_OPTIONAL_HEADER, DATA_DIRECTORY deformation, followed by the transformation of IMAGE_SECTION_HEADER.

The IMAGE_SECTION_HEADER is the last part of the header of the file. The changes of nodal areas include the increase of nodal areas, the decrease of nodal areas, the increase of the number of nodal areas and so on. UPack has also changed the section area of the PE file. The following figure shows the comparison between the original notepad file and the compressed notepad file.

Comparing the two images, the name of the section area, virtual size, offset, file size, file start offset and so on have changed before and after the change.

Looking at the section area of the compressed notepad file, it is found that the file start offset of the first section area and the third section area is exactly the same as the size in the file. However, the starting RVA (VirtualOffset) entry of node memory is different from the memory size (VirtualSize) value. According to the PE specification, there will be no problem with doing so (more precisely, the PE specification does not explicitly state that this will not work). UPck overlaps the PE header, section 1, and section 3.

According to the value defined in the section header, the PE loader maps the area of the file offset 0x10-0x200 to the first and third sections in memory, respectively. In other words, the same file is used to create memory images of different locations and sizes.

Observe the compressed section area, the size of the header area of the file is 200 bytes. In contrast, the second section size (AD6C) is so large that the original file is compressed with it. Another thing to note is the first section area in memory, which has a memory size of 13000, which is the same as the sizeofImage of the original file.

Schematic diagram of file section compression

That is, the file image compressed in the second section is likely to be extracted to the first section. The schematic diagram after the file starts to be loaded into memory is shown in the following figure.

Http://blog.nsfocus.net/upack-works-case-analysis1/

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.