Lab de rétro-ingénierie : lire des programmes avec gdb, radare2, strace et ltrace dans une VM

Ce lab apprend à lire un programme dont on n’a pas le code source. Chaque élève reçoit une VM Ubuntu avec un compilateur, le débogueur gdb, le désassembleur radare2, binutils, strace et ltrace, et cinq petits programmes écrits pour le lab, dont chacun cache une clé. Les élèves trouvent les clés en observant les programmes, comme le ferait un défenseur ou un étudiant en compilation, et les écrivent dans un fichier.

Il s’agit uniquement de lire et de comprendre, sur des programmes que le lab a compilés lui-même. Rien n’est installé sur l’ordinateur de l’élève, et rien ici n’enseigne les logiciels malveillants, le contournement de la licence de vrais logiciels, les générateurs de clés pour eux, le fait de cacher un programme à un débogueur, les exploits, ni l’examen d’un programme qui n’est pas celui du lab.

Ce que les élèves apprennent

Une échelle de cinq programmes, lus chacun avec un outil différent. Le premier garde son mot de passe à découvert, ce que strings et objdump ou radare2 montrent sans l’exécuter. Le deuxième construit son mot de passe pendant qu’il s’exécute : les élèves l’arrêtent dans gdb à la comparaison de chaînes et lisent la réponse dans la mémoire. Le troisième demande un nombre et le teste avec quelques étapes de calcul, que les élèves lisent dans le désassemblage et remontent à l’envers. Le quatrième assemble les deux moitiés d’une clé, que ltrace montre dans un appel de bibliothèque. Le cinquième cherche un fichier dont le nom contient la clé, que strace montre dans un appel système.

Derrière tout cela, la leçon dont un défenseur a besoin : tout ce qu’un programme doit connaître pour fonctionner, un lecteur peut le trouver, donc un secret gardé dans un programme n’est pas un secret.

Des clés différentes pour chaque copie

Le dépôt du lab est public : aucune clé n’y figure. Au premier démarrage de la VM d’un élève, le script crée de nouvelles clés aléatoires, les range dans un dossier où seul l’administrateur peut entrer, construit les programmes avec elles et supprime les sources. Le script n’affiche jamais une clé. Les réponses d’un élève sont comparées aux clés de sa propre copie : les réponses d’un camarade, le README et les fichiers du lab ne donnent donc rien. Un élève qui utilise sudo sur sa propre machine pourrait lire les clés stockées : le lab fait confiance à un élève sur sa machine, et les clés servent à apprendre, pas à garder un secret face à la personne qui possède la VM.

Le lancer dans votre navigateur

Les labs VM se donnent comme tâche de lab dans un module, et l’exemple se trouve sur la page du lab. La machine est petite : un processeur, 1 Go de mémoire et 10 Go de disque. Les outils ensemble en utilisent bien moins d’un dixième.

  1. Ajouter le lab. Dans un module que vous enseignez, ajoutez une tâche et choisissez la carte Lab VM Ubuntu. La page affiche une courte description de la machine au lieu d’un fichier compose.
  2. Partir de l’exemple. La page propose des labs prêts à l’emploi. Choisissez Rétro-ingénierie. Utiliser un exemple remplace le texte, et Annuler rend le vôtre.
  3. Publier et démarrer votre propre copie. Publiez, puis Démarrez. Le script d’installation du lab installe le compilateur, gdb, radare2, strace et ltrace depuis l’archive d’Ubuntu, crée de nouvelles clés aléatoires, construit les programmes avec elles et écrit le README, au premier démarrage de la VM, en quelques minutes.
  4. Ouvrir le terminal. Ouvrez son terminal et lisez README.md dans le dossier personnel : il dit quoi faire et ne donne aucune réponse.

Une leçon de base sur ce lab

