🤖 AI

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

De studie toont aan dat Claude Opus 4.6, ondanks het correct begrijpen van de semantiek van gedecodeerde JavaScript, systematisch vergiftigde identifier-namen behoudt in de gegenereerde code, tenzij de taak wordt herformuleerd van 'deobfuscatie' naar 'een nieuwe implementatie schrijven'.

Oorspronkelijke auteurs: Luis Guzmán Lorenzo

Gepubliceerd 2026-04-07

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Luis Guzmán Lorenzo

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

De Kern van het Onderzoek: "Vergiftigde Namen" in Code

Stel je voor dat een programmeur een stukje computercode schrijft, maar deze code vermomt (verdraait) zodat niemand hem makkelijk kan lezen. Dit heet obfuscatie. Het is alsof je een recept in een vreemde taal schrijft of de ingrediënten met raadselachtige namen noemt.

Vervolgens vraagt men een slimme AI (zoals Claude) om dit recept weer in begrijpelijk Nederlands te vertalen.

Het probleem:
De programmeur heeft in de "geheime lijst" van ingrediënten (de string-tabel) de namen opzettelijk bedorven.

In plaats van "suiker" staat er "zout".
In plaats van "bakken" staat er "vriezen".

De AI leest de code, begrijpt perfect wat er echt moet gebeuren (het is een taartrecept), maar schrijft in het eindresultaat toch de verkeerde namen: "Voeg zout toe en vries het mengsel."

Dit onderzoek van Luis Guzmán Lorenzo (met de titel Poisoned Identifiers) kijkt naar hoe goed deze AI dit kan oplossen.

De Grote Verrassing: De "Vertaal-Val"

De onderzoekers dachten eerst dat ze de AI simpelweg konden dwingen om goed te zijn. Ze gaven de AI de opdracht: "Kijk heel goed naar de wiskunde en zorg dat de namen kloppen!"

Het resultaat: Dit werkte niet. De AI bleef de verkeerde namen gebruiken, zelfs als ze wist dat het fout was.

De Analogie: Het is alsof je een tolk vraagt: "Vertaal dit boek, maar zorg dat je de namen van de personages aanpast aan hun karakter." De tolk leest het verhaal, begrijpt dat de held een moedige man is, maar schrijft in het eindresultaat toch: "De held, genaamd Kobold, liep het bos in." De AI blijft de oorspronkelijke, vergiftigde naam gebruiken omdat die in de "broncode" stond.

De Oplossing: Verander de Opdracht

Toen de onderzoekers de opdracht veranderden, gebeurde er iets wonderlijks. In plaats van te zeggen: "Vertaal deze vergiftigde code," zeiden ze: "Schrijf een nieuw programma dat precies hetzelfde doet, maar gebruik je eigen woorden."

Het resultaat: De AI schreef nu de juiste namen!

De Analogie: Het is alsof je de tolk niet vraagt om het boek te vertalen, maar om het verhaal opnieuw te vertellen vanuit zijn eigen hoofd. Nu zegt de tolk: "De held, genaamd Ridder, liep het bos in." De vergiftigde namen zijn verdwenen.

De les: Hoe je de AI vraagt om een taak te doen (de "frame"), is belangrijker dan hoe streng je haar instrueert om op te letten.

Twee Belangrijke Ontdekkingen

1. De "Dubbele Wereld" (Het Raadsel)

In bijna alle gevallen waar de AI de verkeerde naam in de code zette, schreef ze er direct naast in een commentaar (een notitie voor mensen) de juiste betekenis.

Code: let attraction = 400; (Fout: het is afstoting)
Commentaar: // Dit is de kracht van afstoting. (Goed)

De AI wist het antwoord, maar durfde de vergiftigde naam niet te veranderen in de code zelf. Het was alsof ze dachten: "Ik moet deze naam gebruiken omdat hij in de originele lijst stond, maar ik leg erbij wat hij echt betekent."

2. Het maakt niet uit of de naam "zinnig" is

De onderzoekers dachten eerst: "Misschien gebruikt de AI alleen de verkeerde namen als ze klinken alsof ze bij het onderwerp horen (bijv. 'zout' in een kookrecept)."
Maar ze ontdekten dat de AI zelfs namen overnam die helemaal niets met het onderwerp te maken hadden.

