什么时候ELF .text段不是ELF .text段？

Question

我无法找到适合我在内核和用户空间中生成一致HMACS的问题的文档。根据LKD的R.Love，内存描述符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个可执行文件生成了用户级HMACS，所以即使内核内存描述符中的代码段指向依赖项，而不是主要可执行文件，我仍然应该得到一个匹配项，但没有骰子。这两个“.text”段有些根本不同，我想知道有没有人知道它是什么，这样我可以节省一些时间 - 任何线索？在此先感谢，皮特; 1

Answer 1

有什么东西在两者之间根本不同“的.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段。所有这些部分都具有相同的保护措施，并且所有这些部分都由单个​​“区域”进行“覆盖”。

比较这对.text部分：

readelf -WS /bin/date | grep '\.text' 
    [13] .text    PROGBITS  0000000000401900 001900 0077f8 00 AX 0 0 16 

你会注意到，部分较小，并开始在不同的偏移。

难怪你会得到不同的HMAC。尝试在段上用户空间中计算HMAC，并且您应该获得匹配。