Justin Seitz - Gray Hat Python: Python Programming for Hackers and Reverse Engineers

Copyright 2009

For information on book distributors or translations, please contact No Starch Press, Inc. directly:

No Starch Press, Inc.

555 De Haro Street, Suite 250, San Francisco, CA 94107

phone: 415.863.9900; fax: 415.863.9950;

Library of Congress Cataloging-in-Publication Data :

The phrase most often heard at Immunity is probably, "Is it done yet?" Common parlance usually goes something like this: "I'm starting work on the new ELF importer for Immunity Debugger." Slight pause. "Is it done yet?" or "I just found a bug in Internet Explorer!" And then, "Is the exploit done yet?" It's this rapid pace of development, modification, and creation that makes Python the perfect choice for your next security project, be it building a special decompiler or an entire debugger.

I find it dizzying sometimes to walk into Ace Hardware here in South Beach and walk down the hammer aisle. There are around 50 different kinds on display, arranged in neat rows in the tiny store. Each one has some minor but extremely important difference from the next. I'm not enough of a handyman to know what the ideal use for each device is, but the same principle holds when creating security tools. Especially when working on web or custom-built apps, each assessment is going to require some kind of specialized "hammer." Being able to throw together something that hooks the SQL API has saved an Immunity team on more than one occasion. But of course, this doesn't just apply to assessments. Once you can hook the SQL API, you can easily write a tool to do anomaly detection against SQL queries, providing your organization with a quick fix against a persistent attacker.

Everyone knows that it's pretty hard to get your security researchers to work as part of a team. Most security researchers, when faced with any sort of problem, would like to first rebuild the library they are going to use to attack the problem. Let's say it's a vulnerability in an SSL daemon of some kind. It's very likely that your researcher is going to want to start by building an SSL client, from scratch, because "the SSL library I found was ugly ."

You need to avoid this at all costs. The reality is that the SSL library is not uglyit just wasn't written in that particular researcher's particular style. Being able to dive into a big block of code, find a problem, and fix it is the key to having a working SSL library in time for you to write an exploit while it still has some meaning. And being able to have your security researchers work as a team is the key to making the kinds of progress you require. One Python-enabled security researcher is a powerful thing, much as one Ruby-enabled one is. The difference is the ability of the Pythonistas to work together, use old source code without rewriting it, and otherwise operate as a functioning superorganism. That ant colony in your kitchen has about the same mass as an octopus, but it's much more annoying to try to kill!

And here, of course, is where this book helps you. You probably already have tools to do some of what you want to do. You say, "I've got Visual Studio. It has a debugger. I don't need to write my own specialized debugger." Or, "Doesn't WinDbg have a plug-in interface?" And the answer is yes, of course WinDbg has a plug-in interface, and you can use that API to slowly put together something useful. But then one day you'll say, "Heck, this would be a lot better if I could connect it to 5,000 other people using WinDbg and we could correlate our results." And if you're using Python, it takes about 100 lines of code for both an XML-RPC client and a server, and now everyone is synchronized and working off the same page.

Because hacking is not reverse engineeringyour goal is not to come up with the original source code for the application. Your goal is to have a greater understanding of the program or system than the people who built it. Once you have that understanding, no matter what the form, you will be able to penetrate the program and get to the juicy exploits inside. This means that you're going to become an expert at visualization, remote synchronization, graph theory, linear equation solving, statistical analysis techniques, and a whole host of other things. Immunity's decision regarding this has been to standardize entirely on Python, so every time we write a graph algorithm, it can be used across all of our tools.

In ). On the other hand, this is precisely the sort of thing you can whip up in 15 minutes to demonstrate to developers exactly which of the assumptions they are making about their software are clearly untrue. Software companies invest a lot in protecting their internal memory for what they claim are security reasons but are really copy protection and digital rights management (DRM) related.

So here's what you get with this book: the ability to rapidly create software tools that manipulate other applications. And you get to do this in a way that allows you to build on your success either by yourself or with a team. This is the future of security tools: quickly implemented, quickly modified, quickly connected. I guess the only question left is, "Is it done yet?"

Dave Aitel

Miami Beach, Florida

February 2009