Als je een computerprogramma over vissen vergiftigt met woorden als "brandstof" of "factuur", gebruikt de AI die woorden toch in de code, zolang de lijst maar niet duidelijk een ander thema (zoals een kookboek) vormt.
De AI kijkt niet per woord, maar naar het geheel. Als de lijst van namen niet duidelijk een ander verhaal vertelt, behoudt ze gewoon de originele (vergiftigde) namen.

Waarom is dit belangrijk?

Veiligheid: Hackers kunnen deze techniek gebruiken om schadelijke code te verstoppen. Als een beveiligings-AI de code "ontcijfert" maar de verkeerde namen behoudt, kan de AI denken dat het onschuldig is, terwijl het gevaarlijk is.
Kosten: Om deze code echt veilig te maken, moet een mens (of een heel slim proces) de code opnieuw schrijven. Dit kost veel tijd en geld. Het is een "kostenvermenigvuldiger": het maakt het voor hackers makkelijker om tijd te winnen, maar het blokkeert hen niet volledig.
AI-gedrag: Het laat zien dat AI's soms "slap" zijn in het corrigeren van fouten als ze in een vertaal-modus zitten, maar "slim" als ze in een creatieve modus zitten.

Samenvatting in één zin

Als je een AI vraagt om vergiftigde code te vertalen, blijft ze de vergiftiging gebruiken; als je haar vraagt om het verhaal opnieuw te verzinnen, schrijft ze de waarheid op.

Het onderzoek concludeert dat we niet moeten vertrouwen op simpele instructies ("Kijk goed uit!"), maar dat we de manier waarop we AI's een opdracht geven, fundamenteel moeten veranderen om fouten te voorkomen.

Titel: Vergiftigde Identificatoren Overleven LLM-Deobfuscatie: Een Case Study over Claude Opus 4.6

Auteur: Luis Guzmán Lorenzo
Model: Claude Opus 4.6 (en beperkte checks met Haiku 4.5)
Datum: April 2026

1. Het Probleem

