什么时候ELF .text段不是ELF .text段？
我在为在内核和用户空间中生成一致的HMAC的问题找到合适的文档时遇到了困难。根据Linux内核开发中的Robert，内存描述符mm->start_code和mm->end_code应该包含.text段。在一个静态可执行文件中找到.text段是在ELF文档中定义的，并且很容易获得。因此，考虑到以下两个代码片段，您可能会期望得到一个匹配的HMAC：
内核：
__mm = get_task_mm(__task);
__retcode = ntru_crypto_hmac_init(__crypto_context);
if(__retcode != NTRU_CRYPTO_HMAC_OK)
return 1;
__retcode = ntru_crypto_hmac_update(__crypto_context, (const uint8_t*)__mm->start_code,
__mm->end_code - __mm->start_code);
if(__retcode != NTRU_CRYPTO_HMAC_OK)
return 1;
__retcode = ntru_crypto_hmac_final(__crypto_context, __hmac);
if(__retcode != NTRU_CRYPTO_HMAC_OK)
return 1;
return 0;用户土地：
for (j = 0; j < file_hdr32.e_shnum; j++)
{
if (!strcmp(".text", strIndex + section_hdr32[j]->sh_name))
{
retcode = ntru_crypto_hmac_init(__crypto_context());
if(retcode != NTRU_CRYPTO_HMAC_OK)
{
syslog(LOG_ERR, "ntru_crypto_hmac_init error: retcode = %d, TID(0x%lx)",
retcode,pthread_self());
return 0;
}
retcode = ntru_crypto_hmac_update(__crypto_context(),
filebuf + section_hdr32[j]->sh_offset, section_hdr32[j]->sh_size);
if(retcode != NTRU_CRYPTO_HMAC_OK)
{
syslog(LOG_ERR, "Internal crypto error (%d)", retcode);
return 0;
}
retcode = ntru_crypto_hmac_final(__crypto_context(), _hmac);
if(retcode != NTRU_CRYPTO_HMAC_OK)
{
syslog(LOG_ERR, "Failed to finalize HMAC, TID(0x%lx)", pthread_self());
return 0;
}
return 1;
}
}在这两种情况下，.text段都是被记录在案的确切位置，但它们从来没有匹配过。我已经为系统上的所有17,000个可执行文件生成了userland HMAC，所以即使内核内存描述符中的代码段指向依赖项，而不是主可执行文件，我仍然应该得到匹配。但没有骰子。两个.text片段之间有一些根本不同的地方，我想知道是否有人知道它是什么，这样我就可以节省一些时间--任何线索吗？
回答 1
Stack Overflow用户
发布于 2014-01-22 16:11:22
两个".text“段之间有一些根本不同的地方
您的问题是，您忽略了段和节之间的差异。
ELF格式是一种可执行和链接格式。段用于前者，节用于后者(这里的链接意味着静态链接，即构建时)。一旦将二进制文件链接起来，就可以从其中完全丢弃部分，并且在运行时只需要段。段是mmap编辑的，而不是区段。
现在让我们来看看两者之间的区别。
readelf -l /bin/date
Elf file type is EXEC (Executable file)
Entry point 0x402000
There are 9 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040
0x00000000000001f8 0x00000000000001f8 R E 8
INTERP 0x0000000000000238 0x0000000000400238 0x0000000000400238
0x000000000000001c 0x000000000000001c R 1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x000000000000d5ac 0x000000000000d5ac R E 200000
LOAD 0x000000000000de10 0x000000000060de10 0x000000000060de10
0x0000000000000440 0x0000000000000610 RW 200000
DYNAMIC 0x000000000000de38 0x000000000060de38 0x000000000060de38
0x00000000000001a0 0x00000000000001a0 RW 8
NOTE 0x0000000000000254 0x0000000000400254 0x0000000000400254
0x0000000000000044 0x0000000000000044 R 4
GNU_EH_FRAME 0x000000000000c700 0x000000000040c700 0x000000000040c700
0x00000000000002a4 0x00000000000002a4 R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 8
GNU_RELRO 0x000000000000de10 0x000000000060de10 0x000000000060de10
0x00000000000001f0 0x00000000000001f0 R 1
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06 .eh_frame_hdr
07
08 .ctors .dtors .jcr .dynamic .got上面可以看到多个部分(.interp，.note.ABI-tag，. .text，.)所有这些都映射到一个PT_LOAD段中。所有这些部分都有相同的保护，所有的保护都由一个单一的[mm->start_core, mm->end_code)区域“覆盖”。
将其与.text部分进行比较：
readelf -WS /bin/date | grep '\.text'
[13] .text PROGBITS 0000000000401900 001900 0077f8 00 AX 0 0 16您将注意到，该部分较小，并以不同的偏移量开始。
难怪你会有不同的HMAC。尝试计算HMAC在用户土地上的片段，你应该得到一个匹配。
https://stackoverflow.com/questions/21279618
复制相似问题
腾讯云开发者
