Formation — Premiers pas en recherche de zéro-day

Comprendre les bases pour découvrir des vulnérabilités structurelles : identifier où chercher, mettre en place un environnement d’analyse, réaliser des tests guidés et documenter ses trouvailles en toute sécurité.

Parcours progressif Logiciel & firmware Pré-requis : bases programmation + curiosité

Sommaire opérationnel

Introduction Recherche logiciel Recherche hardware Notes & outils

Pourquoi se lancer dans la chasse aux zéro-day ?

Objectifs accessibles

Découvrir une vulnérabilité inconnue ne demande pas de tout savoir dès le départ. Il faut surtout apprendre à observer un logiciel, reproduire ses comportements et remarquer quand il dévie. Cette formation vous aide à :

  • Comprendre comment une faille structurelle naît (erreur de logique, mauvaise gestion mémoire, défaut matériel).
  • Monter un petit laboratoire pour tester sans risque un programme ou un équipement.
  • Documenter ce que vous trouvez pour progresser et partager en toute responsabilité.

Avant de commencer

Vérifiez ces fondamentaux :

  • Savoir lire/écrire un programme simple (C, Python ou Rust).
  • Être à l’aise avec la ligne de commande et l’installation d’outils.
  • Connaître les bases du fonctionnement d’un système (processus, mémoire, fichiers).

Pas grave si tout n’est pas acquis : chaque étape renvoie vers des ressources pour combler les trous.

Feuille de route simplifiée

Gardez en tête ce cycle d’apprentissage :

Choisir une cible claire Installer son environnement de test Observer & instrumenter Tester et provoquer des anomalies Analyser les crashs Rédiger et sécuriser les résultats

Cartographie rapide des surfaces à explorer

Logiciel

  • Parsers : images, audio, documents, formats propriétaires.
  • Services réseau : protocoles binaires, RPC, VPN, VoIP.
  • Moteurs d’exécution : navigateur, JavaScript JIT, VM bytecode.
  • Chaîne CI/CD : convertisseurs, générateurs de rapports, outils internes.

Hardware / Firmware

  • Bootloader : signature, mises à jour, anti-rollback.
  • Interfaces debug : UART, JTAG, SWD, modes cachés.
  • Modules radio : BLE, Zigbee, Sub-GHz, UWB.
  • Gestion d’énergie : capteurs, PMIC, circuits de sécurité.

Chaque famille demande des outils spécifiques ; suivez les liens internes et les listes d’outils ci-dessous pour construire votre base de connaissance.

Cadre légal et éthique

Travaillez uniquement sur des environnements que vous possédez, sur des programmes explicitement autorisés ou dans le cadre d’un programme responsable. Sauvegardez toujours vos preuves et chiffrez vos échanges si vous contactez un éditeur.

Découvrir des vulnérabilités logicielles étape par étape

Le but est de passer d’un programme que l’on connaît mal à une zone précise où un défaut apparaîtra. Chaque phase ci-dessous peut être effectuée avec des outils gratuits et beaucoup de patience.

Vocabulaire utile

  • Harness : petit programme qui appelle juste la fonction à tester.
  • Fuzzing : envoyer automatiquement beaucoup d’entrées légèrement modifiées pour repérer les crashs.
  • Primitive : effet intéressant obtenu grâce à la faille (lecture mémoire, écriture arbitraire, etc.).

Parcours conseillé

  1. Comprendre ce que fait la cible

    Notez la version, les dépendances et la manière dont le programme est utilisé. Repérez les parties qui manipulent des données en entrée (fichiers, paquets réseau, scripts). Un tableau simple module → rôle → type d’entrée suffit au début.

    Astuce : fouillez la documentation ou le code source public pour savoir quelles fonctions sont critiques.

  2. Installer un labo reproductible

    Créez une machine virtuelle ou un conteneur avec toutes les dépendances. Ajoutez des outils de surveillance faciles : gdb ou lldb pour déboguer, asan (Address Sanitizer) pour détecter les erreurs mémoire. Sauvegardez vos commandes dans un script pour relancer le test rapidement.

  3. Observer le code calmement

    Avec des outils comme ghidra, Binary Ninja (version gratuite), semgrep ou codeql Community, cherchez des zones vulnérables : boucles sans contrôle, conversions de types, copies de mémoire sans vérification. Comparez différentes versions du logiciel : un correctif silencieux peut révéler une faille encore exploitable ailleurs.

  4. Lancer un fuzzing contrôlé

    Écrivez un harness qui ouvre un fichier, envoie une requête ou appelle une fonction. Démarrez un fuzzer facile (AFL++ ou honggfuzz) avec quelques exemples de données valides. Surveillez le dossier de sortie : chaque crash est sauvegardé avec l’entrée qui l’a provoqué.

    Niveau +1 : ajoutez l’option coverage (libFuzzer, Sanitizers) pour guider le fuzzer vers des chemins encore inexplorés.

  5. Analyser un crash prometteur

    Rejouez l’entrée fautive dans votre débogueur. Notez l’appel de fonction, la mémoire impactée et ce que vous pouvez contrôler. Si le crash est stable, décrivez la cause racine et imaginez comment transformer ce bug en primitive utile. Même si vous n’avez pas encore d’exploit, documenter clairement est déjà une victoire.

    Livrable : fiche de suivi contenant entrée, explication, impact pressenti, état des recherches.

