PE文件中没有.BSS [英] No .BSS in PE file
问题描述
这是简短的控制台应用程序示例
Here is short console application example
static char buffer[4096];
int main() {
for(int i=0;i<4096;i++) {
buffer[i] = 1234;
}
return 0;
}
据我了解，编译器生成的"exe"文件应包含.bss节以存储"buffer"变量.
As I understand, 'exe' file produced by the compiler should contain .bss section to store 'buffer' variable.
我正在使用Tiny C编译器，结果文件不包含对.bss的任何引用.
I'm using Tiny C Compiler and resulting file does not contain any reference to .bss.
DOS Header
Magic number: 0x5a4d (MZ)
Bytes in last page: 144
Pages in file: 3
Relocations: 0
Size of header in paragraphs: 4
Minimum extra paragraphs: 0
Maximum extra paragraphs: 65535
Initial (relative) SS value: 0
Initial SP value: 0xb8
Initial IP value: 0
Initial (relative) CS value: 0
Address of relocation table: 0x40
Overlay number: 0
OEM identifier: 0
OEM information: 0
PE header offset: 0x80
COFF/File header
Machine: 0x14c IMAGE_FILE_MACHINE_I386
Number of sections: 2
Date/time stamp: 0 (Thu, 01 Jan 1970 00:00:00 UTC)
Symbol Table offset: 0
Number of symbols: 0
Size of optional header: 0xe0
Characteristics: 0x30f
IMAGE_FILE_RELOCS_STRIPPED
IMAGE_FILE_EXECUTABLE_IMAGE
IMAGE_FILE_LINE_NUMS_STRIPPED
IMAGE_FILE_LOCAL_SYMS_STRIPPED
IMAGE_FILE_32BIT_MACHINE
IMAGE_FILE_DEBUG_STRIPPED
Optional/Image header
Magic number: 0x10b (PE32)
Linker major version: 6
Linker minor version: 0
Size of .text section: 0
Size of .data section: 0
Size of .bss section: 0
Entrypoint: 0x1060
Address of .text section: 0x1000
Address of .data section: 0x2000
ImageBase: 0x400000
Alignment of sections: 0x1000
Alignment factor: 0x200
Major version of required OS: 4
Minor version of required OS: 0
Major version of image: 0
Minor version of image: 0
Major version of subsystem: 4
Minor version of subsystem: 0
Size of image: 0x4000
Size of headers: 0x200
Checksum: 0x95d5
Subsystem required: 0x3 (IMAGE_SUBSYSTEM_WINDOWS_CUI)
DLL characteristics: 0
Size of stack to reserve: 0x100000
Size of stack to commit: 0x1000
Size of heap space to reserve: 0x100000
Size of heap space to commit: 0x1000
Data directories
IMAGE_DIRECTORY_ENTRY_IMPORT: 0x2000 (40 bytes)
IMAGE_DIRECTORY_ENTRY_IAT: 0x2028 (32 bytes)
Imported functions
msvcrt.dll
_controlfp
__set_app_type
__getmainargs
exit
_XcptFilter
_exit
_except_handler3
export directory not found
Sections
Name: .text
Virtual Address: 0x1000
Physical Address: 0x1e8
Size: 0x200 (512 bytes)
Pointer To Data: 0x200
Relocations: 0
Characteristics: 0x60000020
IMAGE_SCN_CNT_CODE
IMAGE_SCN_MEM_EXECUTE
IMAGE_SCN_MEM_READ
Name: .data
Virtual Address: 0x2000
Physical Address: 0x10e0
Size: 0x200 (512 bytes)
Pointer To Data: 0x400
Relocations: 0
Characteristics: 0xc0000040
IMAGE_SCN_CNT_INITIALIZED_DATA
IMAGE_SCN_MEM_READ
IMAGE_SCN_MEM_WRITE
可执行文件的反汇编版本引用了'buffer'变量，就好像它位于.data节之后.怎么运行的 ? PE加载程序如何知道应在.data段后保留特定区域?
Disassembled version of executable references 'buffer' variable as if it was positioned right after .data section. How it works ? How PE loader knows that it should reserve particular area after .data section ?
可执行文件: https://www.dropbox.com/s/99bpil11j7396ej/test-bss.exe?dl = 0
PEDUMP在线: http://pedump.me/40c40172cf08c89c3d97bd6840dbd3a0/
推荐答案
现在有了.data节的实际内存和磁盘大小，我认为可以解释buffer的位置以及到达的方式
With the actual in memory and on disk size of the .data section now known I think it's possible to explain where buffer is located and how it got there.
为了保持一致，我使用了 Microsoft Portable中的术语可执行文件和通用目标文件格式规范.
For the sake of consistency I'm using terms from the Microsoft Portable Executable and Common Object File Format Specification.
这就是我们对.data节的了解，它的VirtualSize为4320(0x10E0)，其SizeOfRawData为512(0x200).这意味着.data节在磁盘上为512字节，但是在内存中填充了零，填充为4320字节. SizeOfRawData值是可执行文件中已初始化数据的大小，当您从VirtualSize中减去该值时，会得到未初始化数据的大小.如注释中所述，这意味着.data节具有3808字节的未初始化数据，这不足以容纳名为buffer的4096字节数组.
So this is what we know about the .data section, it's VirtualSize is 4320 (0x10E0) and it's SizeOfRawData is 512 (0x200). This means that the .data section 512 bytes on disk, but gets zero padded to a size of 4320 bytes in memory. The SizeOfRawData value is the size of initialized data in the executable, and when you subtract that from VirtualSize and you get the size of uninitialized data. As noted in the comments, this means the .data section has 3808 bytes of uninitialized data, which isn't enough space to contain the 4096 byte array named buffer.
那么buffer在哪里?它必须在.data节的已初始化部分的某处开始，然后继续到未初始化的部分. PECOFF要求将SizeOfRawData值四舍五入到FileAlignment的下一个倍数(512).这意味着，链接器在创建可执行文件的.data节时，会使用未初始化的数据填充磁盘上的初始化数据，从而使SizeOfRawData最终为512的倍数.换句话说，可执行文件中的实际初始化数据量小于512.个字节，并且实际的未初始化数据量大于3808.
So where is buffer? It must start somewhere in the initialized part of the .data section and continue into the uninitialized part. PECOFF requires that SizeOfRawData value be rounded up to the next multiple of FileAlignment (512). This means that when the linker created the executable's .data section it padded out the initialized data on disk with uninitialized data so that SizeOfRawData ends up being a multiple of 512. In other words the actual amount of initialized data in the executable is less than 512 bytes and the actual amount of uninitialized data is greater than 3808.
此图试图显示链接器如何布置.data节.顶部表示相对于.data节的开始，链接器将可执行文件中使用的所有已初始化变量和未初始化变量放置在内存中的相对位置.中间部分显示buffer的放置位置.底部显示了.data节中作为初始化数据存在于可执行文件中的部分.
This diagram attempts to show how the linker would have laid out the .data section. The top part represents where in memory, relative to the start of the .data section, the linker put all the initialized variables and uninitialized variables used in the executable. The middle part shows where buffer was placed. The bottom section shows the part of the .data section that exists as initialized data in the executable.
+------------------+----------------------------------------+
| Initialized Vars | Uninitialized Variables |
+--------------------+-----------------------------------+--+
| | buffer[4096] | |
+--------------------+---+-------------------------------+--+
| Initialized on Disk | 4320
+------------------------+
0 512
这篇关于PE文件中没有.BSS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