Reverse Engineering Basics est une petite leçon donnée dans ce lab, une VM Ubuntu. Elle a une accroche, un objectif Je peux, la règle à retenir, des mots-clés, une mise en route, une vérification après chaque idée, une erreur fréquente et une vérification finale, et chaque étape a un bouton Exécuter qui tape sa commande dans le terminal de la machine. L’élève examine un programme inoffensif avec file, strings, objdump, radare2, gdb, ltrace et strace.

La leçon fait le tour des outils et laisse à l’élève les cinq programmes à clé, qui sont la tâche du lab : elle ne donne donc aucune réponse.

Comment il est noté

Le lab a une vérification. Elle s’exécute sur une copie de la machine enregistrée après un démarrage à neuf et lit le fichier answers.txt du dossier personnel de l’élève. Chacune des cinq clés doit être la clé créée pour la copie de cet élève et pour ce programme : une supposition, une ligne vide, la clé d’une autre copie ou une clé mise en face du mauvais programme ne passe pas. La vérification essaie aussi chaque programme avec sa propre clé, ce qui révèle un programme modifié. La première ligne de ce que la vérification a affiché dit quel programme est faux.

  1. Le distribuer. Attribuez le lab comme n’importe quelle tâche, avec une échéance si vous le voulez. Chaque élève reçoit sa propre VM, conservée entre les séances, avec ses propres clés.
  2. Lancer la vérification. Sur la ligne d’un élève dans la liste de classe, appuyez sur Lancer la vérification. Elle démarre une copie de sa machine enregistrée, qui n’est pas sauvegardée en retour, exécute le script de vérification du lab en root et montre s’il a réussi, ce qu’il a affiché et quand. L’élève n’est pas informé du résultat.
  3. Noter. Lisez la première ligne de ce que la vérification a affiché : elle nomme le premier programme dont la clé manque ou n’est pas celle de cette copie. Renvoyez le travail avec un motif s’il faut aller plus loin.

La définition sur GitHub

Le fichier est toute la définition du lab, le texte même que la plateforme exécute : taille, script d’installation, sources des cinq programmes, README et vérification. Copiez-le et changez les programmes ou les clés pour faire un lab plus long.

Essayer ce lab, et ce qu’il coûte

Un compte personnel gratuit permet de suivre les leçons de base de ce lab, avec chaque mois assez de crédit gratuit pour suivre la plupart des leçons, sans carte. Pour une classe, un établissement a ses 365 premiers jours gratuits pour 50 élèves au plus, puis paie par élève et par an, tous les labs compris et les enseignants gratuits.

Questions fréquentes

Le lab demande-t-il une licence ou un logiciel particulier ?
Non. Le compilateur, gdb, radare2, binutils, strace et ltrace sont libres et viennent de l’archive d’Ubuntu au démarrage de la VM de l’élève. Nous ne distribuons rien de cela.
Apprend-on ici à s’introduire dans des logiciels ?
Non. Les programmes sont les jouets du lab, et chacun est lu pour comprendre comment fonctionne un programme, ce dont ont besoin un défenseur, un développeur sans les sources et un étudiant en compilation. Le lab n’enseigne jamais les logiciels malveillants, le contournement de la licence de vrais logiciels, les générateurs de clés, le fait de cacher un programme à un débogueur, les exploits, ni l’examen d’un programme qui n’est pas le sien, et la copie d’un élève ne peut pas joindre internet pour en récupérer un.
Les élèves peuvent-ils casser quelque chose ?
Seulement leur propre copie. Les programmes s’exécutent avec les droits de l’élève et la VM n’atteint que l’archive d’Ubuntu avec l’offre gratuite. Lire les programmes ne peut pas les abîmer.
Le lab a-t-il été testé dans une vraie VM d’élève ?
L’installation, les commandes de la leçon, la vérification et chaque façon de la tromper ont été exécutées dans un vrai conteneur Ubuntu 26.04, et chacune des cinq clés a été trouvée avec l’outil prévu, par un utilisateur sans droits d’administrateur. Une VM d’élève réellement démarrée, avec le noyau de la machine, mérite un essai avant un cours.