jeudi, juin 23 2011

Les mains dans le cambouis

Après avoir passé des mois à faire de la sécurité informatique à haute dose on peut avoir envie de se changer un petit peu les idées (mais vraiment juste un peu). Ce genre de moment est l'occasion révée pour ressortir des vieux projets des placards ! Pour ma part j'ai ressorti 3~4 vieux projets et en moins de 2h ils ont tous, sauf un, dérivé vers la sécurité informatique (on ne se refait pas ^^ !). Histoire de jeter malgré tout une petite pierre hors de la thématique usuelle de ce blog je vais donc vous parler du dernier de ces projets (ça reste du Hack, ne vous inquiétez pas ;) )

Robot - Based on a picture published under the Creative Common license by "vmario" on Flickr
Il y a fort fort longtemps dans une contrée pas si éloignée que ça j'ai participé deux années de suite à la coupe de France de robotique. Nos deux participations furent des fiascos mais tant pis, on s'était quand même bien amusé ! Mes responsabilités dans l'équipe se cantonnaient au domaine informatique[1] et il faut bien avouer que c'était pour le mieux car j'étais une quiche en électronique (surtout en comparaison avec les brutes qu'on avait de ce coté là !). Le temps a passé et j'ai toujours considéré que connaitre un peu d'électronique m'ouvrirait pleins de nouveaux horizons d'amusements... Il y a quelques mois de celà j'ai donc craqué et j'ai investi lourdement (au moins...pfiou....facilement...oula....25£ au bas mot :D !) dans un arduino !!! J'ai également ratissé ebay, dealextreme, et oomlout pour obtenir une plaque de prototypage, des cables, des résistances de toutes les valeurs possibles, quelques diodes, et un capteur de distance infra-rouge [2].

Une fois tout ce petit matériel reçu j'ai enfin pu m'amuser à faire clignoter mes LED, à changer les patterns de clignotements en fonction de la distance retournée par le capteur, etc. Puis mon jouet est tombé dans l'oubli, submergé par un ras de marré de sécu informatique. La semaine dernière l'envie de ressorti mon arduino s'est fait sentir et en particulier celle de lui faire commander des moteurs ! Pour le signal de commande aucun problème, l'arduino possède une commande toute faite pour envoyer une PWM sur un port de son choix. Reste donc à acheter des moteurs adéquats, et à trouver une façon de leur envoyer de la puissance.

Pour faire simple j'ai d'abord acheté deux micro moteurs 6V consommant 40mA. C'est extrèmement faible, mais c'est pour une bonne raison : l'arduino est capable de fournir cette puissance là tout seul, sans électronique de puissance supplémentaire :) En choisissant ces moteurs je m'assure donc de pouvoir jouer un petit peu mais probablement pas de faire un robot capable de se déplacer. En effet l'arduino seul fournira à mes moteurs la modeste puissance de 0,2W[3], à titre de comparaison à la coupe de France nos moteurs tournaient autour des 30~40W :-D

Seulement voilà : la livraison de mes moteurs devrait prendre au moins 10 jours :-( ...Du coup je me suis dit qu'en les attendant j'allais réfléchir à une carte de puissance capable d'alimenter de plus gros moteurs (et donc, pourquoi pas, de rendre mon arduino mobile). C'est à ce moment du billet qu'on retombe dans l'informatique (et qu'on compte sur les doigts d'une main le nombre de mes lecteurs qui sont arrivés jusqu'ici lol) : pour confirmer les cartes de puissance que je pourrait imaginer j'ai décidé de les simuler sur ordinateur plutôt que d'envoyer un mail toutes les 10mn pour demander leur avis à mes amis qui sont forts en électroniques. Mais pour simuler un circuit électronique il faut un logiciel de simulation électronique, or il s'avère que ce n'est pas si simple à trouver. C'est donc là que ce billet prend tout son intéret : vous faire part de mon retour d'expérience en la matière et vous éviter de galérer autant que moi si l'envie vous prend de faire mumuse avec un fer à souder virtuel.

Le cahier des charges est simple : il me faut un logiciel gratuit, fonctionnant sous linux, et qui soit capable de simuler tout les petits circuits simples auxquels je pourrai penser. Après quelques recherches sur google j'ai trouvé pas mal de pages faisant des comparatifs des différents logiciels disponibles malheureusement beaucoup des infos présentes sur ces pages étaient vieilles et ne correspondaient plus du tout à la réalité. Du coup j'ai passé plusieurs jours à débrousailler le terrain pour ne finalement conserver que deux logiciels valables : Oregano d'une part, et gEDA d'autre part.


Oregano

Oregano - screenshot by Ozwald

J'ai commencé par Oregano parcequ'il a une interface super user-friendly et semble monolythique (donc simple). A l'usage il est effectivement très agréable mais je lui ai très vite trouvé deux inconvénients :

  • Impossible de trouver comment faire des mesures de courant. Poser des sondes de tension est enfantin, mais les sondes de courant doivent se cacher quelque part au fin fond d'un menu d'option et je ne les ai pas trouvé...
  • régler finement les paramètres de ses composants (en particulier des semi-conducteurs) parait impossible. En pratique c'est possible mais ça n'a rien d'intuitif. En effet, alors que toute l'interface est ultra simpliste, il faut aller éditer l'onglet "model" des propriétés du composant pour y renseigner le model SPICE brute (ce qui est franchement cabalistique et semble contre-nature par rapport au reste de l'interface "clic clic").

Finalement je pourrai l'utiliser...d'autant qu'il permet d'exporter les schéma au format netlist (j'expliquerai ce que c'est un peu plus tard) et que je pourrai donc facilement faire mes mesures de courant. Mais bon...comme je suis passé à gEDA quand je n'arrivais pas à spécifier les caractéristiques d'un pauvre transistor bipolaire, je reste pour l'instant sur gEDA !


gEDA

Alors là c'est du lourd ! gEDA est en fait un conglomérat de plusieurs logiciels spécialisés chacun dans une étape du travail de l'électronique, ce qui lui permet d'être très puissant[4] mais aussi de faire très peur aux débutants :-D En réalité, après m'être penché un petit peu sur le monstre, les fonctions que je souhaite réaliser se résument dans seulement deux tout petit logiciels qui se maitrisent finalement assez vite.

gschem - Screenshot by Ozwald Tout d'abord il y a gschem qui permet de "dessiner" son schéma électronique. Le maniement est beaucoup moins intuitif que celui d'oregano mais au moins il est homogène : que celà soit pour paramétrer un transistor ou une résistance la démarche est la même (à savoir : vous n'avez qu'à ajouter manuellement à votre objet un paramètre de nom "value" qui contient le code SPICE du composant). Cet outil ne sert qu'à dessiner le schéma par contre, vous ne pourrez pas faire de routage avec, et vous n'avez pas à placer de sondes de tensions/courants/autre sur le schéma comme vous devez le faire avec oregano. Une fois le schéma dessiné vous le sauvegarder au format gschem (format par défaut) et vous passez au logiciel suivant...

gspiceui - Screenshot by Ozwald ...gspiceui ! Le petit logiciel gspiceui (qui ne fait pas parti de la suite gEDA d'ailleurs lol) va vous permettre de simuler votre circuit. D'ailleurs si vous êtes sous gentoo pensez à le compiler avec les flags "waveform" et "schematics"[5], si vous êtes sous ubuntu n'utilisez pas la version packagée mais allez plutôt télécharger la dernière[6].

Bref, pour réaliser une simulation avec gspiceui vous devrez importer le schéma réalisé avec gschem (menu File>Import), vous sélectionnez les composants du schéma que vous voulez observer, vous sélectionnez le type de simulation à faire (la simulation temporelle correspond à l'onglet "Transient"), vous choisissez les paramètres temporels de la simulation, les grandeurs que vous voulez observer (courant, tensions, etc.) puis il ne reste plus qu'à créer un fichier de simulation (menu "Simulate>Create"), à lancer la simulation (menu "Simulate>Run"), et à lancer l'appli de visualisation de vos courbes (menu "Simulate>Data viewer").

Une fois le "Data Viewer" lancé vous pouvez glisser/déposer les grandeurs que vous voulez observer depuis la fenêtre flotante contenant la liste de toutes les grandeurs disponibles jusqu'à la zone de traçage de courbe et voilà !

Il ne me reste plus qu'à conclure en vous disant qu'aussi bien oregano que gspiceui s'appuient en fait discrètement sur des moteurs de simulation électronique indépendants (le plus connu étant "SPICE", mais gnucap fonctionnant tout aussi bien si ce n'est mieux (c'est d'ailleurs ce dernier que j'utilise)) ; Que ces moteurs de simulation mangent des fichiers au format "netlist" qui sont générées par oregano ou gspiceui[7] ; Que les deux derniers screenshots (gschem et gspiceui) correspondent justement à un schéma d'alimentation de puissance pour moteur que j'ai moi-même pensé ; Que cet amplificateur de puissance fonctionne ; Qu'il est super simple et tout pourri aussi bien en rendement qu'en fonctionnalités (il ne permet de faire tourner le moteur que dans un seul sens par exemple) ; Mais qu'il fonctionne (oui, j'en suis fier :-p !) ; Et enfin que je vous déconseille de l'utiliser en l'état car sur les screenshots il manque la diode de roue libre.

Allez, on se quite sur la description SPICE d'une diode (pour vous prouver que c'est vraiment cabalistique et que ça ne colle pas du tout avec l'interface bisounours d'oregano) :

MODEL 1N1004 D (IS=0.5UA RS=6 BV=5.20)

Notes

[1] et un petit peu de mécanique quand ça se résumait à manier l'arme ultime du travail propre : le pistolet à colle

[2] le même type que ceux qu'on avait utilisé sur notre robot :)

[3] Souvenez-vous : P = UI. Dans mon cas I=40mA et U=5V (et non pas 6V, car l'arduino sort en 5V tout simplement)

[4] Vous pouvez tout faire avec gEDA, du design de schémas aux plans de routage en passant par les simulations électriques de tout poil

[5] sinon vous ne pourrez pas tracer de courbes, ou vous ne pourrez pas importer les schémas dessinés par gschem

[6] la version packagée sous ubuntu souffre d'un bug tout con qui rend le lancement de simulation impossible si vos paramètres de langue utilisent une virgule au lieu d'un point pour les nombres décimaux...ce qui est le cas en Français

[7] C'est justement lors de la génération des fichiers netlist que le problème de séparation des décimales rend la version de gspiceui packagée Ubuntu (9.98) inutilisable en environnement français

jeudi, juin 16 2011

Un geek ne vieillit pas, il level up.

Dans mon système de notation personnel j'ai obtenu un level up la semaine dernière (voire même plusieurs) ! Tout ces "level up" se sont concentrés en 3 jours, à savoir les 8, 9, et 10 juin 2011 et ça mérite bien un article "pot pourri" avec pleins de remerciement dedans (mais pas de technique, donc si c'est ça que vous aimez : passez tout de suite votre chemin et revenez pour le prochain billet :) )

SSTIC 2010 - Creative Common based on pictures from sstic.org published under Creative Common BY-NC-SA
Premier level-up : J'ai présenté, au SSTIC, un outils de cassage de mot de passe qui, en toute modestie[1], mérite qu'on y jette un oeil si jamais on est amené à casser fréquemment du mot de passe. C'est un outil que j'ai développé pour l'entreprise qui m'emploie actuellement en tant que pentesteur et que nous utilisons déjà allègrement donc vous pouvez vérifier que "je ne vous crapule pas"[2] : ça fonctionne. Pour les curieux les détails sont ici, , et probablement bientôt sur le site du SSTIC dans la section Actes.

Second level-up : J'ai rencontré des gens dont j'admire des travaux/réalisations/écrits et qui se sont avérés super sympa. Pour être certain d'en oublier je n'en citerai que deux[3] : Sid et Simon Marechal,

Troisième level-up : J'ai rencontré d'autres auteurs de travaux/réalisations/écrits admirables mais que je ne connaissais pas avant le SSTIC[4] et qui se sont avérés être des personnes très intéressantes et que j'espère revoir l'an prochain (au plus tard :)). Encore une fois pour être certain d'en oublier je n'en cite que deux : Serianox et Nicolas Prigent.

Bref le SSTIC c'était vraiment excellent, mais il faut être rudement rapide pour obtenir des places (tout part en quelques heures) et l'an prochain je n'aurai certainement pas ma place réservée bien au chaud :-/ ... Je comptais conclure ce billet en vous résumant les conférences que j'ai le plus apprécié mais finalement c'est trop difficile tant j'ai aimé de conférences...Allez donc plutôt jeter un oeil chez les gens qui écrivent bien mieux que moi.

Me reste donc à remercier :

  • tout ceux qui m'ont permis de travailler sur les Rainbow Tables probabiliste et d'arriver à ces résultats
  • tout ceux qui m'ont permis de présenter ça au SSTIC[5]
  • tout ceux qui m'ont écouté
  • tout ceux qui sont venu me poser des questions après la conf ou juste me dire que c'était bien
  • Milin et tout les autres[6]
  • Ceux que j'oublie.

Notes

[1] ou pas

[2] Pour citer Stéphane DUVERGER lors de son excellente conférence présentant ramooflax

[3] à noter qu'une rumeur voulait que Zythom soit au SSTIC cette année mais après moult débats sur la façon de prononcer "Zythom" et surtout après une enquête discrète lors du social event il m'a été impossible de confirmer/infirmer la rumeur :(

[4] on ne saurait tout connaitre

[5] ce qui inclus tout ceux qui travaillent pour que le SSTIC ait lieu

[6] remerciement privé, ouais je sais c'est mal

mercredi, juin 1 2011

Android c'est bon, mangez en !

Avec l'été qui revient le soleil se fait de plus en plus présent et c'est donc le moment de ressortir...son android ! Bah oui, avec le beau temps on se retrouve plus souvent à glander en plein air et pour geeker il n'y a alors rien de plus pratique/portable qu'un android :)

Droid Has Landed
J'avais déjà expliqué dans un vieux billet comment installer un environnement d'émulation Android[1], et bien cette fois je vais parler de SL4A. SL4A c'est une application qui vous permet d'utiliser des langages de scripts populaires (LUA, ruby, python, etc.) sur votre android. Pour en profiter il suffit d'installer SL4A (soit depuis le market soit en téléchargeant l'APK directement depuis leur site. Pour l'installer sur emulateur ca fera donc adb install ~/droid/sl4a_r4.apk), de le lancer, de choisir "ajouter" dans le menu de l'application, puis de choisir l'interpretteur du langage de votre choix (pour ma part j'ai choisi Python ;) ).

Une fois SL4A installé et les interpretteurs de votre choix téléchargés et installés depuis SL4A vous avez accès à toute une API qui vous permet d'interragir, depuis vos scripts, avec le terminal Android. Vous pouvez par exemple accéder à la liste des contacts enregistrés, lire les capteurs divers et variés, utiliser l'apareil photo, envoyer/lire des sms, etc. Par contre, coder sur son téléphone ça devient vite fatiguant, donc un tout petit peu de préparation est utile pour coder à son aise.

Tout d'abord nous décidons de coder sur émulateur, ça évitera de mettre trop la grouille sur notre téléphone. Ensuite il faut savoir que les scripts que SL4A est capable de lancer sont stockés par défaut dans "/mnt/sdcard/sl4a/scripts". Enfin il faut savoir un petit peu se servir de l'outil "adb" qui est fourni avec le SDK Android (mais vraiment juste "un peu" je vous rassure).

Pour coder à notre aise donc, nous allons commencer par lancer un AVD[2] (je vous conseille de lui accorder au moins 512Mo de mémoire vive, sinon ça rame vraiment trop !). Ensuite nous choisissons un répertoire sur notre machine hote qui servira de répertoire de développements[3]. Enfin, on va y coder notre premier petit script python pour android (avec VIM bien entendu) :

import android
droid = android.Android()
droid.makeToast("Bonjour le monde")

Pour info on aurait pu se contenter de print "Bonjour le monde" mais dans ce cas nous n'aurions pas eu d'interfaçage avec l'UI android et donc nous n'aurions pas pu afficher "Bonjour le monde" dans une petite info-bulle stylée en bas de l'écran. Bref, une fois le script écrit il faut le pousser sur l'AVD adb push bonjour.py /mnt/sdcard/sl4a/scripts/bonjour.py, il apparait alors dans le répertoire "scripts" de SL4A et en cliquant dessus ça fait bien apparaitre une mini info-bulle contenant "Bonjour le monde" :)

Script PYTHON sous emulateur Android.

Maintenant on peut se pencher sur une amélioration de tout ça. Par exemple optimiser le push. Pour cette étape j'ai bêtement fait un Makefile :

all:
	ls *.py | xargs -I 'X' ../tools/adb push X /mnt/sdcard/sl4a/scripts/X
	ls *.py | xargs -I 'X' ../tools/adb shell rm /mnt/sdcard/sl4a/X.log

Grâce à cette "astuce" il me suffit de faire un "make" avant chaque test pour que l'ensemble de mes scripts soient poussés sur l'AVD, et ça ne me change pas trop des habitudes prises en C/CUDA[4].

