Reverse Engineering avec l'IA

Un guide de recherche pratique pour le reverse engineering de firmwares et de logiciels chiffrés, utilisant l'IA pour soutenir l'analyse, les expérimentations et la revue.

La question centrale est de savoir où le matériel protégé devient utilisable et si ce point est observable. Récupérer une clé est une voie possible. D'autres incluent la recherche d'un artefact en clair équivalent, l'observation d'une transformation, l'exécution d'un lecteur existant, ou la reconstruction du comportement sans récupérer la clé.

Ce dépôt contient une étude de 31 méthodes, un cadre de preuves, des exemples issus de sources publiques et des modèles d'investigation réutilisables. Il couvre l'analyse de fichiers, l'instrumentation logicielle, le rehosting, l'acquisition matérielle, les canaux auxiliaires et les limitations cryptographiques. Chaque méthode distingue les prérequis, les résultats possibles et les preuves nécessaires pour étayer une conclusion.

Commencez ici

1. Suivez le workflow d'investigation pour identifier l'artefact, le résultat souhaité et l'accès disponible.
2. Utilisez l'étude des méthodes pour choisir une expérience adaptée.
3. Appliquez le cadre de preuves avant de revendiquer une récupération ou d'expliquer un échec.
4. Utilisez le guide de collaboration avec l'IA pour répartir la recherche et la revue sans transformer l'accord d'un modèle en preuve.
5. Consignez l'expérience dans le modèle d'investigation.

Les études de cas issues de sources publiques illustrent la conception d'images chiffrées, le déchiffrement transparent de la flash, la persistance des paramètres Android et les jalons de démarrage. L'index des sources référence la documentation, les implémentations et les articles utilisés tout au long du guide.

Choisir le résultat avant de choisir l'outil

Résultat souhaité	Ce qui l'établirait
Un artefact en clair	Authentification correctement délimitée ou concordance avec une référence indépendante, avec une structure cohérente
Une clé de contenu réutilisable	Déchiffrement validé indépendamment sur des échantillons applicables, avec la portée de la clé identifiée
Une clé d'appareil ou racine	Identité et portée de la clé vérifiées ; une clé de contenu ou un handle de clé seul est insuffisant
Une explication du comportement	Traces concrètes, flux de données et tests couvrant le comportement énoncé
Un exécutable reconstruit	Conformité du format plus comportement représentatif dans un environnement documenté
Une image modifiée acceptée par le fournisseur	Preuves distinctes pour la signature réelle et le chemin d'acceptation au démarrage

Corrections qui changent l'investigation

• Une entropie élevée est un indice de hasard. La compression et le chiffrement peuvent tous deux la produire ; consignez l'outil, l'échelle et la taille de fenêtre. Documentation sur l'entropie de Binwalk
• Le placement du bootloader dépend de la plateforme et du format d'image. Les 64 premiers Ko ne constituent pas une règle d'extraction générale, et un paquet de mise à jour peut omettre le bootloader.
• Le chiffrement et les signatures résolvent des problèmes différents. Récupérer le texte en clair ne fournit pas la clé de signature et n'établit pas qu'une image modifiée démarrera. Images chiffrées MCUboot
• Une commande réussie, une chaîne plausible, une bibliothèque chargée ou un retour de wrapper nécessitent une validation à la couche pertinente pour l'affirmation. Voir les exemples issus de sources.
• Une cryptographie forte ne devient pas pratiquement cassable par un décompilateur ou un modèle de langage. Les progrès utiles proviennent généralement de l'implémentation environnante, de représentations accessibles ou d'une faiblesse spécifique démontrée. Recherche sur la biclique AES complet

Portée et provenance

La recherche initiale a été développée par une recherche spécialisée assistée par IA et une revue critique, incluant des contributions d'Astra, Opus et Fable. Les revues ont été intégrées de manière sélective : les interprétations non étayées et les travaux redondants ont été rejetés. Le guide résultant formule des affirmations méthodologiques et cite des sources publiques ; il ne revendique ni un nouveau décrypteur universel ni la compromission démontrée d'un appareil particulier.

Le dépôt public contient de la prose de recherche, des liens publics, des modèles vierges et un outil de validation de documentation. Les binaires de firmware, les captures privées, les identifiants d'appareils, les clés extraites, les identifiants de connexion et les journaux opérationnels sont hors de son périmètre de publication. Appliquez les méthodes aux systèmes et artefacts que vous êtes autorisé à examiner.

Valider le dépôt

Python 3.9 ou une version ultérieure suffit ; aucun paquet tiers n'est requis.

python3 tools/check_docs.py
python3 tools/check_docs.py --self-test

Le harnais local vérifie l'inventaire des fichiers, les liens Markdown, la numérotation des méthodes, l'index des sources, les enregistrements de version et plusieurs schémas courants de publication accidentelle. Il n'exécute pas de firmware, ne contacte pas d'appareils, ne récupère pas les sites web liés et ne prouve pas que chaque affirmation technique est correcte. La vérification des sources reste une partie de la revue de recherche.

Version actuelle de la documentation : 1.0.0. Voir le journal des modifications et l'historique en ajout seul.