Archive for March, 2010

ShaREing is Caring – Announcing the free BinCrowd community server

Thursday, March 25th, 2010

Hi everyone,

today at CanSecWest Thomas and I gave a talk where we announced the BinCrowd community server which zynamics makes available to the reverse engineering community for free. BinCrowd is a collaborative reverse engineering tool that can be used by reverse engineers to keep a repository of reverse engineered information and share this information with friends and colleagues.

The core technology behind BinCrowd is basically a huge database of function information which can be accessed using BinDiff-style algorithms. This allows you to efficiently store information about disassembled functions in a database and to use that database to compare functions from different binary files.

Imagine you are a reverse engineer hunting for new vulnerabilities. Here is what BinCrowd can do for you:

  • You can use BinCrowd to look up whether anybody else in the BinCrowd community has analyzed a particular file before. If the file is already in the database, you can download reverse engineering information like function descriptions or argument names from the database. Due to the fuzzy matching algorithms behind BinCrowd even different versions of the target file are considered.
  • BinCrowd tells you what static libraries are used by the file. If BinCrowd determines that your file is linked against an open-source library you can start reading the original source code instead of the disassembled code.
  • BinCrowd tells you what version of a library is used. If BinCrowd tells you that a vulnerable version of zlib is used in your file, you can go down that path during your audit.
  • You can reverse the lookup process too. If you have a vulnerable function you can ask BinCrowd in what other files this function is used. This will potentially give you many more vulnerable programs without any effort.

Or maybe you are a malware analysis specialist. Your workflow probably differs from that of a vulnerability researcher. Nevertheless, BinCrowd is very useful for you too.

  • You can use BinCrowd as a repository of malware information. If you have identified and documented a certain rootkit hiding technology you can import information from your earlier analysis to new pieces of malware that use the same code.
  • You can use BinCrowd to share information with colleagues from your malware analysis team and even with people from outside your team.
  • If you are working on a team where information flow is restricted by clearance levels you can use BinCrowd as a central information repository. BinCrowd access roles will take care that people with a lower clearance can not download information entered into the system by people with a higher clearance.

There are potentially many more uses for BinCrowd since we are only at the beginning of a long road of creating a repository for reverse engineered information. If you are interested on joining us on that road you can sign up to the community server for free at

To use BinCrowd you only need

Happy shaREing and caring!

Finally, here are the slides Thomas and I used for our talk.

[slideshare id=3856188&doc=shareingiscaring-100325164546-phpapp01-100426045802-phpapp01]

Ralf-Philipp Weinmann & Vincenzo Iozzo own the iPhone at PWN2OWN

Wednesday, March 24th, 2010

Hey all,

this is just a quick announcement that Ralf-Philipp Weinmann (a postdoctoral researcher at the University of Luxembourg) and Vincenzo Iozzo (a researcher at zynamics :-)) owned the iPhone at PWN2OWN today.

A bug in Safari was exploited that extracted the SMS database from the phone and uploaded it to a server.

Vincenzo will write more about the payload construction process once the dust settles — fittingly, the payload used chained return-into-libc (“return oriented programming”) on ARM to execute in spite of code signing. As far as we know, this is the first public demonstration of chainged return-into-libc on thre ARM platform.
I am happy and proud to be able to work with great people (Ralf happens to be a BinNavi/BinDiff user, and Vincenzo is “our youngest” employee).  Now we’ll celebrate for a bit and then prepare tomorrow’s talk.

Here’s a press release and ZDI’s blog post about pwn2own.



A gentle introduction to return-oriented programming

Friday, March 12th, 2010


As I have promised in my last post I will start a series about return-oriented programming. I start with a short introduction about the topic. The introduction covers the origin of return-oriented programming, describes what return-oriented programming is and ends with a definition of return-oriented programming which I will use in the future posts. I will also take some of the recent discussions on Twitter into account which showed that even though I thought I did my history research pretty well, there were still some mailing list post missing from my time-line.

Why do we need return-oriented programming ?

Return-oriented programming is a technique which allows an attacker to execute code in the presence of the following defensive measures.

  • Non executable memory segments
  • Code signing

Where does return-oriented programming come from ?

Return-oriented programming is a recently coined term which describes a technique that has been developed in an iterative process in the security community. The terminology return-oriented programming is used for a subset of techniques which can be referred to as code reuse techniques. To understand where return-oriented programming comes from I show some of the milestones of the techniques history.

Buffer overflows were first publicly documented in the Computer Security Technology Planning Study in 1972 (Appendix 1. Incomplete Parameter Checking). To put this in perspective one must remember that even though we now know that this document was published at the time only a small circle of individuals had access to the document then.

A buffer overflow is, in the original form, a very simple error that is introduced if a function does not perform proper bounds checking for the accessed memory. Basically this means the function receives more input data than it can store. Assuming that the overflowed buffer was located on the stack, the attacker can now write a certain amount of data onto the stack where other variables and the return address might be located. Therefore the attacker can hijack the control flow of the current process and perform an arbitrary computation.