Scénarios typiques pour s’entraîner

Surface Ce qu’on cherche Outils abordables
Systèmes noyau légers (Linux, drivers) Appels IOCTL peu vérifiés, mauvaise synchronisation, dépassement de tampon. syzkaller (images prêtes), gdb, bpftrace.
Moteurs de rendu (PDF, image, navigateur) Parsing complexe, JIT, gestion mémoire spécifique. AFL++ + harness, clusterfuzzlite, outils d’analyse DOM.
Protocoles réseau État mal géré, authentification fragile, surcharges de paquets. boofuzz, scapy, captures Wireshark.
Applications mobiles ou clients lourds Interop natif, stockage sécurisé, communication inter-processus. frida, objection, mobSF.

Bonnes pratiques de triage

  • Notez toujours la version exacte, les options de compilation et la machine utilisée.
  • Vérifiez si le crash n’est pas dû au fuzzer lui-même (sanitizer, instrumentation agressive).
  • Respectez les règles de divulgation : chiffrez les rapports, utilisez un canal sécurisé et donnez des délais raisonnables.

Mini-projet guidé : premier zero-day logiciel

  1. Choisir la cible : un parseur d’image open source (ex. libpng, libtiff) ou une bibliothèque de compression.
  2. Créer le harness : un programme C de quelques lignes qui ouvre un fichier, appelle la fonction de décodage puis se termine.
  3. Lancer AFL++ : utiliser 3 à 5 images valides comme corpus de départ et laisser le fuzzer tourner plusieurs heures.
  4. Triage rapide : chaque crash est rejoué avec asan activé pour identifier la nature du bug (heap overflow, use-after-free, etc.).
  5. Documentation : consigner les étapes, la requête malformée, la fonction fautive et proposer au moins une piste de correctif (vérification de taille, copie sûre, etc.).

Ce mini-projet couvre toutes les compétences de base : instrumentation, fuzzing, analyse de crash et communication responsable.

Erreurs fréquentes à éviter

  • Tester directement sur un système en production ou sans sauvegarde : toujours privilégier une VM, un container ou une machine dédiée.
  • Lancer un fuzzer sans corpus valide : commencez avec quelques exemples fonctionnels pour explorer plus vite.
  • Ignorer la reproductibilité : sans script ou commande claire, il est difficile de rejouer un crash plusieurs jours plus tard.
  • Sauter les étiquettes : indiquez toujours l’état d’un bug (à confirmer, confirmé, exploitable, corrigé) dans votre tableau de suivi.

Ressources pour progresser

  • Livres : “Fuzzing for Software Security Testing” (O’Reilly), “The Art of Software Security Assessment”.
  • Formations en ligne : cours Project Zero (blog), ateliers Open Security Training, pwn.college (modules mémoire).
  • CTF / Labs : Fuzzing101, exploit.education, challenges de Google OSS-Fuzz.

Explorer les vulnérabilités matérielles pas à pas

Pas besoin d’un laboratoire industriel pour démarrer : avec de la méthode et quelques outils abordables, il est possible d’analyser une carte électronique, de comprendre son firmware et de repérer des erreurs de conception.

Itinéraire conseillé

1. Faire connaissance avec la carte

Prenez des photos, notez les références visibles et localisez les connecteurs (UART, JTAG, USB, ports test). Cherchez les fiches techniques des composants pour savoir quelles interfaces sont disponibles.

Matériel abordable : multimètre, microscope USB, analyseur logique type Saleae clone.

2. Récupérer le firmware

Commencez par les méthodes simples : mise à jour officielle, sauvegarde via interface série, lecture d’une puce flash avec un programmateur (flashrom, buspirate). Analysez le binaire avec binwalk pour repérer fichiers, clés ou scripts.

3. Observer les échanges

Capturez les communications (I²C, SPI, UART, CAN, Bluetooth) pendant l’utilisation normale. Rejouez ensuite ces trames pour voir si le système accepte des requêtes inattendues (mode maintenance, downgrade firmware, contournement d’authentification).

4. Tester en toute sécurité

Installez la carte sur un banc d’essai : alimentation régulée, refroidissement basique. Testez des scénarios contrôlés : modification d’un paramètre dans l’EEPROM, envoi d’une trame légèrement altérée, activation d’un pin masqué. Notez chaque changement et revenez en arrière si le comportement devient instable.

Checklist firmware simplifiée

  • Vérifier le processus de démarrage : signature, clé de secours, possibilité de rollback.
  • Chercher des secrets embarqués (clés API, mots de passe, certificats).
  • Identifier les services réseau ou ports série actifs par défaut.
  • Comparer les options de compilation (protections mémoire activées ou non).
  • Repérer les modules de sécurité (TPM, Secure Element) et comment ils sont utilisés.

