I am trying to debug an executable marked as a shared object. I know the trick of run it in GDB and stop with CTRL+C, and other tricks from the question How to handle stripped binaries with GDB? No source, no symbols and GDB only shows addresses?. With "run and CTRL+C" I can to know the addresses where the program is running (0x00005555555547a0, it is the entry point).

ELF headers:

$ readelf -h example 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x7a0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          8504 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           64 (bytes)
  Number of section headers:         27
  Section header string table index: 26

File information in GDB:

gdb-peda$ info file
Symbols from "/home/manu/example".
Local exec file:
        `/home/manu/example', file type elf64-x86-64.
        Entry point: 0x7a0
        0x0000000000000238 - 0x0000000000000254 is .interp
        0x0000000000000254 - 0x0000000000000274 is .note.ABI-tag
        0x0000000000000274 - 0x0000000000000298 is .note.gnu.build-id
        0x0000000000000298 - 0x00000000000002b4 is .gnu.hash
        0x00000000000002b8 - 0x0000000000000438 is .dynsym
        0x0000000000000438 - 0x0000000000000503 is .dynstr
        0x0000000000000504 - 0x0000000000000524 is .gnu.version
        0x0000000000000528 - 0x0000000000000558 is .gnu.version_r
        0x0000000000000558 - 0x0000000000000720 is .rela.dyn
        0x0000000000000720 - 0x0000000000000737 is .init
        0x0000000000000740 - 0x0000000000000750 is .plt
        0x0000000000000750 - 0x00000000000007a0 is .plt.got
        0x00000000000007a0 - 0x0000000000000c62 is .text
        0x0000000000000c64 - 0x0000000000000c6d is .fini
        0x0000000000000c70 - 0x0000000000000f9f is .rodata
        0x0000000000000fa0 - 0x0000000000000fec is .eh_frame_hdr
        0x0000000000000ff0 - 0x000000000000113c is .eh_frame
        0x0000000000201d98 - 0x0000000000201da0 is .init_array
        0x0000000000201da0 - 0x0000000000201da8 is .fini_array
        0x0000000000201da8 - 0x0000000000201db0 is .jcr
        0x0000000000201db0 - 0x0000000000201f70 is .dynamic
        0x0000000000201f70 - 0x0000000000202000 is .got
        0x0000000000202000 - 0x0000000000202018 is .data
        0x0000000000202018 - 0x0000000000202028 is .bss

I would like to know if exist some ways to know this address before of execution?

The executable is a PIE binary

EDIT: Possible solution Set a breakpoint on GDB entry point for stripped PIE binaries without disabling ASLR

  • Are you trying to figure out the address of the entrypoint or do you want to know where the OS will load the executable into memory? The first one is quite easy, the second might be random, depends on your system. – Megabeets Dec 29 '17 at 13:56
  • Hi @Megabeets, yes, it is random. I just want to know if it is possible to get the addresses in the debugger before the execution, but it is no possible. The binary is compiled with PIE. So, the trick "run and CTRL+C" or looking info proc mappings is the only ways, I guess. – sinkmanu Dec 29 '17 at 16:20

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.