UNIX / ELF file format and viral analysis
[SILVIO CESARE]
Introduction
This article describes UNIX virus mechanisms, specific implementations, and ELF file formats. Due to the unix virus detection and anti-detection technology, some examples of Linux / I386 architecture are provided. There are some preliminary UNIX programming experience, understand Linux / i386 assembly language, if it is better to understand that the ELF itself is better.
There is no practical viral programming technology in this article, just apply the virus principle to the UNIX environment. It is not intended here to introduce the ELF specification from beginning to read the ELF specification for the readers of interest.
Infected ELF format file
Process images contain "text segments" and "data segments", the memory protection attributes of the text segment are R-X, so general self-modification code cannot be used for text segments. The memory protection attribute of the data segment is RW-.
The segment does not require an integer multiple of the page size, which is used here.
Keywords:
[...] A complete page M has been used memory P padding
Page # 1 [ppppmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm] | - a segment # 3 [mmmmmmmmmmmppp] /
The segment does not limit the use of multiple pages, so a single page is allowed.
Page number # 1 [ppppmmmmmmmmmppp] <- a section
Typically, the data segment does not need to start from the page boundary, and the text segment requires the starting page boundary alignment, and the memory layout of a process image may be as follows:
Keywords:
[...] A complete page T text segment content d Data segment content P padding
Page # 1 [TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT] <- Text Segment Content # 2 [TTTTTTTTTTTTTTT] <- Text Segment Content # 3 [TTTTTTTTTTTTTPPPP] <- Text Segment Content (Part) # 4 [PPPPDDDDDDDDDDDD] <- Data Section content ( Part) # 5 [DDDDDDDDDDDDDDDDDD] <- Data Section Content # 6 [DDDDDDDDDDDDPPPPP] <- Data Section Content (Part)
Page 1, 2, 3 forms a text section 4, 5, 6 to form a data segment
From now on, for the sake of simplicity, the paragraph describes the chart as a single page, as follows:
Page # 1 [TTTTTTTTTTTTTPPPP] <- Text Segment # 2 [PPPPDDDDDDDDPPPP] <- Data Section
Under I386, the stack segment is always positioned after the data segment is given enough space, and the general stack is located at the high end of the memory, which is growing to the low end.
In the ELF file, the loaded segment is physical image:
Elf header..segment 1 <- Text Section Segment 2 <- Data Section ..
Each section has a virtual address that locates its own starting position. This address can be used in your code.
In order to insert parasitic code, it is necessary to ensure that the original code is not damaged, so it is necessary to extend the memory required for the corresponding segment.
The text segment is in fact, but also contains code, as well as the ELF header, which contain dynamic link information, and the like. If the direct expansion of the text segment is inserted into parasitic code, there are many problems, such as reference to absolute addresses. You can consider keeping the text segment constant and adds an additional parasitic code. However, an additional segment is indeed suspicion, it is easy to discover.
Both the high-end expansion segment or to the low-end expansion data segment may cause segment overlap, and a segment of the memory is positioned again to generate problems with the absolute address. It can be considered to extend the data segment to the high-end, which is not a good idea, some Unix implements the memory protection mechanism, and the data segment is not executable.
The page fills on the segment border provide a place inserted into the parasitic code, as long as the space is allowed. Inserting the parasitic code here does not destroy the original segment, no relocation is required. The page fill at the end of the text section is a good place, and finally looks like this: Keywords:
[...] a complete page V parasitic code T text segment content d Data segment content P fill
Page # 1 [TTTTTTTTTTTVVVVPP] <- Text Segment # 2 [PPPPDDDDDDDDPPPP] <- Data Section
A more complete ELF executable layout is as follows:
Elf HeaderProgram Header Tablesegment 1Segment 2section Header TableSECTION 1..SECTION N
Typical, additional festivals (those who have no corresponding sections) are used to store debug information, symbol table, and more.
Here are some content from the ELF specification:
The ELF header is at the beginning, saving a "road map", describing the organizational structure of the file. Save a large number of link information, symbolic table, relocation information, etc.
If there is a "Program HEADER TABLE", you will tell the operating system how to create a process image (execute a program). The executable must have a "Program Header Table", which can be positioned without the table. "Section Header Table" describes the section organization of the file. Each section has a group in this table, and the entry contains information such as the celebrities, segment size. The files used during the link must have a "section header table", and other target files can have no table.
After inserting the parasitic code, the ELF file layout is as follows:
Elf HeaderProgram Header Tablesegment 1 - Text Section (Main Code) - Parasitic SEGMENT 2SECTION Header TableSection 1..SECTION N
The parasitic code must be physically inserted into the ELF file, and the text segment must extends to include the new code.
The following information is from /usr/include/elf.h
/ * The Elf File Header. This Appears at The Start of Every Elf File. * /
#define Ei_NIDENT (16)
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; E_ENTRY Save the virtual address of the program entry point.
E_PHOFF is the offset of "Program Header Table" in the file. Therefore, in order to read "Program Header Table", it is necessary to call LSeek () to locate the table.
E_SHOFF is the offset of "Section Header Table" in the file. This table is located at the end of the file. After inserting parasitic code at the end of the text segment, the E_SHOFF must be updated to the new offset.
/ * Program segment header. * /
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;
The loader (text segment / data segment) is identified by the member variable p_type in "Program HEADER", which is Pt_Load (1). Like E_SHOFF in "Elf Header", the P_OFFSET member here must update the parasitic code to point to the new offset.
P_vaddr Specifies the starting virtual address of the segment. The base address is re-calculated with the p_vaddr, and you can specify where the program stream begins.
You can use the p_vaddr to specify where the program stream begins.
P_filesz and p_memsz respectively occupy the file size and memory size that should be occupied.
The .BSS section corresponds to the data section that is not initialized in the data segment. We don't want to make uninitialized data, but the process image must ensure that enough memory space can be assigned. The .BSS section is located at the end of the data segment, and any positioning of the file size is assumed to be located in this section. / * Section header. * /
typedef struct {Elf32_Word sh_name; / * Section name (string tbl index) * / Elf32_Word sh_type; / * Section type * / Elf32_Word sh_flags; / * Section flags * / Elf32_Addr sh_addr; / * Section virtual addr at execution * / Elf32_Off sh_offset; / * Section file offset * / Elf32_Word sh_size; / * Section size in bytes * / Elf32_Word sh_link; / * Link to another section * / Elf32_Word sh_info; / * Additional section information * / Elf32_Word sh_addralign; / * Section alignment * / Elf32_Word sh_entsize ; / * Entry size if section holds table * /} ELF32_SHDR;
SH_OFFSET specifies the offset in the file.
In order to insert parasitic code at the end of the text, we must do the following:
* Correct "Elf Header" Position "Text Segment Program" * Fixed P_FILESZ * Fix P_MEMS * Other phDR * Fixed P_offset * for text segment phdr P_offset * For each section of each section that affects offset by insertion of parasitic code * Correct SH_OFFSET * Physically insert parasitic code in the file to this location Text segment p_offset p_filesz (Original)
There is a big problem here, and it is pointed out in the ELF specification.
p_vaddr mod page_size == p_offset mod page_size
In order to meet this request:
* Fixed P_SHOFF in "Elf Header", increase the "Text Segment Program" * Fix the "Text Segment Program" * Fix P_Filesz * Fix the P_MEMSZ * Fixed the other phDr * correct p_offset after the text paragraph PHDR * Add Page_SIZE Size * For those who inserted parasitic code SHDR * correcting SHDR * correcting sh_size size * Increases Page_SIZE Size * Physically inserted parasitic code and fill in the file (make sure to make a full page) to this location Text segment p_offset p_filesz (Original)
We also need to correct the virtual address of the program entry point, so that the parasitic code is executed at the host code. At the same time, it is necessary to jump back to the end of the host code in the end of the parasitic code to continue the normal process.
* Fixed P_SHOFF in "Elf Header", increase the page_size size * correct the end of the parasitic code, enabling it to jump back to the original code original mouthpoint * Locate "Text Segment Program" * Fix "Elf Header" in the "Elf Header", pointing P_vaddr p_filesz * Fixed P_Filesz * Fixed P_MEMSZ * Fixed P_OffSet after text segment phdr, increase Page_SIZE Size * For the last shdr * correcting sh_len (should be sh_size, uncertain) for text segments (should be sh_size, uncertain), increase parasitic code size * Increase the SHDR * correcting SH_OFFSET, which affects the offset of the parasitic code, adds the page_size size * Physically inserted parasitic code in the file and fill (make sure to make a full page) to this location Text segment p_offset p_filesz (Original The virus can randomly traverse a directory tree, find files that E_TYPE equal to ET_EXEC or ET_DYN, which is infected, which is the executable file and dynamic link library file.
Analysis Linux virus
Virus requirements do not use libraries, avoid libc, and use system call mechanisms. In order to dynamically apply for a heap, a BRK system call should be called. The address of the constant string is obtained using the same technique as the buffer overflows.
Use GCC -S to compile C code and observe the adjustment ASM code. Note Save / Restore Registers when entering / leaving parasitic code.
Adjust the offset required by Objdump -D observation.
Detection virus
The virus described here is easy to detect. The most conspicuous is that the program entry point is not in the regular festival, and even in any festival. The process of cleaning the virus and the process of infecting the virus.
Use Objdump --all-headers to easily locate the program entry point, and use ObjDump - Disassemble-ALL to get the original entry point.
The default entry point is _Start, but can change it when the link.
in conclusion
Unix viruses although not popular, it is indeed possible.
