🤖 AI

Poisoned Identifiers Survive LLM Deobfuscation: A Case Study on Claude Opus 4.6

Cette étude démontre que Claude Opus 4.6 conserve systématiquement des identifiants « empoisonnés » lors de la déobfuscation de code JavaScript, même lorsqu'il comprend correctement la sémantique, mais que le taux de persistance chute drastiquement lorsque la tâche est reformulée comme une réécriture complète plutôt que comme une déobfuscation.

Auteurs originaux : Luis Guzmán Lorenzo

Publié 2026-04-07

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Luis Guzmán Lorenzo

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

🕵️‍♂️ Le Scénario : Le Détective et le Traducteur Brouillon

Imaginez que vous avez un livre de recettes de cuisine très complexe, mais qui a été codé (chiffré) pour que personne ne puisse le lire facilement. C'est ce qu'on appelle de l'obfuscation.

Ensuite, vous engagez un super traducteur (l'IA, ici "Claude Opus") pour qu'il déchiffre ce livre et vous rende une version claire et lisible.

Le problème ? Avant de le coder, quelqu'un a joué un tour : il a remplacé les vrais noms des ingrédients par des noms faux mais qui sonnent bien.

Au lieu de dire "Sucre", le livre codé dit "Explosif".
Au lieu de dire "Farine", il dit "Bombe".

La question de la recherche est simple : Quand le traducteur (l'IA) déchiffre le livre, va-t-il se rendre compte que les noms sont faux et les corriger, ou va-t-il répéter bêtement les faux noms ?

🧪 Ce que les chercheurs ont découvert

Les chercheurs ont testé cela avec deux types de "livres" (du code informatique) et ont observé trois phénomènes fascinants :

1. Le problème du "Traducteur Trop Fiable"

Même si le traducteur comprend parfaitement la recette (il sait que "Explosif" sert en fait à faire du sucre), il a tendance à garder le faux nom dans le texte final.

Le résultat étrange : Dans le code qu'il écrit, il met le mot "Explosif" (le faux nom), mais juste à côté, dans ses commentaires, il écrit : "Ceci est du sucre".
L'analogie : C'est comme si un traducteur écrivait : "Mettez 500g d'Explosif (qui est en fait du sucre)". Il sait la vérité, mais il ne change pas le mot dans la recette elle-même.

2. Les ordres explicites ne fonctionnent pas

Les chercheurs ont essayé de dire au traducteur : "Attention ! Vérifie bien chaque mot, assure-toi qu'il correspond à la recette !".

Résultat : Ça ne marche pas du tout. Le traducteur continue de mettre les faux noms, même s'il vous promet de vérifier. C'est comme essayer de convaincre quelqu'un de ne pas regarder un panneau "Interdit" en lui disant "S'il te plaît, ne le regarde pas".

3. Le secret : Changer la mission (Le "Reframing")

C'est ici que ça devient intéressant. Au lieu de dire "Décode ce livre pour moi" (mission de traduction), les chercheurs ont dit : "Écris une nouvelle recette de zéro, en te basant sur ce que tu as compris".

Résultat : Magie ! Le traducteur arrête de copier les faux noms. Il utilise les vrais mots ("Sucre", "Farine").
Pourquoi ? Quand on lui demande de traduire, il se sent obligé de respecter le texte original (même les erreurs). Quand on lui demande de créer, il utilise sa propre intelligence pour trouver les bons mots.

🧩 Les Analogies Clés

L'Effet "Traduction" vs "Création" :
Imaginez un photocopieur. Si vous lui demandez de copier un document taché d'encre rouge, il va copier les taches rouges (même si vous lui dites "efface les taches"). Mais si vous lui demandez de redessiner le document à la main en vous basant sur le sens, il dessinera les lignes propres. L'IA agit comme le photocopieur quand on lui demande de "décode", mais comme l'artiste quand on lui demande de "réécrire".
Le "Domaine Incohérent" :
Les chercheurs ont aussi testé des noms totalement absurdes (remplacer "Sucre" par "Pneus de voiture").
- Si le livre entier semble provenir d'un autre monde cohérent (ex: tout le livre parle de mécanique), l'IA peut parfois comprendre et changer les mots.
- Mais si les noms sont juste un mélange bizarre (Sucre = Pneus, Farine = Batterie), l'IA ne sait pas quel "monde" choisir, alors elle garde les mots bizarres par défaut. C'est comme si elle disait : "Je ne sais pas si c'est une blague ou une erreur, alors je garde le texte tel quel."

💡 Pourquoi est-ce important ?

Ce n'est pas une protection magique : Si quelqu'un essaie de cacher un virus dans du code en changeant les noms, l'IA peut le voir, mais elle risque de garder le nom du virus dans le code qu'elle vous rend, même si elle vous dit "Attention, c'est un virus".
Le coût de l'analyse : Pour nettoyer ce code, il faut passer plus de temps et d'argent (plus de "tokens" pour l'IA).
La solution simple : Si vous utilisez une IA pour analyser du code suspect, ne lui dites pas "Décode ça". Dites-lui : "Réécris ce code de zéro en utilisant les bons noms". C'est beaucoup plus efficace pour éliminer les pièges cachés.

En résumé

Cette étude nous apprend que les IA sont parfois trop fidèles à la source. Si on leur demande de traduire du code obscurci, elles copient les erreurs. Si on leur demande de créer du nouveau code basé sur la logique, elles corrigent les erreurs toutes seules. Le secret n'est pas dans la vérification, mais dans la façon dont on pose la question.

Titre : Identifiers empoisonnés survivent à la déobfuscation par les LLM : Étude de cas sur Claude Opus 4.6

1. Problématique

L'article examine un phénomène critique dans l'analyse de code assistée par les grands modèles de langage (LLM) : la persistance d'identifiants « empoisonnés » (noms de variables malveillants ou sémantiquement incorrects) lors de la déobfuscation de code JavaScript.

Le problème central est le suivant : même lorsque le modèle comprend parfaitement la sémantique du code (les opérations mathématiques, la logique algorithmique), il tend à reproduire les noms de variables erronés présents dans la table de chaînes décodée (string table) du code obfusqué.

Le paradoxe observé : Le modèle peut générer des commentaires corrects décrivant l'opération réelle (ex: « force de répulsion ») tout en utilisant le mauvais nom de variable dans le code généré (ex: attraction au lieu de repulsion).
L'échec des instructions explicites : Les auteurs ont constaté que demander explicitement au modèle de « vérifier que chaque nom correspond aux mathématiques » ne suffit pas à corriger cette erreur.

2. Méthodologie

L'étude se déroule en deux phases principales sur le modèle Claude Opus 4.6 (avec quelques vérifications sur Haiku 4.5) :

Stimuli (Données d'entrée) :
- Deux archétypes de code : une simulation de graphe à forces dirigées (physique) et un algorithme de recherche de chemin A*.
- Obfuscation : Utilisation de techniques avancées (aplatissement du flux de contrôle, encodage RC4 des chaînes, injection de code mort).
- Empoisonnement : Remplacement des noms de variables sémantiquement corrects par des termes incorrects mais plausibles dans le domaine (ex: repulsion $\rightarrow$ attraction) ou totalement incohérents (ex: repulsion $\rightarrow$ combustion).
Protocole expérimental :
- Phase A (Exploratoire) : 28 runs manuels avec Claude Code CLI (avec outils).
- Phase B (Systématique) : 192 runs automatisés via l'API Anthropic Messages (sans outils), répartis sur 50 conditions différentes.
- Variables testées :
  - Instructions de vérification : Prompts demandant une vérification explicite des noms.
  - Reformulation de la tâche (Framing) : Passage d'une instruction de « déobfuscation » (traduction) à une instruction de « réécriture à partir de zéro » (génération).
  - Contrôles appariés : Tests avec des termes ayant un « zéro ajustement sémantique » (ex: invoice pour un algorithme de chemin) pour isoler l'effet de la cohérence du domaine.
Métriques :
- Persistance de l'identifiant empoisonné dans les blocs de code.
- Présence du motif « dual-representation » (mauvais nom dans le code + bonne description dans les commentaires).
- Taux de refus (refus d'exécuter le code).

3. Contributions Clés et Résultats

A. L'échec des instructions explicites

Dans 12/12 runs, l'ajout d'instructions de vérification (« vérifiez que chaque nom correspond aux mathématiques ») n'a pas empêché la propagation des noms erronés. Le modèle passe plus de temps à réfléchir mais conserve les erreurs.

B. L'effet de la reformulation de la tâche (Task Framing)

C'est la découverte la plus significative. Changer le cadre de la tâche de « déobfuscation » (perçu comme une traduction littérale) à « écrivez une nouvelle implémentation à partir de zéro » réduit drastiquement la propagation :
- Artéfact Physique : La propagation passe de 100 % à 20 %.
- Artéfact Pathfinding : La propagation passe de 100 % à 0 %.
- L'algorithme généré reste structurellement correct (vérifié par des contrôles de cohérence), mais les noms de variables sont corrigés.

C. Persistance des termes sans ajustement sémantique

Contrairement à l'hypothèse initiale selon laquelle seuls les termes « plausibles » seraient conservés, les tests montrent que des termes totalement incohérents (ex: combustion pour une force de répulsion) persistent à la même vitesse que les termes plausibles, à moins que la table de chaînes entière ne forme un domaine cohérent alternatif.
Si le modèle reconnaît un domaine cohérent (ex: tous les termes sont du vocabulaire d'ingénierie), il corrige le code. Si la table est incohérente ou mélangée, il conserve les noms décodés par défaut.

D. Le motif « Dual-Representation »

Dans 15/17 runs sur l'artéfact physique, le modèle a produit un code avec des noms de variables incorrects tout en écrivant des commentaires décrivant correctement l'opération. Cela indique que le modèle possède la connaissance sémantique mais échoue à l'appliquer au niveau de la syntaxe des identifiants dans le cadre de la déobfuscation.

E. Impact sur le refus (Safety)

Le modèle refuse d'analyser le code si des fonctions malveillantes réelles (logique de ransomware, vol de credentials) sont détectées. Cependant, si le code contient uniquement des noms de variables « toxiques » mais une logique bénigne (physique), le modèle ne refuse pas et déobfusque le code, perpétuant les erreurs.

4. Signification et Implications

Coût multiplicateur, pas protection : Cette technique d'empoisonnement ne protège pas le code contre une analyse manuelle ou une analyse approfondie. Elle agit comme un multiplicateur de coût pour les flux de travail assistés par LLM. Elle force l'utilisateur à passer par une étape de « réécriture » (generation frame) pour obtenir un code propre, augmentant ainsi le temps de calcul et les tokens nécessaires.
Limites de la vérification explicite : L'étude démontre que les instructions de sécurité ou de vérification explicites sont insuffisantes pour corriger les biais d'identification dans les tâches de déobfuscation. La manière dont la tâche est cadrée (traduction vs génération) est un facteur déterminant.
Mécanisme sous-jacent (Hypothèse) : Les auteurs suggèrent que lors de la déobfuscation, le modèle traite les noms décodés de la table de chaînes comme une « source de vérité » (texte source) à traduire, plutôt que de les réévaluer sémantiquement. Le changement de cadre vers la génération force le modèle à ignorer cette source et à reconstruire les noms basés sur la structure algorithmique.
Perspectives futures : Il est nécessaire de tester ces phénomènes sur d'autres modèles (GPT-4o, Gemini) et d'explorer des mécanismes de mitigation multi-agents ou l'utilisation de tableaux de chaînes conflictuels pour forcer une résolution explicite.

Conclusion :
L'article révèle une vulnérabilité subtile où les LLM, malgré leur compréhension sémantique, reproduisent des identifiants erronés lors de la déobfuscation, sauf si la tâche est reformulée comme une génération de code ex nihilo. Cela souligne la nécessité de repenser les workflows d'analyse de code pour inclure des étapes de réécriture plutôt que de simples demandes de vérification.