💬 NLP

Detecting Ladder Logic Bombs in IEC 61131-3 PLC Programs using ESBMC-PLC+: A Formal Verification Approach with Trigger Synthesis

Questo articolo presenta ESBMC-LLB, un framework di verifica formale che estende ESBMC-PLC+ per rilevare le Ladder Logic Bombs nei programmi PLC IEC 61131-3 esponendo la logica nascosta dei blocchi funzione e sintetizzando i trigger, ottenendo tassi di rilevamento quasi perfetti e robustezza contro i trigger adattivi su dataset pubblici dove i metodi esistenti falliscono.

Autori originali: Pierre Dantas, Lucas Cordeiro, Waldir Junior

Pubblicato 2026-07-10

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Pierre Dantas, Lucas Cordeiro, Waldir Junior

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina un Programmabile Logic Controller (PLC) come il cervello di una fabbrica, che esegue costantemente un ciclo: osserva i sensori, prende una decisione, muove una macchina e poi ricomincia da capo in una frazione di secondo. Ora, immagina un hacker subdolo che nasconde una "bomba logica" all'interno di questo cervello. Questa bomba è come un drago dormiente: non fa nulla finché la fabbrica funziona normalmente, ma nel momento in cui accade una specifica condizione nascosta (come un contatore che raggiunge un certo numero), si sveglia e scatena il caos — che sia congelare la macchina, mentire sulle letture dei sensori o far aprire una valvola quando invece dovrebbe restare chiusa.

Per molto tempo, gli strumenti utilizzati per controllare questi cervelli di fabbrica avevano un punto cieco. Esaminavano il codice principale ma ignoravano i "function block" — che sono come piccole sub-routine o mini-programmi all'interno del codice principale. Il documento spiega che i draghi dormienti (le bombe) si nascondevano dentro questi function block ignorati. Poiché i vecchi strumenti scartavano questi blocchi dalla loro vista, il codice malevolo e il codice sicuro apparivano esattamente uguali al controllore. Era come cercare di trovare una spia in una folla guardando solo i volti delle persone, mentre la spia si nascondeva dentro un cappotto che il controllore non guardava nemmeno.

La Grande Soluzione: Aprire il Cappotto
Gli autori, Pierre Dantas, Lucas Cordeiro e Waldir Junior, hanno costruito un nuovo metodo chiamato ESBMC-LLB. Il loro trucco principale era semplice ma potente: hanno fatto sì che il controllore guardasse dentro i function block. Hanno aggiunto uno "strato di traduzione" che prende il codice nascosto all'interno di questi blocchi e lo stende in piano in modo che il controllore possa vederlo.

Una volta che il codice è visibile, utilizzano due trucchi astuti per catturare la bomba:

Il Cronometro (Scan-Watchdog): Se la bomba cerca di congelare la macchina facendo eseguire al programma un ciclo infinito, il controllore agisce come un arbitro severo con un cronometro. Dice: "Hai 1o passi per finire questo compito. Se vai oltre, sei fuori!". Se la bomba prova a ciclare all'infinito, il controllore la cattura immediatamente.
Il Tester dei Fili (Output Wiring): Se la bomba cerca di mentire su un sensore o forzare una macchina a muoversi, il controllore collega i fili dal codice nascosto al sistema principale. Se il codice nascosto cerca di inviare una "menzogna" (come dire a una valvola di aprirsi quando non dovrebbe), il controllore vede che viola le regole di sicurezza.

Il Risultato Magico: Trovare il "Codice Segreto"
Ecco la parte più incredibile. Quando il controllore trova una bomba, non si limita a dire "Errore!". Esso espelle effettivamente il trigger esatto. È come se il controllore dicesse: "Ho trovato il drago, ed ecco la password segreta che lo risveglia: 'Se il contatore arriva a 12'". Questo è chiamato "trigger synthesis".

Quanto ha funzionato?
Il team ha testato il loro metodo su diversi set di dati e i risultati sono stati impressionanti, ma con alcuni limiti importanti:

Il Test Pubblico: Su un famoso dataset di 60 programmi (30 sicuri, 30 con bombe), il loro metodo ha trovato tutte le 30 bombe. Ha catturato ogni singola bomba e ha trovato il trigger segreto per ciascuna di esse. Ha anche dimostrato che i 29 programmi sicuri erano realmente sicuri. Un programma sicuro era così complesso che il controllore non poteva essere sicuro al 100% (ha detto "non lo so" invece di "sicuro"), ma non ha accusato falsamente il programma.
Il Test dell'Hacker "Intelligente": Hanno cercato di ingannare il loro sistema nascondendo il trigger in enigmi matematici (come l'uso di un calcolo complesso invece di un semplice numero). I vecchi strumenti che cercano solo pattern hanno mancato questi trucchi. ESBMC-LLB, tuttavia, ha compreso il significato della matematica e ha catturato tutte le 5 versioni truccate.
Il Test su Grande Scala: Hanno generato 310 programmi (155 sicuri, 155 con bombe) per testare la velocità. Il sistema ha catturato il 100% delle bombe in una media di 70 millisecondi (più veloce di un battito di ciglia!).
Il Test del Impianto Idrico Reale: Hanno testato questo metodo su una simulazione reale di un impianto di trattamento delle acque (il corpus SWaT).
- Sulla versione più vecchia dei dati (con trigger matematici semplici), hanno trovato 149 bombe su 150 (99%) con zero falsi allarmi.
- Il Limite: Quando hanno testato una versione più recente con matematica non lineare molto complessa (come moltiplicare un numero per se stesso ripetutamente), il sistema si è bloccato. La matematica era troppo difficile da risolvere per il controllore in tempo, e il rilevamento è sceso al 49%. Il documento è molto chiaro su questo punto: il loro metodo è ottimo per la logica standard e la matematica semplice, ma incontra un muro con la matematica non lineare complessa. In quei casi specifici, un altro tipo di strumento (chiamato rilevatore CFG-triage) è ancora migliore.