Une fois qu'on sait afficher du texte dans une info-bulle on peut se pencher sur toutes les autres fonctions de l'API et laisser courir notre imagination. Pour les besoins de la cause je conclue d'ailleurs ce billet par quelques exemples de scripts inutiles mais drôles (et donc indispensables) qui m'ont servi de tests :

IRC-like :

import android
droid = android.Android()

victime = droid.pickPhone()
droid.smsSend(victime.result , "I slap you with a large trout")

IRC-like++:

import android
droid = android.Android()

armes = ['Truite', 'Chaussette', 'Andouillette']
droid.dialogCreateAlert("Choix des armes")
droid.dialogSetItems(armes)
droid.dialogShow()
response = droid.dialogGetResponse().result['item']
try:
  response = armes[int(response)]
except:
  response = armes[0]

victime = droid.pickPhone()
message =  "Je viens de te baffer avec une "+response
droid.smsSend(victime.result , message)
droid.makeToast("ENVOYE : "+message)

Notes

[1] si tant est que quelqu'un aurait eu besoin d'explications pour ça...

[2] AVD = instance d'android virtuel

[3] Répertoire dans lequel vous pourrez faire un petit "bzr init && bzr add * && bzr commit" si le coeur vous en dit.

[4] Pour en savoir plus sur ce que j'ai fais récemment en C/CUDA (et pourquoi j'ai délaissé ce blog pendant des mois) je vous invite à aller suivre le SSTIC puisque j'ai l'immense honneur d'y donner une conférence mercredi prochain :) !

jeudi, décembre 2 2010

Man(i)on(s) des sources

Depuis quelques années le fuzzing a beaucoup fait parlé de lui, et il m'est d'ailleurs déjà arrivé de jouer un petit peu avec et d'y faire allusion sur ce blog. En revanche ce qui, d'après ce que je perçois, est complètement passé de mode c'est l'analyse de code source. Trouvant ça bien dommage je me suis penché sur ce qui existait pour analyser du code PHP...

Sleepy Pixy - Creative Common by "Alkan de Beaumont Chaglar" on Flickr
D'abord soyons clair : ce que je cherche à identifier à partir de code source PHP ce sont exclusivement des failles de sécurité. En aucun cas je ne vais m'attacher à trouver de potentiels bugs (utilisation de variables non déclarées, ...) ou problèmes de performances ($variable++ à la place de ++$variable, ...). En résumé je recherche donc des LFI, des XSS, et des SQLi :)

J'ai ainsi farfouillé un petit peu le net à la recherche d'outils d'analyse de code source PHP qui répondrait à mes attentes et ce qui m'a semblé être la seule solution (Open Source) viable c'est pixy. Pixy est un petit soft codé en Java qui tente d'identifier des XSS et des SQLi grâce à une recherche par teinte[1] à partir de code source PHP.

