Category Archives: Tools

NoSuchCon #1 debrief and slides

NoSuchCon is over and I am finally back home. It was a really great conference with great talks and a full room all the time (let me say I am very surprised about this). The only negative thing was the projection “wall” which was really bad and “killed” almost everyone’s slides. While I understand it is an historical building, that thing must be improved, either with a temporary solution or something else. Good architecture must also be functional else it is not fulfilling its goal. Anyway, awesome conference, congrats to the organizers for all their hard work, and attendees for their enthusiastic interest.

All the conference slides are available here.

My presentation was a reworked SyScan version about OS X rootkits. The DTrace fbt was replaced by the syscall provider and an attack to Volatility, and Little Snitch was removed. Even if it was a trimmed version I still took more time than allocated. I forgot to apologize at the time for that – I just like to give too much information. Sorry for that :-).

The DTrace syscall provider slides contain an old attack – sysent shadowing – against Volatility. I sort of presented it because I have some issues with the conclusion paragraph at this blog post. It is always easy to find what you know about but what you do not know is not always true, even when simple tricks are being used. Memory forensics is a good progress but we must be very careful with its assumptions. That is my goal with those slides, always question the assumptions – your own and tools. As a side note, Volafox is (was?) also vulnerable to the same trick.

Greetings to everyone I met and special greetings to Arnaud and David for the excellent company and wine, even if Benfica lost the UEFA final :-).

Now it is time to get back to work and writing. There is at least one book to write :-).

Have fun,


Hydra, the sample util I am unable to describe!

Let me give you a small gift before moving my ass to Paris to attend and present at NoSuchCon.

Hydra is sample code of a kernel extension that will intercept process creation, suspend, and  communicate it to a userland daemon that will be in charge of patching the application.

It uses the process hijacking technique I described at SyScan presentation. Instead of injecting a library it leaves the process in a suspended state and makes its PID available for the userland daemon. This daemon will be responsible for patching and resuming the process after.

Using this technique there is no need to resign a codesign protected application because it acts after those checks are done. This is true assuming that the application does not have any additional (internal) code checksum routines. Most don’t, barely any even check codesigning result (I wanted to patch Dash, which does check the signing certificate or something and I was too lazy to find where).

As most of my code, it aims to demonstrate “technology” and different ways to do things. It is not feature complete and if I’m not mistaken all the patching could be done from the kernel (right now I’m not sure if codesigning will be verified after the interception point or not, and it is boring to verify it now).

It is available here at github. The kernel extension is fully working, the userland daemon is just a crude example of how to implement it.

See you in Paris if are attending NoSuchCon. Feel free to meet me there!

Have fun,

There is an error in my SyScan slides!

Today I discovered that my slides contain a (stupid) error!
The story begins with Alex Ionescu telling me the symbols are still available in kernel memory in Mountain Lion. I quickly verified this by doing memory dumps and it was really true. Today I finally got some time to sort it out and verify where they were. To my great surprise I fucked up bigtime on my manual calculations and was dumping the wrong memory area (DUH!). I got even more annoyed when I verified that my sample source code has the right formulas! Unfortunately I deleted the computations file I had used for slides #9 and #10, which show memory dumps of the kernel symbol strings, so I could not replicate my original error. After a while I think I found some clues why I messed up…

Snare’s original post about solving kernel symbols uses the following formula: $string_table=$linkedit_address + ($symtab->stroff – $symtab->symoff). This works in Lion because the symbols offset starts at the beginning of __LINKEDIT. This changed in Mountain Lion so that formula is not true. Rubilyn uses the same formula. One assumption that propagated into my computations and led to this mistake. Ah, assumptions, they are so dangerous :-). I should know better because those slides were created a while after the sample rootkit code. More duh!

The correct formula where symbol strings are located is  __LINKEDIT address + Kernel ASLR + (LC_SYMTAB->stroffset – __LINKEDIT->fileoffset). These are the values from the kernel image at disk, except for kernel aslr slide.

What is the real impact of this mistake? Kernel symbols can be solved from a kernel extensions in Lion and Mountain Lion without using the disk image, but keep in mind that __LINKEDIT is marked as pageable. It still holds true that it is not possible for Snow Leopard and below. The number of Snow Leopard installations is still reasonable so the solution I presented is not totally useless (besides, it can be used for other fun stuff ;-)).

Oh well, failure is part of life and the design of our brains is not perfect. You can study and read tons of books about our design flaws and still fall “victim” at unexpected times. One good reason why I love the Human brain :-).



How to compile gdb in Mountain Lion (updated)

This is an up-to-date version of the old original post about recompiling gdb and other open source packages provided by I’m doing it mostly because code signing is now mandatory for gdb and there’s a stupid old bug that Apple still didn’t fixed since Snow Leopard. I forgot about it on my latest reinstall and lost an afternoon :-). This way you and me will not make the same mistake.

You should have XCode installed. Follow these steps:

