This article first highights the limitations of existing projects. Then it focuses on the official Android client for Google Play and its internals, based on a Protobuf variant. Thanks to Androguard and its awesome static analysis features, I show how to automatically recover the .proto file of Google Play, enabling us to generate stubs for querying Google’s servers. Finally, I quickly introduce the unofficial API.

Existing projects

Google Play can be queried in two ways: using the official website or the Android client. The website contains pretty much all the useful information, such as app name and developer name, comments, last version number and release date, permissions required by the app, statistics, etc. I guess one could build a simple program that queries this website and parses the pages, but it would still have one limitation: you simply cannot download apps. Well, you can, but for this you will need an actual compatible phone, and as soon as you perform the install request, the application will get downloaded and installed on your phone. Then if you want to retrieve it in order to analyse it, you must plug in your phone and use adb pull. Some managed to get Google Play run within the emulator, but this is still a bit complicated and not straightforward: you need Java, Android SDK, customize your emulator ROM to embed Google Play, and script everyting yourself.

The main project I have been looking at is android-market-api, written in Java. Actually, I am a Python fan, and played much more with its Python equivalent. The goal of those projects is to simulate the network activity generated by the Android client, query Google Play servers, and parse the result. The underlying protocol used by Google Play is based on Google’s Protocol Buffers, aka Protobuf. For those who do not know, this library provides a way to encode messages in binary, compact blobs before sending them on the network, and decode them on the other side. The documentation contains plainty of details on the actual encoding format, so I won’t cover it. The only important thing to know about Protobuf is that it is much easier to decode messages if you know the structure of exchanged messages. Messages are composed of fields, each one having a tag, a name and a type. When encoded, a message embeds the tag, value and type (only basic types, or a generic « message » type) of each field, but not their names. Therefore, the semantics of each field must be guessed, and that is not always easy.

When Google Play Android client is able to query Google’s servers and download APKs, all network communications are done with Protobuf and HTTP(S). The underlying Protobuf file used by the unofficial API projects (and based on Android Market) has been published as a .proto file. The unofficial API can forge some of those requests and interpret results. While playing with them, I have managed to search Android apps, but I could not always download them. Indeed, this version of the API requires a numeric « assetId » corresponding to the app you want to download. When trying to get appropriate assetIds using other API methods such as search(), I got non-numeric values, such as: v2:com.fankewong.angrybirdsbackup2sd:1:4. This type of value is rejected by Google Server when trying to download the app. Too bad…

A first look at Google Play Android client

The weird thing is that the non-numeric assetId problem occurs quite often, but not on all apps. I guess this is because Google updated their API when they switched to Google Play; those projects are using the old version of the API. The only way to have up-to-date information and be able to download any app would then be to analyse the updated Android client, and adapt existing projects.

Here we go! We retrieve com.android.vending-1.apk from an up-to-date Android phone using adb, and we use our favorite Android RE tools. A first look at class names highlights a pretty explicit VendingProtos class, under the com.google.android.vending.remoting.protos package. It contains references to a package named com.google.protobuf.micro, embedded within the app. This package contains classes used to encode and decode messages. It is actually part of a public project, named micro-protobuf, which is a lightweight version of Protobuf. However, the underlying protocol remains the same.

Most of network traffic is sent using HTTPS. After installing our own on CA onto the phone and setting up an interception proxy like Burp, we can sniff traffic. From a black-box approach, the exchanged data looks like a binary stream:

Capturing a Protobuf response with Burp

All we need now is the .proto file of Google Play to be able to decode it. But how can we get this file? It is unfortunately not embedded within the app, so we have to find another way. A paper and a tool have been published on the subject, but work only when the studied app or program embeds some kind of metadata, used by reflection features of Protobuf. This metadata is generally embedded in regular stubs generated with Google’s standard protobuf compiler called protoc. However, this is not the case here since the Protobuf stubs embedded within Google Play Android client were not compiled with standard protoc. Micro-protobuf seems to remove this metadata, probably to make protocol reversing harder.

Anyway, is there a way to guess the structure of exchanged messages, just by having a look at the decompiled Java code of the app? Let’s go back to the VendingProtos class. It is contains many subclasses, among which one named AppDataProto:

public static final class AppDataProto extends MessageMicro
{
  private int cachedSize = -1;
  private boolean hasKey;
  private boolean hasValue;
  private String key_ = "";
  private String value_ = "";

  [...]

  public AppDataProto mergeFrom(CodedInputStreamMicro 
                                paramCodedInputStreamMicro)
    throws IOException
  {
    while (true)
    {
      int i = paramCodedInputStreamMicro.readTag();
      switch (i)
      {
      default:
        if (parseUnknownField(paramCodedInputStreamMicro, i))
          continue;
      case 0:
        return this;
      case 10:
        String str1 = paramCodedInputStreamMicro.readString();
        AppDataProto localAppDataProto1 = setKey(str1);
        break;
      case 18:
      }
      String str2 = paramCodedInputStreamMicro.readString();
      AppDataProto localAppDataProto2 = setValue(str2);
    }
  }

  public AppDataProto setKey(String paramString)
  {
    this.hasKey = 1;
    this.key_ = paramString;
    return this;
  }

  public AppDataProto setValue(String paramString)
  {
    this.hasValue = 1;
    this.value_ = paramString;
    return this;
  }

  [...]
}

We can guess that this class represents a Micro-Protobuf message (the extends MessageMicro part) and that it has two string fields: key and value. Their tag can be extracted from the mergeFrom() method, which aims at decode incoming binary messages. It is composed of a main loop (while(true)) and a switch statement. Each case – except the first and second ones – corresponds to a field. The value of each case is actually the binary representation of the tag and type of the field. Everything is in the documentation; to skip the details, the actual value of each case is equal to (tag << 3) | type. For instance, 10 stands for tag 1, type 2 (string). 18 means tag 2, string. Thus, the actual .proto file looks as follows:

message AppDataProto {
  optional string key = 1;
  optional string value = 2;
}

Actually type 2 is not exactly « string », but any length-delimited field. It could be a string, a series of bytes, or an embedded message itself. In that case, the code looks like this:

case 26:
  VendingProtos.AppDataProto localAppDataProto = new VendingProtos.AppDataProto();
  paramCodedInputStreamMicro.readMessage(localAppDataProto);
  DataMessageProto localDataMessageProto2 = addAppData(localAppDataProto);
  break;

This field has a tag equal to 3 (26 >> 3) and is a message which name is AppDataProto. In order to get this sub-message structure, we would have to repeat the analysis process to the corresponding class, and so on.

Automatic analysis

We now have a way of recovering a message structure by analyzing the generated code. All we need now is automating the process. For this, we can use Androguard, a multi-purpose framework intended to make Android reversing easier. With Androguard, we can simply open an APK, decompile it, parse its Dalvik code, and do all sorts of things. Once installed, one can use the provided androlyze tool to dynamically interact with the framework, and then write a script to automate everything.

Androguard lets us easily browse the available classes and find those that extends MessageMicro.

In [1]: apk = APK('com.android.vending-1.apk')
In [2]: dvm = DalvikVMFormat(apk.get_dex())
In [3]: vma = uVMAnalysis(dvm)
In [4]: proto_classes = filter(lambda c: "MessageMicro;" in c.get_superclassname(), dvm.get_classes())
In [5]: proto_class_names = map(lambda c: c.get_name(), proto_classes)

Then we extract the mergeFrom() method of each class by filtering the method list generated by dvm.get_methods_class(class_name). The basic block list of each method can be obtained with vma.get_method(m).basic_blocks.gets().
The first is usually the one that implements the switch instruction. In Dalvik, a switch is often represented as a sparse-switch instruction, which operand is a table composed of a list of values and offsets, called sparse-switch-payload. Here is an example:

invoke-virtual v3, Lcom/google/protobuf/micro/CodedInputStreamMicro;->readTag()I
move-result v0
sparse-switch v0, +52 (0xa4)
[...]
sparse-switch-payload sparse-switch-payload 0:9 a:a 12:12 1a:1a 22:22 2a:2a 32:32 3a:3a 42:42 4a:4a

Each (value, offset) tuple correspond to a case of the switch; if the value matches the compared register, then the execution continues to the corresponding offset. Once we are able to browse each case of the switch (and its target basic block), we can determine the name of each field and its type by examining the name of the corresponding accessors. For instance, here is a typical basic block:

invoke-virtual v3, Lcom/google/protobuf/micro/CodedInputStreamMicro;->readString()Ljava/lang/String;
move-result-object v1
invoke-virtual v2, v1, L[...]AddressProto;->setCity(Ljava/lang/String;)L[...]AddressProto;
goto -25

