2

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.

  • Inspect the file with a hex editor. Is it actually a binary, or maybe something else, such as a bash script with the Executable flag set? The sh_entsize number actually contains a fragment of text: /lib64/l – but not enough to decide what the entire file is. – usr2564301 Jun 27 '15 at 13:45
  • 1
    The binary is a C program compiled with GCC. It has probably been altered after compilation. – lunfdxar Jun 27 '15 at 13:56
  • Are you free to post the binary on a public server for others to take a look at it? – usr2564301 Jun 27 '15 at 14:04
  • ...yeahh ... can't you find another server that does not require login/registering? Wherever I click I get a popup for media player 'updates'/online casino's/etc. The button "DATEI HERUNTERLADEN" doesn't really do what it is supposed to do. – usr2564301 Jun 27 '15 at 22:25
2

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.

  • I would be surprised if the crackme is sophisticated enough to alter the executable, and kill debuggers (see the pkill strings), but dumb enough to store the password as a plain string. But the LD_PRELOAD is a good idea to try. Upvoted. – Guntram Blohm supports Monica Jun 29 '15 at 9:47
  • Thanks for the suggestion. The strcmp compares the user input with "Axj54?_", if the input has a length >= 7. That is not the correct password though, the strcmp and the hard coded string are probably just for confusion. – lunfdxar Jun 29 '15 at 11:13
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.