Is it possible to rebuild an nexe file if I can read at arbitrary untrusted memory addresses?

Question

Ok, I’m in a remote situation where I don’t have access to the remote filesystem but where I can run arbitrary python code (except I can’t fork processes and I don’t have access to ulimit and uname).

However, it means I can read and write at arbitrary virtual memory addresses. I know the python interpreter is statically linked so it has no external shared object dependencies.
While nx is enabled, strangely aslr seems to be disabled.
I already identified and dumped the following region whose contents and places never change :

0x00010000:0x00050000 # read only and executable
0x01000000:0x01b80000 # read only and executable
0x11000000:0x1158c000 # writable
# The heap is located between those 2 places and it’s location is chose at random
0xfe500000:0xffffffff # writable

In that case, is it possible to rebuild the ᴇʟꜰ binary ? (it was compiled for native client). It doesn’t have to be the original binary with the original header, but just an executable that can be launched from the various parsed ᴇʟꜰ segments.

Update :

Unlike normal nexe, the python.nexe is compiled nacl_interp can only be ran on Linux. This mean the target ᴏꜱ in the ᴇʟꜰ header is set to 0x7B (whereas normal nexe are ᴏꜱ independent).

The libc is glibc. See also https://groups.google.com/forum/#!topic/native-client-discuss/t54RajuGnPc

Answer 1

It is possible to rebuild the whole binary if you can leak any address in the process address space. As an example here is a memory map of a process

$cat /proc/self/maps
00400000-0040c000 r-xp 00000000 08:01 10223630                           /bin/cat
0060b000-0060c000 r--p 0000b000 08:01 10223630                           /bin/cat
0060c000-0060d000 rw-p 0000c000 08:01 10223630                           /bin/cat
0232c000-0234d000 rw-p 00000000 00:00 0                                  [heap]
.
.
.
.
7ffef94f3000-7ffef9514000 rw-p 00000000 00:00 0                          [stack]
7ffef95cd000-7ffef95cf000 r--p 00000000 00:00 0                          [vvar]
7ffef95cf000-7ffef95d1000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

The first three sections in the map contain the executable itself. You just have to leak that section and then can reassemble to form an executable.

If the binary is not PIE enabled, the location of the executable code will be static every time the binary is ran, as in the above example. By default, you get 0x8048000 load address in 32-bits and 0x400000 64-bit. However this can be changed during the linking process. You can search in the process space for "ELF" and probably your executable would start from there.