Diary of a reverse-engineer

Because we like to play with weird things.

First Dip Into the Kernel Pool : MS10-058


I am currently playing with pool-based memory corruption vulnerabilities. That’s why I wanted to program a PoC exploit for the vulnerability presented by Tarjei Mandt during his first talk “Kernel Pool Exploitation on Windows 7” [3]. I think it’s a good exercise to start learning about pool overflows.


If you want to experiment with this vulnerability, you should read [1] and be sure to have a vulnerable system. I tested my exploit on a VM with Windows 7 32 bits with tcpip.sys 6.1.7600.16385. The Microsoft bulletin dealing with this vulnerability is MS10-058. It has been found by Matthieu Suiche [2] and was used as an example on Tarjei Mandt’s paper [3].

Triggering the flaw

An integer overflow in tcpip!IppSortDestinationAddresses allows to allocate a wrong-sized non-paged pool memory chunk. Below you can see the diff between the vulnerable version and the patched version.

Having a Look at the Windows’ User/Kernel Exceptions Dispatcher


The purpose of this little post is to create a piece of code able to monitor exceptions raised in a process (a bit like gynvael’s ExcpHook but in userland), and to generate a report with information related to the exception. The other purpose is to have a look at the internals of course.

--Exception detected--
ExceptionRecord: 0x0028fa2c Context: 0x0028fa7c
Image Path: D:\Codes\The Sentinel\tests\divzero.exe
Command Line: ..\tests\divzero.exe divzero.exe
PID: 0x00000aac
Exception Code: 0xc0000094 (EXCEPTION_INT_DIVIDE_BY_ZERO)
Exception Address: 0x00401359
EAX: 0x0000000a EDX: 0x00000000 ECX: 0x00000001 EBX: 0x7ffde000
ESI: 0x00000000 EDI: 0x00000000 ESP: 0x0028fee0 EBP: 0x0028ff18
EIP: 0x00401359
EFLAGS: 0x00010246

0x767bc265 0x54f3620f 0xfffffffe 0x767a0f5a
0x767ffc59 0x004018b0 0x0028ff90 0x00000000

00401359 (04) f77c241c                 IDIV DWORD [ESP+0x1c]
0040135d (04) 89442404                 MOV [ESP+0x4], EAX
00401361 (07) c7042424304000           MOV DWORD [ESP], 0x403024
00401368 (05) e833080000               CALL 0x401ba0
0040136d (05) b800000000               MOV EAX, 0x0

That’s why I divided this post in two big parts:

  • the first one will talk about Windows internals background required to understand how things work under the hood,
  • the last one will talk about Detours and how to hook ntdll!KiUserExceptionDispatcher toward our purpose. Basically, the library gives programmers a set of APIs to easily hook procedures. It also has a clean and readable documentation, so you should use it! It is usually used for that kind of things:
    • Hot-patching bugs (no need to reboot),
    • Tracing API calls (API Monitor like),
    • Monitoring (a bit like our example),
    • Pseudo-sandboxing (prevent API calls),
    • etc.

Breaking Kryptonite’s Obfuscation: A Static Analysis Approach Relying on Symbolic Execution


Kryptonite was a proof-of-concept I built to obfuscate codes at the LLVM intermediate representation level. The idea was to use semantic-preserving transformations in order to not break the original program. One of the main idea was for example to build a home-made 32 bits adder to replace the add LLVM instruction. Instead of having a single asm instruction generated at the end of the pipeline, you will end up with a ton of assembly codes doing only an addition. If you never read my article, and you are interested in it here it is: Obfuscation of steel: meet my Kryptonite.

In this post I wanted to show you how we can manage to break that obfuscation with symbolic execution. We are going to write a really tiny symbolic execution engine with IDAPy, and we will use Z3Py to simplify all our equations. Note that a friend of mine @elvanderb used a similar approach (more generic though) to simplify some parts of the crackme ; but he didn’t wanted to publish it, so here is my blog post about it!

Pinpointing Heap-related Issues: OllyDbg2 Off-by-one Story


Yesterday afternoon, I was peacefully coding some stuff you know but I couldn’t make my code working. As usual, in those type of situations you fire up your debugger in order to understand what is going on under the hood. That was a bit weird, to give you a bit of context I was doing some inline x86 assembly, and I’ve put on purpose an int3 just before the piece of assembly code I thought was buggy. Once my file loaded in OllyDbg2, I hit F9 in order to reach quickly the int3 I’ve slipped into the inline assembly code. A bit of single-stepping, and BOOM I got a nasty crash. It happens sometimes, and that’s uncool. Then, I relaunch my binary and try to reproduce the bug: same actions and BOOM again. OK, this time it’s cool, I got a reproducible crash in OllyDbg2.

I like when things like that happens to me (remember the crashes I’ve found in OllyDbg/IDA here: PDB Ain’t PDD), it’s always a nice exercise for me where I’ve to:

  • pinpoint the bug in the application: usually not trivial when it’s a real/big application
  • reverse-engineer the codes involved in the bug in order to figure out why it’s happening (sometimes I got the sources, sometimes I don’t like this time)

In this post, I will show you how I’ve manage to pinpoint where the bug was, using GFlags, PageHeap and WinDbg. Then, we will reverse-engineer the buggy code in order to understand why the bug is happening, and how we can code a clean trigger.

Some Thoughts About Code-coverage Measurement With Pin


Sometimes, when you are reverse-engineering binaries you need somehow to measure, or just to have an idea about how much “that” execution is covering the code of your target. It can be for fuzzing purpose, maybe you have a huge set of inputs (it can be files, network traffic, anything) and you want to have the same coverage with only a subset of them. Or maybe, you are not really interested in the measure, but only with the coverage differences between two executions of your target: to locate where your program is handling a specific feature for example.

But it’s not a trivial problem, usually you don’t have the source-code of the target, and you want it to be quick. The other thing, is that you don’t have an input that covers the whole code base, you don’t even know if it’s possible ; so you can’t compare your analysis to that “ideal one”. Long story short, you can’t say to the user “OK, this input covers 10% of your binary”. But you can clearly register what your program is doing with input A, what it is doing with input B and then analyzing the differences. With that way you can have a (more precise?) idea about which input seems to have better coverage than another.

Note also, this is a perfect occasion to play with Pin :–)).

In this post, I will explain briefly how you can build that kind of tool using Pin, and how it can be used for reverse-engineer purposes.

Regular Expressions Obfuscation Under the Microscope


Some months ago I came across a strange couple of functions that was kind of playing with a finite-state automaton to validate an input. At first glance, I didn’t really notice it was in fact a regex being processed, that’s exactly why I spent quite some time to understand those routines. You are right to ask yourself: “Hmm but the regex string representation should be in the binary shouldn’t it?”, the thing is it wasn’t. The purpose of this post is to focus on those kind of “compiled” regex, like when the author transform somehow the regex in a FSM directly usable in its program (for the sake of efficiency I guess). And to extract that handy string representation, you have to study the automaton.

In this short post, we are going to see how a regular expression looks like in assembly/C, and how you can hide/obfuscate it. I hope you will enjoy the read, and you will both be able to recognize a regular expression compiled in your future reverse-engineering tasks and to obfuscate heavily your regex!