L'instrumentation binaire dynamique (DBI) constitue une technique fondamentale de la rétro-ingénierie et de la sécurité offensive : elle permet d'observer, de tracer et de modifier le comportement d'un programme en cours d'exécution, sans accès au code source ni recompilation. En 2026, deux frameworks dominent ce domaine et incarnent des philosophies complémentaires. Frida repose sur l'injection d'un moteur JavaScript dans le processus cible, privilégiant la rapidité de prototypage, le hooking d'API et l'analyse mobile sur Android comme sur iOS. DynamoRIO, à l'inverse, réécrit et recompile les blocs de base à la volée, offrant une granularité à l'instruction près, indispensable au fuzzing guidé par la couverture et à l'analyse de performance. Maîtriser le couple Frida DynamoRIO instrumentation binaire permet ainsi d'articuler exploration rapide et mesure fine, du reverse d'applications protégées jusqu'à la détection de vulnérabilités mémoire.

En bref

  • Frida = injection JavaScript dans n'importe quel processus avec hooking de fonctions, tracing et modification mémoire
  • DynamoRIO = process virtual machine C/C++ avec instrumentation instruction-level haute performance
  • Le Stalker de Frida permet le tracing instruction-level avec réécriture de code à la volée
  • Frida est le standard pour le pentest mobile (SSL pinning bypass, root détection bypass)
  • DynamoRIO est le standard pour le fuzzing closed-source (WinAFL) et l'analyse de performance
  • Les deux frameworks supportent l'anti-anti-debug en hookant les fonctions de détection

En bref

  • Frida : injection, hooking JavaScript, Interceptor, Stalker et CModule
  • DynamoRIO : architecture, basic block instrumentation, drmemtrace et DrCov
  • Cas d'usage offensifs : bypass SSL pinning, anti-tamper, DRM et EDR evasion
  • Analyse de malware : API tracing, unpacking automatique et protocole reversing
  • Fuzzing guidé par instrumentation : AFL+DynamoRIO, Frida+fuzzing, coverage-guided
Instrumentation Binaire Dynamique (DBI) — Technique consistant à injecter du code d'observation et de modification dans un programme en cours d'exécution. Le framework DBI interpose une couche de traduction entre le CPU et le programme, permettant d'inspecter et modifier chaque instruction, chaque appel de fonction et chaque accès mémoire en temps réel.

Frida : Architecture et Injection

Frida injecte un agent JavaScript (runtime QuickJS ou V8) dans le processus cible. L'architecture est client-serveur : le script Python/Node.js côté contrôle communique avec l'agent JavaScript injecté dans le processus cible via un canal IPC. Frida supporte Windows, Linux, macOS, iOS, Android et peut instrumenter des processus natifs, Java (Android/JVM), Objective-C (iOS/macOS) et .NET.

#!/usr/bin/env python3
# Frida — Hooking d'une fonction avec interception des arguments
import frida, sys

# Script JavaScript injecté dans le processus cible
jscode = """
Interceptor.attach(Module.getExportByName('libssl.so', 'SSL_write'), {
 onEnter: function(args) {
 // args[0] = SSL* ctx, args[1] = buffer, args[2] = length
 var len = args[2].toInt32();
 var buf = Memory.readByteArray(args[1], Math.min(len, 256));
 console.log('[SSL_write] ' + len + ' bytes:');
 console.log(hexdump(buf, {header: true, ansi: true}));
 
 // Sauvegarder le contexte pour onLeave
 this.buf = args[1];
 this.len = len;
 },
 onLeave: function(retval) {
 console.log('[SSL_write] returned: ' + retval);
 }
});

// Hooking Java sur Android
Java.perform(function() {
 var TrustManager = Java.use('javax.net.ssl.X509TrustManager');
 TrustManager.checkServerTrusted.implementation = function(chain, authType) {
 console.log('[*] SSL Pinning bypassed!');
 // Ne rien faire = accepter tous les certificats
 };
});
"""

# Attacher au processus
session = frida.attach("target_app")
script = session.create_script(jscode)
script.on('message', lambda msg, data: print(msg))
script.load()
sys.stdin.read()

