c - 分析混淆的 ELF 二进制文件

Question

我正在尝试使用奇怪的魔法字节调试 ELF

$ xxd binary | head -2
00000000: 7f45 4c46 4141 4141 4141 4141 4141 4141  .ELFAAAAAAAAAAAA
00000010: 0300 0300 0100 0000 0010 0000 3400 0000  ............4...

$ file binary
file binary: ELF, unknown class 65

$ objdump -D binary
objdump: binary: File format not recognised

$ readelf -h binary
ELF Header:
    Magic:   7f 45 4c 46 41 41 41 41 41 41 41 41 41 41 41 41 
    Class:                             <unknown: 41>
    Data:                              <unknown: 41>
    Version:                           65 <unknown: %lx>
    OS/ABI:                            <unknown: 41>
    ABI Version:                       65
    Type:                              DYN (Shared object file)
    Machine:                           Intel 80386
    Version:                           0x1
    Entry point address:               0x1000
    Start of program headers:          52 (bytes into file)
    Start of section headers:          41836 (bytes into file)
    Flags:                             0x0
    Size of this header:               52 (bytes)
    Size of program headers:           32 (bytes)
    Number of program headers:         9
    Size of section headers:           40 (bytes)
    Number of section headers:         29
    Section header string table index: 26

我也无法使用 GDB 调试它，这是我能够运行它的唯一信息

strace ./binary

这表明发生了一些联系。有谁知道如何操作二进制文件以便更好地分析它？

Answer 1

readelf -h除了“魔术”线外，输出看起来很典型。尝试将文件的前 16 个字节更改为 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00使用十六进制编辑器，这可能会使 objdump 更快乐。

此外，如果操作系统能够加载和执行二进制文件，程序头表一定不是胡说八道。试试 readelf -l binary .对于普通的 x86-32 二进制文件，该命令的输出如下所示:

Elf file type is DYN (Shared object file)
Entry point 0x1050
There are 11 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00000034 0x00000034 0x00160 0x00160 R   0x4
  INTERP         0x000194 0x00000194 0x00000194 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x00000000 0x00000000 0x00398 0x00398 R   0x1000
  LOAD           0x001000 0x00001000 0x00001000 0x0022c 0x0022c R E 0x1000
  LOAD           0x002000 0x00002000 0x00002000 0x0017c 0x0017c R   0x1000
  LOAD           0x002ef4 0x00003ef4 0x00003ef4 0x00124 0x00128 RW  0x1000
  DYNAMIC        0x002efc 0x00003efc 0x00003efc 0x000f0 0x000f0 RW  0x4
  NOTE           0x0001a8 0x000001a8 0x000001a8 0x00044 0x00044 R   0x4
  GNU_EH_FRAME   0x002008 0x00002008 0x00002008 0x0004c 0x0004c R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
  GNU_RELRO      0x002ef4 0x00003ef4 0x00003ef4 0x0010c 0x0010c R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt 
   03     .init .plt .plt.got .text .fini 
   04     .rodata .eh_frame_hdr .eh_frame 
   05     .init_array .fini_array .dynamic .got .got.plt .data .bss 
   06     .dynamic 
   07     .note.gnu.build-id .note.ABI-tag 
   08     .eh_frame_hdr 
   09     
   10     .init_array .fini_array .dynamic .got 

在 Type 列中查找带有 LOAD 的条目，在 Flg 列中查找带有 "R E"的条目，以及覆盖入口点地址的 [VirtAddr, VirtAddr+MemSiz) 范围(在此示例中为 0x1050，但在您的文件中为 0x1000)。该条目的 Offset 列告诉您应该在文件中查找至少一些实际 x86 机器指令的偏移量。它们很有可能是某种解包器/去混淆器，您必须对其进行逆向工程。

我可能帮不了你了。