Thursday, February 27, 2014

Dissecting the PE File Format - 5

The PE File Sections

The sections contain the main content of the file including code, data, resources and other executable information. Each section has a header contained in the Section Table but the section bodies lack a rigid file structure. They can be filled with any information as long as the header has enough info to decipher the data.

Executable Code
All code segments reside in .text. Since a page-based system is used in Windows, a large code section is easier to manage for both the OS and the app developer. This section also contains the entry point mentioned earlier and the jump thunk table which points to the IAT.

Data
The .bss section represents uninitialized data, including all variables declared as static within a function.
The .rdata section is read-only data such as literal strings, constants and debug directory information.
All other variables are in the .data section. These are application or module global variables.

Resources
The .rsrc section contains resource information. The first 16 bytes comprises a header like most other sections but this section's data is structured into a resource tree which is best viewed using a resource editor. (e.g. ResHacker)
This is a powerful tool for cracking. It quickly displays dialog boxes including those concerning incorrect registration details. A shareware app can be cracked by just deleting the nag screen dialog resource in ResHacker.

Export Data
The .edata section contains the export directory for an app or DLL. This contains info about names and addresses of exported functions

Import Data
The .idata section contains info about the imported functions including the Import Directory and IAT.

Debug Information
usually placed in the .debug section. Separate debug files (.DBG) are also supported for collecting debug information. The debug section contains debug information but the debug directories live in the .rdata section. Each of these directories references debug information in the .debug section.

Thread Local Storage
Windows supports multiple threads of execution per process. Each thread has its own private storage, Thread Local Storage or TLS, to keep data specific to that thread, such as pointers to data structures and resources the thread is using. The linker creates a .tls section in a PE file that defines the layout for the TLS needed by routines in the executable and any DLLs which it directly refers. Each time a process creates a thread, the new thread gets its own tls, created using the .tls section as a template.

Base Relocations
When the linker creates the EXE, it makes an assumption about where the file will be mapped  into memory. Based on this, the linker puts the real addresses of code and data items of the executable file. If the executable ends up being loaded somewhere else in the virtual address space, the address the linker plugged into the image are wrong. The information stored in the .reloc section allows the PE loader to fix these addresses in the loaded image so that they are correct again.
The entries in the .reloc section are called base relocations since their use depends on the base address of the loaded image. Base relocations are simply a list of locations that need a value added to them. The format of the base relocation data is quirky. The base relocation entries are packages in a series of variable length chunks. Each chunk describes the relocations for one 4KB page in the image.

e.g.  if the assumed base address is 0x10000. At offset 0x2134 within the image is a pointer containing the address of a string. The string starts at physical address 0x14002. You then load the file but the loader maps the file at physical address 0x60000.  The difference between the linker-assumed base load address and the actual load address is called delta which is 0x50000 in this case. Since the entire image is 0x50000 bytes higher in memory, so is the string. The executable file contains a base relocation for the memory location where the pointer to the string resides. To resolve the base relocation, the loader adds the delta value to the original value at the base relocation address. So the string will now point to 0x64002.

No comments:

Post a Comment