Disassamble ELF file - debugging area where specific string of binary is loaded

1k Views Asked by At

I would like to disassamble / debug an elf file. Is it somehow possible to track the function where a specific string in the elf file is called? So I mean, I have a string where I know it is used to search for that string in a file. Is it somehow possible with e.g. gdb to debug exactly that position in the executable? Or is the position of the string in the elf file, somehow visible in the objdump -d output?

1

There are 1 best solutions below

0
On

In order to do that you need a disassembler - objdump just dumps the info - it might not give you enough information as some analysis is needed before you can tell where it is being used. What you need is to get the XREFs for the string you have in mind.

If you open your binary in the disassembler it will probably have the ability to show you strings that are present in the binary with the ability to jump to the place where the string is being used (it might be multiple places).

I'll showcase this using radare2.

Open the binary (I'll use ls here)

r2 -A /bin/ls

and then

iz

to display all the strings. There's a lot of them so here's an extract

000 0x00004af1 0x100004af1   7   8 (4.__TEXT.__cstring) ascii COLUMNS
001 0x00004af9 0x100004af9  39  40 (4.__TEXT.__cstring) ascii 1@ABCFGHLOPRSTUWabcdefghiklmnopqrstuvwx
002 0x00004b21 0x100004b21   6   7 (4.__TEXT.__cstring) ascii bin/ls
003 0x00004b28 0x100004b28   8   9 (4.__TEXT.__cstring) ascii Unix2003
004 0x00004b31 0x100004b31   8   9 (4.__TEXT.__cstring) ascii CLICOLOR
005 0x00004b3a 0x100004b3a  14  15 (4.__TEXT.__cstring) ascii CLICOLOR_FORCE
006 0x00004b49 0x100004b49   4   5 (4.__TEXT.__cstring) ascii TERM
007 0x00004b60 0x100004b60   8   9 (4.__TEXT.__cstring) ascii LSCOLORS
008 0x00004b69 0x100004b69   8   9 (4.__TEXT.__cstring) ascii fts_open
009 0x00004b72 0x100004b72  28  29 (4.__TEXT.__cstring) ascii %s: directory causes a cycle

let's see where this last one is being used. If we move to the location where it's defined 0x100004b72. We can see this:

;-- str.s:_directory_causes_a_cycle:       
; DATA XREF from 0x100001cbe (sub.fts_open_INODE64_b44 + 378)

And here we see where it's being referenced -> DATA XREF. We can move there (s 0x100001cbe) and there we see how it's being used.

⁝   0x100001cbe      488d3dad2e00.  lea rdi, str.s:_directory_causes_a_cycle    ; 0x100004b72 ; "%s: directory causes a cycle"
⁝   0x100001cc5      4c89ee         mov rsi, r13
⁝   0x100001cc8      e817290000     call sym.imp.warnx         ;[1]

Having the location you can put a breakpoint there (r2 is also a debugger) or use it in gdb.