The first major attack which used a buffer overflow as the targeted vulnerability was the Morris worm in 1988. But it was not until the late 90s that major operating systems started to have any protection against buffer overflows. For Microsoft operating systems a form of protection against buffer overflows was only added after the Code-Red and Slammer worms had changed their security mindset in 2004.

One of the defensive measures which have been developed to defend against buffer overflows is the option to mark data memory segments as non-executable. This lead to the next evolutionary step towards return-oriented programming.

Return-into-library technique

The return-into-library technique is the root on which all return-oriented exploit approaches are based.

A return-into-library exploit works as follows: After the attacker has hijacked the control flow, a library function he chooses is executed. The attacker has made sure that the stack pointer points into a memory segment he controls. The attacker has set up the data in the memory segment in a way that it provides the right arguments to the library function of his choice. Through this he can execute a function with the needed arguments.

The technique of return-into-library exploits was initially presented publicly by Solar Designer in his 1997 posting to the Bugtraq mailing list. In this mail the groundwork for return-into-library exploiting was presented. The next milestone in the development of the technique was the Phrack article by Nergal which summarized the known techniques and broadened the attack vector by introducing esp shifting which allowed unlimited chaining of function calls to be used within return-into-library exploitation.

Borrowed code chunks technique

With the introduction of hardware-supported non-executable memory segments in combination with the support of 64 Bit CPUs the game changed again and traditional return-into-library exploits ceased to work. This was due to an ABI change which now required that the arguments to a function must be passed in registers rather than on the stack. Stealth developed a new approach that uses chunks of library functions instead of the call to the function itself to still be able to exploit buffer overflows on machines that employed the newly introduced defense. The approach is designed around the idea to locate instruction sequences which pop values from the stack into the right registers for function calls. By using his approach an attacker can use return-into-library exploits with the new ABI. A library which uses this technique in an automated fashion is DEPLib which has been developed by Pablo Sole. This library completely automates the return-oriented approach for Windows operating systems but it lacks support for loops and conditional branches (which is from a practical point of view negligible).

Return-oriented programming

The return-oriented programming technique broadens the attack vector even further by introducing loops and conditional branches for the return-oriented approach. The first academic work published in the field of return-oriented programming is Hovav Shacham’s ”The Geometry of Innocent Flesh on the Bone: Return-into-libc without function Calls (on the x86)” It describes the two major points which get addressed by return-oriented programming in contrast to the rest of the return-into-library techniques.

  • The return-into-library technique has no support for loops and conditional branching.
  • The removal of functions from libraries does not provide any security against return-oriented programming.

For the x86 the approach he uses to find suitable instruction sequences is based on the fact that the x86 uses a variable length instruction set. Therefore it is possible to search for single binary opcodes which alter control flow such as the return instruction (0xC3) and disassemble the binary from this position backwards. Because x86 uses a variable length instruction set the bytes before the return instruction can provide many possible instruction sequences. Shacham also defined the term gadget which describes one useful instruction sequence which performs one useful operation such as addition.

One assumption which Shacham made is that he thought a fixed length instruction set would make the application of return-oriented programming unfeasible. This was shown not to be the case by Ryan Roemers work which targeted the SPARC architecture which can be seen as the anti-thesis to the x86 architecture. One change which he needed to incorporate into his gadget set was that only memory could be used to pass information between gadgets. This is due to the way SPARC passes information in registers by shifting the register window.

The most practical work which has been published in the field of return-oriented programming is the recent work which targeted the AVC Advantage voting system. This work has provided proof that return-oriented programming is a valid tool for the offensive security researcher as no other technique would have been as useful against the Harvard-type architecture upon which the AVC Advantage is build.

What did we learn ?

Return-oriented programming is a recently coined term but the underlying technology has a long history which is based on the work of many security researchers. We have started with its roots in return-into-library attacks and showed how it evolved until today.

In the next post on return-oriented programming I will explain the first steps of my approach to make return-oriented programming platform independently.


The REIL language – Part I

Sunday, March 7th, 2010

If you have followed the development of BinNavi over the last two years you might know that we are making heavy use of something called REIL to provide features backed by advanced static code analysis. REIL is short for Reverse Engineering Intermediate Language and at its core it is a platform-independent pseudo-assembly language that can be used to emulate native assembly code.

A few years ago, Thomas spent some time thinking about making reverse engineering tools scale (check out the slides of his Black Hat Windows 2004 talk to learn more). Software today is larger and more complex than it was in the past and there are many more interesting platforms to consider as a security researcher (just think of Mac OS, iPhone, Android, Blackberry, Cisco routers, wireless devices, …). Platform-independent automation of common reverse engineering tasks seemed like the way to go. If you manage to develop powerful tools that help you find interesting parts of binary files without manual intervention you can fight growing complexity and reduce its associated costs. We created REIL as one of the key technologies for our path towards this goal.