Frida Stalker : Tracing Instruction-Level

Le Stalker de Frida est un traceur d'instructions qui suit l'exécution instruction par instruction. Il utilise la réécriture de code (code rewriting) : chaque basic block est copié, instrumenté avec du code de tracing, et exécuté à la place de l'original. Le Stalker supporte x86, x64, ARM et ARM64 :

⚡

Retour terrain

Dans l'analyse de code malveillant, la règle que j'applique avant toute décompilation : analyser le comportement dans une sandbox avant d'ouvrir IDA ou Ghidra. Les malwares modernes incluent fréquemment des mécanismes anti-analyse qui se déclenchent en environnement de débogage — timers, vérification de breakpoints, détection de machines virtuelles. Sur les 3 derniers RATs que j'ai analysés, tous avaient au moins une technique d'anti-debug active.

// Frida Stalker — tracer toutes les instructions d'un thread
var mainThread = Process.enumerateThreads()[0];

Stalker.follow(mainThread.id, {
 events: {
 call: true, // Tracer les CALLs
 ret: true, // Tracer les RETs
 exec: false, // Ne pas tracer chaque instruction (performance)
 block: true, // Tracer les basic blocks
 },
 
 onCallSummary: function(summary) {
 // summary = {target_addr: call_count, ...}
 for (var addr in summary) {
 var sym = DebugSymbol.fromAddress(ptr(addr));
 if (sym.name) {
 console.log(sym.name + ' called ' + summary[addr] + ' times');
 }
 }
 },
 
 transform: function(iterator) {
 var instruction;
 while ((instruction = iterator.next()) !== null) {
 // Modifier les instructions à la volée
 if (instruction.mnemonic === 'rdtsc') {
 // Remplacer rdtsc par des valeurs fixes (anti-timing)
 iterator.putCallout(function(context) {
 context.eax = 0x12345678;
 context.edx = 0x00000001;
 });
 } else {
 iterator.keep();
 }
 }
 }
});

DynamoRIO : Instrumentation Haute Performance

DynamoRIO est un framework DBI C/C++ développé par Google, optimisé pour la performance. Contrairement à Frida (injection + scripting), DynamoRIO agit comme un process virtual machine : il traduit chaque basic block du programme avant exécution, insérant l'instrumentation dans le flux de code traduit. Cette approche est plus rapide que le hooking de Frida pour l'instrumentation massive.

// DynamoRIO — Client d'instrumentation : compter les basic blocks
#include "dr_api.h"
#include "drmgr.h"

static int bb_count = 0;
static void *count_mutex;

// Callback appelé pour chaque basic block
static dr_emit_flags_t
event_bb(void *drcontext, void *tag, instrlist_t *bb,
 bool for_trace, bool translating) {
 
 instr_t *first = instrlist_first(bb);
 
 // Insérer un appel à notre fonction de comptage
 dr_insert_clean_call(drcontext, bb, first,
 (void *)increment_count,
 false /* no fp save */, 0);
 
 return DR_EMIT_DEFAULT;
}

static void increment_count(void) {
 dr_mutex_lock(count_mutex);
 bb_count++;
 dr_mutex_unlock(count_mutex);
}

DR_EXPORT void dr_client_main(client_id_t id, int argc, const char *argv[]) {
 count_mutex = dr_mutex_create();
 drmgr_init();
 drmgr_register_bb_instrumentation_event(NULL, event_bb, NULL);
 dr_log(NULL, LOG_ALL, 1, "BB counter initialized ");
}

Cas d'Usage Offensifs

  • SSL Pinning Bypass : Frida intercepte les fonctions de validation SSL/TLS (iOS: SecTrustEvaluate, Android: checkServerTrusted) pour accepter tous les certificats — essentiel pour le pentest d'applications mobiles
  • Anti-tamper/Anti-debug Bypass : hooker les appels système de détection (ptrace, IsDebuggerPresent, timing checks) pour neutraliser les protections des malwares et des applications protégées
  • EDR Evasion Research : instrumenter les hooks EDR userland (ntdll.dll) pour comprendre ce qui est surveillé et identifier les gaps de couverture
  • Game Hacking / DRM Bypass : modifier la logique des validations de licence et les protections DRM en mémoire
  • Protocol Reversing : tracer les entrées/sorties réseau pour reconstruire des protocoles propriétaires

