CODEWITHSUNDEEP
cgdbreverse-engineeringelf
wasp256
wasp256

Reputation: 6242

Analyzing obfuscated ELF binary

I'm trying to debug an ELF with strange magic bytes

$ 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

I can't debug it with GDB either, the only info I was able to get running it with 

strace ./binary

Which showed some connection happening. Would anyone know how to manipulate the binary so it can be analyzed better?

Upvotes: 2

Views: 1769

Answers (1)

zwol
zwol

Reputation: 140445

The readelf -h output looks typical except for the "magic" line. Try changing the first 16 bytes of the file to be 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 with a hex editor, that might make objdump happier.

Also, if the OS was able to load and execute the binary, the program header table must not be nonsense. Try readelf -l binary. For a normal x86-32 binary, the output of that command would look something like this:

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

Look for an entry with LOAD in the Type column, "R E" in the Flg column, and a [VirtAddr, VirtAddr+MemSiz) range covering the entry point address (0x1050 in this example, but 0x1000 in your file). The Offset column for that entry tells you the offset in the file where you should look for at least a few actual x86 machine instructions. There's a good chance they are some kind of unpacker/deobfuscator that you'll have to reverse-engineer.

I probably can't help you any further.

Upvotes: 2

Related Questions