Pwntools Download

[Alfie Overacre]

Thebytes vs text distinction is so important that it even made it to this main page.See the pwntools-tutorial repo for the latest tutorial finallyexplaining the difference once and for all (hopefully).

Recently I was at an awesome security conference in Heidelberg called Troopers. During this event there was a two hour CTF event that consisted of two different stages. First stage was getting an initial foothold into a system while the second stage was to pivot to other machines in the hosted network. These other machines were running different services and I was working on a service called CVE launcher (you can get it here, I also made a writeup here). CVE launcher was a binary that was vulnerable against heap overflows due to several integer overflows. Because I was not able to finish my exploit during the game time I decided that I want to speed up my exploit development. In this blog post I will explain how I was able to speed up my workflow and hopefully give you some ideas for faster exploit development as well.

Pwntools is a really neat library for python which allows you to speed up binary exploitation in several ways. The full scope of its features is huge and I am merely scratching the surface here. If you want to dive deeper into pwntools have a look at the very detailed documentation.

You can perform several automated steps and afterwards drop into an interactive shell. With this feature you can speed up processes that are necessary to get to a certain point in the application state without having to perform these either manually or write overhead code. Instead you can focus on the exploit logic itself.

At this point gef comes into play. For those of you that already know extensions for gdb like pwdbg or peda - basically gef is the same thing. Big plus about gef though is that you can easily install it in less than 20 seconds.

Not lets get to the last thing in the toolchain. pwntools also allows you to execute commands in gdb. This allows you to perform tedious gdb commands in a fast way directly when the exploit is executed.

So the problem is that dependencies of pwntools are not available on windows from any configured channels. In this specific case, you are unfortunately out of luck installing from conda, as don't know of any channel that provides ncurses on windows.

Also one thing to note, pwntools has Python2 and Python3 versions. Atm this course uses the Python2, but I have plans to switch it all over to Python3. Just keep in mind that some things change between Python2 to the Python3 versions, however the changes are relatively small.

Now one thing that pwntools does for us, is it has some nice piping functionality which helps with IO. If we want to connect to the server at github.com (if you have an IP address, just swap out the dns name with the IP address) on port 9000 via tcp:

Now one more thing, ELFs store data via least endian, meaning that data is stored with the least significant byte first. In a few situations where we are scanning in an integer, we will need to take this into account. Luckily pwntools will take care of this for us.

A few weeks ago i just started with binary exploitation and as learning and understanding this topic is not enough challenging, i encountered different problems with the tools and some basics. One of these problems i will describe today.

there are many good tutorials, challanges and ctfs out there, where you can start learning the topic. After some reverse engineering lessons and understanding the basics i decided to do the ropemporium series, also because CryptoCat has a good youtube series about it, so you can watch them if you get stuck or want to proof if there are other solutions.

first i decided to concentrate on the 64bit binaries (ropemporium always provide each challenge in different architectures). Completed the first challenge without any problem. The second challenge (split) is about providing a correct parameter to your Gadget. I remembered from LiveOverflow binexp. series that there is a difference between how 32bit and 64bit binaries handle function arguments (stack vs. registers). So i short decided to do the 32bit challenges as well to get a better understanding and practice about that.

The interesting thing is, if you start the binary with in gdb standalone gdb ./split32 everything is fine and you can debug through the hole binary without any crash. So i thought it must have been related to pwntools. I googled a lot about the missing cache file (cacheinfo.c) gdb is claiming about but cant found any one else having this problem.

Make sure you have the latest gdbserver version installed. This makes sense because with gdb.debug pwntools using the gdbserver and not gdb itself, so this is also the reason why debugging in gdb standalone was always working.

I'm doing my CTFing under Windows. I used to spawn a VirtualBox or Hyper-V with Ubuntu from time to time when needed or used Digital Ocean's droplet but since WSL is in town and especially with the speed-up improvements that WSL2 brings I rarely do that. I do "all" my Linux part of CTF using WSL.

