In this article I will first give an introduction to LLVM, and then I will present a little LLVM-IR obfuscater PoC I have coded for fun. Here is the introduction of the article:

For several months, I came across a lot of papers that use the LLVM framework to develop really cool tools like:

• decompilation framework (Dagger),
• universal deobfuscation (Opticode),
• bug-finding with static binary instrumentation (AddressSanitizer),
• fast C compiler (Clang),
• automatic test cases generator (Klee),
• etc.

In other words, LLVM is everywhere, and it’s only the beginning.

In this paper, I will try in a first part, to give you an overview of the framework: basically what you can do with it and what you cannot. Then, I will introduce a PoC called Kryptonite: a small obfuscater based on LLVM. We will talk about how you can build such tools and how they can be improved.

I’m currently playing with the version 3.3 of LLVM (the latest when I’m writing this paper), so the code may changed a bit for the upcoming version (don’t hesitate to shoot me an email if this is the case).

Keep in mind that no CPUs were harmed during this piece of research, trust me.

The article has been uploaded here, the sources of the PoC are available on my github account here, and the binaries for the crackme are here.

I hope you will enjoy the read, cheers!

This article focus the keygenme challenge made by @elvanderb for the NoSuchCon conference held in Paris some weeks ago. Here is the introduction of the writeup:

As every year, the organizers of the « No Such Con » event give the opportunity to the motivated people to solve some challenges just before the conference. The purpose of the challenge is really simple, you have a light GUI asking you for a login and a password and when they are submitted you either get a bad or a good boy message box. The winner of the challenge wins a trip to Hack In The Box Amsterdam 2014, quite cool: congratulation to Florent Marceau who solved it the first one! The challenge has been solved by approximately eight guys at the moment.

I haven’t seen yet a public writeup, so here is mine: I will try to exactly explain the process I have been through from the beginning of the challenge until the very end, even when my ideas sucks. Last thing, I am really new in breaking those kind of binaries, so if you have figured a part in a different and more elegant/clever way I would really like to have a little chat with you, shoot me an email!

You can find the article here: 0vercl0k_aes_whitebox_unboxing_no_such_problem.pdf, and the github repository here: https://github.com/0vercl0k/stuffz/tree/master/NoSuchCon2013; I hope you will have some fun :).

In this article, I’m going to talk about a little bug I got with IDA, here are the first lines of the introduction:

After spending some cool time for the New Year’s eve, I was back at home ready
to start a new year full of system programming, exploit writing, bug-hunting, etc.
So the 01/01, glad to be alive, I was nally back at my desk (with chocolate boxes
everywhere on it) and I wanted to write a toy program using libogg1
in order to play
with it (someone says fuzzing ?). After reading the examples provided by the libogg
team, I compiled a sort of libogg hello-world and I red up IDA to analyze it. And
at this very moment the impossible happened:

<screenshot IDA crash>

First, I thought this was just a random crash of IDA, maybe because of the IDB
or something like that. Thus, I tried to reload the magic binary (let’s call it this
way) several times in IDA, just to be sure I wasn’t hallucinating ; I wasn’t. Every
time I tried to load the magic binary in IDA the message box poped up and as soon
as I clicked on OK, IDA closed itself.

The article is availabe here: PDB Ain’t PDD, you can also find a bunch of codes related to this article on my github account here.

I hope you guys will enjoy the read, have fun!

In this article I’ll try to give you an overview of the Python API accessible from GDB, and to do that we will create a new command that works approximatively as the DPS’ WinDBG Command.

Here is the introduction:

Since the version 7 of the Gnu Debugger, I’m pretty sure you already know that, but the python interpreter is accessible from GDB. The person behind this work is Tom Tromey: that guy made python available inside GDB, thanks! If you are interested by the implementation of the API, you should check out the sources of GDB, and take a look a the gdb/python directory (also consultable online here).

There are a lot of nice functions you can use to extend your debugger, they are all documented here: GDB Python-API. Indeed, with this API you will be able to do things like:

• Define new (prefixed) commands
• Create pretty-printing modules
• Manipulate breakpoints
• Access the stack frames
• Read/Write/Search directly in the process’ memory
• A lot more!

Lire la suite >>

Here a little paper written during this summer, I finally decided to release it on my blog. This paper gives you a little introduction on the metasm framework and how it can be used in an exploitation way. I let you read a part of the introduction :

The metasm framework is a very powerful weapon that allows you to disassemble, assemble, compile C on-the-y or to debug a binary (yeah you can do a lot of things). It is written in pure ruby by Yoann Guillot (special greets for his job if he reads me o/) since 2007 and the project is very active: check the latest commits!