Fuzzing Guidé par Instrumentation

DynamoRIO et Frida sont utilisés comme backends de couverture pour le fuzzing : au lieu de compiler le programme avec la couverture (source-based), le DBI instrumente le binaire à la volée pour collecter la couverture de code. WinAFL utilise DynamoRIO, Frida-fuzzer utilise le Stalker de Frida. L'avantage : fuzzer des binaires closed-source sans accès au code source ni recompilation.

Frida vs DynamoRIO : Choix du Framework

CritèreFridaDynamoRIO
LangageJavaScript/Python (simple)C/C++ (performance)
InjectionInjection dans process existantLancement sous DynamoRIO
Performance~2-5x slowdown (hooking)~1.5-3x (translation)
MobileiOS + Android natifAndroid (limité)
Cas d'usageHooking, pentest mobile, REFuzzing, taint analysis, profiling
Stalking/TracingStalker (flexible)drmemtrace (rapide)
💡 Conseil pratique — Pour le pentest mobile, Frida est incontournable. Utilisez frida-tools (pip install frida-tools) pour un accès rapide : frida-trace -U -i 'SSL*' com.target.app trace automatiquement toutes les fonctions SSL de l'application. Le repo frida-codeshare contient des scripts prêts à l'emploi pour le SSL pinning bypass, le root détection bypass et le jailbreak détection bypass.

À retenir

  • Frida = injection JavaScript dans n'importe quel processus avec hooking de fonctions, tracing et modification mémoire
  • DynamoRIO = process virtual machine C/C++ avec instrumentation instruction-level haute performance
  • Le Stalker de Frida permet le tracing instruction-level avec réécriture de code à la volée
  • Frida est le standard pour le pentest mobile (SSL pinning bypass, root détection bypass)
  • DynamoRIO est le standard pour le fuzzing closed-source (WinAFL) et l'analyse de performance
  • Les deux frameworks supportent l'anti-anti-debug en hookant les fonctions de détection

FAQ — Questions Fréquentes

Frida est-il détectable par les applications ?

Oui, les applications protégées détectent Frida via plusieurs mécanismes : présence de frida-server dans les processus, port 27042 (default Frida), strings 'frida' en mémoire, et hooks sur les fonctions de détection elles-mêmes. Les techniques d'évasion incluent : recompiler frida-server avec un nom différent, changer le port, utiliser le mode 'gadget' (injection via library loading) et hooker les fonctions de détection avant qu'elles ne s'exécutent.

Quelle est la différence entre Frida et un debugger ?