Quelques téléchargements sur sourceforge et exploit-db plus loin en guise de tests j'identifie plusieurs points marquants de pixy :

  • Il y a peu de faux positif. Quand pixy repère quelque chose, c'est généralement vrai :)
  • pixy ne sait pas repérer les points d'entrées dans un projet PHP, on doit manuellement lui spécifier un à un les fichiers PHP à étudier (il se débrouille en revanche correctement avec les includes :)). Personnellement ça s'est fini avec un find -name *.php -exec ... ;-)
  • pixy n'est pas du tout compatible PHP5...et c'est bien dommage parce que l'écrasante majorité des softs PHP que l'on trouve de nos jours sont en PHP5
  • plus dommage encore : pixy n'est plus mis à jour depuis 2007 et il n'est pas prévu qu'il supporte PHP5 un jour...
  • pixy plante parfois souvent (mais c'est généralement à cause de fichiers en PHP5 :( )

Du coup j'ai poursuivi ma recherche et je suis tombé sur ce papier très sympa (et récent qui plus est) ! En gros il s'agit d'une étude de sécurisation des applis PHP de façon automatisé par analyse de code (bref : pile le sujet de ce billet) et les conclusions[2] en sont qu'il faut soit utiliser des applis propriétaires aux algorithme obscurs, soit utiliser pixy bien qu'il soit vieux/bancale et pas vraiment utilisable de façon sérieuse, soit se tourner vers l'avenir en espérant que quelqu'un fasse quelque chose basé par exemple sur PHC.

Qu'est-ce-que PHC pensez vous en ce moment ? C'est un compilateur de PHP. :) ...Si vous ne voyez pas le rapport avec la choucroute (après tout, transformer du PHP en exécutable et rechercher des vulns dans du code source PHP ce sont deux choses bien différentes) vous y verrez peut-être plus clair quand vous saurez que PHC est capable de transformer du code PHP en 3 autres types de représentations intermédiaires (AST, HIC et MIC) et qu'il peut sortir le code transformé (en AST, MIC, ou HIC) au format "texte" ou au format XML. Donc en utilisant PHC vous avez un outil capable de transformer un code source PHP en une représentation de langage plus abstraite, au format texte ou XML, que vous pouvez alors traiter beaucoup plus facilement dans le but d'y faire une recherche par teinte :) Bon, bien sur, ce n'est donc pas une solution "clef en main" d'analyse de sécurité d'applis PHP à partir des sources (puisqu'il faut en fait re-coder toute la recherche par teinte), mais c'est tout de même une base solide qui pourrait permettre d'élaborer un petit moteur d'analyse assez rapidement.

L'un d'entre vous se sent inspiré... ;) ? Bon bah en attendant je continuerai d'utiliser pixy ^_^

Notes

[1] Un peu comme ce que font d'autres personnes avec valgrind pur du code compilé.

[2] Conclusions TRES résumés par mes soins, je vous invite à lire le sujet original pour en avoir une vision plus complète

dimanche, octobre 24 2010

Dans l'estomac du python

Après un long silence sur ce blog (mais une longue période d'intense activité IRL) il est temps de résumer certains trucs qui m'ont occupé niveau informatique ces derniers temps :) ! Comme le titre le laisse présumer ça parle pas mal de python mais ne vous enfuyez pas pour autant si vous ne maitrisez pas ce langage de script sur le bout des doigts : je vais esquiver les détails gorets du code cette fois et me contenter de donner un aperçu high-level des possibilités qui sont offertes.

Cave - Based on a work published under Creative Common by "Kevin Lawver" on Flickr
J'en avais déjà parlé dans mon précédent billet mais j'insiste lourdement : pefile est une excellente extension python. Pour vous résumer certaines des fonctions qui me plaisent le plus :

  • ouverture, modification, puis sauvegarde du fichier PE modifié (il parait qu'il ne faut pas trop modifier la structure PE pour que ça marche, qu'à celà ne tienne il suffit de modifier "sur place" !)
  • accès ultra simple à toute la table d'importation du fichier PE (et donc éventuellement modification de cette dernière si on en a envie ;-))
  • accès ultra simple au contenu des diverses sections du PE et à leurs propriétés (donc éventuellement modification du contenu ou des propriétés...par exemple on peut rendre des sections "exécutable" ou "writable", je dis ça totalement au hasard... )
  • accès ultra simple à l'arbre des ressources du fichier PE (et donc éventuellement modification de ces ressources si le coeur vous en dit...)
  • cross platform !!! Ca c'est un vrai bonheur, les scripts qui utilisent pefile tournent sans modification sur linux ou windows.

