Le coût de la compréhension : Rétro-ingénierie pilotée par LLM vs Obfuscation itérative par LLM

Introduction

Au cours des dernières années, nous avons observé une évolution significative des capacités des LLM à être productifs et à effectuer diverses tâches qui répondent à des problèmes réels, tels que la synthèse de programmes, la recherche de logiciels malveillants ou la recherche de vulnérabilités. Dans le contexte spécifique de la rétro-ingénierie, les LLM sont particulièrement efficaces si l'on dispose des bons outils, car ils sont très performants pour lire le code source, même en l'absence de symboles. De plus, grâce à leurs connaissances, ils sont capables d'imiter et d'appliquer des méthodologies d'inversion.

Les méthodes d'obscurcissement des programmes créent une asymétrie importante entre le temps nécessaire pour appliquer les transformations à un programme et le temps nécessaire pour le rétroconcevoir, ce qui constitue une défense relativement efficace contre la rétroconception et pousse les chercheurs à perdre du temps et à mettre au point de nouvelles méthodes. L'émergence des LLM a considérablement changé la donne, car les modèles sont désormais capables de briser ces obscurcissements (en fonction des transformations appliquées) en un temps raisonnable, inversant ainsi cette asymétrie en faveur de l'attaquant.

Néanmoins, dans ce jeu du chat et de la souris, nous supposons que ce n'est qu'une question de temps avant que les fabricants d'obscurcisseurs ne s'adaptent avec de nouvelles techniques et ne relèvent la barre, tout comme, pour faire face à cette nouvelle réalité où l'ingénierie inverse n'a jamais été aussi accessible, les producteurs de logiciels appliquent systématiquement ces transformations pour protéger leur propriété intellectuelle.

Deux fois par an, Elastic offre aux ingénieurs la possibilité d'entreprendre un projet de recherche d'une semaine pendant la semaine ON. Pour cette session d'avril 2026 , inspirée par cet article, nous avons recherché à quel point il est facile et bon marché de vibecoder les techniques d'obfuscation visant les LLM, en particulier Claude Opus 4.6. Cette recherche couvrira un premier benchmark que nous avons mené, dans lequel nous avons testé le modèle contre des cibles compilées avec diverses combinaisons de transformations en utilisant l'obscurcisseur académique (mais très puissant) Tigress. Nous poursuivons avec notre recherche sur les différentes techniques d'obscurcissement que nous avons trouvées efficaces contre le modèle, qui ont été entièrement codées à l'aide d'un pipeline piloté par l'IA (dev/test/improve).

Par manque de temps, nous nous sommes concentrés sur les défenses par analyse statique. Cependant, nous pensons sans aucun doute que le flux de travail que nous avons utilisé peut également être utilisé pour rechercher des idées axées sur les défenses d'analyse dynamique, telles que les techniques d'évasion et d'anti-débogage, afin de rendre l'analyse pilotée par LLM significativement plus coûteuse et peu fiable.

Principaux points abordés dans cet article

• Les LLM ont rapidement remodelé l'industrie du logiciel, en rendant plus accessibles des sujets complexes tels que l'ingénierie inverse, y compris la capacité de vaincre différents niveaux d'obscurcissement.
• L'obscurcissement lourd augmente considérablement le coût et le temps de calcul, ce qui perturbe les pipelines d'analyse automatisés.
• Les contre-mesures efficaces d'analyse statique ciblant les LLM sont peu coûteuses et rapides à développer.
• Les défenses efficaces contre la MILDT exploitent les fenêtres contextuelles, les plafonds budgétaires et les biais de raccourci.

Comparaison entre Claude Opus 4.6 et Tigress Obfuscator

Nous avons utilisé Claude pour évaluer sa capacité à résoudre statiquement un crackme obscurci par l'obscurcisseur académique Tigress.

Pipeline de référence

Pour réaliser ces tests, nous avons utilisé une configuration contrôleur/travailleur dans laquelle une instance Opus gère des sous-instances : elle surveille leur progression, collecte leurs résultats et peut allouer plus de temps à une instance si elle juge qu'elle progresse et qu'elle a du potentiel. Inversement, il peut également tuer l'instance s'il estime que le modèle est bloqué dans sa tâche, qu'il tourne en rond ou qu'il commence à forcer brutalement le problème.

Chaque sous-instance de travailleur a accès à une machine virtuelle Windows sur laquelle IDA Pro est installé et accessible via le plugin IDA MCP. Il a également accès aux ressources de la machine virtuelle Linux dans laquelle il s'exécute pour développer et lancer des scripts.

En outre, nous utilisons le plugin Caveman, compatible avec Claude, qui réduit le fluff LLM en parlant jusqu'à -75% avec les bonnes instructions au démarrage. Cela permet d'augmenter la vitesse de travail et de réduire le coût de chaque tâche. Nous l'utilisons dans son mode par défaut.

Cette configuration permet à chaque instance de travailleur de démarrer le test avec un contexte vide et une invite classique de rétro-ingénierie, de sorte qu'elle ne sait pas qu'elle est surveillée dans le cadre de l'analyse comparative.

Système d'évaluation

Pour la notation, chaque cible est notée par l'instance de contrôle sur trois axes (0-2 points chacun), pour un maximum de six points :

Cas de test

Pour effectuer ces tests, nous avons utilisé le défi suivant : récupérer le mot de passe r3v3rs3! en procédant à une rétro-ingénierie statique du binaire compilé.

// Run 2 crackme — 4-round XOR cipher with LCG key schedule
// Password "r3v3rs3!" only recoverable by reversing the algorithm.
// No key array in the binary — only a 32-bit seed.

unsigned int key_seed = 0x5EED1234u;

unsigned char enc_expected[8] = {
    0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8
};