Un debugger (GDB, LLDB, x64dbg) arrête l'exécution à des breakpoints et permet l'inspection pas à pas. Frida instrumente le programme sans l'arrêter — le hooking est transparent et l'application continue de s'exécuter normalement. Frida est plus adapté à l'instrumentation massive (tracer des milliers d'appels) et à la modification de comportement à la volée, tandis qu'un debugger est meilleur pour l'analyse fine d'un crash ou d'un bug.

DynamoRIO peut-il instrumenter des programmes Windows ?

Oui, DynamoRIO supporte Windows, Linux et Android. Sur Windows, il est le backend de WinAFL (le fuzzer de référence pour les binaires Windows). DynamoRIO peut instrumenter des programmes 32-bit et 64-bit, des DLLs, et même des services Windows. Il est particulièrement efficace pour le fuzzing de parsers (PDF, Office, navigateurs) sur Windows.

Conclusion

Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.

Besoin d'un accompagnement expert ?

Nos consultants spécialisés en reverse engineering et sécurité applicative vous accompagnent dans l'évaluation de votre posture de sécurité.

Contactez-nous
Article recommandé : ETW Tampering : Évasion et Détection sur Windows

📚 Articles connexes

🔗 Références externes

Ayi NEDJIMI

Analyse de malwares & rétro-ingénierie

Analyse de code malveillant, reverse engineering, threat intelligence — rapport IOC complet.

Frida et DynamoRIO en pratique : cas d'usage avancés pour l'instrumentation binaire

L'instrumentation dynamique de binaires avec Frida et DynamoRIO va bien au-delà du simple hooking de fonctions. En analyse de malware, Frida permet de scripter l'interception des appels API critiques (CreateProcess, WriteProcessMemory, CryptEncrypt) pour documenter le comportement en temps réel sans modifier le binaire analysé. Sa compatibilité multi-plateforme (Windows, Linux, macOS, Android, iOS) en fait l'outil polyvalent par excellence pour les équipes de reverse engineering. Les scripts Frida peuvent automatiser l'extraction des configurations de malware packés ou l'identification des clés de chiffrement utilisées par des ransomwares.

DynamoRIO, orienté performance et analyse à grande échelle, excelle dans la génération de traces d'exécution pour des analyses de coverage (quel pourcentage du code est atteint lors d'un fuzzing) et la construction de graphes de flot de contrôle dynamiques. Son framework DrCov génère des fichiers de coverage compatibles avec IDA Pro et Binary Ninja pour visualiser les chemins d'exécution. La combinaison Frida (interactivité, scripting rapide) et DynamoRIO (performance, coverage) couvre l'ensemble des besoins d'instrumentation binaire en équipe de recherche en sécurité offensive. Des plateformes comme DRAKVUF Sandbox intègrent directement ces techniques pour l'analyse automatisée de malware à grande échelle.

Mise en œuvre pratique : étapes et livrables

La conformité réglementaire génère une documentation substantielle qui doit être maintenue à jour et accessible lors des audits. Une organisation structurée de ces livrables simplifie considérablement les exercices de conformité et réduit le temps consacré à leur préparation.

Livrables documentaires essentiels

Quel que soit le référentiel de conformité concerné, les livrables fondamentaux incluent : un registre des traitements (obligatoire RGPD, utile pour tout SMSI) maintenu par le DPO ou le RSSI ; une politique de sécurité de l'information (PSI ou PSSI) approuvée par la direction et diffusée à tous les collaborateurs ; des procédures opérationnelles documentées pour les processus critiques (gestion des incidents, accès privilégiés, sauvegardes) ; un plan de continuité d'activité (PCA) testé annuellement ; et des rapports d'audit internes et de revue de direction formalisés. Ces documents constituent le «squelette» du SMSI et sont systématiquement vérifiés lors des audits de certification.

Gouvernance et responsabilités

La conformité réglementaire est un effort collectif qui ne peut pas reposer uniquement sur le RSSI ou le DPO. Une gouvernance efficace définit clairement les rôles : le COMEX assume la responsabilité globale de la conformité (risque financier et réputationnel) ; les DSI et RSSI mettent en œuvre les mesures techniques ; les métiers identifient les données et processus critiques à protéger ; et les DPO/compliance officers assurent la cohérence réglementaire. Les comités de sécurité trimestriels, impliquant toutes ces parties prenantes, garantissent l'alignement entre les exigences réglementaires et les capacités opérationnelles de l'organisation. Le suivi des actions de remédiation dans un outil de GRC (Governance, Risk & Compliance) formalise ce processus et facilite la production des preuves d'audit.

Sanction et contrôle : ce que les autorités vérifient

Comprendre les priorités de contrôle des autorités de régulation permet aux organisations de concentrer leurs efforts sur les domaines qui font l'objet d'une surveillance accrue. Les autorités de supervision (CNIL, ANSSI, ACP pour le secteur bancaire, HAS pour le secteur santé) publient régulièrement leurs priorités de contrôle.

Priorités de contrôle 2025-2026

Les domaines prioritaires identifiés par les autorités françaises pour 2025-2026 : la sécurité des données de santé (contrôles HDS en forte augmentation suite aux incidents hospitaliers) ; l'IA et le traitement des données personnelles (CNIL a annoncé 300 mises en demeure liées à l'IA en 2025) ; les sous-traitants et tiers (vérification des DPA et des audits de sécurité des fournisseurs) ; et la notification des violations de données dans les délais légaux (72h RGPD, 24h NIS 2 pour les entités essentielles). Les organisations qui documentent proactivement leur conformité dans ces domaines réduisent significativement leur exposition aux sanctions et bénéficient généralement d'une procédure d'audit moins contraignante.

