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?
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.