Une autre extension super cool que j'ai découvert en jouant avec pefile : pydasm. C'est un binding python vers la librairie libdasm qui, comme son nom l'indique, permet de faire du désassemblage. Pour la petite histoire pydasm est livré avec pydbg dont je ne parlerai pas dans ce billet-ci mais que je vous conseille vivement de regarder si vous avez envie de jouer sous windows. Si on combine donc pefile avec libdasm on est en possession d'un vrai couteau suisse pour désosser et comprendre comment tourne un fichier PE donné.

Si vous avez tout suivi vous devez vous douter de ce que fait la prochaine extension dont je vais parler...On a du désossage et modification de fichier PE, on a du désassemblage de langage machine, il ne manque donc plus que....de l'assemblage :-D ! Et c'est là que vous allez (peut-être) être surpris : je ne vais pas parler de python dans ce paragraphe. Il y a bien des librairies d'assemblages pour python mais je n'ai, pour l'instant, été convaincu par aucune d'entre elles. En revanche j'ai été tout à fait convaincu par fasm qui cumule deux avantages non négligeables :

  • Il est open source
  • Il tourne aussi bien sous linux que windows

Donc tant pis pour le 100% python, je me suis laissé tenté par la simplicité absolue d'écrire un fichier temporaire[1] à partir de mon code python puis d'enchainer avec un petit

if re.match('win.*',sys.platform):
        system('FASM.EXE tmp.asm tmp.bin')
else:
        system('./fasm tmp.asm tmp.bin >> /dev/null')
assembly=open('tmp.bin','rb').read()

Bref, on a du désassemblage, on a de l'assemblage, on a de la manipulation de fichiers PE...je vous laisse imaginer tout seul ce qu'on peut faire avec ça parce que de mon coté je manque de "motif légitime" pour publier sur ce blog ce que j'en ai fait jusqu'à présent[2]

Enfin, le dernier bout de code python qui m'a occupé ces derniers temps c'est sulley. Pour ceux qui ne connaissent pas c'est un framework de fuzzing[3] qui permet de fuzzer des services accessibles par TCP ou UDP[4]. J'ai un petit peu joué avec et ça tourne pas mal; on peut très facilement avoir un script sulley qui tourne sur une VM windows afin de monitorer le processus cible alors que les autres processus sulley tournent sur une autre machine (au hasard une linux) et se chargent d'offrir une belle interface web de suivi de la campagne de fuzzing, de générer les requêtes réseau à destination du process à fuzzer, etc. Seule petite astuce à vous communiquer si vous voulez y jeter un oeil : si jamais vous galérez à installer pcapy ne vous prenez pas la tête plus de 2mn et allez plutôt directement faire de la boucherie dans network_monitor.py pour vous débarasser des appels à pcapy; en 10mn vous les aurez tous remplacés par l'équivalent en scapy ou carrément par des os.system("tcpdump blabla")[5].

Voilà, la prochaine étape sera peut-être de faire un binding amusant entre sulley et d'autres scripts python qui trainent dans mes cartons en les adaptants en pydbg...ou bien ça sera tout autre chose, allez savoir :) ! D'ici là : geekez bien ;)

Notes

[1] Pour info, si vous voulez faire propre, vous pouvez utiliser os.tempnam ou os.tmpfile à la place de toujours réutiliser 'tmp.bin'.

[2] En revanche je ne manquais pas de motif légitime pour en faire profiter mes collègues pentesteurs, c'est déjà ça. D'ailleurs l'un d'entre eux m'a fait remarquer qu'un certain "Nick Harbour" avait fait des choses similaires en 2008, si ça vous intéresse d'aller jeter un oeil ... ;-)

[3] Moins complet que Peach mais infiniment plus simple à prendre en main, ce qui explique à 100% pourquoi je l'ai préféré à Peach :)

[4] Pas de fuzzing de fichier donc, ni de ligne de commande, ou autre.

[5] c'est quand même très moche de faire ça à coup de os.system('tcpdump blabla') puis os.system("killall tcpdump"), préférez scappy qui sera bien plus précis et moins lourd (faites ce que je dis, ne faites pas ce que je fais ^^)

- page 3 de 8 -