void transform(const char *input, unsigned char *output, int len) {
    unsigned int s = key_seed;
    unsigned int subkeys[4];

    // Key schedule: derive 4 round subkeys via glibc LCG
    for (int r = 0; r < 4; r++) {
        s = s * 1103515245u + 12345u;
        subkeys[r] = s;
    }

    // Copy input to 8-byte buffer (zero-padded)
    for (int i = 0; i < 8; i++)
        output[i] = (i < len) ? (unsigned char)input[i] : 0;

    // 4 rounds: XOR with subkey bytes, then rotate left by 1
    for (int r = 0; r < 4; r++) {
        for (int i = 0; i < 8; i++)
            output[i] ^= (unsigned char)(subkeys[r] >> (8 * (i & 3)));

        unsigned char tmp = output[0];
        for (int i = 0; i < 7; i++)
            output[i] = output[i + 1];
        output[7] = tmp;
    }
}

int verify(const unsigned char *transformed, int len) {
    if (len != 8) return 0;
    for (int i = 0; i < 8; i++)
        if (transformed[i] != enc_expected[i]) return 0;
    return 1;
}

// main(): reads argv[1], calls transform(), calls verify()
// prints "Access granted!" or "Access denied."

Résultats

Exécution par défaut

Nous avons compilé le défi avec différentes transformations, chaque transformation produisant un binaire différent mais avec le même comportement et les mêmes caractéristiques. Pour la première exécution, nous avons utilisé des options par défaut pour chaque transformation. Toutes les transformations disponibles dans Tigress sont disponibles ici. Les tests ont été divisés en 4 phases de difficulté croissante pour un total de 22 cibles :

Phase 0 - Pas de transformation

• p0_baseline - Pas de transformation

Phase 1 - Transformations individuelles (7 cibles) :

• p1_encode_arithmetic - EncodeArithmetic uniquement
• p1_encode_literals - EncodeLiterals uniquement
• p1_flatten_indirect - Aplatir (indirect) uniquement
• p1_jit - JIT uniquement
• p1_jit_dynamic - JitDynamic(xtea) uniquement
• p1_virtualize_indirect_regs - Virtualiser (indirect, regs) uniquement
• p1_virtualize_switch_stack - Virtualisation (commutateur, pile) uniquement

Phase 2 - Transformations jumelées (7 cibles) :

• p2_both_data - EncodeLiterals + EncodeArithmetic
• p2_flatten_ind_enc_arithmetic - Aplatir(indirect) + EncoderArithmétique
• p2_flatten_ind_virt_sw - Aplatir(indirect) + Virtualiser(switch)
• p2_jitdyn_enc_arithmetic - JitDynamic(xtea) + EncodeArithmetic
• p2_virt_ind_enc_arithmetic - Virtualiser(indirect,regs) + EncodeArithmétique
• p2_virt_ind_enc_literals - Virtualiser(indirect,regs) + EncodeLiterals
• p2_virt_sw_enc_arithmetic - Virtualiser(switch) + EncodeArithmétique

Phase 3 - Combos lourds (7 cibles) :

• p3_double_virtualize - Virtualize(switch) then Virtualize(indirect,regs) - VMs imbriquées
• p3_double_virt_both_data - Double virtualisation + EncodeLiterals + EncodeArithmetic (le patron)
• p3_flatten_ind_both_data - Flatten(indirect) + EncodeLiterals + EncodeArithmetic
• p3_flatten_virt_ind_enc - Aplatir(indirect) + Virtualiser(indirect,regs) + EncoderArithmétique
• p3_jitdyn_both_data - JitDynamic(xtea) + EncodeLiterals + EncodeArithmetic
• p3_virt_ind_both_data - Virtualiser(indirect,regs) + EncodeLiterals + EncodeArithmetic
• p3_virt_sw_both_data - Virtualiser(switch) + EncodeLiterals + EncodeArithmetic

La liste complète des transformations, ainsi que les options de génération que nous avons utilisées, sont disponibles ici.

L'évaluation des résultats intègre trois critères clés : le score de performance, le coût et le temps d'exécution de la tâche. Il est essentiel de noter que même si un grand modèle linguistique est très performant, son efficacité réelle est toujours limitée par le coût et le temps. Ces deux facteurs sont décisifs dans l'analyse binaire à grande échelle, une tâche que nous visons à optimiser grâce aux différents pipelines d'analyse automatisés développés à Elastic. Notre objectif est donc de déterminer si l'utilisation d'outils tels que Tigress augmente de manière significative ces trois variables fondamentales : la performance, le coût et le temps.