For RE (which is my main area of interest) it mostly boils down to running a binary or jumping into gdb on occasion and for that I didn't need anything fancy. But, I've recently started to teach myself some pwn and for that the only logical choice is to use pwntools.

If we would inspect the object l, we wouldn't find a method .error but it does have something close enough - .failure. Maybe it is a bug and our pwntools aren't updated to the latest. Updating pwntools took few seconds but it didn't help.

python3-pwntools is a CTF framework and exploit development library.Written in Python 3, it is designed for rapid prototyping and development,and intended to make exploit writing as simple as possible.

In this article, I will briefly go over how I integrated pwntools with radare2. The means by which I have accomplished this are generic and can be extended to integrate pwntools with your debugger of choice (for instance: IDA Pro, pwndbg, Binary Ninja, etc).

Like most techies, I have a constant struggle to get my setup working "just the way i like it". I have been a fan of pwntools for quite a while as it provides nice abstractions for things such as interacting with programs, utilizing memory leaks, and more. When it comes to interacting with programs, the abstraction layer allows you uniformly interact with a program, and not worry whether your program is being run locally, over a network, via ssh, and more. For reversing and writing exploits, it's often times helpful to run the program under a debugger. Pwntools provides an abstraction for that, in the form of the GDB module.

The GDB module of pwntools was created specifically to automate and abstract starting a process under gdb and performing debugging. Note that I said, specifically, gdb, not a generic debugger. This is mostly a historical choice, likely due to GDB being a defacto debugger for Linux executables. So much so, that the use of gdb sneaks in many places (such as QEMU even having default gdb support). A quick aside on gdb:

When discussing gdb, I'd venture most think of the command-line tool that has that name (i.e.: "gdb ./my_program"). Using GDB in that way is fine if what you want to run is local to the same machine you're running the gdb command from. However, what if you wanted to run gdb against an application running on a separate server? Or for that matter, what if you wanted to debug an application/exploit against an emulated architecture that you were not running locally? One commonly used option in this case is to utilize the GDB Server (gdbserver). The GDB Server allows you to run an application under the purview of the GNU debugger on one server, and connect to and control it from another. In this way, you can interact with an application as if you were running it locally, however in the back-end your gdb is transparently sending commands to the gdbserver instead of directly controlling the binary.

What would actually be happening from pwntool's perspective is that it will start "my_application" up inside gdbserver. From there, it will connect to the gdbserver with a gdb instance. More specifically, the command will look something like this

Luckily, many debuggers out there support connecting to the gdbserver as the backend. For instance, IDA Pro and radare2 both support this. With this in mind, I submitted a PR that added an extra step into this functionality. Specifically, pwntools will now check if an executable file named "pwntools-gdb" exists in it's path. If so, it will preferentially utilize that instead of the gdb binary itself. So the above execution instead looks like:

Why is this a good thing? This now allows for you as a user to create your own handlers for whatever you want to use to debug. The only thing that needs to be supported is that your debugger of choice has to be able to connect to the gdbserver. For my case, I have created a few simple files to manage this. The first, is a script that simply moves or removes ("enables" and "disables") utilization of radare2 as the backend by simply symbolically linking the file name as necessary. The second, more important part, is the script that takes the above pwntools-gdb line, interprets the gdb commands inside the pwntools script file (which contains IP address/port/etc), and runs the application.

This post is already longer than I was hoping it to be, so in short I have uploaded a version of my pwntools-gdb file for radare2. To utilize this, you simply need to name it "pwntools-gdb", chmod u+x, and put it in your PATH somewhere. Also, for the script, any radare2 commands you want to run should start with a hashtag ("#"). This was just a means to shim in commands without getting in the way of the gdb commands which will treat that as a comment. For example:

Also, note that in my script I utilize GNU Screen (for which I also added some extra support to pwntools). If you're not a GNU Screen user, you will need to tweak line 60 to start radare2 how you want to. If you're a tmux user who wants to rant about how much better it is, you can send your feedback to >/dev/null. ;-)

3a8082e126