Programme de préparation aux audits

Un programme structuré de préparation aux audits réduit le stress et améliore les résultats. Douze mois avant un audit de certification : gap analysis interne pour identifier les non-conformités. Six mois avant : corrections des écarts majeurs et préparation de la documentation. Trois mois avant : audit blanc interne conduit par un consultant externe indépendant. Un mois avant : formation des équipes sur les procédures et livrables à présenter. Cette approche systématique, validée par des centaines d'organisations certifiées ISO 27001, transforme l'audit de certification d'une épreuve redoutée en une validation formelle d'un travail déjà accompli.

Synthèse et feuille de route conformité

La conformité réglementaire est un processus continu, non un projet ponctuel. Les organisations qui abordent ISO 27001, NIS 2, RGPD ou HDS comme des certifications à obtenir une fois pour toutes échouent systématiquement lors des audits de renouvellement. La clé du succès est l'intégration des exigences réglementaires dans les processus opérationnels quotidiens, non leur traitement comme des obligations externes.

En pratique, les organisations matures en matière de conformité fonctionnent avec un SMSI vivant : des revues de direction trimestrielles, un audit interne annuel, des exercices de gestion de crise bi-annuels, et une veille réglementaire hebdomadaire. Le coût de la conformité maintenue en continu est significativement inférieur au coût d'une remise à niveau précipitée avant un audit ou une notification de violation. Les amendes CNIL, les pénalités NIS 2, et les pertes de contrats liées à une non-conformité documentée représentent des risques financiers et réputationnels mesurables que la gouvernance de direction doit intégrer dans l'analyse des risques métier.

La maîtrise des concepts et techniques détaillés dans cet article est un investissement à long terme dans la posture de sécurité de votre organisation. Les menaces évoluent rapidement, mais les fondamentaux — durcissement systématique, surveillance continue, et formation régulière des équipes — restent les piliers d'une défense efficace en profondeur.

Bonnes pratiques et recommandations complémentaires

Au-delà des techniques et outils présentés dans cet article, plusieurs principes transverses guident les professionnels de la cybersécurité dans leur approche quotidienne. La défense en profondeur (defense-in-depth) reste le principe fondateur : aucune mesure de sécurité unique n'est suffisante, et la multiplication des couches de protection — même imparfaites individuellement — crée une résilience globale supérieure à la somme de ses parties.

Veille et mise à jour continue

La cybersécurité est un domaine où l'obsolescence est rapide. Une technique ou un outil efficace en 2024 peut être contourné en 2026. Les équipes sécurité maintiennent leur efficacité en s'appuyant sur des sources de veille fiables : bulletins CERT-FR et ANSSI, advisories des éditeurs (Microsoft MSRC, Google Project Zero, Cisco Talos), recherches académiques (USENIX Security, IEEE S&P, CCS), et publications de la communauté (threat intel reports des grands éditeurs, articles de blog de chercheurs reconnus).

Documentation et partage de connaissances

La capitalisation des connaissances est un enjeu organisationnel critique dans les équipes de sécurité. Les runbooks d'investigation, les post-mortems d'incidents, les procédures de réponse documentées, et les bases de connaissance internes permettent de maintenir la cohérence des pratiques indépendamment des rotations d'équipe et de réduire le temps de résolution des incidents récurrents. L'utilisation d'un wiki sécurisé (Confluence, Notion avec contrôles d'accès stricts) pour centraliser ces connaissances est une pratique adoptée par la majorité des équipes SOC matures. La documentation proactive, rédigée juste après les incidents pendant que les détails sont frais, est systématiquement plus précise et utile que la documentation rédigée après coup.

Points d'attention avancés pour les auditeurs et RSSI

Au-delà de la conformité de surface, les auditeurs expérimentés et les RSSI cherchent à évaluer la robustesse réelle du dispositif de sécurité. Ce niveau d'analyse requiert de dépasser la vérification documentaire pour s'intéresser à l'efficacité opérationnelle des contrôles.