Each basic block contains two accessor calls: readXXX() and setYYY(). Their goal is to read an incoming series of bytes and initialize one field of the message. XXX corresponds to the type of the field (here, string), and YYY to its name (city).

The simplified analysis algorithm looks like:

for each class that extends MessageMicro:
  get its mergeFrom() method
    find the sparse-switch instruction
    get the corresponding sparse-switch-payload
    index all values and offsets in a dict
    for each value, offset:
      tag = value >> 3
      get the target basic block using the offset
      find readXXX() and setYYY() calls
      type = XXX
      name = YYY
      index the tuple (tag, type, name)

Then we only need to format the output in order to generate a parsable .proto file, dealing with nested messages and groups among other things.

I called the resulting script androproto.py. It is released with the API code; feel free to play with it. It is able to analyze the target app and print the recovered Profotuf file. I apologize for the dirty code; since Google Play is the only app using Micro-Protobuf that I’ve analyzed, this script is pretty specific. But it should work with any app using this library, with a few changes. Its output on Google Play app looks like this:

message AckNotificationResponse {
}
message AndroidAppDeliveryData {
  optional int64 downloadSize = 1;
  optional string signature = 2;
  optional string downloadUrl = 3;
  repeated AppFileMetadata additionalFile = 4;
  repeated HttpCookie downloadAuthCookie = 5;
  optional bool forwardLocked = 6;
  optional int64 refundTimeout = 7;
  optional bool serverInitiated = 8;
  optional int64 postInstallRefundWindowMillis = 9;
  optional bool immediateStartNeeded = 10;
  optional AndroidAppPatchData patchData = 11;
  optional EncryptionParams encryptionParams = 12;
}
message AndroidAppPatchData {
  optional int32 baseVersionCode = 1;
  optional string baseSignature = 2;
  optional string downloadUrl = 3;
  optional int32 patchFormat = 4;
  optional int64 maxPatchSize = 5;
}
[...]

The resulting output is almost usable with protoc. Almost, because there is a duplicate message that you need to manually remove in order to make protoc happy. But after taking care of that detail, you have a working googleplay.proto that you can use to generate C++, Java and Python stubs for querying Google Play API!

Building Google Play Unofficial Python API

In order to parse Google Play protobuf messages, we dump each server response intercepted with Burp into a file, an use:

protoc --decode=ResponseWrapper googleplay.proto < dump.bin

ResponseWrapper is the root message type; it can be easily guessed by looking at the message names. Once we have a clue of what’s received by the application, we can start building our own API. Since we need a valid auth token from Google server, we need first to authenticate. I simply reused the code from android-market-api-py. Once logged in, we need to deal with protobuf traffic. For most of API requests, the Android client does not send protobuf messages, but only simple GET or POST requests, such as search?c=3&q=%s. In order to parse Protobuf responses, we use the generated Python module (googleplay_pb2):

message = googleplay_pb2.ResponseWrapper.FromString(data)

The resulting message can be browsed like a regular Python object. For some API methods, Google servers also return some prefetch data. A prefetch element contains a URL and raw data. It acts like a cache and can be dealt with pretty easily with a few lines of code.

The final API is pretty straightforward to use. Just follow the README. First make sure to edit googleplay.py and insert your phone’s androidID, then supply your Google credentials in config.py. You can use the provided scripts, producing CSV output, and prettify them with pp. Sorry for the following truncated output due to this blog…

$ alias pp="column -s ';' -t"  # pretty-print CSV

$ python search.py earth | pp
Title                           Package name                            Creator                  Super Dev  Price    Offer Type  Version Code  Size     Rating  Num Downloads
Google Earth                    com.google.earth                        Google Inc.              1          Gratuit  1           53            8.6MB    4.46    10 000 000+
Terre HD Free Edition           ru.gonorovsky.kv.livewall.earthhd       Stanislav Gonorovsky     0          Gratuit  1           33            4.7MB    4.47    1 000 000+
Earth Live Wallpaper            com.seb.SLWP                            unixseb                  0          Gratuit  1           60            687.4KB  4.06    5 000 000+
Super Earth Wallpaper Free      com.mx.spacelwpfree                     Mariux                   0          Gratuit  1           2             1.8MB    4.41    100 000+
Earth And Legend                com.dvidearts.earthandlegend            DVide Arts Incorporated  0          5,99 €   1           6             6.8MB    4.82    50 000+
Earth 3D                        com.jmsys.earth3d                       Dokon Jang               0          Gratuit  1           12            3.4MB    4.05    500 000+
[...]

$ python categories.py | pp
ID                   Name
GAME                 Jeux
NEWS_AND_MAGAZINES   Actualités et magazines
COMICS               BD
LIBRARIES_AND_DEMO   Bibliothèques et démos
COMMUNICATION        Communication
ENTERTAINMENT        Divertissement
EDUCATION            Enseignement
FINANCE              Finance

$ python list.py 
Usage: list.py category [subcategory] [nb_results] [offset]
List subcategories and apps within them.
category: To obtain a list of supported catagories, use categories.py
subcategory: You can get a list of all subcategories available, by supplying a valid category

$ python list.py WEATHER | pp
Subcategory ID            Name
apps_topselling_paid      Top payant
apps_topselling_free      Top gratuit
apps_topgrossing          Les plus rentables
apps_topselling_new_paid  Top des nouveautés payantes
apps_topselling_new_free  Top des nouveautés gratuites

$ python list.py WEATHER apps_topselling_free | pp
Title                  Package name                                  Creator          Super Dev  Price    Offer Type  Version Code  Size    Rating  Num Downloads
La chaine météo        com.lachainemeteo.androidapp                  METEO CONSULT    0          Gratuit  1           8             4.6MB   4.38    1 000 000+
Météo-France           fr.meteo                                      Météo-France     0          Gratuit  1           11            2.4MB   3.63    1 000 000+
GO Weather EX          com.gau.go.launcherex.gowidget.weatherwidget  GO Launcher EX   0          Gratuit  1           25            6.5MB   4.40    10 000 000+
Thermomètre (Gratuit)  com.xiaad.android.thermometertrial            Mobiquité        0          Gratuit  1           60            3.6MB   3.78    1 000 000+

$ python permissions.py com.google.android.gm
android.permission.ACCESS_NETWORK_STATE
android.permission.GET_ACCOUNTS
android.permission.MANAGE_ACCOUNTS
android.permission.INTERNET
android.permission.READ_CONTACTS
android.permission.WRITE_CONTACTS
android.permission.READ_SYNC_SETTINGS
android.permission.READ_SYNC_STATS
android.permission.RECEIVE_BOOT_COMPLETED
[...]

$ python download.py com.google.android.gm
Downloading 2.7MB... Done

$ file com.google.android.gm.apk 
com.google.android.gm.apk: Zip archive data, at least v2.0 to extract

Conclusion

Although there is no metadata within Micro-Protobuf applications, recovering .proto files is still doable and it can still be done automatically. The lack of obfuscation is clearly an advantage for an attacker, since all class and method names are easy to understand. Having a non-official Google Play API is handy for many reasons: performing statistics that aren’t available on the official front-end, looking for plagiarism, automatic malware search / downloading / analysis (Androguard to the rescue)… Feel free to browse the source, fork the project, and improve it!

Conférences

Le programme était aussi riche qu’intense : une douzaine de conférences se déroulant sur deux plateformes ; il y avait donc toujours deux confs en simultané. L’inconvénient était toutefois qu’on ne pouvait assister qu’à la moitié des confs… Pour ma part, j’ai alterné entre les deux plateformes, et j’ai en plus du finaliser quelques slides donc je n’ai pas pu en profiter pleinement. Au final, voila ce à quoi j’ai assisté :

• SCOW – ShellCoding On Windows : Heurs présente son nouvel outil permettant de générer un shellcode générique sous Wndows à partir d’un simple programme C. Un outil permettant de gagner un temps fou lors de la conception d’un exploit, avec en prime une polymorphisation du shellcode en question.
• GoRing0 : Présentée par moi-même. Cette conférence se veut accessible à tous ceux qui s’intéressent de près ou de loin au noyau et au fonctionnement des processeurs x86, en particulier le système de privilèges (ring). J’y présente dans un premier temps toutes les bases nécessaire pour comprendre le coeur de la conférence : un rootkit que j’ai développé et qui permet de passer un thread en ring 0, le contexte étant préservé.
• Drive by Pharming : Abc528 présente une faille XSRF des routeurs de type box (Alicebox, Livebox…) permettant de modifier leur configuration depuis une page HTML hébergée sur un site quelconque.
• XeeK : Ma deuxième conf de la soirée. Je présente XeeK, un projet dont j’ai déjà parlé ici, mais que je n’ai pas encore eu le temps de finir. Il s’agit d’un framework visant à exploiter les failles XSS très rapidement et simplement.
• Lockpicking : Cocolitos et Mr Jack nous démontrent qu’aucun verrou n’est vraiment sûre, en crochetant différents types de serrures, les unes à la suite des autres. On y apprend entre autres qu’on peut crocheter certaines serrures avec un bout d’essuie glace, et ouvrir un cadenas avec une canette. Même certaines serrures réputées haute sécurité y passent.