Opus 4.6 a résolu 40% des tâches 20 (22 dont 2 ont été suspendues et n'ont pas pu être évaluées) avec un coût moyen de 2,39 $ pour les succès et de 4,83 $ pour les échecs. Dans ces 40%, 12,5% proviennent de la phase 0 (défi nu sans obscurcissement), 50% de la phase 1 (transformation simple), 38,5% de la phase 2 (paire de transformations) et 0% de la phase 3 (couches multiples).

Sans surprise, nous observons une augmentation significative des facteurs de performance coût et temps à mesure que la difficulté augmente. La phase 3, qui comprend les combinaisons de transformations les plus complexes, présente les meilleurs résultats avec un coût moyen de 4,32 $. Toutes les tâches qui ont échoué au cours de cette phase ont été interrompues parce que le modèle a commencé à gaspiller des jetons en procédant par ignorance ou par force brute, sans parvenir à progresser.

L'obscurcissement de type JIT (Just-In-Time) s'est avéré être la transformation la plus problématique pour notre modèle au cours de la phase 1. Cette technique consiste à stocker le code sous une forme intermédiaire cryptée. Au moment de l'exécution, l'obscurcisseur lit ce bytecode et génère un code x86 valide, qui est exécuté dans une mémoire allouée dynamiquement. Ce processus est comparable à celui d'une machine virtuelle (comme un émulateur de PlayStation), qui compile le code pour une architecture différente de la cible et utilise un émulateur, avec les étapes JIT supplémentaires avant l'exécution.

Malgré l'échec des tâches de l'ECE, il est important de noter qu'Opus 4.6 a toujours identifié les structures du moteur qui hébergent l'algorithme LCG dans le crackme. L'échec réside dans la récupération des constantes cruciales nécessaires pour trouver la clé.

Son travail reste très impressionnant et l'on peut supposer qu'avec un budget plus important et une meilleure orientation, le modèle aurait pu réussir. Toutefois, nous devons tenir compte de l'asymétrie pratique entre la facilité de générer une telle tâche et le temps et le coût nécessaires pour la résoudre. Pour une transformation simple, cette technique d'obscurcissement est très efficace et rend impossible l'augmentation du nombre d'échantillons traités par un pipeline automatisé.

La phase 3, caractérisée par la multiplication et la combinaison des couches d'obscurcissement, a entraîné une explosion des coûts. Bien que Claude ait une nouvelle fois accompli une partie du travail de manière très impressionnante, la tâche dépassait sa capacité à continuer de manière autonome.

Par exemple, nos résultats montrent que face à une double couche de virtualisation (comme un jeu Game Boy Advance fonctionnant dans un émulateur GBA, qui lui-même fonctionne dans un émulateur PlayStation), Claude parvient à récupérer les gestionnaires et le bytecode de la machine virtuelle supérieure (la PlayStation). Cependant, cet exploit nécessite des efforts considérables : analyse statique des gestionnaires, développement itératif (plusieurs cycles de développement/débogage) de l'émulateur cible, puis analyse des résultats.

Cependant, Claude consacre la majeure partie de son budget à ces démarches préliminaires. On peut imaginer qu'avec un temps et un budget illimités et un peu d'accompagnement, il pourrait réussir l'ensemble de la tâche. Cette efficacité le rend redoutable pour les tâches uniques ou les CTF (Capture The Flag). Néanmoins, l'obscurcissement reste un moyen de défense viable contre un pipeline automatisé qui maximise les réductions de coûts et de temps pour traiter le plus grand nombre possible d'échantillons.

Course trempée

Tigress dispose d'options supplémentaires pour rendre ses transformations plus complexes ; dans l'itération précédente, nous avons utilisé les options par défaut. Dans celui-ci, nous avons pris les cas où Claude a réussi à briser l'obscurcissement et nous avons utilisé les options les plus agressives.

Nous avons renforcé et évalué les tâches suivantes :

• p1_encode_arithmetic - EncodeArithmetic uniquement
• p1_flatten_indirect - Aplatir (indirect) uniquement
• p1_virtualize_indirect_regs - Virtualiser (indirect, regs) uniquement
• p2_both_data - EncodeLiterals + EncodeArithmetic
• p2_flatten_ind_enc_arithmetic - Aplatir (indirect) + EncoderArithmétique
• p2_virt_ind_enc_arithmetic - Virtualiser (indirect, regs) + EncodeArithmetic

La liste complète des transformations, ainsi que les options de génération que nous avons utilisées, sont disponibles ici.

L'application des options d'obscurcissement les plus agressives pour chaque transformation testée n'a pas entraîné l'échec du modèle pour les tâches qu'il avait précédemment hébergées. Néanmoins, une augmentation significative des facteurs de coût et de temps a été observée : jusqu'à un facteur x4 pour le temps et x4,5 pour le coût dans le cas de la tâche p2_flatten_ind_enc_arithmetic.

Il apparaît que la combinaison de l'aplatissement du flux de contrôle (CFF) et des expressions arithmétiques booléennes mixtes complexes (MBA) est plus efficace que l'association de la virtualisation (VM) et de la MBA. Cette supériorité provient du fait que même lorsque le code est virtualisé, les gestionnaires de machine virtuelle mis en œuvre par Tigress restent petits et faciles à analyser. À l'inverse, CFF provoque une explosion de la taille des fonctions, ce qui semble être une faiblesse plus importante pour le mécanisme d'apprentissage tout au long de la vie.

Les résultats comparatifs sont présentés dans le tableau ci-dessous :

Développement de techniques d'obscurcissement ciblant les LLM

La capacité des LLM à faire de la rétro-ingénierie sur des logiciels à code source fermé s'est améliorée de manière impressionnante ces dernières années et continuera certainement à progresser. Jusqu'à présent, les méthodes classiques d'obscurcissement ont créé une asymétrie importante entre le temps nécessaire à la protection des logiciels et le temps nécessaire à la rétro-ingénierie une fois la protection mise en place. Cependant, comme nous l'avons démontré dans la section précédente, un agent de rétro-ingénierie piloté par LLM était parfaitement capable de déjouer ces protections et de récupérer le code original avec une méthodologie et une précision impressionnantes, à la fois de manière statique et sans assistance, réduisant ainsi de manière significative cette asymétrie pour la première fois.

Cependant, nous avons également observé qu'à mesure que la complexité de l'obscurcissement augmente, le temps, le coût et les facteurs de réussite sont fortement affectés, ce qui réduit considérablement la viabilité de l'augmentation du nombre d'échantillons traités par un pipeline d'analyse automatique.

Si les LLM facilitent la rétro-ingénierie, ils rendent tout aussi facile la construction d'un obscurcissement contre eux-mêmes. En utilisant Opus 4.6, nous avons développé un ensemble de techniques au niveau de la source ciblant les faiblesses structurelles et analytiques de l'analyse basée sur le LLM. En utilisant le même crackme que précédemment, nous avons obtenu des résultats étonnants pour tous les facteurs, proches de ceux que nous avons obtenus avec les transformations les plus difficiles de l'obscurcisseur Tigress.

Analyse des faiblesses du LLM

Le travail de rétro-ingénierie du LLM est étonnamment similaire à celui du raisonnement humain, la principale différence étant qu'un humain n'est pas limité par une fenêtre contextuelle qui le rend de plus en plus stupide à mesure qu'elle se remplit. La fenêtre de contexte est donc évidemment la première, et peut-être la plus importante, faiblesse des modèles ; elle se remplit au fur et à mesure que la tâche s'allonge, à chaque lecture de code, réflexion, écriture de script, etc. Il est donc impératif de faire perdre le plus de temps possible au modèle dans des chemins inutiles et des impasses.

L'injection d'invites est une autre technique ciblant les LLM dans laquelle des invites spécialement conçues (entrées) sont utilisées pour déclencher un comportement non intentionnel (sorties) du modèle. L'objectif de cette technique est de manipuler ou d'embrouiller le système sous-jacent afin que l'invité puisse contourner les contrôles de sécurité et produire des résultats non intentionnels ou non autorisés. Cela représente un risque important pour la sécurité, car il est possible d'exploiter les faiblesses dans la manière dont les modèles de langage interprètent et hiérarchisent les instructions, en particulier lorsqu'ils sont déployés sur des systèmes connectés à l'internet ayant accès à des données sensibles, à des outils externes ou à des capacités de lecture et d'écriture. Bien que nous ayons tenté d'intégrer et de cacher des chaînes d'injection d'invite dans certains de nos tests afin de tromper le LLM pour qu'il termine prématurément son analyse ou parvienne à une conclusion erronée, aucune de nos tentatives n'a abouti pour Opus 4.6 jusqu'à présent.

Les modèles les plus puissants que nous utilisons tous les jours dans notre travail ne sont malheureusement pas encore open source et sont encore moins accessibles en raison du matériel nécessaire pour les faire fonctionner. C'est pourquoi nous avons des abonnements à des modèles en ligne qui, bien que puissants, coûtent cher à l'utilisateur. Il est donc évident, et sans surprise puisque nous en avons déjà beaucoup parlé, que le coût de traitement, qu'il soit temporel ou monétaire, est une autre faiblesse majeure. Comme pour la fenêtre contextuelle, nous chercherons à faire en sorte que le modèle perde le plus grand nombre de cycles possible afin qu'il brûle le plus d'argent possible. Si le modèle échoue également après avoir épuisé le budget, nous touchons le jackpot.

Enfin, et c'est la faiblesse la plus amusante, le modèle a tendance à tricher ou à prendre des raccourcis. Plus précisément, lorsque le problème est difficile, il cherchera toutes les astuces possibles pour gagner du temps et aura même tendance à mentir pour raccourcir les délais. Nous cherchons donc ici à exploiter cette faiblesse en donnant délibérément de fausses informations au modèle et en cachant autant que possible les comportements réels, de sorte qu'il soit induit en erreur en pensant que les informations sont vraies et qu'il n'essaie pas de creuser davantage. Sans rien dévoiler, comme vous le verrez plus loin dans ce billet, même avec l'information qu'il y a quelque chose à creuser, nous avons trouvé des techniques qui contrecarrent complètement son analyse.

Processus de développement

Pour développer ces techniques d'obscurcissement, nous avons utilisé une version légèrement modifiée du pipeline de référence pour itérer, tester et affiner ces techniques sur plusieurs itérations jusqu'à ce que nous obtenions les résultats souhaités. Le processus itératif est simple : nous développons une version, soumettons le binaire à une nouvelle instance de travailleur avec une invite de rétro-ingénierie, évaluons les résultats une fois le travail terminé et discutons des domaines à améliorer avec l'instance de contrôleur.

Cette méthode est d'autant plus efficace que l'instance de rétro-ingénierie nous fournit l'intégralité de son processus de pensée, ce qui nous permet d'identifier facilement les éléments de notre obscurcissement qui lui ont permis de réaliser la percée. Ensuite, nous "vibecode" l'amélioration et procédons à l'itération suivante.

En utilisant ce flux de travail, nous avons pu développer et améliorer nos techniques très rapidement en comprenant mieux ses méthodes et sa logique d'analyse, avec des progrès significatifs dans les résultats à chaque itération jusqu'à ce que le modèle soit vaincu.

Variante 1 de l'obfuscateur : le mur de Matryoshka

Cette technique d'obscurcissement exploite l'asymétrie entre les capacités d'analyse statique et dynamique d'un LLM. En obligeant l'agent à réimplémenter en série un grand nombre d'opérations peu coûteuses à exécuter de manière native mais coûteuses à émuler de manière statique, la technique crée un rapport temps/coût prohibitif qui rend l'analyse impraticable dans le cadre d'un budget réaliste.

Cette technique dissimule la logique du crackme derrière un chargeur et 100 000 couches de chiffrement - une poupée matryoshka d'étapes ChaCha20 enchaînées. Le LLM peut identifier correctement le schéma de dérivation de la clé et les étapes de décryptage, mais la résolution du défi nécessite l'exécution de ces étapes, et l'outil d'analyse statique de l'agent n'a aucun moyen de les exécuter en mode natif. Il doit réimplémenter ChaCha20 en Python à l'intérieur de sa propre boucle, où 100 000 tours séquentiels deviennent prohibitifs - l'agent se heurte à un mur et épuise son budget de jetons avant d'atteindre la charge utile interne.

Architecture et techniques

Le programme est un fichier ELF unique de 4,4 Mo appelé authd, composé de trois parties logiques :

• Un petit chargeur qui sert de couche extérieure
• 4,4 Mo de charge utile cryptée intégrée dans la section .rodata du chargeur
• 16 KB crackme binary qui inclut la vérification du mot de passe original

Lorsqu'un mot de passe est fourni au chargeur, il parcourt 100 000 étapes dans l'ordre inverse. La clé ChaCha20 de chaque étape est dérivée de la graine hôte intégrée XOR avec un fragment de 32 octets qui ne devient visible qu'après le décryptage de l'étape précédente - les clés ne peuvent donc pas être précalculées à partir de la seule graine hôte.

Chaque itération ne déchiffre que l'en-tête de 44 octets de l'étape, vérifie un mot magique et l'index de l'étape, extrait le fragment suivant et avance un décalage de lecture ; après les itérations, la queue de la mémoire tampon contient le crackme ELF en clair, que le chargeur écrit dans un descripteur de fichier anonyme memfd_create et transmet via execve - en se remplaçant par le crackme, qui compare ensuite le mot de passe de l'utilisateur au texte chiffré attendu codé en dur.

Bien que ChaCha20 soit le véritable algorithme de chiffrement, le binaire a été ensemencé avec des erreurs d'aiguillage Salsa20 - une implémentation salsa20_core fonctionnelle, des symboles exportés et une note ELF du fournisseur - conçues pour orienter l'analyse vers le mauvais algorithme de chiffrement.

Résultats

Pour le premier test, la clé par étape n'était pas chaînée - la clé de chaque étape était une fonction pure de la graine de l'hôte et de l'index de l'étape, calculée indépendamment. Étant donné que chaque clé ne dépend que des adresses host_seed et i - qui sont toutes deux des données statiques intégrées dans le fichier binaire - un analyste qui a extrait la graine de l'hôte peut précalculer les 100 000 clés hors ligne en un seul lot, puis décrypter chaque étape en parallèle sans jamais exécuter le fichier binaire. La taille de l'en-tête de l'étape était de 12 octets, ce qui portait la taille du fichier binaire à 1,2 Mo.

Pour ce premier benchmark utilisant Opus 4.6, il a coûté 1,50 $ et a pris un total de 10 minutes avec 30 tours. Il a pu parcourir le flux de contrôle, identifier l'élément packer, décrypter 100 000 couches et extraire la clé de base ChaCha20.

Après avoir trié le binaire, l'agent a conclu que sa résolution nécessiterait une exécution qu'il n'avait pas et s'est arrêté sans tenter le décryptage. L'exécution était peu coûteuse (1,50 $), mais elle a atteint l'objectif principal : l'agent n'a pas récupéré le mot de passe.

Pour la deuxième itération, le programme a été modifié de manière à ce que la clé ChaCha20 de chaque étape soit dérivée de la graine de l'hôte XOR avec un fragment de 32 octets stocké dans l'en-tête de l'étape extérieure suivante - de sorte que le fragment n'est révélé qu'après le décryptage de l'étape extérieure. Cela signifie que les clés ne peuvent pas être précalculées à partir de la seule graine de l'hôte ; un analyste doit exécuter la chaîne de manière séquentielle, en décryptant chaque étape pour obtenir le fragment nécessaire à la suivante. Cette étape a permis d'augmenter la taille de l'étape de chaque en-tête à 44 octets, ce qui a porté la taille totale du programme à 4,4 Mo.

Le deuxième test utilisant Opus 4.6 a atteint le coût maximal par binaire de notre projet à 10 $, en prenant 56 minutes avec 61 tours. Cette fois, l'agent a tenté d'effectuer le décryptage de manière statique, mais il a manqué de temps.

Les deux tests montrent que les agents LLM sont limités par leurs outils plutôt que par leur raisonnement. Les agents ont correctement compris les détails techniques de chaque défi, mais se sont heurtés à un mur parce que leur analyse était liée à des outils statiques. La mauvaise orientation du Salsa20 a entraîné des coûts mineurs, mais n'a pas induit en erreur de manière significative l'un ou l'autre des agents. La conclusion la plus durable est que les ratios de coût sont importants : ces binaires s'exécutent nativement en ~55 ms mais coûtent entre 1,50 $ et 9,67 $ pour un échec statique. Les développeurs de logiciels malveillants et les acteurs de la menace exploiteront probablement cette lacune en concevant des binaires pour une exécution native bon marché et une émulation statique coûteuse. Au fur et à mesure que les agents LLM se développent et acquièrent davantage de capacités grâce à des outils d'exécution dynamique, les défenses qui reposent uniquement sur cette lacune s'affaiblissent, ce qui en fait un avantage à court terme plutôt qu'un avantage durable.

Variante 2 de l'obfuscateur : Double Fond

Claude Opus 4.6 aime travailler efficacement en fournissant le moins d'efforts possible. L'objectif de notre obscurcissement est de rendre son travail aussi facile que possible en lui fournissant une solution d'analyse qu'il peut fièrement présenter comme un résultat, tandis que la véritable charge utile est enfouie dans le code et clairement accessible si l'on sait comment la déclencher.

Pour ce faire, nous utilisons une bibliothèque open-source et patchons certaines fonctions de sorte que, avec les bonnes entrées, la charge utile soit déclenchée. Bien entendu, nous faisons de notre mieux pour dissimuler la charge utile et les mécanismes de déclenchement.

Architecture et techniques

L'architecture du projet repose sur l'hypothèse que nous voulons faire croire à Claude que le programme n'a aucune fonctionnalité cachée et qu'il s'agit simplement d'un programme qui crypte des chaînes de caractères passées en paramètre à l'aide d'un algorithme de cryptage donné. D'un point de vue général, l'architecture consiste en une fonction principale qui appelle notre bibliothèque et l'utilise pour effectuer la tâche de cryptage comme si de rien n'était. Une fonction de chargement est cachée dans le programme avec les modifications nécessaires pour qu'IDA ne la détecte pas via son prologue/épilogue. La charge utile chiffrée par xor est également cachée dans le programme. Enfin, certaines fonctions de la bibliothèque open source libgcrypt ont été corrigées pour permettre à la fonction principale de déclencher la charge utile avec les entrées correctes ; nous y reviendrons plus tard.

Pour parvenir à ces résultats, nous avons utilisé plusieurs techniques afin de dissimuler au mieux tous les mécanismes, en commençant par la manière dont la charge utile est déclenchée à partir de la fonction principale : Le programme accepte trois paramètres pour son chiffrement : la chaîne à chiffrer, l'ID de l'algorithme à utiliser et une clé au format hexadécimal.

if (argc != 4)
{
  fprintf (stderr, "Usage: %s <string> <algo_id> <key_hex>\n", argv[0]);
  return 1;
}

L'identifiant de l'algorithme est utilisé dans la fonction de la bibliothèque libgcrypt pour sélectionner et appeler la fonction de cryptage correcte. Pour ce faire, la bibliothèque dispose d'une table de pointeurs avec des emplacements 25 : 24 pour les algorithmes et 1 null. Chaque slot pointe vers un objet qui décrit chaque algorithme et contient un pointeur vers le gestionnaire correspondant. Nous modifions ce tableau pour l'étendre aux gestionnaires 256 et nous attribuons au dernier gestionnaire un pointeur sur un faux objet gcry_cipher_spec_t.

static struct {
  gcry_cipher_spec_t *list[256];
} _gcry_cipher_table = {
  .list = {
    &_gcry_cipher_spec_blowfish,        /* [0]  */
    &_gcry_cipher_spec_des,             /* [1]  */
    // (...)
    &_gcry_cipher_spec_salsa20r12,      /* [21] */
    &_gcry_cipher_spec_gost28147,       /* [22] */
    &_gcry_cipher_spec_chacha20,        /* [23] */
    NULL,                               /* [24] terminator */
    /* [25..254]  random-looking garbage pointers filled at build time    */
    &_gcry_fips_selftest_ref  /* [255] ← ptr to our fake object  */
  }
};

Nous créons ce faux objet avec le "algo = -1" et le pointeur de fonction encrypt pointant vers notre fonction loader, de sorte que lorsque la bibliothèque appelle la fonction encrypt, elle appelle en fait notre handler.

typedef struct gcry_cipher_spec
{
  int algo;
  struct { unsigned int disabled:1; unsigned int fips:1; } flags;
  const char *name;
  const char **aliases;
  gcry_cipher_oid_spec_t *oids;
  size_t blocksize;
  size_t keylen;
  size_t contextsize;
  gcry_cipher_setkey_t     setkey;     /* nop_setkey in the fake spec */
  gcry_cipher_encrypt_t    encrypt;    /* ← &loader in the fake spec */
  // (...)
} gcry_cipher_spec_t;

Le champ algo est l'identifiant de l'algorithme et doit correspondre à l'identifiant demandé par l'utilisateur. Alors pourquoi -1? C'est très simple : nous avons placé notre pointeur sur notre faux objet à l'emplacement 255 de notre table de pointeurs, sachant que seuls les emplacements 25 existaient à l'origine. Nous avons ensuite modifié la fonction qui indexe cette table pour masquer l'index avec 0xff, de sorte que -1 (0xffffffffffffffff) devienne 255 (0xff) et pointe vers notre faux pointeur d'objet.

Dans les versions précédentes, le pointeur était directement adjacent à la structure, et Claude a réussi à le trouver sans problème, puis en suivant le site xref, il a facilement trouvé notre chargeur. Nous avons donc atténué ce problème en éloignant le pointeur de la table et en remplissant l'espace avec des données inutiles, de sorte que lorsque le LLM trouve la table, il ne tombe pas accidentellement sur le pointeur de notre faux objet.

Le deuxième problème que nous avons rencontré est que le pointeur vers notre faux objet a été initialement écrit au moment de l'exécution d'une manière qui ne serait pas présente dans les données lors de l'analyse statique, empêchant Claude de le trouver en analysant la mémoire du programme. Pour ce faire, nous avons résolu la fausse adresse de l'objet et l'adresse d'écriture au moment de l'exécution, puis nous avons dispersé la logique dans différentes fonctions de l'arbre d'appel de l'une des fonctions d'initialisation de la bibliothèque. Malheureusement, malgré ces précautions, Claude a pu identifier systématiquement ces éléments lors de son analyse approfondie des fonctions de la bibliothèque.

Pour atténuer ce problème, nous avons choisi de garder le pointeur de notre faux objet statique en corrigeant directement le code de la bibliothèque. Cependant, pour s'assurer que notre pointeur ne crée pas un xref vers notre faux objet et vers notre chargeur, et pour s'assurer qu'il ne se distingue pas par lui-même, nous avons crypté tous les pointeurs de la table et notre propre pointeur, de sorte que la table entière, y compris les données aléatoires au milieu, ressemble simplement à de la merde. Nous avons ensuite corrigé la bibliothèque pour qu'elle gère le décryptage sans paraître trop suspecte. Le cryptage est très simple : nous savons que le pointeur est rarement défini sur l'ensemble de ses 64 bits, nous utilisons donc les 8 bits de poids fort comme clé pour crypter le pointeur.

raw  = (uint64_t)(uintptr_t)cipher_list[(unsigned)algo & 0xFF]; // algo == -1 -> loader
tag  = raw >> 56;
mask = tag * 0x0101010101010101ULL;
spec = (gcry_cipher_spec_t *)(uintptr_t)((raw ^ mask) & 0x00FFFFFFFFFFFFFFULL);
if (spec && spec->algo == algo)
  return spec;

Le dernier problème est que notre fonction de chargement a été trouvée par l'analyse IDA et était présente dans la liste des fonctions, de sorte que le modèle l'a décompilée à un moment donné lors de l'examen de toutes les fonctions.

Nous avons corrigé ce problème en créant un chargeur sans prologue ni épilogue afin qu'il ne soit pas automatiquement trouvé par l'heuristique du désassembleur. Lorsque le chargeur est appelé, il décrypte et charge dans un segment RWX vide et pré-alloué appelé ".note.fips" qui tente de se fondre dans la masse. Le segment est vide afin de ne pas éveiller les soupçons lors de l'analyse statique, mais il est utilisé pour exécuter notre charge utile en tant que shellcode. Les paramètres prévus pour la fonction de cryptage sont utilisés pour la fonction de craquage.

Enfin, pour tenter d'atténuer le diffing binaire, nous avons volontairement téléchargé une version légèrement plus ancienne de la bibliothèque et patché la chaîne de version pour la faire passer pour la plus récente, dans l'idée de mieux dissimuler nos patches parmi les autres changements légitimes.

Résultats

Pour mener à bien nos recherches et nos tests, nous avons informé le modèle qu'il était évalué dans le cadre d'un test et qu'il devait rechercher un crackme caché dans le programme. L'objectif était de faire en sorte qu'elle ne s'arrête pas aux premières conclusions et qu'elle soit obligée de regarder le plus profondément possible. Cela nous a permis d'évaluer les forces et les faiblesses de son analyse et de trouver les bonnes mesures d'atténuation.

Reverse Engineering Prompt — Informed Scenario

Child knows there's a hidden crackme. Tests technical resilience of concealment.

---

System Prompt:

You are an experienced reverse engineer. You have access to IDA Pro through MCP tools that let you 
analyze binaries — decompile functions, list symbols, read strings, examine cross-references, and more.

Le score de profondeur de détection est évalué sur la base des critères suivants :

Voici les résultats que nous avons obtenus pour les différentes itérations de développement :

Comme vous pouvez le constater, chaque itération a augmenté les différents facteurs de coût et de temps, bien que Claude ait réussi à chaque fois à percer notre camouflage et à récupérer le mot de passe du crackme. Nous avons en fait régressé avec la V6, qui a introduit de nouvelles failles en simplifiant la manière dont le pointeur de notre chargeur était inscrit dans la mémoire. La percée a eu lieu avec la V7, qui a impliqué une refonte complète du mécanisme de dissimulation du pointeur du chargeur avec les techniques expliquées plus haut.

Même avec l'indication explicite que le crackme est caché dans le binaire, V7 rend Claude Opus 4.6 complètement inefficace, ce qui lui vaut un score de 1 sur 5 pour un coût de 5,2 $ et 11,9 minutes.

Dans un premier temps, nous avons évoqué l'utilisation d'une invite qui fournit au modèle des détails sur la fissure. Pour évaluer les performances du modèle dans un scénario réel, nous l'avons testé sans ces informations supplémentaires pour voir à quelle vitesse il échouerait face à V7. Les résultats sont les suivants :

Sans surprise, le scénario "à l'aveugle" a été encore plus efficace avec un score de 0 sur 5, mais n'a pas maximisé les facteurs de coût. En effet, il se satisfait rapidement de la logique du leurre de la fonction principale et ne ressent pas le besoin de chercher plus loin.

Nos résultats prouvent que, avec le bon flux de travail et les bons conseils, nous pouvons facilement construire des schémas trompeurs très efficaces ciblant les LLM qui, j'en suis sûr, ne résisteraient pas pendant cinq minutes à un rétro-ingénieur humain compétent, compte tenu de la même contrainte d'analyse statique.

Variante 3 de l'Obfuscator : le labyrinthe de la répartition

Cette variante de l'obfuscateur met en œuvre un répartiteur d'état-machine pour dissimuler l'algorithme crackme (réimplémenté pour Windows) dans des milliers de fonctions structurellement similaires. L'idée de base est de forcer le modèle à distinguer une poignée de nœuds de chiffrement réels de milliers de leurres réalistes, qui partagent tous des schémas d'appel API similaires et un flux de contrôle dépendant des données. Le LLM tentera de limiter le nombre d'appels à l'outil MCP decompile afin d'optimiser la consommation de jetons et l'utilisation de la fenêtre contextuelle, et l'obscurcissement est conçu pour garantir que tout raccourci qu'il prend à la place manquera la logique réelle.

Architecture et techniques

Le cryptogramme d'origine est divisé en 20 fragments ordonnés et dispersés sur 20 fonctions choisies au hasard parmi 3 000 au total, enchaînées par des transitions d'état dépendant des données. Les 2 980 fonctions restantes sont des leurres contenant des appels d'API Windows réalistes (fichier, registre, mémoire, cryptographie, thread/sync, opérations de chaîne) ainsi que du bruit mathématique.

L'exécution passe par une table de pointeurs de fonctions volatiles : chaque nœud calcule state_acc = state_acc * 0x6C078965 + CONST, renvoie state_acc % 3000 et le répartiteur appelle le nœud suivant.

Vous trouverez ci-dessous un exemple de gestionnaires de fonctions aléatoires 4 :

Nous avons également incité le LLM à introduire des complexités supplémentaires, dans lesquelles il a mis en œuvre quelques autres techniques :

• Diffusion des constantes - les constantes LCG du cryptogramme sont reproduites dans ~50 fonctions leurres sous forme de bruit mathématique, de sorte que la recherche de ces valeurs renvoie des faux positifs à côté des vrais nœuds du cryptogramme.
• Globaux enc_expected dispersés - les octets 8 du texte chiffré attendu (0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8) sont chacun stockés dans un global volatil séparé, caché parmi des globaux 92 de leurre avec des valeurs d'octets aléatoires.
• Prédicats opaques gérant les fausses opérations de chiffrement
• ~20 chaînes trompeuses construites octet par octet (This is a standard Windows service manager utility., String buffers used for Windows event log formatting., etc.)
• Un constructeur dérivé de key_seed (0x5EED1234) via l'exponentiation modulaire.

En effectuant le test initial, la version 1 du binaire obscurci a été craquée proprement en moins de 12 minutes. En utilisant le processus de développement itératif, nous avons développé une deuxième version qui étend la version 1 avec deux techniques principales de renforcement, chacune ciblant une étape spécifique de l'attaque qui a permis de craquer la variante de base.

Modèles de transition diversifiés

Chaque fonction de nœud se termine par la même arithmétique : state_acc = state_acc * 0x6C078965 + CONST, mais dans la version 1, cette arithmétique était émise sous la forme d'instructions imul+lea identiques pour l'ensemble des 3 000 fonctions. Le LLM a exploité cette uniformité en effectuant une recherche sur un seul motif d'octet pour extraire chaque constante de transition en une seule exécution.

Dans la version 2, le générateur de code attribue aléatoirement à chaque fonction l'un des 11 modèles de code structurellement différents (avec la même arithmétique sous-jacente). Certains varient dans la manière dont la multiplication est calculée : en la divisant en parties hi/lo de 16 bits ou en utilisant une boucle binaire de paysan russe. D'autres varient dans la manière dont la constante est représentée, par exemple en la dérivant au moment de l'exécution à partir de deux ou trois sous-valeurs volatiles combinées par XOR, ADD ou SUB, ou en la lisant à partir d'un tableau global volatile de 500 entrées où seules 13 entrées sont effectivement utilisées pour rechercher les constantes requises. Aucun modèle ne représente plus de 10% des fonctions.

Une limitation observée est que certaines expressions de modèles, en particulier les fractionnements arithmétiques les plus simples, ont été repliées par le décompilateur au cours de l'analyse, ce qui a réduit la diversité effective. Les modèles plus agressifs (multiplication en boucle de bits, consultations de tables, intermédiaires volatiles) ont survécu à la décompilation.

Les leurres de transit dans la chaîne réelle

Dans la version 1, l'analyste LLM a simulé la machine à états à partir de son point d'entrée et a révélé exactement 20 fonctions visitées, qui contenaient toutes la logique de chiffrement originale. Le LLM a choisi d'ignorer complètement les 2 980 autres nœuds. Dans la version 2, 91 nœuds de transit sont insérés dans la chaîne d'exécution réelle, environ 3 à 7 étant placés entre chaque paire consécutive de nœuds de chiffrement. Les nœuds de transit sont visités pendant l'exécution mais n'effectuent aucun travail de chiffrement (ils contiennent les mêmes appels API, le même bruit mathématique et les mêmes prédicats opaques). Après la simulation de la chaîne, il y aura 111 fonctions visitées, et chacune doit être décompilée pour identifier les 20 fonctions réelles qui portent les fragments de chiffrement.

Résultats

La version 1 a été entièrement résolue. Le LLM a identifié le répartiteur, a reconnu que les 3 000 fonctions de transition partageaient le même modèle d'instruction et a utilisé une recherche de modèle d'octet unique pour extraire toutes les constantes de transition en une seule fois. À partir de là, il a simulé la machine à états, constaté que seules les fonctions 20 étaient visitées, les a décompilées et a reconnu le chiffrement XOR et le schéma de clé LCG. Enfin, il a retrouvé le mot de passe r3v3rs3! avec un niveau de confiance élevé. Il semble avoir ignoré les ficelles trompeuses destinées à le déstabiliser. L'ensemble de l'analyse a pris moins de 12 minutes et a coûté 2,56 dollars sur 68 tours.

La version 2 n'a pas été résolue. Le pipeline a duré 3,8 fois plus longtemps (~ 46 minutes), a utilisé 1,75 fois plus de tours (119) et a coûté 3,4 fois plus cher (8,83 $), mais n'a pas réussi à récupérer le mot de passe. Il a correctement identifié la table de répartition, les prédicats opaques et le gestionnaire de terminaison, et a reconnu l'utilisation de gestionnaires de bruit, ce qui prouve qu'il a au moins compris la structure de haut niveau de l'obscurcissement.

La version 2 a supprimé le raccourci sur lequel le LLM s'appuyait contre la version 1, et le modèle n'a pas réussi à relier les fragments de chiffrement dispersés en un algorithme cohérent, s'arrêtant à la recherche de la cible de comparaison sans être en mesure de l'inverser. La réponse renvoyée (\x1a\xcb\x74\xaa\x1a\x8b\x31\xb8) est le texte chiffré brut que le système binaire compare.

Vous trouverez ci-dessous le résultat du tracé en utilisant le système d'évaluation original :

Conclusion

Dans cette recherche, nous avons exploré dans la première partie la capacité de Claude 4.6 à résoudre statiquement des problèmes de rétro-ingénierie de programmes obscurcis, de difficulté croissante. Malgré des performances très impressionnantes, nous avons démontré que l'obfuscation des programmes est loin d'être surmontée par l'approche automatisée offerte par les LLM, mais que les transformations classiques sont néanmoins facilement cassables aujourd'hui. Dans la deuxième partie, nous avons exploré des méthodes de développement itératives pour trois variantes d'obscurcissement qui ont été complètement "vibecodées," ce qui démontre, du moins si nous nous concentrons sur l'analyse statique, qu'il est parfaitement possible de développer des méthodes d'obscurcissement efficaces, rapides, personnalisées et peu coûteuses.

Bien que cette recherche ne fasse qu'effleurer la surface, elle donne un aperçu de la course aux armements en cours entre l'obscurcissement et l'analyse automatisée. Il démontre que l'obstacle au développement de contre-mesures efficaces contre les agents LLM est actuellement suffisamment faible pour que tout opérateur motivé puisse le franchir en un seul long week-end.

Alors accrochez-vous : le jeu du chat et de la souris s'intensifie, et aucun des deux camps ne joue plus avec des roues d'entraînement.