Analyser un exécutable inconnu avant de l’autoriser

L'essentiel à retenir

Un exécutable inconnu ne devrait pas entrer dans le système d'une PME sur la seule foi de son nom, de son icône ou de la personne qui l'a transmis. Ghidra permet à un analyste d'examiner du code compilé quand le code source n'est pas disponible. Il réunit notamment désassemblage, décompilation, graphes et scripts, sur plusieurs systèmes et formats de processeurs. Son intérêt n'est pas de prononcer automatiquement « sûr » ou « dangereux ». Il aide à transformer un fichier opaque en questions techniques vérifiables.

Pour une PME belge de 10 à 50 personnes, le bon usage est une étape d'escalade. Le fichier est d'abord isolé. L'entreprise documente sa provenance et la décision à prendre. Un spécialiste examine ensuite les fonctions, les flux et les zones suspectes, puis formule des conclusions limitées par les preuves disponibles. Ghidra ne remplace ni un environnement d'analyse maîtrisé, ni d'autres moyens de sécurité, ni l'autorisation d'examiner le logiciel. Il ne reconstitue pas non plus le projet original. Il donne une vue exploitable du programme compilé. La valeur vient du protocole autour de l'outil : cadrer, inspecter, contredire, décider.

Le problème que ça résout

Dans une petite entreprise, l'arrivée d'un logiciel inconnu ressemble rarement à un incident spectaculaire. Un prestataire envoie un utilitaire pour convertir des fichiers. Un ancien poste contient un programme métier dont personne ne retrouve l'éditeur. Un collaborateur propose un outil téléchargé pour débloquer une tâche urgente. Une pièce jointe porte un nom crédible. Le besoin est immédiat, alors la question de confiance est traitée trop tard.

La direction se retrouve devant un choix pauvre : autoriser le fichier parce qu'il semble utile, ou l'interdire parce que personne ne sait ce qu'il fait. Les deux décisions peuvent coûter cher. La première ouvre une surface de risque mal comprise. La seconde peut bloquer une opération légitime ou prolonger la dépendance à un ancien système.

Ghidra crée une troisième voie : examiner avant d'autoriser. L'outil analyse du code compilé sur Windows, macOS et Linux. Il peut produire une représentation des instructions, une vue décompilée plus lisible, des graphes de contrôle et des résultats issus de scripts. L'analyste peut alors chercher des indices précis au lieu de se fier à l'apparence du fichier.

Cette inspection répond à des questions bornées. Quelles fonctions semblent liées au réseau ? Où le programme lit-il ou écrit-il des données ? Quelles bibliothèques appelle-t-il ? Quels chemins d'exécution méritent une vérification supplémentaire ? L'objectif n'est pas d'expliquer chaque instruction. Il est de réduire l'incertitude qui bloque une décision opérationnelle.

Pour une PME de 10 à 50 personnes, ce travail doit rester proportionné. Une analyse complète d'un logiciel complexe peut dépasser les moyens internes. En revanche, une question étroite peut justifier une intervention spécialisée : faut-il maintenir le fichier en quarantaine, demander des informations à l'éditeur, poursuivre l'analyse ou refuser son utilisation ? Le résultat utile n'est pas un rapport impressionnant. C'est une décision mieux étayée, avec ses limites écrites.

Ce que c'est concrètement

Ghidra est un framework de rétro-ingénierie créé et maintenu par la Research Directorate de la NSA. Le dépôt le présente comme une suite d'outils d'analyse de logiciels compilés. Il prend en charge de nombreux jeux d'instructions et formats d'exécutables, avec un usage interactif ou automatisé. Des extensions et des scripts peuvent être développés en Java ou en Python. Le projet est publié sous licence Apache 2.0.

Le désassemblage traduit le contenu binaire en instructions proches du processeur. La décompilation cherche à produire une représentation plus lisible, proche d'un langage de haut niveau. Cette seconde vue accélère la compréhension, mais elle ne rend pas le code source original. Les noms de variables, les commentaires, l'architecture initiale et une partie de l'intention ont disparu pendant la compilation. Le résultat doit donc être lu comme une reconstruction, pas comme une copie fidèle du projet.

Les graphes aident à suivre les embranchements et les appels entre fonctions. Les scripts permettent d'automatiser des recherches répétitives, de classer des éléments ou de compléter une analyse. Ces capacités deviennent utiles quand un analyste doit comparer plusieurs zones du programme ou reproduire une méthode. Elles peuvent aussi donner une fausse impression de certitude si l'équipe confond volume de sortie et qualité de preuve.

Ghidra travaille surtout sur ce qui est présent dans l'artefact compilé. Un comportement peut dépendre d'une configuration externe, d'un serveur, d'une donnée reçue plus tard ou d'un chemin qui ne devient visible qu'à l'exécution. L'analyse statique doit donc être complétée lorsque la question l'exige. Un outil de rétro-ingénierie n'est pas une preuve universelle de sécurité. Il éclaire une partie du système.

Le dépôt avertit également que certaines versions de Ghidra ont connu des vulnérabilités de sécurité et renvoie vers ses avis dédiés. Cette réserve compte dans le protocole d'une PME : l'outil d'analyse doit lui-même être choisi, maintenu et isolé avec sérieux. Examiner un fichier douteux avec un environnement négligé déplace le problème au lieu de le réduire.

Comment s'en servir

Étape 1 : formuler la décision avant l'analyse

Écrivez la décision attendue en une phrase. Par exemple : « pouvons-nous autoriser cet utilitaire sur un poste dédié pour traiter des fichiers non sensibles ? » Cette formulation est plus utile que « dites-nous tout sur ce programme ». Elle précise le périmètre, le contexte d'usage et le niveau de confiance nécessaire.

Ajoutez la provenance du fichier, sa version, la personne qui l'a fourni et le besoin métier associé. Si ces éléments manquent, l'absence elle-même devient un signal à traiter. L'analyse technique ne doit pas servir à compenser une chaîne de provenance inexistante.

Étape 2 : isoler l'artefact et préserver les preuves

Ne lancez pas le programme sur un poste de travail ordinaire pour « voir ce qui se passe ». Conservez une copie contrôlée de l'artefact et identifiez précisément ce qui est examiné. L'environnement d'analyse doit être séparé des données courantes, des accès de production et des comptes habituels.

Cette discipline protège aussi la qualité du rapport. Si plusieurs fichiers portant le même nom circulent, une conclusion peut être techniquement correcte et concerner le mauvais artefact. Chaque observation doit rester rattachée à la version réellement inspectée.

Étape 3 : vérifier le droit et le mandat d'analyse

Avant d'aller plus loin, faites vérifier le droit d'utiliser la copie du logiciel et le périmètre exact de l'analyse. La directive européenne 2009/24/CE distingue les droits du titulaire (article 4), l'observation du fonctionnement par une personne habilitée à utiliser le programme (article 5, paragraphe 3) et la décompilation nécessaire à l'interopérabilité sous conditions (article 6). La Cour de justice de l'UE a également reconnu, dans l'affaire Top System, une possibilité de décompiler dans la mesure nécessaire à la correction d'erreurs pour l'acquéreur légitime, sous les conditions qu'elle précise. Il serait donc imprudent de déduire d'un simple accès au fichier une autorisation générale de décompiler, de modifier ou de diffuser son code. Ces règles doivent être appréciées selon le cas et le contrat applicable.

Références juridiques : directive 2009/24/CE, articles 4 à 6 ; arrêt Top System, CJUE, 6 octobre 2021.

Le mandat doit aussi préciser qui reçoit les résultats et ce qui peut être partagé. Une analyse peut révéler des éléments sensibles sur le logiciel, son environnement ou les données qu'il traite. La curiosité technique n'est pas un cadre de gouvernance.

Étape 4 : commencer par une carte, pas par une conclusion

L'analyste importe l'artefact et construit une première carte : architecture visée, fonctions repérées, chaînes utiles, bibliothèques appelées, relations entre composants et zones qui demandent une lecture plus fine. À ce stade, une chaîne de caractères n'est pas la preuve qu'une action a lieu. Un appel possible n'est pas la preuve qu'il sera exécuté dans le scénario de la PME.

Chaque constat devrait donc porter un niveau de confiance et une limite. « Cette fonction semble préparer une connexion » est différent de « le programme transmet ces données à cette destination ». La première phrase ouvre un test. La seconde exige une preuve plus complète.

Étape 5 : faire contredire les hypothèses importantes

Une première lecture trouve souvent ce qu'elle cherche. Demandez une seconde vérification sur les points qui déterminent la décision : accès réseau, manipulation de fichiers, persistance, collecte d'informations ou mécanismes de mise à jour. La contradiction peut venir d'un autre analyste, d'une autre méthode ou d'une observation contrôlée à l'exécution.

Le rapport final doit séparer les faits observés, les interprétations probables et les questions non résolues. Cette séparation évite qu'une décompilation fluide soit présentée comme une certitude. Un pseudocode lisible reste une reconstruction.

Étape 6 : traduire l'analyse en décision métier

La direction n'a pas besoin d'un cours d'assembleur. Elle a besoin d'un choix compréhensible. Le livrable peut conclure à un refus, à une demande d'information complémentaire, à un usage limité dans un environnement dédié ou à une poursuite de l'analyse. Il doit expliquer ce qui soutient cette décision et ce qui reste inconnu.

Ajoutez les conditions de réexamen. Une nouvelle version du fichier, un changement de fournisseur ou un autre scénario d'usage invalide potentiellement une partie des conclusions. L'autorisation doit porter sur un artefact et un contexte, pas devenir un blanc-seing permanent.

Ce que ça coûte vraiment

Le code de Ghidra est ouvert, mais l'analyse coûte surtout du temps compétent. Installer un outil ne donne pas la capacité d'interpréter du code compilé, de reconnaître une reconstruction trompeuse ou de distinguer une fonction disponible d'un comportement réellement exécuté. Pour une PME sans spécialiste interne, le coût principal sera souvent l'intervention d'un analyste qualifié et la préparation d'un environnement adapté.

