Base address of shared objects from ldd output
Does this mean that libc.so.6 will be loaded at the address 0xb7e5c000 ? I’m trying to build a ROP chain for an old CTF challenge and I’d like to get gadgets from the library. I’m looking to know the base address of the library so that I can add it to the offsets of the gadgets.
If you want to create a ROP just for recreational purpose, you may just compile your binary with the -static option. It will statically link the libc to the executable and, thus, increase drastically the number of potential gadgets.
2 Answers 2
In fact, ldd is loading the libraries on-the-fly to list what libraries are needed. So, on this run, you can say that libc.so.6 has been loaded at 0xb7e5c000 , but you have no warranty that it will always be the case. Even with no ASLR, it is mainly depending on the loading order of the libraries that might vary from one run to another.
Nevertheless, assuming you have no ASLR, and speaking about the libc , which will be very likely to be the first loaded library anyway, you can safely assume that it will loaded at this address most of the time.
Yes, the base address of libc.so.6 should be 0xb7e5c000 for that binary. You can verify this by catting /proc//maps while your application is running.
perror gave a much more detailed answer, obviously; he posted it as I was typing mine, else I would have left well enough alone. 🙂 I don’t see much of a contradiction though; as he said, with libc and no ASLR, this address should be the same. Pre-ASLR ret2libc and ROP exploits generally rely on the address of libc not changing.
@Mellowcandle: I agree with devttys0, our both answers end up with the same conclusion. I did just try to be more accurate on what hypothesis were to be taken into account (and why).
How get base address its shared library?
i want to get address of testlib.so from libc.so.6 base address.(because of ASLR) testlib.so is shared library.
gcc -o ./testlib.so ./testlib.c -fPIC -shared -ldl from ctypes import * #libc = CDLL('libc.so.6') libc = CDLL('/lib/x86_64-linux-gnu/libc.so.6') test = CDLL('./testlib.so') print libc print test Start Addr End Addr Size Offset objfile 0x400000 0x6ea000 0x2ea000 0x0 /usr/bin/python2.7 0x8e9000 0x8eb000 0x2000 0x2e9000 /usr/bin/python2.7 0x8eb000 0x962000 0x77000 0x2eb000 /usr/bin/python2.7 0x962000 0xa6f000 0x10d000 0x0 [heap] 0x7ffff63e1000 0x7ffff6483000 0xa2000 0x0 /home/wwwlk/Downloads/testlib.so ^ target address 0x7ffff6483000 0x7ffff6682000 0x1ff000 0xa2000 /home/wwwlk/Downloads/testlib.so 0x7ffff6682000 0x7ffff6683000 0x1000 0xa1000 /home/wwwlk/Downloads/testlib.so 0x7ffff6683000 0x7ffff6684000 0x1000 0xa2000 /home/wwwlk/Downloads/testlib.so . 0x7ffff77f0000 0x7ffff79b0000 0x1c0000 0x0 /lib/x86_64-linux-gnu/libc-2.23.so ^ libc.so.6 address 0x7ffff79b0000 0x7ffff7bb0000 0x200000 0x1c0000 /lib/x86_64-linux-gnu/libc-2.23.so 0x7ffff7bb0000 0x7ffff7bb4000 0x4000 0x1c0000 /lib/x86_64-linux-gnu/libc-2.23.so 0x7ffff7bb4000 0x7ffff7bb6000 0x2000 0x1c4000 /lib/x86_64-linux-gnu/libc-2.23.so 0x7ffff7bb6000 0x7ffff7bba000 0x4000 0x0 . 0x7ffff7ff8000 0x7ffff7ffa000 0x2000 0x0 [vvar] 0x7ffff7ffa000 0x7ffff7ffc000 0x2000 0x0 [vdso] 0x7ffff7ffc000 0x7ffff7ffd000 0x1000 0x25000 /lib/x86_64-linux-gnu/ld-2.23.so 0x7ffff7ffd000 0x7ffff7ffe000 0x1000 0x26000 /lib/x86_64-linux-gnu/ld-2.23.so 0x7ffff7ffe000 0x7ffff7fff000 0x1000 0x0 0x7ffffffde000 0x7ffffffff000 0x21000 0x0 [stack] . Possible to change dynamic libc.so address?
Is it possible to change the address where libc.so.6 will be mapped in memory? For example, have libc.so.6 instead be mapped at, say, 0xb0000000. I’m running Xubuntu 32bit: Linux 3.2.0-23-generic i686 i686 i386 GNU/Linux
In order to perform a few ret2libc buffer overflow exploits, the payload string has to contain the addresses of a few libc functions that are not present in the plt section of my binary. This string should not contain any \x00 bytes, hence why I would like to have the libc library higher up in memory. Note that this is just a custom ‘training binary’. ASLR has temporarily been disabled on my system (it’s just a virtual machine for this sole purpose, so there’s no harm in it).
1 Answer 1
There is an prelink utility (wiki page) which is capable of changing loading address (it is called «base address») of so libs.
What does this prelink do? It changes the base address of a dynamic library to the actual address in the user program’s address space when it is loaded into memory. Of course, ld.so recognizes GNU_PRELINKED tag and will load a dynamic library to its this base address (recall the first argument of mmap is the preferred address; of course, this is subject to the operating system.)
Normally, a dynamic library is built as position independent code, i.e. the -fPIC compiler command-line option, and thus the base address is 0. For example, a normal libc.so has ELF program header as follows ( readelf -l command).
According to man prelink there is an option of prelink utility to rebase (relocate) given library to specified address:
-r —reloc-only=ADDRESS Instead of prelinking, just relink given shared libraries to the specified base address.
The prelink —reloc-only=0x7896000 libc.so.6 should be enough to achieve the change you want.
PS: you can do this relocation on your local copy of libc and then give the path to it via export LD_LIBRARY_PATH=/path/to/your/rebased/copy:$LD_LIBRARY_PATH
Base Address of ELF
I am trying to find the base address of ELF files. I know that you can use readelf to find the Program Entry Point and different section details (base address, size, flags and so on). For example, programs for x86 architecture are based at 0x8048000 by linker. using readelf I can see the program entry point but no specific field in the output tells the base address.
$ readelf -e test ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x8048390 Start of program headers: 52 (bytes into file) Start of section headers: 4436 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 9 Size of section headers: 40 (bytes) Number of section headers: 30 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .interp PROGBITS 08048154 000154 000013 00 A 0 0 1 [ 2] .note.ABI-tag NOTE 08048168 000168 000020 00 A 0 0 4 [ 3] .note.gnu.build-i NOTE 08048188 000188 000024 00 A 0 0 4 [ 4] .gnu.hash GNU_HASH 080481ac 0001ac 000024 04 A 5 0 4 [ 5] .dynsym DYNSYM 080481d0 0001d0 000070 10 A 6 1 4 In the section details, I can see that the Offset is calculated with respect to the base address of the ELF. So, .dynsym section starts at address, 0x080481d0 and offset is 0x1d0. This would mean the base address is, 0x08048000. Is this correct? similarly, for programs compiled on different architectures like PPC, ARM, MIPS, I cannot see their base address but only the OEP, Section Headers.