RVA and RWA of relationship

RVA and the relationship of RWA

Principle is simple: first determine whether the address in the PE header, if the file offset and the offset memory are equal, if the file is present in the section, then using the following equation:
Memory Offset - the segment starting with RVA (the VirtualAddress) = file offset - this segment PointerToRawData
memory offset = the segment starting with RVA (VirtualAddress) + (file offset - this segment PointerToRawData)
file offset = the segment PointerToRawData + (memory offset - the segment starting with RVA (VirtualAddress))

DOS header, the PE header, the block list offset and the offset in memory on the disk are the same. The rest of the disk and memory offset shift is needed to convert.

The concept of various addresses:

Base address ( Image Base): the PE file into memory starting address.

Relative virtual address ( Relative the Virtual the Address, the RVA): in memory with respect to the PE file loading offset address is a relative address.

Virtual Address ( Virtual Address, VA): Load the actual address in memory.

File offset ( the Fill Offset): When the disk file header offset position with respect to the PE file storage. Address of hex file editor to open the file offset address.

Virtual address ( VA) = Base Address ( Image Base) + relative virtual address) ( the RVA)

The RVA converted to File Offset, give us a very classic formula:

Set: VK relative virtual address offset address RVA file File Offset difference

VA=ImageBase+RVA

File Offset = RVA -VK

File Offset = VA-ImageBase-VK

+ --------- + --------- + --------- + --------- + --------- + --------- +
| name of the virtual address of the virtual segment size of the physical address of the physical size of the symbol |
+ --------- + --------- + ----- + --------- + --------- + ---- + ---------
| VOffset the Name VSize Roffset RSIZE Flags |
+ ------ --- + --------- + --------- + --------- + --------- + ------ + ---
| .text 00001000 00000400 00.0002 million 60.00002 million 00,000,092 |
| 000000F6 the .rdata 00002000 00000600 00.0002 million 40.00004 million |
| .data 00.003 million 0000018E 00000800 00.0002 million C0000040 |
| 000003A0 00000A00 .rsrc 00004000 00000400 C0000040 |
+ --------- + --------- + --------- + --------- + --------- + --------- +
file offset and the calculated virtual physical file offset address as follows:

>>>>>>> VaToFileOffset (virtual file offset address address)
as VA = 00401000 (virtual addresses)
ImageBase = 00400000 (group address)
VRk VOffset = - = Roffset 00001000 - 00000400 = C00 (virtual file VRk value obtained between the physical address and the file address)
the FileOffset for = VA - the ImageBase - VRk = 00.401 million - 00400000 - C00 = 400 ( file offset address of the physical address)

as VA = 00401325, then:
the FileOffset for = VA - the ImageBase - VRk = 00,401,325 - 00400000 - C00 = 725

>>>>>> FileOffsetToVa (file offset address translation of the virtual address)
as FileOffset = 435 (file offset address)
VA = + VRk the FileOffset for the ImageBase = + 435 + C00 + 00400000 = 00,401,035 (virtual addresses)

Typically, the data blocks are logically linked. PE file will typically have at least two blocks: one block, the other is a data block. Each block needs to have a different name, the name is mainly used to express purpose block. For example there is a block called .rdata, that he is a read-only block. Note: The tile is based on the start address (the RVA) are arranged in the image, rather than alphabetically.
In addition, people just use the name of the block in order to facilitate understanding and programming, and for these operating systems are irrelevant. Microsoft to take these blocks had a distinctive name, but this is not necessary. When the content needs to be programmed and read from the PE file, such as the input table, the output table, not as a reference to the name of the block, the correct way is according to the data fields in the directory table to locate.

Various block Description:

Blocks usually start from OBJ files are placed compiler. Work linker is consolidated around OBJ and block library needs, making it a suitable final block. Links will follow a fairly complete rules, it will determine which blocks will be combined and how the merger.

Merge block:
An interesting feature of the linker is able to block the merger. If the two blocks have similar properties of consistency, so that they can be linked at the time merged into a single block. It depends / merge compiler switch is turned on. In fact block the merger there is a benefit that can save disk memory space ...... Note: We should not be .rsrc, .reloc, .pdata to merge ++ block in.

Align value block:

