1

So I tried performing a return-to-libc according to https://sploitfun.wordpress.com/2015/05/08/bypassing-nx-bit-using-return-to-libc/ .

I found libc's address by using "ldd vuln", and found system's offset by using "readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system".

I was struggling with finding the address of "sh" in the fflush command in the program.

I tried hexdump of the binary, and found the offset of "sh\x00", but couldn't find the base-address of the binary.

I am not sure if the addresses I found of libc and system's offset are valid, and I don't really know how to find the actual address of the "sh\x00" string.

Please correct me if I'm wrong about the way I found the addresses, and I'd love to get help with finding the string's address :)

Thank you in advance! :-)

  • Open a debugger, and look for anything loaded without ASLR/DEP. Look for a JMP ESP or JMP EAX address inside a module loaded without ASLR support. You'll need to do ROP chaining if ASLR is enabled on all libraries. Are you still lost? Then go practice the Corelan tutorials. This sounds more suited for Reverse Engineering Stack Exchange, though. – Mark Buffalo Aug 26 '17 at 23:11
2

First, before you can approach your problem, you need to check if the executable is running under ASLR (https://en.wikipedia.org/wiki/Address_space_layout_randomization) If that's the case, you will need to find a way to leak the address from the program, as the address of libc will be different every time. You can easily check this by running gdb-->b main-->info proc mappings a couple of times and comparing the offsets. If they are different, your executable is probably running under ASLR. Assuming there is no ASLR protection, using gdb-->b main-->info proc mappings should give you the base address of the libc SO. In order to find the offset of the function you'd like to jump to, you can use many methods, but using readelf -s should work fine - this will give you the offset of the function calculated from the base of the SO (base address of SO + offset = position of code at runtime).

In order to find the base address of the executable module at runtime you can use use gdb or any other debugger and search for the entry point of the executable (or just search for your string after the executable is loaded into memory...). Basically any program that will load your executable to memory and allow you to view the memory will do.

The address of an executable under linux is usually 0x400000 for 64 bit executables and 0x08048000 for 32 bit executables as defined by the gnu linker. But there's nothing stopping someone from changing the entry point to a different address.

After you've figured out the memory mappings, you'll need to find gadgets in the code, I'll leave that for you to research... https://en.wikipedia.org/wiki/Return-to-libc_attack

Perhaps you can find more answers by looking at exercises at exploit-exercises.com for example, protostar stack6 should deal with ret2libc, you can look for a walkthrough

edited: it seems that ldd won't always give you the correct address, it even ignores disabling of ASLR on my system - It's probably better to use gdb

  • When using "info proc mappings" I get 3 different addresses for libc, which one is the actual one? Heres a screenshot of the 3 libc addresses I get : prntscr.com/gdjo0o – Jonathan Aug 27 '17 at 7:47
  • The lowest offset is the base of module, in your case 0xb7e20000 (see the 0x0 on the column before the last column on that line) – lightnet Aug 27 '17 at 15:41
  • 1
    Thank you @lightnet for the help! You answer definitely helped, but the way I found system's address was using "print system" in GDB (b main --> run ---> print system). Adding this technique to your solution since yours was useful! Thanks! – Jonathan Sep 2 '17 at 9:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.