如何检查HexDump的“ ELF”文件？
我正在学习elf文件布局，所以我正在阅读 >。
一开始，我使用readelf -a来exmine elf（.o file），但它不是我想要的，所以我使用了hexdump -c hexdump -c < /code>将其二进制形式形成。
我将用作-og -g ... -o ...，ld ... -o ...和hexdump -c ... < /代码>检查精灵文件，以下是我的代码。
.section .data
iary:
.int 1, 2
lary:
.long 3, 4
.section .text
.globl _start
_start:
movq $0, %rdi
leaq iary(, %rdi, 4), %rbx
movl iary(, %rdi, 4), %ecx
movq $1, %rdi
leaq iary(, %rdi, 4), %rbx
movl iary(, %rdi, 4), %ecx
#===============================
movq $0, %rdi
leaq lary(, %rdi, 4), %rbx
movl lary(, %rdi, 4), %ecx
movq $1, %rdi
leaq lary(, %rdi, 4), %rbx
movl lary(, %rdi, 4), %ecx
movq $60, %rax
syscall
我正在寻找程序标头，部分标题 .ETC。但是我不确定我的搜索方法是否正确！
请与上图相关联。
I'm learning elf file layout, so I'm reading Executable_and_Linkable_Format.
In the beginning, I used readelf -a to exmine elf(.o file), but it provided is not my want, so I used hexdump -C to exmined it binaries form.
I used as -Og -g ... -o ..., ld ... -o ... and hexdump -C ... to examine elf file, below is my code.
.section .data
iary:
.int 1, 2
lary:
.long 3, 4
.section .text
.globl _start
_start:
movq $0, %rdi
leaq iary(, %rdi, 4), %rbx
movl iary(, %rdi, 4), %ecx
movq $1, %rdi
leaq iary(, %rdi, 4), %rbx
movl iary(, %rdi, 4), %ecx
#===============================
movq $0, %rdi
leaq lary(, %rdi, 4), %rbx
movl lary(, %rdi, 4), %ecx
movq $1, %rdi
leaq lary(, %rdi, 4), %rbx
movl lary(, %rdi, 4), %ecx
movq $60, %rax
syscall
I'm looking for program header, section header, .etc. But I'm not sure my search method is correct!
![[1]: https://i.sstatic.net/5WX6E.png](https://i.sstatic.net/epPwX.png)
Please connect with above picture.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要查找程序标头：
首先，字节0x4为2，所以这是一个64位二进制文件。然后，字节0x5是1，所以它是小的。
由于它是64位，因此程序标头的偏移量为0x20，是64位值。这里的字节是
40 00 00 00 00 00 00 00，是小型数字0x40。因此，当您循环时，程序标头从文件中的偏移0x40开始。截面标题偏移量在0x28，指向0x22F0，因此当您圆圈时，截面标题开始的位置。第一个具有偏移0x4的零（即文件中的0x22f4），这意味着它是未使用的，这就是为什么您在0x22f0开始的0x40字节中看到零。第一个真实部分标题始于0x22F0 + 0x40 = 0x2330。
Offset 0x1000看起来像程序的实际代码的开始。它与页面边界保持一致是有道理的（0x1000 = 4096 =页面的大小）。您可以通过解码部分标题来确认；该区域可能会成为
.text的一部分。这些字节看起来像机器代码，您可以使用拆卸器来解码它们。48 C7 C7 00 00 00 00是MOV RDI，0如果我正确阅读。偏移0x2000可能是数据部分的开始。第一部分看起来像是32位整数的数组
{0x1、0x2、0x3、0x4}。稍后，我们有可能是调试信息的一部分。也许这将帮助您入门。
To find the program header:
First, byte 0x4 is 2, so this is a 64-bit binary. Then, byte 0x5 is 1, so it is little-endian.
Since it is 64-bit, the offset of the program header is at 0x20 and is a 64-bit value. The bytes here are
40 00 00 00 00 00 00 00which is the little-endian number 0x40. So as you circled, the program header starts at offset 0x40 in the file.The section header offset is at 0x28, and points to 0x22f0, so that's where the section headers begin, as you have circled. The first one has zeros at offset 0x4 (i.e. 0x22f4 in the file), meaning it is unused, which is why you see zeros in the 0x40 bytes starting at 0x22f0. The first real section header starts at 0x22f0 + 0x40 = 0x2330.
Offset 0x1000 looks like the start of the program's actual code. It makes sense that it is aligned to a page boundary (0x1000 = 4096 = size of a page). You could confirm by decoding the section headers; this region will probably turn out to be part of
.text. These bytes look like machine code and you could use a disassembler to decode them.48 c7 c7 00 00 00 00ismov rdi, 0if I read correctly.Offset 0x2000 is probably the start of a data section. The first part looks like an array of 32-bit integers
{0x1, 0x2, 0x3, 0x4}. Later on we have what is possibly a section of debug info.Perhaps this will help get you started.