Before we simply understood the block is to be aligned, whether it is stored in memory or stored on disk - but they are generally aligned values are different.

PE header inside the alignment values defined FileAligment disk blocks. Each block stored starting from a multiple alignment offset value. The size of the actual code or data blocks is not necessarily just so much, so generally 00h to fill in the extra space, this is the gap between the blocks.

For example, in the PE file, a typical value is 200h aligned, so that, from each block are a multiple of the start position of file offset 200h, 400h is assumed in the first block, a length of 90H, then from 400h to 490h of the file content of this block, since the file alignment value is 200H, so in order to make the block length is an integral multiple of FileAlignment, 490h to 600h 00h that a section will be filled this space block is called a gap, a start address of the block for 600h.

PE header defines inside SectionAligment alignment values in memory blocks. When the PE file is mapped into memory, the block always starts with at least a page boundary.

In general X86 series CPU, a page is based 4KB (1000h) arrayed; on IA-64, is press 8KB (2000h) arrayed. Therefore X86 system, memory alignment value PE file extent generally equal to 1000h, 1000h multiples of each block is stored in memory.

RVA and file offset conversion

in front of us explored RVA term, but for the initial contact with the PE file my friends, is particularly strange and helpless. Chinese people do not like to abbreviate foreigners, but always naked to accept ...... However, after the front had knowledge of the bedding, now talk about the concept of the big guy should be able handy. At least not seemed so obscure and helpless ~

RVA is an abbreviation for relative virtual addresses (Relative Virtual Address) as the name suggests, it is a "relative addresses." PE files in various data structures involved in the field to address most of them are represented by RVA, there are wood? ?

More precisely, when the RVA is a PE file is loaded into memory, a data location offset with respect to the file header. For example, if a Windows PE file loader loaded into memory at 00400000h, whereas a data block is loaded into a 0040 ** XH, the data is then the RVA (0040 ** xh - 00400000h) = ** xh, conversely, the value of the RVA loaded with the file base address, the actual address of the data can be found in memory.

DOS file header, PE header and a block offset table size did not change. After each of the blocks and the memory-mapped, which would change the offset position.

RVA makes positioning data file into the memory becomes convenient, but gave us to locate the static PE files located on the disk trouble.

How to convert RVA and file offset it?

When dealing with PE file, any file RVA must be to offset the conversion in order to locate and access the data in the file, but the conversion can not be done with a simple formula, in fact, the only available option is the most soil most stupid method:

step a: scan cycle starting block for each block obtained RVA table in memory (in accordance VirtualAddress IMAGE_SECTION_HEADER field), and according to the size of the block (in accordance IMAGE_SECTION_HEADER SizeOfRawData field) RVA end block is calculated (by adding to both), and finally determines whether the target falls within the region RVA.

Step two: a positioning step in the RVA target a specific block, then subtracting the starting RVA RVA in the target block, so that the target can be obtained RVA offset relative to the starting address of RVA2 .

step three: acquiring offset address of the block in the file is located in a block table (in accordance IMAGE_SECTION_HEADER PointerToRawData field), the value of the offset value plus RVA2 obtained in step two, get real file offset address.

reference

Book: "Encryption and decryption"

Video: Small turtle decrypted video series

Blocks

Behind the partition table is a one block, each block occupying an integral multiple of the alignment value, the general files have data blocks with code block (typically .text their names but can be modified with the .data ). Each data block has the same properties. The compiler to generate different blocks in obj, the linker and then merge different obj according to certain rules with fast library. For example, each block in obj certainly .text connector will merge them into a single block .text; For another example, if the two blocks have the same properties it may be combined into one block.

And converting the file offset RVA

Because the disk is aligned with the memory alignment may be different. There must be a multiple of each block, i.e. in the alignment value of each disk block size of the executable file is an integer multiple disk alignment, the size of the program loaded into memory block is an integer multiple of a memory alignment. Lead to different file offsets and RVA conversion, need to be converted.

Examples: converting an input file offset table with RVA

RVA entry form can be found by looking at the binary executable file, but can not find the input table file offset.

First check the binary executable file, the disk can be found in this program memory alignment is aligned 200h 1000h (SectionAlignment with FileAlignment IMAGE_OPTIONAL_HEADER in)

Picture 1