VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

ELF executable reconstruction from a core image

Silvio Cesare
Matrix Zine [1]
December 1999

[Back to index] [Comments]

Kernel changes from 2.0 to 2.2

This article was written primarily in Linux 2.0.x but the code was patched to work in both 2.0.x and 2.2.x If any inconsistancies occur in this article related to kernel changes (the ELF core dump image I know has changed. No longer is the first PT_LOAD segment in the image the TEXT segment). I may modify this article to reflect 2.2, but this is currently not planned.

Silvio Cesare, 28 January 2000


This article documents the results from experimenting with binary reconstruction of an ELF executable given a core dump or snapshot of the process image. ELF knowledge is assumed and it is suggested that the interested reader understand the structure of an ELF binary before undertaking full understanding, but if only a rudimentary understanding of the reconstruction is required, then it may be possible to ignore ELF understanding. A Linux implementation of this reconstruction code is provided.

The process image

In summary, a core image is a dump of the process image at dump time. The process image contains a number of loadable program segments or virtual memory regions. In an ELF binary these are referred to by program headers and in the Linux kernel they are referred to as vm_area_struct's. The actual core dump is a dump of the vm_area_struct's but these correspond to the program headers of the executable and shared libraries used to create the process image. In Linux, a group of vm_area_struct's are referred to as a memory map or as a map in the proc file system. A typical map is given below for a program using libc.

debian# cat /proc/16114/maps
08048000-08049000 r-xp 00000000 03:03 50198
08049000-0804a000 rw-p 00000000 03:03 50198
40000000-4000a000 r-xp 00000000 03:03 6001
4000a000-4000c000 rw-p 00009000 03:03 6001
4000c000-4000e000 r--p 00000000 03:03 30009
4000e000-400a0000 r-xp 00000000 03:03 6030
400a0000-400a7000 rw-p 00091000 03:03 6030
400a7000-400b4000 rw-p 00000000 00:00 0
bffff000-c0000000 rwxp 00000000 00:00 0

The first two memory regions using virtual addresses 8048000 - 8049000 and 8049000 - 804a000 correspond to the text and data segments respectively. Notice also that the permission bits represent this also. Also notice that the memory regions only lie on page borders. All memory regions in a core dump or mapping lie on page borders. This means, that the smallest memory region is one page long. It must also be noted that a program segment represented by a program header in an ELF binary does not have to lie on a page border, so program segments do not map one to one on virtual memory regions. The following six mappings correspond to libc memory regions. The last region is the stack.

The core image

The core image as stated above is a dump of the process image with some extra sections for registers and any useful information. In an ELF core image, the memory regions belonging to the process image as stated correspond to program segments, so a core file has a list of program headers each for each virtual memory region. The register information and so forth is stored in a notes section in the ELF binary. To reconstruct an executable from a core dump or process image we can ignore the registers and concentrate only on the memory regions.

Executable reconstruction

To reconstruct an executable from a core dump we simply have to create the ELF execute Abel with the memory regions corresponding to the text and data segments of the core image. It must be remembered, that when loading the text segment, the ELF header and program headers are also loaded into memory (for efficiency) so we can use these for our executable image. The executable ELF header contains such information as the true text and data segment start and size (remember the memory regions lie on page borders).

Now, if we only use the text and data segments in our reconstruction, the result executable may only work on the system it was reconstructed on. This is because the Procedure Linkage Table (PLT) may have resolved shared library functions to point to its loaded value. Moving the binary means that the library may be at a different position, or that the function may be at a different location. Thus for true, system independence, the entire image excluding the stack must be used in the reconstructed executable.

Failures in reconstruction

The problem with reconstruction, is that the snapshot of the process image is at runtime, not at initiation time, so its possible that the data segment which is writable may have changed values. Consider the following code

        static int i = 0;

        int main()
                if (i++) exit(0);

In this instance, reconstructing the image will result in an executable that immediately exits because it relies on the initial value of the global variable 'i'. The educated user may use debugging tools to find such code but for the uneducated user its not so easy.

Uses of reconstruction

Reconstructing images does not have many uses outside academic use but one possible use is the ability to copy an executable that has only execute permission on. Creating the core dump is easy by sending the process a SIGSEGV or alternately, the image may be copied from the process image in the proc filesystem.


$ cat test_harness.c
int main()
	for (;;) printf("Hi\n");
$ gcc test_harness.c -o test_harness
$ ./test_harness
$ kill -SIGSEGV `ps|grep test_harness|grep -v grep|awk '{print $1}'`
$ ./core_reconstruct
$ ./a.out


By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! aka