Évaluer l’impact d’une découverte

Pour chaque vulnérabilité potentielle, posez-vous ces questions :

  • Disponibilité : la carte peut-elle être bloquée ou rendue inutilisable ?
  • Confidentialité : un secret (clé, certificat, données) peut-il être récupéré ?
  • Intégrité : peut-on modifier le firmware ou un paramètre critique ?
  • Sûreté : cela peut-il mettre un utilisateur ou un processus industriel en danger ?

Notez également le type d’accès nécessaire (physique, proximité radio, accès distant) et le matériel utilisé pour reproduire l’attaque.

Mini-projet guidé : carte IoT grand public

  1. Repérage : choisir un objet connecté peu coûteux (routeur, ampoule, caméra), documenter ses ports et récupérer les schémas communautaires.
  2. Dump firmware : extraire l’image via l’interface web (mise à jour) puis, si possible, avec un programmateur SPI.
  3. Analyse statique : ouvrir le firmware dans binwalk, monter les systèmes de fichiers et chercher des scripts shell ou des mots de passe par défaut.
  4. Test ciblé : rejouer une requête HTTP ou un paquet réseau en ajoutant un paramètre inattendu (longueur, commande) et observer la réaction.
  5. Rapport : décrire le bug, l’accès nécessaire, une preuve de réussite et une mesure de mitigation (désactiver un service, appliquer une mise à jour).

Ce scénario apprend à manipuler le matériel en douceur tout en gardant une approche responsable.

Erreurs fréquentes côté hardware

  • Brûler une carte par manque de limitation de courant : utilisez toujours une alimentation de labo ou un câble USB avec coupe-circuit.
  • Oublier d’étiqueter les pins : prenez des photos annotées pour savoir où reconnecter vos sondes.
  • Glitcher sans mesure : notez la tension, la durée et l’outil utilisé afin de pouvoir reproduire l’expérience.
  • Publier des secrets bruts : hachez ou chiffrez les clés découvertes avant de partager vos résultats.

Aller plus loin

  • Lectures : “Hardware Hacking Handbook” (No Starch Press), “Practical Hardware Pentesting”.
  • Formations : cours de Joe Grand, ateliers ChipWhisperer, lab iot-security.io.
  • Communautés : forums Dangerous Prototypes, Discord Hardwear.io, groupe Hardware Village (DEF CON).

Prise de notes et outils – kit de démarrage

Organiser ce que vous apprenez

  • Journal simple : un dossier notes/ avec un fichier par jour (format markdown) suffit pour noter commandes, idées et résultats.
  • Table crash : un tableau (Excel, Notion, SQLite) avec date, entrée, symptôme, état permet de suivre votre progression.
  • Glossaire perso : listez les concepts nouveaux (ASLR, harness, primitive) avec votre propre définition pour révision rapide.

Mini modèle de fiche bug

Titre · Sur quoi ? · Étapes pour reproduire · Ce que j’observe · Idées de suite · Protection à prévoir.

Tableau de suivi type (CSV)

Vous pouvez démarrer avec un fichier comme :

date,cible,étape,statut,notes
2025-10-08,libpng,harness,En cours,"initialisation du corpus"
2025-10-09,libpng,fuzzing,Terminé,"3 crashs collectés"
2025-10-10,libpng,analyse,À revoir,"crash #2 instable"

Outils à découvrir progressivement

Fuzz (début) AFL++ · honggfuzz

Fuzz (après) libFuzzer · syzkaller

Reverse Ghidra (gratuit) · radare2

Debug gdb · lldb · WinDbg preview

Instrumentation légère Frida · DynamoRIO

Diff & analyse BinDiff (trial) · Diaphora

Matériel abordable BusPirate · Saleae clone · J-Link edu

Automatiser petit à petit

Commencez par des scripts Python ou Bash pour lancer vos fuzzers et sauvegarder les résultats. Quand vous serez à l’aise, regardez du côté de clusterfuzzlite ou d’un orchestrateur de conteneurs pour lancer plusieurs campagnes en parallèle.

Index thématique personnel

Ajoutez à votre wiki local des sections récurrentes :

  • Formats : notes sur PNG, ELF, PDF, etc. (structure, signatures magiques, pièges connus).
  • Primitives : exemples de “type confusion”, “heap overflow”, “TOCTOU” avec liens vers études de cas.
  • Outils : commandes favorites, scripts maison, paramètres utiles.
  • Divulgation : modèles de mail, contacts éditeurs, politiques responsables.

Veille et progression continue

  • Suivez quelques sources fiables : oss-security, blog Project Zero, bulletins des éditeurs que vous analysez.
  • Rejouez les correctifs publics : comparer un patch et l’ancienne version est un excellent exercice pour comprendre les erreurs récurrentes.
  • Conservez une liste d’idées (nouvelles surfaces, outils à tester) et explorez-en une à chaque session libre.