We designed REIL with one thing in mind: Create a language that can model the effects of real assembly code but – unlike real assembly code – is very easy to analyze programmatically. To achieve this we carefully designed a minimal instruction set of just 17 different instructions and we made sure that the structure of the instruction operands is regular and comprehensible. We also made sure that all REIL instructions have exactly one obvious purpose because we wanted to avoid side effects like setting flags or implicitly accessing memory. Furthermore we have designed a very simple virtual machine (REIL VM) for REIL code to define the semantic behaviour of REIL code.

In the next few posts I will show you what the instruction set of REIL looks like, how the semantic model behind REIL interpretation works, how to use REIL in BinNavi and what the future of REIL will look like.

For now I am going to finish this post with a screenshot that shows some REIL code in BinNavi (click to enlarge). Notice the MIPS-like regularity and simplicity of the instructions. The original x86 instructions that were the source of the REIL code are shown as gray line comments.

A basic block of REIL code

If you already want to learn more about REIL you can check out the BinNavi manual. Here you can find everything that is necessary to understand the REIL language and its use in BinNavi.

BinNavi 3.0 Feature Preview

Monday, March 1st, 2010

Hi everyone,

this week we launched the first beta of BinNavi 3.0 to select customers. We are planning to have a beta phase of 8 weeks with the final release of BinNavi 3.0 coming May 1st 2010.

Existing customers who want to get their hands on the beta version please send an email to

In BinNavi 3.0 we have added many valuable features that once again make it faster and easier for you to complete your reverse engineering jobs. You can find the complete list of new features in the manual on our website. It’s quite lengthy so I only want to talk about the Top 10 new features in this post.

Analyze code of MIPS-based devices

In previous versions of BinNavi it was possible to analyze x86 code, ARM code, and PowerPC code. In BinNavi 3.0 we have added support for MIPS code because MIPS was by far the platform we received most requests for.

Of course we have also added MIPS support to our static code analysis language REIL so your platform-independent analysis algorithms work on MIPS code too.

If you are a customer of our GDB Agent add-on, you can also debug MIPS-based Cisco routers like those of the 3600 family now.

Reverse Engineering MIPS code with BinNavi

Rename local and global variables to understand code

For the longest time BinNavi has had support for fancy stuff like abstract interpretation but not for basic stuff like variable renaming. In BinNavi 3.0 you can now rename local and global variables. This helps you understand code better than with previous versions of BinNavi.

Renaming variables with BinNavi

Find out where global variables are used

While improving support for variables we have also added a new view where you can see all global variables of a module and the functions that access them. This is very useful for tracking inter-function side-effects stored in global variables.

Cross-references to global variables

Quickly get back to your favourite projects, modules, and views

The ability to mark projects, modules, and views (like functions) as favorites is a really simple feature which turned out to be incredibly helpful in practice. With just two clicks you can now “star” items you consider important. Starred items have a small star next to their names and they always show up on top of tables. This makes it very simple to find functions again which you previously considered interesting.

Favorite functions are shown on top of the list

Use a faster disassembly data exporter to get started

Before BinNavi 3.0 we used a Python-based exporter to import disassembly from IDA Pro into our BinNavi MySQL databases. This exporter was really slow and required a lot of additional software packages to be installed. In BinNavi 3.0 we have switched to a C++-based exporter which is blazingly fast (we managed to export more than 80,000 functions per hour here) and does not require any additional installs. Once you realize that your exports now go more than twice as fast as they used to you will love this exporter.

Set conditional breakpoints to make debugging more efficient

Another really useful feature, conditional breakpoints were added to BinNavi 3.0 to allow you to enable or disable breakpoints depending on the current program state.

Breakpoint conditions can include checks for register, flags, and memory values as well as for thread IDs.

Configuring conditional breakpoints

Edit the target process memory to test small patches

Editing the memory of the target process was previously not possible in BinNavi. In BinNavi 3.0 you can edit the memory of whatever process you are debugging using either the GUI or the plugin API.

Editing target process memory

Isolate code quickly using the improved trace mode

I have already written two posts on this blog dedicated to this new feature (see here and here). In essence, we have found a great way to help you find relevant code while debugging.

Improved differential debugging

Quickly see where variables are used

You can now highlight instructions that use a given variable. This helps you quickly see where variables are used in a function.

Highlighting all instructions that access the _hwndNP variable

Quickly recognize special instructions

You can also highlight special instructions now. In this release “special” means either function calls, instructions that read from memory, or instructions that write to the memory. Especially the function call highlighting turned out to be really useful while reverse engineering code. We will probably extend this feature in the future.

Highlighting all function call instructions

So, to wrap this up. Once again, many new features were added and many older features were improved. It was really difficult to pick a Top 10 for this blog post and if you have looked through the list of changes in the manual you might consider other improvements to be more important than the ones presented here.