Yeah, me revoilà!
La dernière fois, je vous parlais de dissection de binaire. Du temps a passé, et je reviens faire un petit tour sur linuxfr pour donner mes retours d'expérience. Sans plus attendre, les outils kidéchirent sont:
-gdb : bah oui, c'est vraiment incontournable. Mais gdb à poil, c'est chiant. Je conseille à tout le monde de prendre le plugin http://reverse.put.as/gdbinit/. C'est le genre de trucs que j'adore: la conf par défaut juste marche. Pas besoin de lire 15000 pages de docs pour comprendre. L’intérêt du truc vient instantanément. On peut plus s'en passer. Je donne juste une copie d'écran pour donner envie. 
Les flags sont toujours données, les registres aussi, on a les prochaines instructions, et on peut même afficher la stack si on le souhaite en plus (taper la commande enablestack). Lorsqu'il y a un jump, il est précisé dans la fenêtre s'il est pris ou non. Juste génial, et fait gagner beaucoup de temps. Je ne m'en passe plus.
-radare2 : on me l'avait conseillé, et c'est effectivement pratique, mais un peu plus rugueux dû à mon manque d'habitude. Par contre, c'est le seul qui sache disséquer du binaire linux avec des sections en vrac. Voir à ce sujet: http://0x90909090.blogspot.fr/2013/12/linux-anti-debug-trick.html et un grand coup de chapeau aux devs de radare2 qui ont pris en compte le bug et corrigé super vite: https://github.com/radare/radare2/issues/396.
-metasm et IDA: J'ai testé les deux (la version free sous nux avec Wine), et je m'en sers juste pour voir les CFG (call function graph). Je sais que radare2 le fait, mais c'est juste un png, alors que j'aime bien cliquer depuis le CFG pour voir des adresses, naviguer dans les fonctions etc.. Je pense que je n'utilise que 1/100e de IDA, faudrait que je m'y mette sérieusement un jour (des idées de tutos pour utiliser mieux IDA?). A ce sujet, le site wine indique qu'il manque les tooltips dans IDA. Sous nux, il suffit de scroller avec la molette de souris pour les voir apparaître.
Je continue de m'éclater toujours autant a reverser du binaire, certains challenges sont vraiment super simples, d'autres m'ont bien empêché de dormir (Genre, ooOoOOooh, il est 6h du mat'!). Pour s'entrainer, je conseille un site comme crackmes.de.
Si vous avez des tutos, des challenges ou des sites qui parlent de reverse, ça m'intéresse :)
Happy reversing !
mitsurugi
# ooups, typo
Posté par mitsurugi (site web personnel) . Évalué à 10.
L'image n'est pas passée, il s'agit de
Si un modo peut remettre le bon lien et supprimer ce message, merci (Et faire ainsi du reverse de journal linuxfr, yeaah!)
[^] # Re: ooups, typo
Posté par Anonyme . Évalué à 5. Dernière modification le 28 janvier 2014 à 22:30.
sans forcement faire un tuto, tu peux nous donner ta ligne de commande gdb sur un binaire simple, genre /bin/ls
que l'on puisse faire des essais a l'arrache sans rien connaître a l'assembleur x86, ni a gdb d'ailleurs…
[^] # Re: ooups, typo
Posté par mitsurugi (site web personnel) . Évalué à 4.
eeeeeeuh, c'est une question soit trop courte, soit trop longue.
Par exemple:
gdb /path/to/my/binary
gdb$ b * main
gdb$ r arguments to binary
Ensuite, l'avantage de ce gdbinit, c'est qu'il donne une interface simple au debugger.
Au lieu de faire des enchainements de:
nexti
info regs
x/10i $eip
x/4dwx $esp
nexti
info regs
x/10i $eip
x/4dwx $esp
nexti
etc…
L'affichage te donne à chaque break l'affichage des registres, les prochaines instructions et éventuellement la stack. C'est donc un gain de temps énorme, il te suffit de faire
nexti
nexti
nexti
etc..
Maintenant, si tu ne connais rien à gdb ou l'assembleur, je pense que le gain apporté par ce gdbinit est très faible.
# Quelques tools !
Posté par pyknite . Évalué à 2.
Une petite liste de tools qui sont chouette :
- cgdb (une interface curse pour gdb)
- hopper (payant, mais vraiment vraiment bien, IDA-like, multiplateformes,…)
- capstone-engine (un projet assez récent, basé sur LLVM)
[^] # Re: Quelques tools !
Posté par Zylabon . Évalué à 10.
Please do not feed the trolls
[^] # Re: Quelques tools !
Posté par hsyl20 (site web personnel) . Évalué à 5.
Il y aussi MAQAO (http://maqao.org/), dont j'ai intégré l'équipe de développement, qui devrait être libéré bientôt (fin février si tout se passe bien) et qui est plutôt orienté calcul haute performances. Il permet de faire du patchage de binaires pour ajouter du code à des endroits précis quitte à relocaliser du code ailleurs (e.g. des sondes), il y a des modules pour évaluer les performances statiquement et dynamiquement, pour donner des conseils d'optimisation, etc.
[^] # Re: Quelques tools !
Posté par Tonton Th (Mastodon) . Évalué à 5.
OMFG ! Ils ré-inventent SUPERZAP !
[^] # Re: Quelques tools !
Posté par hsyl20 (site web personnel) . Évalué à 5.
Je ne connaissais pas, mais pour ce que je viens d'en lire c'est un peu différent. Dans notre cas le but n'est pas de corriger un binaire mais de modifier le comportement temporairement et de façon générique (i.e. sans connaître à l'avance le binaire). Par exemple on peut demander à modifier un binaire de façon à ce qu'il dump les dates d'entrée et sortie dans les boucles les plus internes, etc. Enfin bon je ferai peut-être un journal quand ce sera libéré.
[^] # Re: Quelques tools !
Posté par Krunch (site web personnel) . Évalué à 2.
Et donc en quoi c'est mieux que SystemTap par exemple ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Quelques tools !
Posté par hsyl20 (site web personnel) . Évalué à 3.
Je ne connaissais pas SystemTap, mais de ce que je viens d'en lire, c'est différent (donc ni mieux ni moins bien). On est plus bas niveau dans le sens où ne va typiquement pas instrumenter des appels système ou autres appels de fonctions mais des portions de codes de calcul (boucles avec instructions SIMD, etc.). On essaie de les caractériser autant que possible pour proposer des optimisations.
[^] # Re: Quelques tools !
Posté par lasher . Évalué à 4.
Histoire de répondre en vrac :
SUPERZAP, SystemTap, etc. sont tous des outils très intéressants. Ayant indirectement bossé sur MAQAO et directement avec (quand la plupart de ses modules étaient éclatés en divers endroits), j'ai eu l'occasion parler avec la plupart des gens qui y ont bossé entre ~2005 et ~2010. Pour prendre l'exemple du module MADRAS (qui s'occuper de « décompiler » les binaires, rajouter des trampolines où il faut, puis recompiler le tout), son auteur avait cherché un peu partout s'il n'existait pas déjà des bibliothèques ou exécutables qui feraient l'affaire. La réponse a été non : soit on avait des trucs de type
objdump/gdb/etc. fait pour le debug, soit on avait des trucs typeIDA Propour le reverse engineering, mais ce que cherchait l'auteur de MADRAS, c'était un moyen de facilement patcher des bouts de binaires sans avoir à se taper l'intégralité de l'assembleur, pour mieux instrumenter les parties chaudes qui devront être plus tard optimisées. Bref, tout plein d'outils faisaient « presque » l'affaire, mais pas vraiment ce qu'il voulait. De plus, l'idée était déjà à l'époque d'unifier dans un même framework tous les outils utilisés pour analyser/mesurer la performance de codes de calcul intensif.Le « front-end » de MAQAO (Sylvain ne te gène pas pour me contredire si ça a changé et que je dis des bêtises) est censé bouffer de l'assembleur (ou du binaire décompilé) de la partie chaude de l'exécutable, puis à l'aide d'un modèle machine codé en interne (obtenu à grands coups de micro-benchmarking pour savoir quel est l'effet réel d'instructions SIMD/SSE, en fonction du flux, de l'occupation des ports de décodage du front-end pour processeurs Intel¹, etc. Cette information est statique (MAQAO recrée le graphe de dépendances de données ainsi que le graphe de flot de contrôle à partir de l'asm). Du coup, on obtient des informations « optimistes » de la meilleure performance possible. Par exemple, même si le code n'est pas vectorisé, si MAQAO déduit que statiquement il y a bien trop de chargements mémoire comparé aux instructions arithmétiques, il le rapportera dans son diagnostic.
Ensuite, si la performance mesurée s'écarte grandement de ce qu'on promet « au mieux », on peut utiliser différentes techniques, comme l'analyse décrémentale (DECAN), qui consiste à patcher le binaire de la boucle chaude, et retirer petit à petit des instructions (en suivant un pattern précis, ou bien « aléatoirement », etc.). L'idée est de repérer quel est le « deliquent load/store » (la lecture ou écriture mémoire qui rend le code lent). On retire une ou plusieurs instructions, on réinstrumente la portion de code, et on itère.
Il y a tout plein d'autres trucs que MAQAO sait faire, mais il faut garder à l'esprit que les codes visés sont généralement assez réguliers en terme de flot de contrôle. Si le code passe sont temps dans des constructions de type
if-else, MAQAO ne pourra sans doute rien pour aider le programmeur.[1] Je ne sais pas comment c'est obtenu maintenant, mais à l'époque, c'était l'affaire de quelques minutes/heures, à faire tourner tout plein de micro-benchmarks avec à peu près toutes les instructions « utiles » en calcul haute performance imaginables, et vérifier que les latences et le débit étaient ceux promis par Intel. On se servait pas mal des manuels de Agner pour vérifier que nous avions les mêmes nombres — et je dirais que 90-95% du temps, c'était le cas.
[^] # Re: Quelques tools !
Posté par le_poney (Mastodon) . Évalué à 1.
Sans oublier PEDA :)
http://ropshell.com/peda/
# Attention au site reverse.put.as
Posté par mitsurugi (site web personnel) . Évalué à 7.
Attention, le site reverse.put.as est actuellement infecté ..
https://twitter.com/0xmitsurugi/status/428138329951838210
[^] # Re: Attention au site reverse.put.as
Posté par warwick . Évalué à 3.
Content d'avoir NoScript du coup.
# todo list
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Cela serait marrant de faire une todo list de truc à faire sur des binaires.
J'imagine que certain aimerait faire du reverse engineering sur certain drivers de carte 3D, pour faire une doc avant de recoder (pour éviter les problèmes légaux).
J'aurais aimé aussi connaitre les fuites d'information qu'il peut y avoir sur des binaires différents, connaitre les différences sur les exe générés par gcc, lvm et ocaml par exemple.
J'imagine qu'il y a aussi pas mal de chose à voir sur smartphone, pour vérifier le captage d'information sur les téléphones faite par les applications.
"La première sécurité est la liberté"
[^] # Re: todo list
Posté par palm123 (site web personnel) . Évalué à 7.
Comme virer la pub et la géolocalisation ? Ah le .exe est vide ensuite ?
ウィズコロナ
[^] # Re: todo list
Posté par papap . Évalué à -2.
Ce qui serait plus intéressant c'est de faire du reverse sur des virus/trojan/exploit qu'on a chopé histoire de trouver le rigolo qui a fait ça ou son serveur vers lequel il envoie nos infos.
[^] # Re: todo list
Posté par Zenitram (site web personnel) . Évalué à 4.
Tu crois sérieusement que les entreprises de sécurité et le FBI (par exemple) ne font pas ça, avec des outils qui sont bien plus performants que ce que tu as?
(surtout que pour le serveur vers lequel il renvoit l'info, il n'y a vraiment pas besoin de faire du reverse… Juste regarder les flux)
[^] # Re: todo list
Posté par Zarmakuizz (site web personnel) . Évalué à 7.
Pourquoi faire ? Les virus sont faits par des jeunôts sur les forum de sécurité des éditeurs de solutions antivirus. Là-bas ils s'échangent des conseils, ensuite c'est le jeu d'avoir un virus suffisamment sérieux pour esquiver l'analyse heuristique et avoir sa signature ajoutée à la base de données virale.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: todo list
Posté par Anonyme . Évalué à 2.
oui mais c'est mal de faire justice sois même.
[^] # Re: todo list
Posté par papap . Évalué à -2. Dernière modification le 29 janvier 2014 à 14:12.
C'est le problème de la milice : s'il y a un manque d'ordre, les gens se défendent comme ils peuvent. Et puis, il n'y a pas que les jeunôts qui font des virus et autres chevaux de Troie. Et si tu as plus d'infos à donner à la police, c'est tant mieux non. D'ailleurs, est-ce que la police s'intéressera à un particulier qui a chopé un Troyan?
[^] # Re: todo list
Posté par mitsurugi (site web personnel) . Évalué à 3.
Ta remarque est super intéressante. Pour moi, il n'y a qu'une seule chose à faire en reverse, c'est comprendre le fonctionnement d'un binaire dont on a pas les sources.
Double but: être sur du fonctionnement du binaire (pas de fonctions cachées qui mettrait à mal la sécurité du système), ou contourner une protection (crack).
Quand je connaîtrai bien le reverse, je m'intéresserai à l'exploit, ou l'on a un peu plus souvent les sources.
Mais effectivement, le reverse peut être fait pour éviter de recoder des trucs.
Concernant les fuites d'informations, un bon tcpdump est généralement suffisant pour savoir si des choses sortent.
[^] # Re: todo list
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
tcpudump fonctionne si le flux n'est pas crypté et si l'application n'est pas trop complexe, pour être sur de savoir quand ce genre d'info peut sortir.
Concernant les binaires, je suis toujours étonné des infos qui trainent dedans quand on fait un simple "strings".
"La première sécurité est la liberté"
# Plugins IDA
Posté par pasBill pasGates . Évalué à 7.
a) http://www.binarypool.com/idapluginwriting/ c'est un peu vieux mais en gratuit c'est la reference niveau documentation pour les APIs d'IDA (qui est notoirement horrible niveau doc officielle). Chris Eagle a aussi un livre sur IDA qui explique plutot bien comment ecrire des plugins.
b) Il y a un nombre enorme de plugins pour IDA pour faire un tas de trucs differents (trouver des vtable dans un binaire, etc…) cf. http://www.openrce.org/downloads/browse/IDA_Plugins
[^] # Re: Plugins IDA
Posté par mitsurugi (site web personnel) . Évalué à 2.
Merci des liens, mais avant de vouloir écrire des plugins, je voudrais juste apprendre à utiliser l'outil :)
Comme je dis, je m'en sers juste pour avoir une version graphique du binaire, et de pouvoir cliquer pour aller d'un point à un autre. Je pense que IDA fait beaucoup beaucoup plus de choses que ça, et c'est ce que j'aimerai savoir faire.
# Juste
Posté par xseticon . Évalué à 0.
Pardon de ne pas commenter sur la technique mais moi je suis juste intrigué du nombre de fois où l'adverbe (ou adjectif) juste intervient dans ce journal pourtant court. Plus généralement, j'ai l'impression que ce mot (qui est un anglicisme) envahit les conversations ces temps-ci, et maintenant les écrits.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.