Gray Hat Python: Python Programming for Hackers and Reverse Engineers

283 Pages·2009·1.68 MB·English

by  Justin Seitz

Gray Hat Python
Table of Contents
FOREWORD
ACKNOWLEDGMENTS
INTRODUCTION
1. SETTING UP YOUR DEVELOPMENT ENVIRONMENT
Operating System Requirements
Obtaining and Installing Python 2.5
Installing Python on Windows
Installing Python for Linux
Setting Up Eclipse and PyDev
The Hacker's Best Friend: ctypes
Using Dynamic Libraries
Constructing C Datatypes
Passing Parameters by Reference
Defining Structures and Unions
2. DEBUGGERS AND DEBUGGER DESIGN
General-Purpose CPU Registers
The Stack
Function Call in C
Debug Events
Breakpoints
Soft Breakpoints
Hardware Breakpoints
Memory Breakpoints
3. BUILDING A WINDOWS DEBUGGER
Debuggee, Where Art Thou?
my_debugger_defines.py
Obtaining CPU Register State
Thread Enumeration
Putting It All Together
Implementing Debug Event Handlers
my_debugger.py
The Almighty Breakpoint
Soft Breakpoints
Hardware Breakpoints
Memory Breakpoints
Conclusion
4. PYDBG—A PURE PYTHON WINDOWS DEBUGGER
Extending Breakpoint Handlers
printf_random.py
Access Violation Handlers
Process Snapshots
Obtaining Process Snapshots
Putting It All Together
5. IMMUNITY DEBUGGER—THE BEST OF BOTH WORLDS
Installing Immunity Debugger
Immunity Debugger 101
PyCommands
PyHooks
Exploit Development
Finding Exploit-Friendly Instructions
Bad-Character Filtering
Bypassing DEP on Windows
Defeating Anti-Debugging Routines in Malware
IsDebuggerPresent
Defeating Process Iteration
6. HOOKING
Soft Hooking with PyDbg
firefox_hook.py
Hard Hooking with Immunity Debugger
hippie_easy.py
7. DLL AND CODE INJECTION
Remote Thread Creation
DLL Injection
Code Injection
Getting Evil
File Hiding
Coding the Backdoor
Compiling with py2exe
8. FUZZING
Bug Classes
Buffer Overflows
Integer Overflows
Format String Attacks
File Fuzzer
file_fuzzer.py
Future Considerations
Code Coverage
Automated Static Analysis
9. SULLEY
Sulley Installation
Sulley Primitives
Strings
Delimiters
Static and Random Primitives
Binary Data
Integers
Blocks and Groups
Slaying WarFTPD with Sulley
FTP 101
Creating the FTP Protocol Skeleton
Sulley Sessions
Network and Process Monitoring
Fuzzing and the Sulley Web Interface
10. FUZZING WINDOWS DRIVERS
Driver Communication
Driver Fuzzing with Immunity Debugger
ioctl_fuzzer.py
Driverlib—The Static Analysis Tool for Drivers
Discovering Device Names
Finding the IOCTL Dispatch Routine
Determining Supported IOCTL Codes
Building a Driver Fuzzer
ioctl_dump.py
11. IDAPYTHON—SCRIPTING IDA PRO
IDAPython Installation
IDAPython Functions
Utility Functions
Segments
Functions
Cross-References
Debugger Hooks
Example Scripts
Finding Dangerous Function Cross-References
Function Code Coverage
Calculating Stack Size
12. PYEMU—THE SCRIPTABLE EMULATOR
Installing PyEmu
PyEmu Overview
PyCPU
PyMemory
PyEmu
Execution
Memory and Register Modifiers
Handlers
Register Handlers
Library Handlers
Exception Handlers
Instruction Handlers
Opcode Handlers
Memory Handlers
High-Level Memory Handlers
Program Counter Handler
IDAPyEmu
addnum.cpp
Function Emulation
PEPyEmu
Executable Packers
UPX Packer
Unpacking UPX with PEPyEmu
Gray Hat Python
Justin Seitz
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: [phone]; fax: [phone]; [e-mail];
www.nostarch.com
Library of Congress Cataloging-in-Publication Data:
Seitz, Justin.
Gray hat Python : Python programming for hackers and reverse engineers /
Justin Seitz.
p. cm.
ISBN-13: 978-1-59327-192-3
ISBN-10: 1-59327-192-1
1. Computer security. 2. Python (Computer program language) I. Title.
QA76.9.A25S457 2009
005.8--dc22
2009009107
No Starch Press and the No Starch Press logo are registered trademarks of
No Starch Press, Inc. Other product and company names mentioned herein may
be the trademarks of their respective owners. Rather than use a trademark
symbol with every occurrence of a trademarked name, we are using the names
only in an editorial fashion and to the benefit of the trademark owner, with no
intention of infringement of the trademark.
The information in this book is distributed on an "As Is" basis, without
warranty. While every precaution has been taken in the preparation of this work,
neither the author nor No Starch Press, Inc. shall have any liability to any person
or entity with respect to any loss or damage caused or alleged to be caused
directly or indirectly by the information contained in it.
No Starch Press
Dedication
Mom,
If there's one thing I wish for you to remember, it's that I love you very
much.
Alzheimer Society of Canada—www.alzheimers.ca
FOREWORD
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
ugly—it 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