Processing of PE/ELF File shelling

Preface:

The initial shell was developed in infectious virus technology, with the goal of compressing or encrypting the shell. This article mainly
This section briefly introduces and summarizes the implementation of Win32 PE and Linux elf shelling programs on the X86 platform.
The program provides clues, in which the program source code is open-source. If you are interested, you can continue to improve the program.

PS: some of them haven't been touched for a long time. Some of them may have incorrect descriptions. Please forgive me :)

Body:

-------------------------------------------------------
SLM x86 Win32 R3 PE packer
Mimisys x86 Win32 R0 PE packer
Elfp x86 Linux R3 elf packer
-------------------------------------------------------

I. Composition of a shell

A complete shell program consists of packer and loader. Their specific functions are as follows:

(1) packer

Responsible for compressing and encrypting the program to be shelled, and writing the loader to the program to be shelled. Take the SLM pakcer
For example, the specific operations include determining the PE validity, optimizing the data that can be compressed, compressing and encrypting, adding loader, and storing
Shell parameters, original data (OEP, etc.) of the program to be shelled, and entry points for rewriting.

(2) Loader

The main task is to decompress Or decrypt the shell program. The SLM loader is used as an example to perform the following operations:
Body location, obtain shell parameters, decompress Or decrypt, fill the import table, relocate, and initialize TLS.

Ii. SLM (x86 Win32 R3 PE packer)

MATERIALS:
Http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx

Tools:
Lordpe file format viewing and editing tool
Dumpbin VC comes with coff file format viewing tool
Ollydbg R3 debugging tool

Source code structure:
./SLM/cm public header file and module
./SLM/PK packer implementation
./SLM/SC loader implementation

At this time, I just learned about PE, so SLM seems to have some problems in many places :). In the first
SLM workflow has been briefly described in this section. The following describes the problems I encountered at the beginning:

(1) resource processing

SLM's resource processing is cumbersome. It was originally designed to merge the compressed resource data
Lines are compressed once and cannot be compressed and stored separately. The following describes the directory data format of a resource.
Check Microsoft documentation and related source code :)

From image_nt_headers.image_data_directory [image_directory_entry_resource]
Obtain the resource data address res_rva. After conversion, the first struct is image_resource_directory.

Image_resource_directory:

Numberofidentries
Numberofnamedentries

The image_resource_directory is followed by the image_resource_directory_entry structure.
Array. The number of elements in this array is numberofidentries + numberofnamedentries.

Image_resource_directory_entry:

Id directory ID, which is valid only when nameisstring is invalid
Whether the nameisstring directory name is a string. If it is true, nameoffset is valid.
The offset of the nameoffset directory name string, which is relative to res_rva.
If dataisdirectory is true, offsettodata is valid; otherwise, offsettodirectory
Valid
Offsettodata points to resource data. The offset type is RVA.
Offsettodirectory points to a subdirectory, which is an offset type RVA.

If the Directory Entry name is a string, obtain pimage_resource_dir_string_u through nameoffset.
Directory Name Is In unicode format and is not a string ending with zero. If the directory name is not a character
The string is the ID, and its value is defined in winnt. h. Common IDs include rt_icon and rt_version.

The structure is roughly described. Pay attention to the need to modify offsettodirectory and offsettodata.
DWORD alignment; otherwise, a strange phenomenon may occur.

(2) Import table Processing

From image_nt_headers.image_data_directory [image_directory_entry_import]
Extract the import table address imp_rva. After conversion, the first struct is image_import_descriptor.

Image_import_descriptor:

Name indicates the name of the imported DLL. The offset type is RVA.
Firstthunk points to the image_thunk_data struct, which is an offset type RVA.
Originalfirstthunk points to a copy of firstthunk, which can be empty. Offset type RVA

The import is composed of an array of image_import_descriptor structures. The array length is composed of a knot with an empty name field.
Structure.

Both firstthunk and originalfirstthunk point to data composed of image_thunk_data arrays.
Structure. The system loader modifies the structure pointed to by firstthunk when filling the import table.

(3) TLS Processing

The TLS mentioned here is the so-called static TLS (implemented in the PE file structure). You can check what TLS is.
The thread chapter in Windows core programming.

1. What is TLS?

For example, to declare a TLS variable in VC, the _ declspec (thread) int x = 0;
The variable will be put into the. TLS section by the linker. This section is no different from other sections.
1. The difference is that a structure pointing to image_data_directory [image_directory_entry_tls] Will
This section describes the structure of image_tls_directory.

Image_tls_directory:

