分析混淆的 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 输出看起来很典型，除了 "magic" 行。尝试使用十六进制编辑器将文件的前 16 个字节更改为 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00，这可能会使 objdump 更快乐。

另外，如果OS能够加载并执行二进制文件，程序头table一定不是废话。尝试 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 机器指令。它们很可能是某种 unpacker/deobfuscator，您必须对其进行逆向工程。

我可能帮不了你了。

分析混淆的 ELF 二进制文件

Analyzing obfuscated ELF binary

c

gdb

reverse-engineering

elf