CODEWITHSUNDEEP
linuxgdbcoredumpaslr
HardcoreHenry
HardcoreHenry

Reputation: 6387

How is ASLR supposed to work with coredumps?

I have a situation where a coredump (generated on a remote system) is not matching symbols in the .o file. I am suspecting this is due to ASLR. Unfortunately, I'm not sure how ASLR is supposed to work with coredumps, so I can't verify.

My logic is that because coredump dumps actual memory, the ASLR offsets must be incorporated into the corefile itself (so now, all address reference to function foo in the corefile would actually hold foo.vaddr + aslr_offset). gdb would have to know what the aslr offset is in order to translate that address back to foo. I'm not finding the where the aslr offset is stored in the corefile though. Does anyone know if such a mechanism even exists, and if it does, how it is supposed to work?

Upvotes: 0

Views: 146

Answers (1)

Employed Russian
Employed Russian

Reputation: 213877

Does anyone know if such a mechanism even exists, and if it does, how it is supposed to work?

It does exist, as you can trivially verify by creating a local core and loading it into GDB.

You can examine the file to segment mapping in the NT_FILE note. It should look like this:

eu-readelf -n core

  CORE                 846  FILE
    15 files:
      5645cecd5000-5645cecd6000 00000000 4096        /tmp/a.out
      5645cecd6000-5645cecd7000 00001000 4096        /tmp/a.out
      5645cecd7000-5645cecd8000 00002000 4096        /tmp/a.out
      5645cecd8000-5645cecd9000 00002000 4096        /tmp/a.out
      5645cecd9000-5645cecda000 00003000 4096        /tmp/a.out
      7f6ea8322000-7f6ea8348000 00000000 155648      /usr/lib/x86_64-linux-gnu/libc.so.6
      7f6ea8348000-7f6ea849d000 00026000 1396736     /usr/lib/x86_64-linux-gnu/libc.so.6
      7f6ea849d000-7f6ea84f0000 0017b000 339968      /usr/lib/x86_64-linux-gnu/libc.so.6
      7f6ea84f0000-7f6ea84f4000 001ce000 16384       /usr/lib/x86_64-linux-gnu/libc.so.6
      7f6ea84f4000-7f6ea84f6000 001d2000 8192        /usr/lib/x86_64-linux-gnu/libc.so.6
      7f6ea851c000-7f6ea851d000 00000000 4096        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
      7f6ea851d000-7f6ea8542000 00001000 151552      /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
      7f6ea8542000-7f6ea854c000 00026000 40960       /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
      7f6ea854c000-7f6ea854e000 00030000 8192        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
      7f6ea854e000-7f6ea8550000 00032000 8192        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

I am not sure that's the mechanism GDB actually uses though.

Upvotes: 1

Related Questions