Dommage, j’ai loupé la conférences de Virtualabs sur les framework Web next gen, qui pourraient fortement m’intéresser pour poursuivre XeeK.

Sinon, si je devais donner mon opinion sur les 3 confs que j’ai vues, je dirai qu’elles étaient à la hauteur de mes attentes et qu’elles valaient vraiment le coup d’oeil, sauf une : le Drive By Pharming. Soyons clairs : je respecte tous les conférenciers ainsi que les présentations qu’ils ont données. Mais je pense que cette conférence, bien que s’adressant à des débutants, manquait de préparation, de contenu (elle a duré 10 min) et contenait des erreurs assez flagrantes. Je reste enthousiaste à l’idée d’accueillir des confs de tous les niveaux, mais je pense toutefois que les conférenciers ne devraient pas hésiter à approfondir un peu plus leurs sujets. Enfin, pour ce qui est de la conférence sur le lockpicking, bien que je n’ai aucune expérience en la matière, j’ai vraiment adoré.

Slides

Voici les slides de mes conférences ainsi que les sources/binaires que je publie :

• GoRing0 : Slides - Binaires - Sources
• XeeK : Slides

Pour les autres, allez sur le site officiel ou contacter directement les conférenciers.

Challenge

Grosse nouveauté de cette année : le challenge principal est un Capture The Flag. Le principe est simple : chaque équipe possède quelques serveurs, leur but étant de les protéger et d’attaquer ceux des autres. En gros :

• Règle n°1 : pas d’attaques physiques.
• Règle n°2 : pas d’attaques sur le serveur du staff.
• Règle n°3 : tout le reste est permis. Même  le déni de service.

Pour pimenter l’affaire, aucune information n’est donnée au préalable, pas même les IP de nos propres machines. Pas de DHCP. Il nous faut alors sniffer le traffic pour nous apercevoir qu’une machine emmet en broadcast. Nous nous attribuons donc des IP statiques sur la même plage, et configurons la machine qui broadcast comme passerelle. A partir de là, nous découvrons le serveur de monitoring qui contient les résultats en temps réel su challenge avec le classement des équipes, ainsi que la liste de toutes les machines. Autant dire que Nmap a bien tourné…

On nous fait parvenir les logins/pass de notre machine Windows, mais pas ceux de celle sous Linux. Prétexte:  ils sont facile à trouver. Je m’acharne donc à bruteforcer avec Hydra (en l’ayant recompilé au passage avec le support pour SSH), mais rien n’y fait. Pierz se penche sur Windows, fait tourner Metasploit, et découvre que les machines sont vulnérables au MS08_067. En quelques secondes, il roote une machine adverse et récupère les hashs à valider. Le score décolle enfin ! Décidé à faire baisser le score des autres équipes, j’exploite la vuln à mon tour et en profite supprimer le contenu de c:\Windows\system32 ainsi que boot.ini et autoexec.bat, puis je lance un reboot. Cependant, je n’avais pas prévu que Windows restaurerai ces 2 fichiers et que la machine booterait toujours. Dommage…

Pendant ce temps, sh4ka et Ivan s’acharnent sur notre Windows en remote desktop. Ivan se fait plaisir sur les crackmes fournis et les reverse rapidement. Kal0n est quant à lui sur un exploit PhpMyAdmin. Avec Sh4ka, je me penche sur le Web. Cependant, il y a un imprévu : le challenge Web prévu est inaccessible car mal configuré. Nous allons alors sur le serveur commun que HZV a laissé pour que même les non participants puissent s’entraîner. Nous trouvons rapidement une include locale, une injection SQL, une faille par authentification faible via cookies et une XSS qui n’a d’ailleurs pas été validé (non prévue à la base). Pendant ce temps, Ivan se penche sur un crackme en kernel, qui lui donne du fil à retordre mais qui fini par tomber.

