Misc HS 24

Reverse engineering :

Apprenez à analyser des binaires

Plus de détails

14,90 € TTC

 
Sommaire :

Témoignage

p. 06 Interview avec Alexandre Gazet, reverse engineer
p.
10 Revue de livre : « Practical Reverse Engineering »

Organisation

p. 12 Donner les clés aux développeurs pour sécuriser leurs applications

Dossier : Reverse engineering

p. 21 Introduction
p. 2
2 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

Threat intelligence

p. 88 L’attribution : piège abscons ?

Malware

p. 100 Analyse de documents malveillants en 2021

Édito :

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

A propos du magazine
Logo

LE MAGAZINE POUR LES EXPERTS DE LA SéCURITé informatique multiplateformes

Face à la transformation digitale de notre société et l’augmentation des menaces, la cybersécurité doit être aujourd’hui une priorité pour bon nombre d’organisations. Après plus de 15 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.

Déjà vus

Nouveaux produits