Is it possible to retrieve the original executable file by reading in memory addresses on Linux ᴀᴍᴅ64 ?

40 views
Skip to first unread message

lael.c...@gmail.com

unread,
Sep 7, 2016, 8:48:34 PM9/7/16
to Native-Client-Discuss
Basically when normal statically linked executables are loaded, the original ᴇʟꜰ file is copied into ʀᴀᴍ (by default at 0x400000 on x86_64 if pie and ᴀꜱʟʀ is disabled).

I read https://chromium.googlesource.com/native_client/src/native_client/+/master/docs/initial_dynamic_load.md and none of the following regions contains an ᴇʟꜰ structure :

0x20000:0x50000
0x1000000:0x1b80000
0xfe500000:0xffffffff

But if I understood how nexe works, although those memory regions used by untrusted code are always the same for my executable, the address are fake and doesn’t corresponds to their virtual equivalent.

So, does the original executable file is copied into ʀᴀᴍ ?
If yes, at which address ?

lael.c...@gmail.com

unread,
Sep 8, 2016, 1:03:56 PM9/8/16
to Native-Client-Discuss
I forgot to tell 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).

This means the loader isn’t sel_ldr but/lib64/ld-nacl-x86-64.so.1. It also implies the INTERP is set to /lib64/ld-nacl-x86-64.so.1.

I guess this change something

Victor Khimenko

unread,
Sep 9, 2016, 6:49:32 PM9/9/16
to Native Client Discuss
Yes, but without ELF headers. ELF headers usually reside in the beginning of code block and thus couldn't be loaded in code segment (when interpreted as code it wouldn't pass rules for code). Instead first page is copied, non mmap'ed - and ELF headers are replaced with HLT instructions.
 
If yes, at which address ?

The one which is specified by ELF file? Everything else is loaded, just elf header is omitted. And if I rememeber correctly it must always be put at 128KiB.

lael.c...@gmail.com

unread,
Sep 9, 2016, 7:17:40 PM9/9/16
to Native-Client-Discuss
Le samedi 10 septembre 2016 00:49:32 UTC+2, khim a écrit :
Yes, but without ELF headers. ELF headers usually reside in the beginning of code block and thus couldn't be loaded in code segment (when interpreted as code it wouldn't pass rules for code). Instead first page is copied, non mmap'ed - and ELF headers are replaced with HLT instructions.

Thanks, is it possible to rebuild it without the original headers ? 

Victor Khimenko

unread,
Sep 9, 2016, 8:44:01 PM9/9/16
to Native Client Discuss
What do you mean by "rebuild it without the original headers"? If it wouldn't be ELF file then loader wouldn't recognize it, obviously...

lael.c...@gmail.com

unread,
Sep 9, 2016, 8:45:33 PM9/9/16
to Native-Client-Discuss
Le samedi 10 septembre 2016 02:44:01 UTC+2, khim a écrit :

What do you mean by "rebuild it without the original headers"? If it wouldn't be ELF file then loader wouldn't recognize it, obviously...
I mean rebuild an executable file in the case I don’t have access to the original binary file… 

Victor Khimenko

unread,
Sep 9, 2016, 8:53:48 PM9/9/16
to Native Client Discuss
I don't think so. Information about executable layout is only used by loader, I don't think it's passed around to user's program. You rarely need it, though: NaCl has very strict restrictions of what's allowed and what's not allowed and newlib-based toolchain defines appropriate symbols which you could use to find out where code segment resides and where data segment resides...
 

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.
To post to this group, send email to native-client-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

lael.c...@gmail.com

unread,
Sep 9, 2016, 9:03:15 PM9/9/16
to Native-Client-Discuss
Le samedi 10 septembre 2016 02:53:48 UTC+2, khim a écrit :
I don't think so. Information about executable layout is only used by loader, I don't think it's passed around to user's program. You rarely need it, though: NaCl has very strict restrictions of what's allowed and what's not allowed and newlib-based toolchain defines appropriate symbols which you could use to find out where code segment resides and where data segment resides...

No, I thought about rebuilding something that can be launched as nexe. not the original file.
If the addresses about where the ᴇʟꜰ segments are loaded are knows, I guess this should be possible to recreate such headers manually, isn’t it ?

Victor Khimenko

unread,
Sep 10, 2016, 4:45:24 AM9/10/16
to Native Client Discuss
Yes, probably. But if you are creating this file then you have access to original, and if you are not then these addressed are not guaranteed to be provided...

If you are using glibc and dynamically linked executables then it's a moot point, anyway: the binary which is loaded first would always be runnable-ld.so, you need to look a how IT loads the binary to see where it's placed and what's awailable.

lael.c...@gmail.com

unread,
Sep 10, 2016, 7:55:10 AM9/10/16
to Native-Client-Discuss
Le samedi 10 septembre 2016 10:45:24 UTC+2, khim a écrit :

Yes, probably. But if you are creating this file then you have access to original, and if you are not then these addressed are not guaranteed to be provided...

If you are using glibc and dynamically linked executables then it's a moot point, anyway: the binary which is loaded first would always be runnable-ld.so, you need to look a how IT loads the binary to see where it's placed and what's awailable.
Again the binary is statically linked so there’s no undefined symbols and the mapped regions are known.

The real probem is don’t have any knowledge  in ᴇʟꜰ structures. So is there a tool that can reverse operations created by
objdump

Victor Khimenko

unread,
Sep 10, 2016, 1:37:37 PM9/10/16
to Native Client Discuss
objcopy could be used, I think, but I'm not a guru.

lael.c...@gmail.com

unread,
Sep 10, 2016, 3:17:09 PM9/10/16
to Native-Client-Discuss
objcopy could be used, I think, but I'm not a guru.
Same thing for me thank you for help. I’ll try to see what need to be copied.
Reply all
Reply to author
Forward
0 new messages