Aux environs de 5h, on finit par nous donner les accès Linux. Dépités, nous constatons que le login/pass n’était en effet pas bien dur à trouver (freeman:team2). En supposant que la combinaison soit similaire sur les autres machines, nous parvenons à nous connecter chez les autres équipes. Mais nous voyons que tout a été chrooté dans tous les sens, et qu’au final n’avons accès qu’à cat, ls, cs, mv, mkdir et python. Nous découvrons plusieurs binaires suid root, dont un vulnérable à un buffer overflow. L’ASLR étant activé, l’exploitation via  ret onto ret est toujours faisable mais comme nous n’avons pas gdb sur la machine distante, et qu’il commence à se faire tard (ou tôt, question de point de vue), nous préférons nous arrêter là. En plus, nous sommes une des seules équipes restantes…

Remise des prix

Vers 6h, Crashfr annonce les résultats. Nous sommes premiers ! Jamais nous n’aurions pensé gagner, car nous nous attendions à affronter Dvrasp, Fozzy et Artyc… Mais en fait, il étaient trop occupés au bar

Crashfr remet les prix aux équipes : des certifications CEH pour les 1ers, et des livres pour les deuxièmes et troisièmes. Sans oublier bien sûr les super trophées en verres, réalisés pour l’occasion. Pour ma part, comme je serai bientôt consultant chez Sysdream, je pense plutôt convertir ce CEH en LPT (Licensed Penetration Tester), une autre certification d’EC-Council. En tout cas, si j’ai particupé à cette nuit, c’était uniquement pour le fun. Comme d’habitude, la NDH est de mieux en mieux, et son ampleur augmente au fil du temps. A quand une NDH rivalisant avec le Black Hat et le Defcon ? En plus, c’était ma dernière NDH en tant que challenger, vu que l’année prochaine je ferai partie du staff et je pourrai à mon tour goûter aux joies de voir tout le monde s’arracher les cheveux sur un challenge dont je suis l’auteur

See you next year !

GoRing0

GoRing0 est donc un rootkit qui a pour objectif de faire passer un thread en ring 0, et de le rebasculer accessoirement en ring 3 lorsqu’il le souhaite. Pour cela, celui-ci devra bien évidemment charger un driver, afin de s’élever les droits et de permettre une telle commutation. La partie utilisateur du rootkit pourrait se présenter sous la forme d’une librairie exportant deux fonctions principales : GoRing0() et GoRing3(), permettant le basculement en ring 0 et ring 3 respectivement. N’importe quel programme pourrait alors faire appel à ces fonctions et s’élever les droits à volonté. Je développe pour le moment sous Windows, mais idéalement, GoRing0 devrait être capable de fonctionner aussi bien sous sous Linux, la manipulation qu’il effectue étant surtout liée à l’architecture x86.

Le principe de fonctionnement de GoRing0 repose sur les interruptions. Les fonctions GoRing0() et GoRing3() déclenchent une interruption spécifique qui est hookée par le driver et qui se charge de modifier la valeur de CS empilée automatiquement par le processeur. En effet il se trouve que le ring courant du processeur (le CPL) est encodé dans les 2 premiers bits de CS ainsi que dans le descripteur de segment (dans la GDT) auquel il correspond. Plus intéressant encore, Windows définit deux valeurs spéciales de CS : une en userland (0x1b), et une en kernelland (0×8). Il suffit alors au handler d’interruption de substituer la valeur empilée de CS par la valeur kernelland pour passer le thread en ring 0 au retour d’interruption.

Pour le moment, j’ai un prototype fonctionnel stable : j’arrive à passer un thread en ring 0 et à le rebasculer en ring 3. Pour m’en assurer, je peux afficher la mémoire kernel depuis ce thread (adresses supérieures à 0×80000000 sous Windows). Cependant, lorsqu’un thread est en ring 0, il est impossible d’appeler des API Windows car celles-ci vérifient apparamment si le thread qui les appelle vient bien du ring 3. De même, il n’est pas possible d’appeler des fonctions du kernel depuis le thread même en ring 0, à moins d’en connaître l’adresse ou de la résoudre à l’exécution.

Nouvelle conférence à la Nuit Du Hack

