core2ELF64
Introduction
core2ELF64 is an utility to recover 64 bit ELF executables from core dumps. It supports a wide variety of core dumps:
- Core dumps of Dynamically linked binaries
- Core dumps of PIE binaries
- Core dumps of RELRO enabled binaries
- Core dumps of Statically linked binaries without
glibc
This project is heavily based on core2elf, a project by Reno Robert for 32 bit core dumps, which, in turn, it is based on Silvio Cesare's white paper.
core2ELF64, unlike core2elf, supports to statically linked, PIE and RELRO binary dumps.
Compilation
To compile core2ELF64 simply use the provided Makefile:
make all
In this way the program is compiled together with all the provided examples.
How to use it / Example
First we need to obtain a core dump of a program. For that you can use the gcore utility or the provided sample/dump.sh script that before calling gcore it assures that coredump_filter is correctly set.
$ cd sample/hello
$ ./hello &
[1] 9143
bss_var....[0x60106c]=0x13371337
data_var...[0x601050]=0x00bef03e
stack_var..[0x7ffda80f17dc]=0xcafecafe
heap_var...[0x15fa010]=0xabcdabcd
[1]+ Stopped ./hello
$ sudo ../dump.sh $(pgrep hello)
Saved corefile core.9143
After the dump is obtained, in order to recover the binary it is sufficient to call the core2ELF64 program by passing as first argument the core dump file and as second parameter the desired name of the output file:
$ ../../core2ELF64 core.9143 rebuild
[*] Core dump contains the following segments:
Index Type Virt. addr. start Virt. addr. end Flags
[ 0] NOTE 0x0000000000000000 - 0x0000000000000000 R
[ 1] LOAD 0x0000000000400000 - 0x0000000000401000 R X
[ 2] LOAD 0x0000000000600000 - 0x0000000000601000 R
[ 3] LOAD 0x0000000000601000 - 0x0000000000602000 R W
[ 4] LOAD 0x00000000015fa000 - 0x000000000161b000 R W
[ 5] LOAD 0x00007f6ca4380000 - 0x00007f6ca4540000 R X
[ 6] LOAD 0x00007f6ca4540000 - 0x00007f6ca4740000 R
[ 7] LOAD 0x00007f6ca4740000 - 0x00007f6ca4744000 R
[ 8] LOAD 0x00007f6ca4744000 - 0x00007f6ca4746000 R W
[ 9] LOAD 0x00007f6ca4746000 - 0x00007f6ca474a000 R W
[ 10] LOAD 0x00007f6ca474a000 - 0x00007f6ca4770000 R X
[ 11] LOAD 0x00007f6ca4948000 - 0x00007f6ca494b000 R W
[ 12] LOAD 0x00007f6ca496f000 - 0x00007f6ca4970000 R
[ 13] LOAD 0x00007f6ca4970000 - 0x00007f6ca4971000 R W
[ 14] LOAD 0x00007f6ca4971000 - 0x00007f6ca4972000 R W
[ 15] LOAD 0x00007ffda80d3000 - 0x00007ffda80f4000 R W
[ 16] LOAD 0x00007ffda8180000 - 0x00007ffda8182000 R X
[ 17] LOAD 0xffffffffff600000 - 0xffffffffff601000 R X
[*] Valid text segments: 1 5 10 16
[*] Text segment index = 1
[*] Reconostructed Program Header:
Index Type Virt. addr. start Virt. addr. end Flags
[ 0] PHDR 0x0000000000400040 - 0x0000000000400238 R X
[ 1] INTERP 0x0000000000400238 - 0x0000000000400254 R
[ 2] LOAD 0x0000000000400000 - 0x000000000040095c R X
[ 3] LOAD 0x0000000000600e10 - 0x0000000000601070 R W
[ 4] DYNAMIC 0x0000000000600e28 - 0x0000000000600ff8 R W
[ 5] NOTE 0x0000000000400254 - 0x0000000000400298 R
[ 6] GNU_EH_FRAME 0x0000000000400834 - 0x0000000000400868 R
[ 7] GNU_STACK 0x0000000000000000 - 0x0000000000000000 R W
[ 8] GNU_RELRO 0x0000000000600e10 - 0x0000000000601000 R
[*] Text segment: 0x400000 - 0x40095c
[*] Data segment: 0x600e10 - 0x601070
[*] Dynamic segment: 0x600e28 - 0x600ff8
[*] Recovered sections:
.interp
.dynamic
.note
.eh_frame
.eh_frame_hdr
.bss
.init_array
.fini_array
.dynstr
.dynsym
.got.plt
.data
.plt
.init
.rela.dyn
.rela.plt
.text
.fini
.gnu.version
.gnu_version_r
.gnu.hash
[*] 8 GOT entries found
Then it is possible to check that the recovered executable correctly works:
$ ./rebuild
bss_var....[0x60106c]=0x13371337
data_var...[0x601050]=0x000af7e3
stack_var..[0x7ffdfb7799ec]=0xcafecafe
heap_var...[0x20d7010]=0xabcdabcd
Details
The provided solution works with the dump of these kind of binaries:
- ELF 64-bit LSB executable
- ELF 64-bit LSB shared object (PIE executables)
- Full RELRO binaries
- Statically linked binaries without libc
The steps to recover the binaries from the dump can be summarized as follow:
- Loop over all core dump's memory segments and search for a text segment, i.e. a memory region with Read and eXecute permissions for which the first 4 bytes correspond to the ELF magic numbers. In case of multiple segments that satisfy these requirements, it is requested the user interaction to choose the correct one.
- From the recovered text segment it is possible to recover the ELF program/segment header. From this it is possible to recover all executable segments.
- All the recovered segments are written to the output file. This process is enough for statically linked program to work.
- To help binary analysis, the sections that have a 1:1 match to the recovered segments are written in the recovered ELF.
- The recovered dynamic segment, if present, is analyzed to recover other sections. Thanks to these information it is possible to fix the GOT values so that they point to the correct place in the PLT.
- Finally, the section header is written to the recovered ELF
In the following diagram a graphical summary is shown:
Limitations
-
As shown in the example the data segment that is rebuilt contains runtime values that may differ from the ones present at startup.
-
For binaries compiled with
-staticthat uselibcare correctly rebuild but when run always cause a segmentation fault. Need some investigations to understand the cause.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent