About pwntools

Whether you’re using it to write exploits, or as part of another software project will dictate how you use it.

Historically pwntools was used as a sort of exploit-writing DSL. Simply doing from pwn import * in a previous version of pwntools would bring all sorts of nice side-effects.

When redesigning pwntools for 2.0, we noticed two contrary goals:

• We would like to have a “normal” python module structure, to allow other people to familiarize themselves with pwntools quickly.

• We would like to have even more side-effects, especially by putting the terminal in raw-mode.

To make this possible, we decided to have two different modules. pwnlib would be our nice, clean Python module, while pwn would be used during CTFs.

pwn — Toolbox optimized for CTFs

As stated, we would also like to have the ability to get a lot of these side-effects by default. That is the purpose of this module. It does the following:

• Imports everything from the toplevel pwnlib along with functions from a lot of submodules. This means that if you do import pwn or from pwn import *, you will have access to everything you need to write an exploit.

• Calls pwnlib.term.init() to put your terminal in raw mode and implements functionality to make it appear like it isn’t.

• Setting the pwnlib.context.log_level to “info”.

• Tries to parse some of the values in sys.argv and every value it succeeds in parsing it removes.

pwnlib — Normal python library

This module is our “clean” python-code. As a rule, we do not think that importing pwnlib or any of the submodules should have any significant side-effects (besides e.g. caching).

For the most part, you will also only get the bits you import. You for instance would not get access to pwnlib.util.packing simply by doing import pwnlib.util.

Though there are a few exceptions (such as pwnlib.shellcraft), that does not quite fit the goals of being simple and clean, but they can still be imported without implicit side-effects.