The main purpose of this paper is to introduce you with my friend metasm and to show how metasm can be very useful in a « real » exploitation case. I don’t know if you remember my latest article on the CVE-2010-3970 but I will use this vulnerability as an example. We will use metasm to create an exploit able to bypass SafeSEH/DEP thanks to the msacm32.drv module, and not l3codeca.acm.

Follow this link: How I Met Your Metasm

After a long time without activity on this blog, today I suggest you a little talk about CVE-2010-3970. Here is a little description of the security hole:

Stack-based buffer overflow in the CreateSizedDIBSECTION function in shimgvw.dll in the Windows Shell graphics processor (aka graphics rendering engine) in Microsoft Windows XP SP2 and SP3, Server 2003 SP2, Vista SP1 and SP2, and Server 2008 Gold and SP2 allows remote attackers to execute arbitrary code via a crafted .MIC or unspecified Office document containing a thumbnail bitmap with a negative biClrUsed value, as reported by Moti and Xu Hao, aka « Windows Shell Graphics Processing Overrun Vulnerability. » – http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3970

So, you will see how I broke DEP and SafeSEH in Windows XP SP2 with ROP. I hope you will enjoy it : CVE-2010-3970_Demystified.pdf.

001] Introduction

Me revoilà aujourd’hui pour vous parler d’un framework développé en python qui permet de faire pas mal de petites choses sympa. Typiquement, les différents modules qui compose volatility servent à extraire de l’information d’une « empreinte mémoire« . L’exemple classique est quand vous demander la création d’un snapshot sous VMWare : celui-ci va créer un fichier ayant l’extension .vmem. Pour rentrer un peu plus dans les détails, ce fichier VMEM n’est ni plus ni moins une copie du contenu de la RAM. Cette manière d’opérer permet de disposer d’un dump de la RAM « propre » : il faut comprendre ici que le dispositif de prise d’empreinte n’affecte en rien cette image. Je vais donc aujourd’hui me focaliser sur le fonctionnement de ce genre d’outils, à savoir comment parser un tel fichier, quelles informations peut-on tirer de ce genre d’analyse et comment donner du sens à une tel analyse.

Lire la suite >>

Aujourd’hui je vais vous parlez d’une feature que propose windows depuis pas mal de temps, le  WMI (Windows Management Instrumentation) est une interface servant au contrôle et au monitoring des différentes ressources de Windows comme par exemple les processus et les périphériques. On la retrouve sur win XP/vista et server 2003/2008. La fonction « Propriété Système » par exemple, utilise WMI pour ‘afficher les différentes informations. Mais ce qui est plutôt cool, c’est que WMI n’est pas seulement utilisable avec vbs.

Lire la suite >>

Voici le dernier article que je consacrerais à mon os (à prioris), je vous donnerais alors les sources du projet en fin d’article ; au cours de celui-ci nous allons nous intéressez à la gestion de la mémoire virtuel en mettant en place de l’identy-mapping et une autre règle pour gérer une tache utilisateur.

C’est vraiment la partie la plus technique que j’ai rencontré, car beaucoup de mécanisme ont été mis en place il faut donc les configurer convenablement afin que le système ne soit pas perturber par l’ajout d’une ou plusieurs features. De plus, il faut vraiment acquérir quelques réflexes comme  la lecture massive de documentation, avec bien évidemment la bible d’intel ; je vous l’accorde c’est pas le plus facile :]. Voilà pour le blabla d’introduction, attachez vos ceintures, et plongeons dans les entrailles de la pagination.

Lire la suite >>

Et c’est repartis, après vous avoir exposé le développement de mon bootloader, je vais commencer à vous parler de la mise en place de mon noyau qui sera entièrement codé (ou presque) en C.

Avant de commencer à parler du kernel, je vais vous rafraichir un peu la mémoire sur ce qui a été fait précédemment.

Nous avions un bootloader capable de passer en mode protégé, avec une petite utilisation de la segmentation :

• Un segment de code kernel, qui avait pour base 0x1000 et pour limite la taille de notre noyau.
• Un segment de donné qui était capable de se balader dans toute la mémoire .

Notre kernel était ensuite chargé en mémoire à l’adresse 0x1000, c’est ici que notre bootloader sautait pour passer la main au noyau.

L’objectif de l’article d’aujourd’hui est déjà de mettre en place notre environnement de développement pour être capable de produire un binaire utilisable par Bochs.

Lire la suite >>