Pièges courants dans les audits de conformité

Plusieurs patterns d'échec reviennent régulièrement lors des audits de renouvellement. La conformité sur papier sans effectivité opérationnelle : des politiques formalisées mais non appliquées, des procédures documentées mais inconnues des équipes, des contrôles déclarés actifs mais non supervisés. La dérive post-certification : les organisations qui traitent la certification comme une fin en soi plutôt que comme un jalons d'un processus continu connaissent systématiquement une dégradation de leur posture sécurité entre deux audits. La gestion insuffisante des tiers : plus de 60% des violations impliquent un fournisseur ou un prestataire, mais les contrats de sous-traitance et les audits tiers sont souvent les parents pauvres des programmes de conformité. Adresser ces trois points avant l'audit réduit significativement le risque de non-conformité majeure.

Métriques de maturité à présenter en audit

Les auditeurs modernes s'intéressent aux indicateurs de fonctionnement réel du SMSI plutôt qu'à la simple existence des documents. Préparer : statistiques de gestion des incidents sur 12 mois (nombre, délai de traitement, taux de récidive) démontrant une amélioration continue ; résultats des exercices de continuité avec les actions correctives entreprises ; données de sensibilisation (taux de participation aux formations, taux d'échec aux simulations de phishing) ; et résultats des audits internes avec suivi des actions de remédiation. Ces métriques transforment l'audit en démonstration de la maturité de l'organisation plutôt qu'en exercice de conformité documentaire, et constituent la meilleure défense contre les questions inattendues des auditeurs sur l'efficacité opérationnelle des contrôles.

Checklist de mise en œuvre et points de contrôle

La mise en pratique des recommandations de cet article nécessite une approche structurée. Cette checklist synthétise les points de contrôle essentiels pour évaluer l'état d'avancement de votre déploiement et identifier les actions prioritaires.

Phase de préparation et d'inventaire

Avant toute action technique, constituer un inventaire précis est indispensable. Les éléments à recenser : cartographie exhaustive des actifs concernés (systèmes, applications, flux de données) avec leur criticité métier associée ; identification des propriétaires techniques et fonctionnels pour chaque actif ; évaluation du niveau de maturité actuel à partir des référentiels reconnus (CIS Controls, ISO 27001, NIST CSF) ; et documentation des dépendances entre composants pour anticiper les impacts des modifications. Un inventaire incomplet génère des angles morts qui deviennent des vecteurs d'attaque exploitables par des acteurs malveillants disposant d'informations accessibles publiquement (OSINT, Shodan, LinkedIn).

Phase de déploiement et validation

Le déploiement progressif réduit les risques d'interruption de service et facilite la détection des régressions. Adopter un modèle de déploiement par vagues (wave deployment) : d'abord les environnements de développement et de test pour valider les configurations, ensuite les systèmes non-critiques en production, enfin les systèmes critiques lors de fenêtres de maintenance planifiées. Chaque vague s'accompagne d'une validation fonctionnelle complète et d'une période d'observation des métriques de performance et de sécurité. Un plan de retour arrière documenté et testé est obligatoire avant toute opération sur un système critique. Les critères de succès doivent être définis avant le déploiement, non après — un taux de faux positifs inférieur à 5% pour les alertes de sécurité, une disponibilité maintenue au niveau SLA contractuel, et l'absence d'incidents de sécurité liés aux modifications.

Phase de supervision et d'amélioration continue

La mise en place d'indicateurs de suivi permet de mesurer l'efficacité des mesures déployées et de justifier leur maintien auprès de la direction. Tableau de bord mensuel recommandé : nombre d'alertes générées par catégorie (critique, majeur, mineur) avec tendance sur 6 mois ; taux de couverture des actifs critiques par les contrôles de sécurité ; délai moyen de remédiation des vulnérabilités par sévérité CVSS ; et résultats des tests de régression mensuels sur les règles de détection. Ce tableau de bord, présenté en comité de sécurité, constitue la base d'un dialogue constructif entre les équipes techniques et le management sur les priorités d'investissement en cybersécurité.

Sources et références