Startaddressofrawdata TLS data start address type va
Endaddressofrawdata TLS data end address type va
Addressofindex; the TLS slot address. The default TLS slot is 0.

Addressofcallbacks points to a pimage_tls_callback array.
End with 0. Each pimage_tls_callback is of the VA type.

The sizeofzerofill data area needs to clear the size of 0 Data
Characteristics

2. How does the system loader process TLS of EXE?

After the system loader completes the relocation and input table filling, it starts to process TLS. If tls_dir exists,
Obtain the TLS data size. endaddressofrawdata-startaddressofrawdata +
Sizeofzerofill: allocates a piece of memory by size and stores the address in pdword FS: [0x2c] +
Tls_slot, and then copy the number between startaddressofrawdata-> endaddressofrawdata
Data to the new memory, and then use sizeofzerofill to clear the remaining data, and then loop back
Call the addressofcallbacks function. The pimage_tls_callback function is similar to the dllmain prototype,
But there is no returned value.

3. How does the system loader process dll tls?

First, it is clear that the DLL can use TLS. The only difference is that the addressofcallbacks call method will
There are some differences. If the target DLL is listened to and linked to another file, it is loaded when the process is created,
The TLS callback will be triggered, but the loadlibrary method will not.

(4) RVA & Raw Conversion

The pointer type of many structure fields in the PE file is RVA, and RVA is the number of method-related values after the PE file is loaded by the system.
The relative offset of the data. When we perform shell processing, the direct map file data access uses the file
Needle, which requires RVA conversion. (Every time I do PE-related tools, I will get used to writing such a function.
If no version is later than 10, none of them can be guaranteed to be correct --)

The following is the latest rva2raw version, which is not guaranteed to be correct.

Iii. mimisys (x86 Win32 R0 PE packer)

MATERIALS:
Windows research Kernel
Wrk/base/ntos/MM/sysload. C: mmloadsystemimage
Tools:
The syser kernel debugger. You can also choose another R0 debugger.
If VMware does not want to restart frequently, a virtual machine is required.

For processing the file format, refer to SLM. Here we will introduce the differences between R0 PE and R3 PE:

(1) Sections and pages

Memory in R0 space is often very tight, which leads to the Sys section attribute in several special places.

1. Convertible and prohibited

When the memory is insufficient, the system memory manager will enumerate the loaded section objects.
Pageout attribute, the system memory manager will swap out the corresponding page of this section (This section goes through the system page
After all, swap out the memory) Section alignment principle virtualaddress up, virtualsize down. Do not swap out as shown in
The section named by name will remain in memory.

2. The section alignment is smaller than one page.

Most sys's section alignment indexes are smaller than one page, and the system loader is quite
Simple. After the file is loaded, the file layout on the disk is basically the same. When the section alignment is smaller than one page,
Sizeofrawdata must be greater than or equal to virtualsize, that is, the uninitialized section is not supported. Mimisys
Add sizeofimage to allocate an uninitialized buffer after the file is loaded to ensure the decompression process.

(2) checksum verification

One sentence: only the correct checksum sys file can be loaded.

(3) Win2k Problems

The system loaders of Win2k are different from those of other NT systems. R3 and R0 are different, such as R3 PE.
You must have an import table. Otherwise, the data cannot be loaded. R0 PE must have relocation information. Otherwise, the data cannot be loaded. This
In this case, you need to construct an empty relocation directory.

Mimisys adopts merged sections. As a result, only two sections are left after shelling. The first section is loader, which stores
Loader and various shelling parameters. The second section is the compressed data optimized by the original program (such as mobile relocation and mobile resources ).
). The attributes of the two sections cannot be swapped out.

4. elfp (x86 Linux R3 elf packer)

MATERIALS:
Tool interface standard (TIS) executable and linking format
Http://www.x86.org/ftp/manuals/tools/elf.pdf
Mao decao's introduction to kernel compatibility: 8, 9 loading of ELF Images
Http://linux.insigma.com.cn/jszl.asp? Docid = 132762762
Http://linux.insigma.com.cn/jszl.asp? Docid = 133617926
Linux kernel source code
Linux/fs/binfmt_elf.c: load_elf_binary

Tools:
Objdump: view the structure of the ELF File Format
Http://www.gnu.org/software/binutils/binutils.html

If you use the ALD assembly-level debugger, GDB cannot debug files without debugging information.
Http://ald.sourceforge.net/

Elfp is the Linux ELF File compression shell completed in magiclinux.

The ELF format is the main executable file format in Linux. It is also designed based on coff, so it and
The format of the PE file is very similar. The following description will be compared with the PE file.

