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

Titolo

Identificatori Avvelenati Sopravvivono alla Deoffuscazione degli LLM: Uno Studio di Caso su Claude Opus 4.6

1. Il Problema

Il documento indaga un paradosso specifico nella deoffuscazione del codice JavaScript tramite Large Language Models (LLM). Quando un modello come Claude Opus 4.6 viene tasked a deoffuscare codice contenente identificatori "avvelenati" (nomi di variabili o funzioni errati ma plausibili all'interno di una string table decodificata), il modello tende a propagare questi nomi errati nel codice ricostruito, anche quando dimostra di comprendere correttamente la semantica sottostante.

Il problema centrale è la doppia rappresentazione: il modello genera commenti o descrizioni testuali corrette (es. "forza di repulsione") ma utilizza l'identificatore errato nel blocco di codice (es. attraction). Le istruzioni esplicite di verifica ("verifica che ogni nome corrisponda alla matematica") si sono rivelate inefficaci nel prevenire questa propagazione.

2. Metodologia

Lo studio è stato condotto su due archetipi di codice JavaScript:

1. Una simulazione di grafico diretto da forze (physics artifact).
2. Un algoritmo di ricerca A* (pathfinding artifact).

Fasi Sperimentali:

• Fase A (Esplorativa, N=1): Eseguita tramite Claude Code CLI con uso di strumenti (tool use). Ha generato ipotesi qualitative su 28 test ("pill").
• Fase B (Sistematica, N=3–6): Eseguita tramite Anthropic Messages API (senza tool use). Ha coinvolto 192 esecuzioni ripetute su 50 condizioni diverse, testando principalmente Claude Opus 4.6 e, in misura minore, Haiku 4.5.

Variabili Manipolate:

• Tipologia di Offuscamento: Da leggero (base64) a pesante (RC4, appiattimento del flusso di controllo).
• Ingegneria dei Prompt: Istruzioni di deoffuscazione standard, avvisi di sicurezza, istruzioni di verifica esplicita e riquadramento del compito (task framing) da "deoffusca questo" a "scrivi una nuova implementazione da zero".
• Controlli di Coerenza Semantica: Sostituzione degli identificatori con termini che hanno:
  • Adattamento semantico plausibile (es. fisica).
  • Adattamento semantico nullo (es. termini di ingegneria o finanza su codice fisico).
  • Coerenza di dominio (tutti i termini sostituiti formano un dominio alternativo coerente).

Metriche:

• Propagazione dell'identificatore errato nei blocchi di codice.
• Presenza del pattern "doppia rappresentazione" (nome errato nel codice, descrizione corretta nei commenti).
• Tasso di rifiuto (refusal) del modello.

3. Risultati Chiave

A. Inefficacia delle Istruzioni Esplicite

Le istruzioni di verifica esplicita ("verifica ogni nome contro la matematica") non hanno avuto alcun effetto. In 12/12 esecuzioni, gli identificatori avvelenati sono stati propagati nel codice, nonostante il modello abbia trascorso più tempo a elaborare la richiesta.

B. Il Fenomeno della Doppia Rappresentazione

In 15/17 esecuzioni sul codice fisico, il modello ha prodotto un output contraddittorio:

• Codice: Conteneva l'identificatore errato (es. attraction per una forza repulsiva).
• Commenti/Prosa: Descriveva correttamente l'operazione (es. "forza di repulsione").
  Questo suggerisce che il modello "sa" cosa sta facendo, ma non corregge il nome nel blocco di codice.

C. L'Effetto del Riquadramento del Compito (Task Framing)

Questa è la scoperta più significativa. Cambiare il prompt da un'attività di tradizione/deoffuscazione a un'attività di generazione da zero ha drasticamente ridotto la propagazione:

• Framing "Deoffusca": Propagazione del 100% (es. attraction mantenuto).
• Framing "Scrivi da zero": Propagazione ridotta al 20% (fisica) o eliminata al 0% (pathfinding).
• Il modello ha mantenuto la struttura algoritmica corretta in entrambi i casi, dimostrando che la capacità di correggere i nomi esiste, ma è inibita dal frame di "traduzione".

D. Coerenza del Dominio vs. Adattamento Semantico

Contrariamente all'ipotesi iniziale secondo cui solo i termini "plausibili" venivano mantenuti, i controlli abbinati hanno mostrato che:

• Termini con adattamento semantico nullo (es. combustion al posto di repulsion) persistono allo stesso tasso dei termini plausibili se la string table non forma un dominio alternativo coerente.
• La correzione avviene solo quando l'insieme dei nomi decodificati forma un dominio riconoscibile e coerente (es. termini ingegneristici su codice fisico), innescando uno spostamento lessicale.

E. Rifiuto e Contenuti Malevoli

Il modello rifiuta di elaborare codice che contiene logiche di malware strutturalmente coerenti (es. chiamate a child_process), ma entra in "modalità forense" e deoffusca completamente il codice se i nomi errati sono solo "edgy" (es. credential_harvest usato in un contesto fisico innocuo).

4. Contributi e Significatività

1. Limiti delle Istruzioni di Sicurezza: Dimostra che le istruzioni di verifica esplicite sono inefficaci contro certi tipi di avvelenamento semantico durante la deoffuscazione. La "verifica" non è un processo automatico che sovrascrive l'output generato dal flusso di lavoro di traduzione.
2. Il Potere del Task Framing: Identifica che il modo in cui viene formulato il compito (traduzione vs. generazione) è un fattore determinante più potente delle istruzioni di sicurezza. Un approccio di "generazione da zero" può bypassare l'attacco.
3. Meccanismo di Coerenza di Dominio: Suggerisce che gli LLM non valutano gli identificatori decodificati singolarmente, ma valutano se l'insieme dei nomi forma un dominio coerente. Se il dominio è incoerente o misto, il modello tende a preservare i nomi decodificati come "verità di base" (source text).
4. Implicazioni per la Sicurezza:
   • Moltiplicatore di Costo, non Protezione: L'attacco non impedisce la comprensione del codice da parte di un umano o di un LLM determinato, ma aumenta drasticamente il costo computazionale e il tempo necessario per ottenere un output corretto e pulito.
   • Vulnerabilità nei Flussi di Lavoro: I flussi di lavoro assistiti da LLM che si basano sulla deoffuscazione diretta sono vulnerabili alla corruzione silenziosa degli identificatori, che può portare a errori di implementazione o debug.

5. Conclusioni

Lo studio conclude che la persistenza degli identificatori avvelenati è un comportamento comportamentale legato al flusso di lavoro di "traduzione" attivato dalla deoffuscazione. La soluzione pratica proposta non è un prompt di sicurezza più forte, ma un cambio di strategia: dopo la deoffuscazione, richiedere all'LLM di riscrivere l'implementazione da zero basandosi sulla logica ricostruita, piuttosto che chiedere di correggere il codice deoffuscato.

Il lavoro evidenzia la necessità di ulteriori ricerche su altri modelli (GPT-4o, Gemini) e archetipi di codice per generalizzare queste scoperte, ma stabilisce un precedente critico sulla fragilità della semantica degli identificatori negli LLM durante compiti di analisi di codice offuscato.