Le cadrage consomme également du temps. Il faut retrouver la provenance, identifier la version, définir la décision attendue et rassembler le contexte métier. Cette étape peut sembler lente face à une demande urgente. Elle évite pourtant de payer une analyse large qui ne répond à aucune question exploitable.

L'environnement d'analyse représente un autre poste. Il doit protéger les données de l'entreprise, limiter les accès et conserver les éléments nécessaires à la reproductibilité. La maintenance de Ghidra compte aussi : le dépôt signale que certaines versions sont concernées par des avis de sécurité. Une équipe doit donc vérifier la version utilisée et les informations de sécurité pertinentes avant de lui confier des artefacts sensibles.

Enfin, il faut compter le coût de l'incertitude résiduelle. Une analyse statique peut réduire le doute sans l'éliminer. Certaines fonctions restent ambiguës. Certains comportements dépendent d'éléments absents. Certains chemins ne sont pas déclenchés pendant les tests. Une entreprise paie donc pour mieux décider, pas pour acheter une certitude absolue.

Le bon indicateur n'est pas le nombre de fonctions examinées. C'est la qualité de la décision obtenue : le périmètre est-il clair, les preuves sont-elles conservées, les limites sont-elles visibles et l'entreprise sait-elle quoi faire ensuite ? Si le rapport ne change aucune décision, l'analyse était probablement mal cadrée.

Pour qui ce n'est pas

Ghidra n'est pas un outil destiné au collaborateur qui veut vérifier rapidement un fichier avant de l'ouvrir. Sa courbe d'apprentissage est réelle, et une lecture approximative peut rassurer à tort. Une PME sans compétence adaptée devrait confier l'analyse à un spécialiste plutôt que transformer un outil puissant en feu vert improvisé.

Ce n'est pas non plus un antivirus, un bac à sable automatique ni un service qui classe un fichier en un clic. Il peut révéler des éléments utiles à une enquête, mais il ne remplace pas les autres couches de sécurité. Une absence d'indice évident dans la vue décompilée ne démontre pas l'absence de comportement dangereux.

L'outil convient mal aux situations où l'entreprise n'a pas établi son droit d'utiliser la copie ni le périmètre légal de l'analyse. Une urgence métier ne tranche pas les conditions de la directive 2009/24/CE ni la portée de l'arrêt Top System, cités plus haut. Si le mandat est incertain, le fichier reste isolé pendant que le périmètre est clarifié avec un professionnel qualifié.

Il n'est pas non plus proportionné lorsque la décision peut être prise plus simplement. Si l'éditeur fournit une version vérifiable, une documentation suffisante, une signature contrôlable et un canal de support fiable, commencer par la rétro-ingénierie peut ajouter de la complexité sans réduire davantage le risque.

Enfin, Ghidra n'est pas adapté à une direction qui exige un verdict sans nuance. L'analyse de code compilé produit des preuves, des hypothèses et des zones inconnues. Refuser cette incertitude ne la supprime pas. Cela pousse seulement l'équipe à la cacher derrière une formulation trop sûre.

Source : https://github.com/NationalSecurityAgency/ghidra

FAQ

Ghidra peut-il dire si un exécutable est sûr ?

Non. Ghidra aide un analyste à inspecter le code compilé et à rechercher des comportements ou composants pertinents. La sécurité d'un fichier dépend aussi du contexte, des éléments externes, de ce qui se produit à l'exécution et des autres contrôles appliqués. L'outil réduit l'opacité ; il ne délivre pas un certificat.

Faut-il exécuter le programme pour l'analyser avec Ghidra ?

Ghidra permet une analyse statique du fichier compilé sans lancer directement le programme cible. Cette vue peut révéler de nombreuses informations, mais elle ne montre pas nécessairement tous les comportements possibles. Une observation à l'exécution peut être nécessaire dans un environnement maîtrisé lorsque la question dépasse ce que contient l'artefact.

Une PME peut-elle utiliser Ghidra sans expert interne ?

Elle peut décider de faire utiliser Ghidra par un prestataire qualifié. Le point important est de garder la maîtrise de la question, du périmètre, des données partagées et de la décision finale. Acheter une compétence ponctuelle est souvent plus réaliste que former toute l'équipe à la rétro-ingénierie.

La décompilation restitue-t-elle le code source original ?

Non. Elle produit une représentation destinée à faciliter l'analyse. La compilation a supprimé ou transformé une partie des informations du projet original. Les noms, les commentaires, la structure et l'intention peuvent manquer. Le pseudocode obtenu doit être vérifié contre d'autres éléments.

Quel livrable demander après l'analyse ?

Demandez un rapport lié à l'artefact exact, à la question de départ et aux preuves observées. Il doit distinguer faits, interprétations et inconnues, puis formuler une décision exploitable avec ses conditions : refus, analyse supplémentaire, usage limité ou autorisation dans un contexte défini.

---

Publié le 25 octobre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.