Het paper onderzoekt een specifiek beveiligingsrisico bij het gebruik van Large Language Models (LLM's) voor het deobfusceren van JavaScript-code. Wanneer een LLM geprobeerd wordt om obfusceerde code (waarbij variabele namen en strings zijn versleuteld) te decoderen, kan de string-tabel van de obfuscatie "vergiftigde" (poisoned) identificatoren bevatten.

De kernvraag is: Behoudt het model deze foutieve, maar plausibele namen in de gegenereerde code, zelfs wanneer het model de onderliggende semantiek (de wiskunde of logica) correct begrijpt?

De auteurs tonen aan dat LLM's vaak de decodede identificatoren uit de string-tabel overnemen, zelfs als deze semantisch incorrect zijn (bijvoorbeeld een variabele voor "afstoting" noemen "aantrekking"), terwijl ze tegelijkertijd in commentaarregels de juiste betekenis beschrijven. Dit creëert een "dual-representation" patroon: foutieve variabelen in de code, maar correcte uitleg in commentaar.

2. Methodologie

De studie bestaat uit twee fasen en test twee code-archetypen:

Een kracht-gebaseerde graf-simulatie (physics artifact).
Een A-padvindingsalgoritme* (pathfinding artifact).

Fase A (Exploratief):

Gebruik van de Claude Code CLI met toolgebruik (Bash, bestandslezen).
28 runs met verschillende "pillen" (adversariale stimuli), waaronder verkeerde namen, malware-decoys en numerieke onnauwkeurigheden.
Doel: Hypothesen genereren over hoe het model reageert op verschillende soorten manipulaties.

Fase B (Systematisch & Repliceerbaar):

Gebruik van de Anthropic Messages API (zonder toolgebruik).
192 runs over 50 verschillende condities.
Models: Voornamelijk Claude Opus 4.6 (183 runs), enkele Haiku 4.5 (9 runs).
Scoring: Automatisering op code-blok-niveau om te bepalen of vergiftigde namen in de gegenereerde code voorkomen.
Variabelen: Prompt-varianten (verificatie-instructies), taak-frames ("deobfuscate" vs. "schrijf opnieuw"), en obfuscatie-niveaus.

Belangrijke experimentele controle:
De auteurs gebruikten "matched controls" waarbij ze termen met nul semantische fit gebruikten (bijv. "combustion" voor "repulsion" of "invoice" voor "heuristic"). Dit testte of het model alleen plausibele termen overneemt of dat het overneemt zolang de string-tabel geen coherent alternatief domein vormt.

3. Belangrijkste Resultaten

A. Het falen van expliciete verificatie

Het geven van expliciete instructies om namen te verifiëren ("verifieer of elke naam overeenkomt met de wiskunde") had geen enkel effect.

In 12/12 runs met verschillende verificatie-prompten bleven de vergiftigde namen in de code staan.
Het model besteedde meer tijd aan verificatie, maar corrigeerde de namen niet.

B. Het succes van Taak-herformulering (Framing)

Het veranderen van de taakdefinitie had een drastisch effect:

Frame "Deobfuscate": 100% propagatie van vergiftigde namen.
Frame "Schrijf een nieuwe implementatie vanaf scratch": Propagatie daalde naar 20% (physics) en 0% (pathfinding).
De algoritme-structuur bleef correct, maar de namen werden nu semantisch correct gekozen.
Conclusie: De impliciete "frame" van de taak (vertalen vs. genereren) beïnvloedt de naamkeuze meer dan expliciete instructies.

C. Het "Dual-Representation" Patroon

In 15/17 runs (physics artifact) produceerde het model een tegenstrijdigheid:

Code: Verkeerde variabelenamen (bijv. attraction in plaats van repulsion).
Commentaar: Correcte beschrijving van de operatie (bijv. // Repulsion force strength).
Dit suggereert dat het model de semantiek begrijpt, maar de lexicaal gedecodeerde namen uit de string-tabel prioriteert boven de semantische correctie.

D. Semantische Fit vs. Domein-Coherentie

Eerdere experimenten suggereerden dat alleen "plausibele" termen werden overgenomen. De matched-control experimenten toonden echter aan dat:

Termen met nul semantische fit (bijv. "combustion" voor een fysica-functie) even vaak werden overgenomen als plausibele termen, mits de string-tabel geen coherent alternatief domein vormde.
Als de hele string-tabel een coherent alternatief domein vormde (bijv. engineering-termen op fysica-code), corrigeerde het model de namen wel.
Dit wijst erop dat het model kijkt naar de coherentie van het volledige domein en niet naar individuele termen.

E. Numerieke Onnauwkeurigheid

In tegenstelling tot namen, werden afgekorte wiskundige constanten (bijv. $\tau \approx 6.283$ in plaats van $2\pi$ ) consistent overgenomen, zelfs in leesbare code zonder obfuscatie.

4. Bijdragen en Significatie

Technische Bijdragen:

Ontmaskering van een zwak punt: Het paper toont aan dat LLM's bij deobfuscatie gevoelig zijn voor "source-text bias" uit gedecodeerde string-tabellen, zelfs als ze de logica begrijpen.
Framing als mitigatie: Het introduceert het concept dat het herformuleren van de prompt van "vertalen/deobfuscate" naar "genereren/herimplementeren" een effectieve mitigatiestrategie is, terwijl verificatie-instructies nutteloos zijn.
Domein-coherentie: Het identificeert dat de overname van foutieve namen afhangt van de coherentie van het alternatieve domein in de string-tabel, niet alleen van de plausibiliteit van individuele woorden.

Praktische Implicaties:

Geen volledige bescherming: De obfuscatie fungeert niet als een onbreekbare beveiliging, maar als een kostenvermenigvuldiger (cost multiplier). Het maakt automatische semantische herstelprocessen door LLM's minder betrouwbaar en tijdrovender.
Workflow-aanpassing: Voor ontwikkelaars die LLM's gebruiken voor code-analyse of reverse engineering, is het cruciaal om de prompt te herformuleren naar een generatie-taak ("schrijf dit opnieuw") in plaats van een vertaalttaak, om vergiftigde identificatoren te elimineren.
Beveiliging: Browser-geleverde code is uiteindelijk inspecteerbaar. Deze techniek vertraagt de analyse, maar voorkomt niet dat een gemotiveerde attacker de structuur begrijpt.

Beperkingen:

De studie is beperkt tot twee code-archetypen en één model-familie (Claude). Generalisatie naar andere modellen (GPT-4o, Gemini) en domeinen is nodig.
De scoring van het "dual-representation" patroon was handmatig en niet geblindeerd.

Conclusie

Het paper concludeert dat de manier waarop een taak wordt geframed (deobfuscate vs. genereren) een grotere invloed heeft op de nauwkeurigheid van identificatoren in LLM-outputs dan expliciete instructies om te verifiëren. Vergiftigde identificatoren uit obfuscatie-tabellen overleven vaak de deobfuscatie, tenzij het model wordt aangespoord om de code volledig opnieuw te genereren, waarbij het de semantische structuur behoudt maar de lexicaal vergiftigde namen verwerpt.