@fr0ster
Ok doing all of these challenges (and some of the boxes) requires a lot of LibC changes. The best “environment” I’ve been able to find that allows me to work on pwn’s as well as systems like rope is this:
Tools
This is a docker that you can spin up on any docker supported system. This docker has most of the tools needed for stack/heap exploit. Follow the instructions but in the run script you’ll see the -v $(pwd)/${ctf_name} option set. This will link a local directory (in this case your current working directory and whatever name you give it) to the docker.
For example. I’ve created a pwndocker.sh that contains the following:
docker run -d \
--rm \
-h pwn \
--name pwn \
-v /home/gridith/challenges/pwn/docker:/ctf/work \
-p 23946:23946 \
--cap-add=SYS_PTRACE \
skysider/pwndocker
So any boxes, challenges I’m working on I make sure to create a subdirectory under /home/gridith/challenges/pwn/docker. Then they will show up inside the docker under /ctf/work
Next is how to use this environment now that its “spun up”. Easiest way to work with this is to have two or three terminals into the docker and to modify any pwntools scripts to allow for gdb to work. To do this I’ve created another bash script file (simple one) called pwnshell.sh
docker exec -it pwn /bin/bash
All this does is get you to the bash prompt on the pwn docker. I typically have two terminal windows up and in each I’ve run the above script so I’m at the pwn docker bash prompt.
Now once there in one window you can work on your pwntools script and in the other window you will load GDB.
Configuring The Docker
The docker contains a /glibc directory. In here you’ll find most of the common glibc compiled bins. so, for example, if you need to work with 2.27. You can have your pwntools script reference:
/glibc/2.27/64/lib/ld-2.27.so
But follow the directions on the github page. They show two ways to refernce libc. One is by copying it around to say the tmp dir and the other is to use pwntools ability to force load environments. Either way works. Dont forget to patch the elf if needed as well to make sure its using the proper libc.
Debugging
In one of your terminal windows run tmux (no parameters just tmux). In the other you will run your scripts. If you’re using pwntools I add this to all my scripts
if args.GDB:
context.terminal = ['tmux', 'new-window']
heapEXE = process('./someELF')
debugger = gdb.attach(heapEXE, '''
break * 0x4011123
c
''')
Now when I run the script I can just add GDB to the args to force gdb to open, set break points, and automatically continue.
python pwnHeapEXE.py GDB
because tmux is running in the other terminal window that is where GDB will load and auto attach to your process. You can step through and when you’re ready quit GDB, make changes to your script and run again.
Vi is not my editor of choice so I typically have a third terminal window open and have nano up editing my script as the docker doesn’t contain nano.
Hopefully this was helpful. This is at least he process I’ve used on almost all of the HTB challenges and boxes that involve Heap for sure and some that are Stack popping.