Cosa non pretendono di fare
Gli autori sono molto onesti riguardo a ciò che il loro strumento non può fare. Affermano esplicitamente che se una bomba è progettata per completare il suo compito rapidamente (senza ciclare all'infinito) e non viola nessuna delle regole di sicurezza specifiche che hanno istruito il controllore a cercare, lo strumento potrebbe mancarla. Non è una bacchetta magica che trova ogni possibile cosa negativa; trova quelle che congelano il sistema o violano le regole di sicurezza definite.

In sintesi
Questo articolo dimostra che, semplicemente "aprendo il cappotto" per guardare dentro i function block e utilizzando un controllore intelligente che comprende il significato del codice, possiamo catturare gli subdoli ordigni industriali che prima si nascondevano in piena vista. Trova le bombe, ci dice esattamente come attivarle (per poterle fermare) e dimostra che il resto del sistema è sicuro — a meno che la matematica non diventi troppo folle, nel qual caso abbiamo bisogno di un tipo diverso di detective. Gli autori presentano questo come un potente nuovo strumento che lavora insieme ai metodi esistenti, non uno che li sostituisce tutti.

Sintesi Tecnica: Rilevamento di Ladder Logic Bomb in programmi PLC IEC 61131-3 utilizzando ESBMC-PLC+

1. Definizione del Problema

I Programmabili Logici Programmabili (PLC) sono l'ossatura dei sistemi di controllo industriale (ICS) critici per la sicurezza. Una minaccia specifica, la Ladder Logic Bomb (LLB), consiste nell'inserimento di una logica di controllo malevola che rimane dormiente durante il normale funzionamento e i test di messa in servizio. La bomba si attiva solo quando viene soddisfatta una specifica condizione di trigger, eseguendo un payload che manipola gli attuatori, falsifica le letture dei sensori o nega il controllo all'operatore (ad esempio, tramite non-terminazione).

I metodi di rilevamento esistenti affrontano due limitazioni primarie:

Cecità Strutturale: Molte LLB si nascondono all'interno dei corpi dei Function Block (FB). I verificatori standard di Ladder Diagram (LD) spesso scartano i corpi dei FB dalla loro Rappresentazione Intermedia (IR) per semplificare la verifica, rendendo la logica malevola invisibile al prover.
Mancanza di Garanzie Illimitate: I rilevatori basati su firme o sul triage del Control Flow Graph (CFG) si affidano a pattern sintattici. Possono essere elusi da trigger adattivi (ad esempio, valori calcolati, aritmetica opaca) e non possono fornire prove formali dell'assenza di bombe in tutti i possibili cicli di scansione.

2. Metodologia: ESBMC-LLB

Gli autori presentano ESBMC-LLB, un metodo che riutilizza l'esistente verificatore ESBC-PLC+ (un model checker IEC 61131-3 che utilizza bit-vector SMT e $k$ -induzione) per rilevare le LLB. L'approccio non modifica il backend di verifica ma introduce uno strato di modellazione leggero nel frontend per esporre la logica nascosta e ricondurre il rilevamento a un controllo di proprietà di sicurezza formale.

Componenti Core

Traduzione del Corpo del Function-Block:
- Gli autori osservano che i verificatori LD esistenti scartano i corpi dei FB. ESBMC-LLB analizza i corpi degli FB definiti dall'utente e li traduce in codice GOTO nativo (assegnazioni, loop, confronti).
- Ciò garantisce che la logica malevola residente nei FB sia presente nell'IR ed sia raggiungibile dal prover.
Meccanismi di Rilevamento:
Il metodo mappa i payload delle LLB a specifiche violazioni di sicurezza:
- Scan-Watchdog (per Denial-of-Control/Non-terminazione): Un contatore di iterazione limitato è asserito all'interno di ogni loop di rung, fedele a un vero timer watchdog di un PLC. Se un payload mediato da un trigger entra in un loop non terminante, viola il vincolo di budget, diventando una violazione di sicurezza raggiungibile.
- Output Wiring (per Falsificazione di Attuatori/Sensori): I pin di uscita dei FB sono cablati alle variabili di programma che li consumano. Se un payload falsifica un valore, questo si propaga attraverso il programma e viola una proprietà di sicurezza fornita (ad esempio, la mutua esclusione di attuatori interbloccati).
Risultati della Verifica:
- $k$ -Induction: Se il programma è benigno, la $k$ -induzione fornisce una prova illimitata che la proprietà di sicurezza si mantiene per tutti i cicli di scansione, certificando l'assenza di bombe della classe modellata.
- Bounded Model Checking (BMC): Se è presente una bomba, il BMC restituisce una traccia di controesempio. Questa traccia costituisce il trigger di detonazione (la specifica sequenza di input e il numero di cicli di scansione), consentendo la sintesi automatica del trigger.

3. Contributi Principali

L'articolo delinea cinque contributi primari:

Esposizione della Logica Nascosta: Uno strato di modellazione che traduce i corpi dei FB nella IR del verificatore, rendendo raggiungibile la logica precedentemente non rilevabile residente nei FB.
Doppio Rilevamento con Sintesi del Trigger: Meccanismi per rilevare sia la non-terminazione (tramite scan-watchdog) che la falsificazione dei valori (tramite output wiring), dove il controesempio BMC recupera automaticamente il trigger di detonazione.
Robustezza contro l'Avversario Adattivo: Poiché il metodo ragiona sulle semantiche del programma piuttosto che su pattern sintattici, rileva trigger progettati per eludere il triage basato su CFG (ad esempio, costanti calcolate, accumulatori multi-scansione).
Valutazione Esaustiva:
- Validazione di Terze Parti: Rilevamento al 100% sul dataset pubblico Iacobelli et al. (30 programmi malevoli).
- Scalabilità: Recall del 100% e zero falsi positivi su un corpus tassonomico di 310 programmi Booleani/integer (tempo di esecuzione mediano 70ms).
- Benchmark del Mondo Reale: La prima valutazione di un model checker semantico sul benchmark analogico PLC-Defuser SWaT.
Caratterizzazione del Trade-off Semantica vs. CFG: Una chiara delineazione di dove il model checking semantico eccelle (logica Booleana/integer, analogico lineare, prove illimitate) rispetto a dove il triage CFG mantiene il vantaggio (non-terminazione analogica non lineare).

4. Risultati Sperimentali

Logica Booleana e Integer

Dataset Iacobelli: Ha rilevato tutti i 30 programmi malevoli (recall del 100%) con zero falsi positivi. L'unico programma benigno riportato come "UNKNOWN" non era un falso positivo, ma un limite del passo induttivo sullo stato integer.
Trigger Adattivi: Ha rilevato con successo 5/5 varianti di una bomba in cui il trigger era nascosto tramite valori calcolati, squaring, fattorizzazione o accumulo temporale, mentre un proxy di triage CFG ha rilevato solo la baseline ingenua (1/5).
Scalabilità: Su un corpus generato di 310 programmi (Booleani/integer), il metodo ha ottenuto il 100% di recall e zero falsi positivi con un tempo di rilevamento mediano di 70ms.

Controllo Analogico (Benchmark SWaT)

Gli autori hanno valutato il metodo sul corpus PLC-Defuser SWaT (Secure Water Treatment plant), che coinvolge logica non booleana (REAL/INT).

Parsing Abilitante: Un'estensione di modellazione analogica (che supporta tipi REAL e bobine non booleane) ha permesso di analizzare il corpus per la prima volta da parte di un model checker semantico.
Trigger Lineari (v1.0.0): Sul rilascio archiviato contenente bombe di non-terminazione con trigger lineari, ESBMC-LLB ha rilevato 149/150 (99%) dei programmi malevoli con zero falsi positivi.
Trigger Non Lineari (Dev Snapshot): Su una versione successiva contenente bombe di non-terminazione con aritmetica non lineare (ad esempio, $i := i*i$ ), il rilevamento è sceso al 49%. Il backend SMT è andato in timeout quando costretto a ragionare sull'aritmetica non lineare attraverso l'unrolling dei loop.
Confronto: Gli autori notano che sulla non-terminazione analogica non lineare, i rilevatori di triage CFG (come PLC-Defuser) mantengono il vantaggio, mentre il model checking semantico prevale sulla logica Booleana/integer e sul controllo analogico lineare.

5. Significato e Rivendicazioni

L'articolo posiziona ESBMC-LLB non come un sostituto per tutti i rilevatori esistenti, ma come un approccio complementare che colma lacune specifiche nel panorama della verifica della sicurezza:

Garanzie Illimitate: A differenza degli scanner di firme o dei model checker limitati, ESBMC-LLB può fornire una prova formale che nessun bomb di una specifica classe esiste attraverso tutti i cicli di scansione.
Sintesi Automatica del Trigger: Non si limita a segnalare un programma come malevolo; genera la sequenza esatta di input necessaria per detonare la bomba, agevolando l'analisi forense.
Robustezza all'Offuscamento: È immune alle tecniche di offuscamento sintattico che sconfiggono il triage basato su CFG.
Limiti Modesti: Gli autori riconoscono esplicitamente che l'approccio è sound ma non completo per tutti i tipi di payload. È limitato ai payload che o non terminano o violano una specifica proprietà di sicurezza. Inoltre, fatica con l'aritmetica non lineare nei contesti analogici, dove attualmente resta indietro rispetto ai metodi di triage strutturale basati su CFG.

Il lavoro conclude che il model checking semantico e il triage CFG sono complementari: il primo fornisce prove illimitate e robustezza per la logica Booleana/integer e analogica lineare, mentre il secondo rimane superiore per la gestione della non-terminazione analogica non lineare. Il superamento di questi approcci (ad esempio, tramite loop summarization o controlli guidati da ibridi CFG) è identificato come una direzione promettente per la ricerca futura.