Debug binary with GDB & disassembly: File format not recognized (elf headers corrupted)

Question

I'm trying to reverse engineer a binary file using GDB and objdump. I can execute the binary in my linux shell, however the file seems to be changed in a way that it can't be debugged / reverse engineered.

The file utility shows the following information:

mybinary: ERROR: ELF 64-bit LSB executable, x86-64, invalid version (SYSV), dynamically linked (uses shared libs)error reading (Invalid argument)

I get the follwing error in GDB:

gdb ./mybinary
mybinary: not in executable format: File format not recognized

and a similar error from objdump:

objdump -S -l -C -F -t -w ./mybinary
objdump: ./mybinary: File format not recognized

readelf shows this at the end of the output:

readelf -h ./mybinary
readelf: Error: Unable to seek to 0xffffff60e9000000 for string table
readelf: Error: Section 8 has invalid sh_entsize 6c2f343662696c2f (expected 18)
readelf: Error: Section 23 has invalid sh_entsize 0 (expected 10)
readelf: Error: no .dynamic section in the dynamic segment

What can I do to debug / reverse engineer this binary?

Edit: gdb and objdump show these error messages, because the elf header of the binary was corrupted on purpose. Still don't know how to fix elf headers or debug this file.

Answer 1

I was not able to run the crackme here, but I did run "strings" on it:

$ strings crackme
/lib64/ld-linux-x86-64.so.2
libc.so.6
srand
puts
time
clock
stdin
calloc
malloc
system
getline
strcmp
__libc_start_main
__gmon_start__
GLIBC_2.2.5
%z   
%r   
%j   
AWAVAUE1
ATE1
[]A\A]A^A_
t7"Hc
[]A\A]A^A_
$&463847345GeF387
pkill -f gdb > /dev/null 2>&1
pkill -f ddt > /dev/null 2>&1
pkill -f ddd > /dev/null 2>&1
Axj54?_
Password check failed!
Congratulations, password check successful!
;*3$"
GCC: (Ubuntu 4.8.2-19ubuntu1) 4.8.2
.shstrtab
.interp
.note.ABI-tag
.note.gnu.build-id
.gnu.hash
.dynsym
.dynstr
.gnu.version
.gnu.version_r
.rela.dyn
.rela.plt
.init
.text
.fini
.rodata
.eh_frame_hdr
.eh_frame
.init_array
.fini_array
.jcr
.dynamic
.got
.got.plt
.data
.bss
.comment

And I have a couple of suggestions:

1. Just above to the "Password check failed!" and "Congratulations, password check successful!" messages, you will find a "Axj54?_" string. You should try it as a solution to the crackme.

2. As there is a reference to "strcmp" you can try the LD_PRELOAD trick to replace strcmp() for your own function. Here is an example code which will print the strings being compared and will also force them to be equal:

Save this file as "mystrcmp.c":

#include <stdio.h>
int strcmp ( const char * str1, const char * str2 ) {
    printf("strcmp intercepted: str1=%s, str2=%s\n", str1, str2);
    return 0;
}

Compile it as:

$ gcc -shared -ldl mystrcmp.c -o mystrcmp.so

And run the crackme as:

$ LD_PRELOAD=./mystrcmp.so ./crackme

It should accept any answer as valid but it should also show you the real answer in one of the intercepted parameters.

Answer 2

Could be that your GNU Debugger (gdb) doesn't support x86_64 architecture.

So try under x86_64 version of it or try LLDB Debugger (lldb) which aims to replace it. It's possible that it could better handle the headers.

See: gdb to lldb command map page for more info.