14,90 € TTC
p. 06 Interview avec Alexandre Gazet, reverse engineer
p. 10 Revue de livre : « Practical Reverse Engineering »
p. 12 Donner les clés aux développeurs pour sécuriser leurs applications
p. 21 Introduction
p. 22 La compilation : du code au binaire… et retour !
p. 30 Comment analyser un programme : du statique au dynamique jusqu’à l'instrumentation
p. 48 Introduction au reverse hardware
p. 62 Analyser des malwares en 2021 : pipelining
p. 78 De l’extraction de firmware à l’exécution de code sur la carte SD FlashAir
p. 88 L’attribution : piège abscons ?
p. 100 Analyse de documents malveillants en 2021
Le retour d’un vieux con
Public chéri mon amour, me revoilà !!
Après m’être occupé de 77 numéros et quelques hors séries, avoir fait ma propre nécrologie [1], et comme le formol n’est pas mon kif malgré mon âge canonique, hop, hop, je reviens. Telles ces vieilles gloires déchues qui font des tournées sur des paquebots pour un public centenaire, me revoilà, avec un public rajeuni.
C’est donc le retour de ce fameux « vieux con » qui répond toujours présent quand on lui propose de (re)faire un hors-série didactique sur l’analyse de programmes. Très vite, je craignais que je ne fourrasse le numéro, non pas d’impairs, mais d’articles trop complexes. Or, un HS se doit de prendre les jeunes lecteurs curieux par la main et leur ouvrir les chakras.
Être con n’est pas forcément être vieux, et inversement : être vieux n’est pas forcément être con. Prodiguons donc quelques conseils pour lutter contre les idées préconçues sur le reverse, et faciliter la vie des néophytes assoiffés d’assembleur, le bit et le Cousteau entre les dents.
Tout d’abord, non, on n’utilise pas les sources. Vraiment ! Et oui, on peut analyser un programme même quand on n’a pas ses sources. Donc, sans source, mais avec des pistes, tel l’inspecteur, des (b)riques sont unies pour faire émerger du sens. Au mieux, des extraits de code sont reconstruits à l’aide d’un décompilateur. Donc oui, l’analyste travaille « en aveugle » et doit se référer à l’assembleur (ou du bytecode pour des langages interprétés).
Pour autant, ce n’est pas parce que l’analyste est aveugle qu’il n’a pas le droit d’être malin. De nombreuses « fuites » sont à exploiter, comme les bibliothèques chargées, les symboles utilisés, les chaînes de caractères, en particulier les messages d’erreur. Certaines fonctions peuvent donner, avec un peu d’habitude, une première idée de ce qui se passe dans un binaire. Avec cette vue panoramique, les ingrédients sont réunis pour préparer une potion magique qui mènera vers la compréhension du binaire.
Mais il y a d’autres endroits où aller chercher de l’information : génial quand retors tu es. La documentation donne souvent plein de détails, et permet d’inférer des éléments sur l’architecture et l’organisation du programme ou du hardware analysés. Ne jamais sous-estimer le pouvoir de la doc, même d’un iota.
Et puis parfois, il existe du matériel spécifique pour le debug (par exemple des sondes JTAG) voire des matériels de développement. Un peu de soufre du fond du gouffre, tel un brigand à l’fesse du camion, ce matériel tombe et ressort immaculé dans les mains d’un analyste : qui n’a pas son iPhone de dév, rempli d’outils Apple ?
Autre idée contre laquelle il faut lutter : lire tout l’assembleur. L’assembleur, c’est vraiment ce qu’on va lire à la toute fin, et il faut en lire le moins possible. Son job consiste, à partir des informations précédemment évoquées, à trouver ce qu’il doit analyser. L’analyste explore le binaire comme le termite le tronc. Mais n’oublions pas que le cerveau de l’analyste, et du termite, perd vers la 7ème information ingurgitée en 30 secondes son appétit. Donc mangeons peu, mais mangeons bien, sinon, ça mine l’appétit.
Dernière légende urbaine : changer les noms de variables ou des fonctions (ou mettre des noms aléatoires) dans un programme en C/C++ ne sert strictement à rien pour un reverser. Mais vraiment à rien de rien. Comme nous le verrons dès le premier article du dossier, le compilateur utilise de la mémoire et des registres, et c’est tout. Donc les noms sont perdus à la compilation, une fois pour toutes. Ces briques d’information disparaissent, mais de Lego, las, le reverser n’est pas démuni.
Un grand merci à tous les auteurs qui m’ont rejoint dans ce numéro, et plus encore à ceux dégagés dans un numéro ultérieur pour leur infinie patience.
Bonne lecture,
Fred Raynal, aka pappy – @fredraynal
Rédac chef originel de MISC – Fondateur et ex-président de SSTIC
Fondateur et encore à l’œuvre pour Quarkslab – Co-fondateur de l’exceptionnelle petite Romane
Par ordre d’apparition, plus ou moins capillotracté : Agecanonix, Le père Fouras, Jacques-Yves Cousteau, Stefan Derrick, Panoramix, Tortue Géniale, Yoda, Gandalf, Jiraya, Legolas.
[1] Nécrologie à retrouver en ligne : https://boutique.ed-diamond.com/numeros-deja-parus/794-misc-77.html
Face à la transformation digitale de notre société et l’augmentation des cybermenaces, la cybersécurité doit être aujourd’hui une priorité pour bon nombre d’organisations. Après plus de 20 années de publications et de retours d’expérience, MISC apporte un vivier d’informations techniques incontournable pour mieux appréhender ce domaine. Précurseur sur ce terrain, MISC a été fondé dès 2002 et s’est peu à peu imposé dans la presse française comme la publication de référence technique en matière de sécurité informatique. Tous les deux mois, ses articles rédigés par des experts du milieu vous permettront de mieux cerner la complexité des systèmes d’information et les problèmes de sécurité qui l’accompagne.

2020 aura été une année marquante pour nos vies et nos sociétés. Il aura fallu se réinventer, trouver des solutions à des situations exceptionnelles. Dans les entreprises, l'Éducation ou la Santé, la mobilisation des ressources informatiques aura été maximale. Nos infrastructures auront ployé, tangué, parfois presque craqué, mais au final, cela aura tenu.
Nos serveurs présentent désormais une surface d’attaque réseau maîtrisée et une sécurisation système d’un niveau cohérent avec notre modèle de menaces. De même, le service SSH tournant sur ces serveurs est configuré de manière optimisée. Nous pouvons donc être relativement sereins si nos adversaires sont d’un niveau intermédiaire. Et si malgré toutes ces protections, une attaque comme un rançongiciel réussissait ? Et bien dans ce cas-là, pour l’instant, notre infrastructure serait particulièrement vulnérable. Aucune sauvegarde externalisée. Pas de centralisation des traces. Une supervision sécurité inexistante. Remédions à cette situation afin d’élever le niveau de maturité de la sécurité de notre infrastructure.
Notre infrastructure est désormais stable et sécurisée tant au niveau système que réseau. Nous allons pouvoir étudier de manière un peu approfondie un logiciel particulier : OpenSSH. Ce démon réseau nous permet de nous connecter en toute sécurité sur nos serveurs via le protocole SSH. Son développement a commencé il y a plus de 20 ans chez nos amis d’OpenBSD. La liste de ses fonctionnalités est d’une longueur impressionnante. Nous allons en parcourir ensemble quelques-unes qui, je l’espère, nous permettront d’améliorer tant notre sécurité que notre productivité quotidienne.