The first data structure of the ELF file starts with elf32_ehdr.

Typedef struct
{
Unsigned char e_ident [ei_nident];/* magic number and other info */
Elf32_half e_type;/* object file type */
Elf32_half e_machine;/* architecture */
Elf32_word e_version;/* object file version */
Elf32_addr e_entry;/* entry point virtual address */
Elf32_off e_phoff;/* program header table file offset */
Elf32_off e_shoff;/* section header table file offset */
Elf32_word e_flags;/* processor-specific flags */
Elf32_half e_ehsize;/* elf header size in bytes */
Elf32_half e_phentsize;/* program header table entry size */
Elf32_half e_phnum;/* program header table entry count */
Elf32_half e_shentsize;/* section header table entry size */
Elf32_half e_shnum;/* section header table entry count */
Elf32_half e_shstrndx;/* section header string table Index */
} Elf32_ehdr;

The elfmag macro corresponding to e_ident in elf. h. The length is four bytes.
E_entry entry point image offset (the image offset is the RVA mentioned in PE)
File offset of e_phoff elf32_phdr Array
File offset of the e_shoff elf32_shdr Array
E_ehsize the size of the elf32_ehdr Structure
E_phentsize elf32_phdr structure size
E_phnum elf32_phdr array member count
E_shentsize elf32_shdr structure size
E_shnum elf32_shdr array member count

After elf32_ehdr, It is the elf32_phdr array. The elf32_phdr address is determined by elf32_ehdr.e_ehsize.
OK. Elf32_ehdr array (or field table), you can regard phdr as a PE section table.

Typedef struct
{
Elf32_word p_type;/* segment type */
Elf32_off p_offset;/* segment file offset */
Elf32_addr p_vaddr;/* segment virtual address */
Elf32_addr p_paddr;/* segment physical address */
Elf32_word p_filesz;/* segment size in file */
Elf32_word p_memsz;/* segment size in memory */
Elf32_word p_flags;/* segment flags */
Elf32_word p_align;/* segment alignment */
} Elf32_phdr;

P_type describes the loading behavior attribute of this segment.
P_offset data is offset in the file, similar to pointertorawdata In the PE section.
P_vaddr segment offset in the image after data is loaded, similar to virtualaddress in PE section
P_filesz segment data is large or small in the file, sizeofrawdata in the type pe section
P_memsz segment data is loaded in the image size, virtualsize In the PE section of the type
P_flags describes the memory attributes of this segment, similar to the Section attributes in the PE section.
P_align segment alignment Granularity

The main types of p_type are:

The pt_load segment needs to be loaded into the memory.
The pt_phdr segment stores the elf32_phdr array.
The pt_interp segment stores an interpreter name and requests the system loader to transfer the image loading requirement to this
Interpreter. Elf interpreter problems can be understood as NTDLL loading in windows.
PE file. the interpreter of the ELF file is mainly responsible for operations such as relocation and import table filling.

Main p_flags types are:

This pf_x segment is executable.
This pf_w segment can be written.
The pf_r segment is readable.

After elf32_ehdr (segment table), it is the elf32_shdr array (segment table). You may be surprised here. Why?
Is it a node table? If you are familiar with PE, you should know the importance of the section table to PE files, but this is not the section table in PE. You
We should regard it as the data_dir [] structure in the NT header. tools such as the loader or debugger will determine the specific section by the node name.
Usage, such as storing debugging information, version information, string tables, etc. elfp discards the section table during shelling.

The following describes the loader processing process of elfp (the shelling process is very simple). After an elf file is loaded
Some parameters pushed by the system loader in the stack before execution.

// Stack structure:
// + ------------------- +
// | Return address
// + ------------------- +
// | Argc | number of parameters
// + ------------------- +
// | Argv [?], Null | parameter table, ending with null
// + ------------------- +
// | Envp [?], Null | environment table, ending with null
// + ------------------- +
// | Auxv [?] | The Chinese language does not know what it is called. This is mainly used by the interpreter,
// + ------------------- + Stores information about the elf. If the shell program needs to solve this problem
Releaser, You need to rewrite and enter this parameter correctly so that the interpreter can
To find the correct data address.

The execution process of the elfp shell loader is roughly as follows:

Apply for memory --> extract each segment to the specified address --> obtain original information of the shelled program --> check the original
Start field table, override auxv --> load interpreter --> call Interpreter

For the interpreter of ELF, refer to the text on the document link, which is more complete than what I described.

V. Appendix

[1]Code
./Pstzine_0a_01.zip

-EOF-