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.

La domotique, c'est fantastique ! Surtout quand ça ne coûte pas trop cher, que ça rend service aussi bien pour le contrôle des lumières, le suivi de la consommation électrique, le contrôle de l'environnement ou l'automatisation, et que tout cela fonctionne avec du logiciel libre, sans exfiltrer des tonnes de données privées chez un fournisseur qui se fera tôt ou tard pirater. Mais à trop vouloir jouer la carte de la sécurité, on se prive parfois de certains avantages. Trouvons donc le bon compromis pour rendre notre installation accessible, sans créer d'énormes brèches...
Nombre de phénomènes physiques qui nous entourent peuvent être décrits par un graphe d'états. Ce dernier représente les états successifs du phénomène en question, par exemple, les différents états de l'eau : état solide, état liquide et état gazeux. Il en est de même pour la majorité des systèmes que nous utilisons couramment : machine à café, lave-linge, automobile, distributeur de boissons, jusqu'à aller au comportement même des threads gérés par votre système d'exploitation.
Durant mes pérégrinations dans le petit monde du développement FPGA avec LiteX s'est posée une problématique intéressante, consistant à devoir écrire un support pour une interface série (UART) en n’ayant à disposition rien d'autre qu'une poignée de registres où lire ou écrire. Cet exercice, pour moi, était une phase préalable à l'implémentation d'un pilote pour un système d'exploitation, mais serait transposable à n'importe quel type d'interface reposant sur des mécanismes similaires, et ce, sur n'importe quel MCU ou SoC, actuel ou ancien. Faisons donc connaissance avec l'UART LiteX, voulez-vous ?