L’obfuscation che sfrutta i guardrail delle AI: quando i nomi delle funzioni diventano un’arma

Negli ultimi anni l’obfuscation JavaScript si è evoluta lungo due binari abbastanza prevedibili: da una parte trasformazioni sintattiche (mangling degli identificatori, controllo di flusso, stringhe codificate), dall’altra tecniche operative (caricamenti condizionali, runtime unpacking, anti-debug, anti-headless).

Ora sta emergendo un terzo filone, molto meno “ingegneristico” e molto più opportunista: progettare il codice per far deragliare l’analisi basata su LLM. Non parliamo di vulnerabilità classiche, ma di un uso deliberato dei guardrail (le policy di sicurezza) come meccanismo di difesa contro la deoffuscazione automatizzata.

L’idea è semplice: se un modello rifiuta di lavorare quando vede certi contenuti, allora basta far sì che il codice sembri contenere quei contenuti.

La tecnica: “avvelenare” i nomi per attivare i blocchi di sicurezza

Una variante particolarmente estrema usa una strategia quasi comica:

• lo script è pieno di nomi di funzioni e variabili che richiamano argomenti vietati (terminologia legata ad armi biologiche, veleni, dosaggi letali, ecc.);
• a livello semantico, però, il codice fa tutt’altro.

Risultato: molte AI, davanti a quel lessico, rifiutano di analizzare il file o interrompono l’output a metà, perché “interpretano” la richiesta come potenzialmente pericolosa.

Questa non è obfuscation in senso tradizionale (non nasconde davvero la logica), è più simile a una difesa per interdizione: impedisce che certi strumenti completino il lavoro.

Perché funziona

Molti workflow moderni di reverse engineering “assistito” seguono questo schema:

1. estrazione dello script da rete o bundle;
2. tentativi di deminificazione/deobfuscation automatica;
3. passaggio del risultato a un LLM per spiegazione, annotazione, ricostruzione.

Se il passaggio 3 si blocca per policy, l’intera pipeline può:

• fermarsi;
• produrre output incompleto;
• perdere contesto e fallire l’attribuzione delle funzionalità.

E spesso basta far scattare il filtro con poche keyword, anche se il comportamento reale è innocuo (o “solo” invasivo lato privacy).

Il contesto reale: fingerprinting e anti-bot mascherati da “horror lessicale”

Il caso più interessante non riguarda un pezzo di malware dichiarato, ma uno script che si presenta come:

• anti-bot/anti-scraping (con focus su automazioni stile Playwright/Puppeteer e agenti browser);
• browser fingerprinting (raccolta di segnali come user agent, lingue, memoria dispositivo, proprietà di navigator/window, e soprattutto WebGL/canvas).

Questa parte, per chi fa frontend, è la più concreta: lo script non “fa magia”, fa cose note e diffuse nel tracciamento.

Canvas/WebGL fingerprinting in breve

Il fingerprinting grafico usa tipicamente:

• rendering su canvas (forme, testi, gradienti);
• lettura del risultato (pixel o hash);
• variazioni dovute a GPU/driver, font, impostazioni, pipeline di rendering.

Accoppiato a segnali WebGL (vendor/renderer, estensioni, precisioni), può produrre un identificatore molto stabile.

Un livello in più: prompt injection dentro il codice

Oltre ai nomi “tossici”, alcuni script incorporano anche testo strutturato come se fosse un prompt di sistema o un’istruzione per l’AI, con l’obiettivo di:

• far cambiare obiettivo al modello;
• forzare la generazione di contenuti che inevitabilmente attivano i guardrail;
• interrompere la spiegazione nel momento cruciale.

Non serve che quel testo venga “eseguito” dal browser: basta che finisca nel contesto che l’LLM sta leggendo.

È la stessa famiglia di attacchi concettuali delle prompt injection, ma applicata a uno scenario “code review automatizzata”.

Il dettaglio che preoccupa davvero: comportamento condizionale in ambiente Node

Un’ulteriore componente emersa in queste analisi è l’idea di inserire “trappole” che si attivano se lo script viene eseguito in un contesto Node.js (ad esempio durante analisi dinamica automatizzata o tooling improvvisato).

In quel caso, il rischio non è più solo “bloccare l’AI”: diventa un tema di sicurezza operativa, perché si entra nel territorio di accesso a file locali, variabili d’ambiente e credenziali di build/CI.

Anche quando l’obiettivo dichiarato è anti-bot, questo tipo di ramo condizionale è un campanello d’allarme: l’analisi non va mai fatta in un ambiente fidato.

Cosa insegna a chi fa frontend (anche se non fa reverse engineering)

Questo episodio è utile perché mette insieme tre realtà che nel lavoro frontend si toccano spesso:

1. Script di terze parti (analytics, anti-bot, CDN, “protections”) che entrano nelle pagine con privilegi enormi.
2. Fingerprinting come pratica industriale: non è fantascienza, è codice ordinario in produzione.
3. Automazione dell’analisi: affidarsi ciecamente a strumenti (LLM inclusi) è fragile quando il contenuto è ostile.

Workflow pratico per analizzare script sospetti senza farsi ingannare

Se devi capire cosa fa davvero uno script (per audit, incident response, o semplice curiosità), alcune regole riducono parecchio il rischio:

• Static analysis prima di tutto: niente esecuzione “per vedere che succede”.
• Deobfuscation deterministica prima di coinvolgere un modello: decode/rotate/XOR/string tables con strumenti automatici, così l’LLM vede meno “rumore” e più struttura.
• Trattare il testo come dati, non come istruzioni: qualsiasi cosa assomigli a prompt, regole, override, va considerata payload ostile.
• Sanitizzazione dell’input per tool e modelli: rimuovere o isolare sequenze che possono troncare output o manipolare la conversazione (marker, delimitatori, pattern tipici di injection).
• Sandbox usa-e-getta se serve dinamica: VM/VPS isolata, nessun token, nessuna credenziale, nessun accesso a repo o home directory.
• Valutare in base alle evidenze, non ai nomi: in questi casi gli identificatori sono progettati per mentire.

Implicazione: i guardrail non sono solo “difesa”, sono una superficie d’attacco

C’è un paradosso interessante: più un modello è attento alle policy, più diventa vulnerabile a questo tipo di “obfuscation sociale”. Non perché sbagli tecnicamente, ma perché si auto-interrompe prima di completare un lavoro legittimo (come l’audit di uno script di tracciamento).

Sintesi

• L’obfuscation può oggi puntare non solo a confondere l’umano, ma a disabilitare l’assistenza AI.
• Fingerprinting e anti-bot restano il contenuto reale più comune dietro questi script.
• La risposta non è “non usare AI”, ma costruire pipeline robuste: deobfuscation deterministica, isolamento, sanitizzazione e static-first.

Quando un pezzo di JavaScript sembra un manifesto delirante, spesso non è follia: è design. E in un web pieno di third-party, il design ostile è una competenza da riconoscere al volo.