1) Download darwinbuild from their SVN repository.
1.1) Since Snow Leopard there is a svn client by default so no need to download.
1.2) Follow the instructions on how to download,compile and install darwinbuild here. Use the guide for Snow Leopard/Lion version, it’s compatible with Mountain Lion.

2) Compile and install darwinbuild:

$ make ; sudo make install

3) Create the DMG file and initialize darwinbuild environment (you should use at least 2 gigabytes):

The plists and build numbers are available at Use build number 12A269 (it’s for 10.8.0 but works ok for all others).

$ hdiutil create -size 2G -type UDIF -fs HFSX -volname Builds -uid 0 -gid 0 -attach Builds.dmg
$ sudo sh
# vsdbutil -a /Volumes/Builds
# cd /Volumes/Builds
# mkdir Build12A269
# cd Build12A269
# darwinbuild -init 12A269 (you need Internet connection)
# darwinxref edit

In darwinxref edit you need to add the gdb package to the configuration. Go to the projects section and add the following:

gdb = {
version = 1822;

Default editor is VI. Save and quit. If you have a problem with an invalid property list, use the same tab alignment as the other entries. That should fix it.

4) Clone the gdb-ng repo from github if you want my patches included (you probably do!). Else skip to step 5) (darwinbuild will download the package from Apple opensource repo).

# cd /Volumes/Builds/Build12A269/Sources
# git clone git://
# cd gdb-ng
# bash
# mv gdb-1822.tar.gz .. (check version in case it changes)
# cd /Volumes/Builds/Build12A269

5) Compile gdb.

# darwinbuild -nochroot gdb

The -nosource option has been added to recent darwinbuild versions. This option will allow you to patch directly into BuildRoot/SourceCache/.
The first time you shouldn’t use this option so darwinbuild will download gdb package. After that you can use it if you want to patch directly gdb source files (that’s what I do with my gdb patches). It’s much easier and faster than having to patch and compress the whole gdb source. After you patch, you just issue “darwinbuild -nochroot -nosource gdb” and this will not unpack the original source but instead use whatever is at SourceCache.

Wait for the compilation to finish…

Go to Roots/gdb/gdb-1822.root*/usr/libexec/gdb. You should have a gdb-i386-apple-darwin. Backup the original and copy this one over.

# cp /usr/libexec/gdb/gdb-i386-apple-darwin /usr/libexec/gdb/gdb-i386-apple-darwin.orig
# cp gdb-i386-apple-darwin /usr/libexec/gdb/

The latest step is to codesign the binary. This is because taskgated default configuration has changed and it’s not anymore sufficient to have the binary suid to procmod group. It must have entitlements and be codesigned. The process is not just creating a self-signed certificate and codesign the binary with it. There is an old bug since Snow Leopard that complicates it a little bit. Follow this guide from LLDB code signing document. You can either code sign the binary you copied above to /usr/libexec/gdb or sign it at the Roots folder and copy the signed version.

Launch gdb and see if it works. It should ask you for your password the first time (after each reboot). If everything is ok you should be able to attach to or run the target process.

Now you can enjoy your next afternoon in case you want/have to compile gdb. You might also want to download and install gdbinit to improve gdb’s output and available commands.


OS.X/Boubou – Mach-O infector PoC source code

More than half a year as passed since Hitcon’12 and as far as I know no one cared much about implementing some sort of detection/protection against this type of attack (correct me if I’m wrong :-)). As explained in Hitcon slides, this trick can be very useful to install backdoors and avoid the usual lame LaunchDaemons type of thing.

I did some massive cleanup to the original PoC that I had glued for Hitcon but it’s still a bit messy and definitely not “production” ready. It contains many “design” decisions that make it easily detectable but keep in mind it can be worked and improved a lot.

The goal here is to show how (easily) it can be done and improve detection/protection. History keeps repeating itself and while everyone is worried with 0days, stupid simple tricks are still very effective. We need to get rid of these first!

Code is available at github and also a zip at the end of the post.

This version only supports non-fat targets so you need to work on it if you want to make a cyberweapon out of it (ahhh, couldn’t resist to make the joke :P).

Link to the Hitcon slides in case you want to reread the concept.

Don’t forget to chown -R root:wheel to all apps in /Applications (very few give problems with this, at least protect the main binary and frameworks).

Have fun,
SHA256( 4e5429aeca58f8d6aea89034409804cc4a8a787fc56b1ce617bb28071eb8d0ce

Ice the Guardian v2, the OS X anti-lamware

Another day, another lame malware attacking and spying on OS X users, and still using the same old lame Daemons and Agents approach to gain persistence at victims machine. Hey, it works, so why change, right?

Ice the guardian v2 is a quick hack using TrustedBSD to monitor the system LaunchDaemons and LaunchAgents folders. There’s a lot of room for improvement so I’m waiting for your commits 😉

Apple has the technology in place so they could probably implement something like this default oin OS X. Gatekeeper can’t be the only obstacle to this kind of stuff.

You can find the source at github repo.

Have fun,