Enfin, j’en viens à la véritable news de ce post… Au départ, je devais présenter une conférence sur XeeK et une autre sur InjecSO. Etant donné qu’InjecSO est sorti depuis un moment maintenant (avec la doc sur ce blog), que je me suis lancé dans ce nouveau projet, et que cette année il n’y a pour l’instant aucune conférence orientée kernel, j’ai pensé intéressant de remplacer la conférence sur InjecSO par une sur GoRing0. Je compte y présenter le projet et par la même occasion de présenter rapidement l’architecture x86 et le développement en mode kernel aux débutants en la matière. Ceux pour qui les concepts d’interruption, segments et autre GDT sont du chinois (autrement dit ceux qui n’ont pas compris le paragraphe technique ci-dessus…) sont les bienvenus, je compte justement expliquer tout cela ! Ca sera de plus l’occasion de releaser officiellement GoRing0 et de faire une petite démo. Sur ce, à la NDH !

Ma première conférence sera l’occasion de présenter XeeK, un projet personnel en cours de développement dont le but est de fournir un framework pour exploiter facilement des failles XSS et démontrer leur puissance. L’outil n’est toujours pas fini, donc il va falloir que je fasse vite pour arriver à quelque chose de présentable… :p

Le sujet de la deuxième conférence n’est pas encore décidé à 100%, mais une chose est sure : il traitera d’un domaine nettement plus applicatif et bas niveau. Je pensais au départ présenter InjecSO, mais je vais voir si je ne peux pas trouver un autre sujet encore plus intéressant et inédit…

Enfin, j’en profite pour faire de la pub pour Heurs qui présentera quant à lui son dernier projet : SCOW, un outil permettant de développer des shellcodes entièrement en C sous Windows. Avec un peu de chance, on aura droit à la dernière version en avant première…

Retrouvez le programme complet sur le site officiel. Avec un challenge de type Capture The Flag et un lieu inédit (une péniche sur la Seine), la soirée s’annonce mémorable d’avance ! J’ai déjà hâte d’y être

Parmi tous les sujets proposés, nous avons choisis le «Web 2.0». Même si c’est un sujet très populaire ces derniers temps, il faut avouer qu’il est aussi très controversé : certains le considère comme un phénomène de mode sans réelle innovation technique, d’autres parlent même d’argument marketing pour être plus «vendeur».

Notre travail a consisté à rechercher des informations, et à les synthétiser pour fournir un exposé qui se veut pertinent, le tout en moins de dix pages. Ce document ne se veut pas complet (c’est bien un exposé), mais fournira un bon point de départ pour ceux qui s’intéressent de près ou de loin à ce sujet. Il est toutefois préférable d’avoir quelques bases sur le technologies Web, même s’il n’y a nullement besoin d’être spécialiste dans le domaine pour le comprendre.

Je publie aujourd’hui ce document, et j’espère qu’il vous plaira. La licence n’est pas définie, car je dois avouer que je n’ai pas encore demandé à mes collègues leur autorisation pour utiliser une licence libre. Considérez donc que ce sont les règles standards du copyright qui s’appliquent : vous êtes libre de citer des passages de ce document si vous n’oubliez pas de citer leurs sources dans le document d’origine. Ceci étant dit, bonne lecture !

• Exposé technique sur le Web 2.0 (PDF)

Nous avons choisis le sujet du logiciel libre, et plus précisément de ses enjeux aussi bien pour les particuliers que pour les professionnels. Notre travail a été ensuite présenté devant un jury lors d’une soutenance. Nous avons eu la surprise de voir notre exposé gagner le concours des monographies l’établissement.

Notre monographie fait une trentaine de pages, et est publiée sous licence FDL. Pour ceux qui l’ignorent, cette licence est l’équivalent de la licence GPL pour les documents. Ce qui veut dire que vous êtes libre de la consulter, de la copier, de la redistribuer, à condition que ces oeuvres résultantes soient publiées également sous cette même licence, et qu’elles citent tous les contributeurs.

Vous pouvez télécharger les fichiers suivants :

• La monographie au format PDF
• Les sources du document, au format LaTeX et BibTeX

Par soucis de place sur mon hébergeur, je ne publie pas les images qui sont assez volumineuses. Si vous souhaitez néanmoins reprendre notre travail pour l’améliorer tout en souhaitant inclure ces images, vous pouvez me contacter afin que je vous les fournisse.

Bonne lecture, et n’hésitez pas à améliorer vous-même ce document !