💬 NLP

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

This paper presents ESBMC-LLB, a formal verification framework that extends ESBMC-PLC+ to detect Ladder Logic Bombs in IEC 61131-3 PLC programs by exposing hidden function-block logic and synthesizing triggers, achieving near-perfect detection rates and robustness against adaptive triggers on public datasets where existing methods fail.

Original authors: Pierre Dantas, Lucas Cordeiro, Waldir Junior

Published 2026-07-10

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Pierre Dantas, Lucas Cordeiro, Waldir Junior

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a Programmable Logic Controller (PLC) as the brain of a factory, constantly running a loop: it looks at sensors, makes a decision, moves a machine, and then starts all over again in a split second. Now, imagine a sneaky hacker hiding a "logic bomb" inside this brain. This bomb is like a sleeping dragon; it does nothing while the factory is running normally, but the moment a specific, hidden condition happens (like a counter hitting a certain number), it wakes up and causes chaos—either by freezing the machine, lying about sensor readings, or making a valve open when it should stay closed.

For a long time, the tools used to check these factory brains had a blind spot. They would look at the main code but ignore the "function blocks"—which are like little sub-routines or mini-programs inside the main code. The paper explains that the sleeping dragons (the bombs) were hiding inside these ignored function blocks. Because the old tools dropped these blocks from their view, the malicious code and the safe code looked exactly the same to the checker. It was like trying to find a spy in a crowd by only looking at the people's faces, while the spy was hiding inside a coat that the checker didn't even look at.

The Big Fix: Opening the Coat
The authors, Pierre Dantas, Lucas Cordeiro, and Waldir Junior, built a new method called ESBMC-LLB. Their main trick was simple but powerful: they made the checker look inside the function blocks. They added a "translation layer" that takes the hidden code inside these blocks and lays it out flat so the checker can see it.

Once the code is visible, they use two clever tricks to catch the bomb:

The Stopwatch (Scan-Watchdog): If the bomb tries to freeze the machine by making the program run in an endless loop, the checker acts like a strict referee with a stopwatch. It says, "You have 100 steps to finish this task. If you go over, you're out!" If the bomb tries to loop forever, the checker catches it immediately.
The Wire Tester (Output Wiring): If the bomb tries to lie about a sensor or force a machine to move, the checker connects the wires from the hidden code to the main system. If the hidden code tries to send a "lie" (like telling a valve to open when it shouldn't), the checker sees it break the safety rules.

The Magic Result: Finding the "Secret Code"
Here is the coolest part. When the checker finds a bomb, it doesn't just say "Error!" It actually spits out the exact trigger. It's like the checker saying, "I found the dragon, and here is the secret password that wakes it up: 'If the counter hits 12'." This is called "trigger synthesis."

How Well Did It Work?
The team tested their method on several sets of data, and the results were impressive, but with some important limits:

The Public Test: On a famous dataset of 60 programs (30 safe, 30 with bombs), their method found all 30 of the bombs. It caught every single one and found the secret trigger for each. It also proved that the 29 safe programs were truly safe. One safe program was so complex the checker couldn't be 100% sure (it said "I don't know" instead of "Safe"), but it didn't falsely accuse it.
The "Smart" Hacker Test: They tried to trick their system by hiding the trigger in math puzzles (like using a complex calculation instead of a simple number). Old tools that just look for patterns missed these tricks. ESBMC-LLB, however, understood the meaning of the math and caught all 5 of these tricky versions.
The Big Scale Test: They generated 310 programs (155 safe, 155 with bombs) to test speed. The system caught 100% of the bombs in an average of 70 milliseconds (that's faster than a blink!).
The Real-World Water Plant Test: They tested this on a real-world simulation of a water treatment plant (the SWaT corpus).
- On the older version of the data (with simple math triggers), they found 149 out of 150 bombs (99%) with zero false alarms.
- The Limit: When they tested a newer version with very complex, non-linear math (like multiplying a number by itself repeatedly), the system got stuck. The math was too hard for the checker to solve in time, and detection dropped to 49%. The paper is very clear here: their method is great for standard logic and simple math, but it hits a wall with complex, non-linear math. In those specific cases, a different type of tool (called a CFG-triage detector) is still better.

What They Don't Claim
The authors are very honest about what their tool can't do. They explicitly state that if a bomb is designed to finish its task quickly (without looping forever) and doesn't break any specific safety rule they told the checker to look for, the tool might miss it. It's not a magic wand that finds every possible bad thing; it finds the ones that either freeze the system or break the safety rules they defined.

The Bottom Line
This paper shows that by simply "opening the coat" to look inside the function blocks and using a smart checker that understands the meaning of the code, we can catch sneaky industrial bombs that used to hide in plain sight. It finds the bombs, tells us exactly how to trigger them (so we can stop it), and proves that the rest of the system is safe—unless the math gets too crazy, in which case we need a different kind of detective. The authors present this as a powerful new tool that works alongside existing methods, not one that replaces everything.

Technical Summary: Detecting Ladder Logic Bombs in IEC 61131-3 PLC Programs Using ESBMC-PLC+

1. Problem Statement

Programmable Logic Controllers (PLCs) are the backbone of safety-critical Industrial Control Systems (ICS). A specific threat, the Ladder Logic Bomb (LLB), involves inserting malicious control logic that remains dormant during normal operation and commissioning tests. The bomb activates only when a specific trigger condition is met, executing a payload that manipulates actuators, forges sensor readings, or denies operator control (e.g., via non-termination).

Existing detection methods face two primary limitations:

Structural Blindness: Many LLBs hide inside Function Block (FB) bodies. Standard Ladder Diagram (LD) verifiers often drop FB bodies from their Intermediate Representation (IR) to simplify verification, rendering the malicious logic invisible to the prover.
Lack of Unbounded Guarantees: Signature-based or Control Flow Graph (CFG) triage detectors rely on syntactic patterns. They can be evaded by adaptive triggers (e.g., computed values, opaque arithmetic) and cannot provide formal proofs of bomb absence across all possible scan cycles.

2. Methodology: ESBMC-LLB

The authors present ESBMC-LLB, a method that repurposes the existing ESBMC-PLC+ verifier (an IEC 61131-3 model checker using SMT bit-vectors and $k$ -induction) to detect LLBs. The approach does not modify the verification backend but introduces a lightweight modeling layer in the frontend to expose hidden logic and recast detection as a formal safety property check.

Core Components

Function-Block-Body Translation:
- The authors observe that existing LD verifiers discard FB bodies. ESBMC-LLB parses user-defined FB bodies and translates them into native GOTO code (assignments, loops, comparisons).
- This ensures the malicious logic residing inside FBs is present in the IR and reachable by the prover.
Detection Mechanisms:
The method maps LLB payloads to specific safety violations:
- Scan-Watchdog (for Denial-of-Control/Non-termination): A bounded iteration counter is asserted within every rung loop, faithful to a real PLC watchdog timer. If a trigger-gated payload enters a non-terminating loop, it violates the budget constraint, becoming a reachable safety violation.
- Output Wiring (for Actuator/Sensor Forgery): FB output pins are wired to the program variables that consume them. If a payload forges a value, it propagates through the program and violates a supplied safety property (e.g., mutual exclusion of interlocked actuators).
Verification Outcomes:
- $k$ -Induction: If the program is benign, $k$ -induction provides an unbounded proof that the safety property holds for all scan cycles, certifying the absence of bombs of the modeled class.
- Bounded Model Checking (BMC): If a bomb is present, BMC returns a counterexample trace. This trace constitutes the detonation trigger (the specific input sequence and scan cycle count), enabling automatic trigger synthesis.

3. Key Contributions

The paper outlines five primary contributions:

Exposing Hidden Logic: A modeling layer that translates FB bodies into the verifier's IR, making previously undetectable FB-resident bombs reachable.
Dual Detection with Trigger Synthesis: Mechanisms to detect both non-termination (via scan-watchdog) and value forgery (via output wiring), where the BMC counterexample automatically recovers the detonation trigger.
Adaptive-Adversary Robustness: Because the method reasons over program semantics rather than syntactic patterns, it detects triggers engineered to evade CFG-based triage (e.g., computed constants, multi-scan accumulators).
Comprehensive Evaluation:
- Third-Party Validation: 100% detection on the public Iacobelli et al. dataset (30 malicious programs).
- Scalability: 100% recall and zero false positives on a 310-program Boolean/integer taxonomy corpus (median runtime 70ms).
- Real-World Benchmark: The first evaluation of a semantic model checker on the PLC-Defuser SWaT analog benchmark.
Semantic vs. CFG Trade-off Characterization: A clear delineation where semantic model checking excels (Boolean/integer logic, linear analog, unbounded proofs) versus where CFG-triage retains the edge (nonlinear analog non-termination).

4. Experimental Results

Boolean and Integer Logic

Iacobelli Dataset: Detected all 30 malicious programs (100% recall) with zero false positives. The single benign program reported as "UNKNOWN" was not a false positive but a limitation of the inductive step on integer state.
Adaptive Triggers: Successfully detected 5/5 variants of a bomb where the trigger was hidden via computed values, squaring, factoring, or temporal accumulation, whereas a CFG-triage proxy detected only the naive baseline (1/5).
Scalability: On a generated corpus of 310 programs (Boolean/integer), the method achieved 100% recall and zero false positives with a median detection time of 70ms.

Analog Control (SWaT Benchmark)

The authors evaluated the method on the PLC-Defuser SWaT corpus (Secure Water Treatment plant), which involves non-Boolean (REAL/INT) logic.

Enabling Parsing: An analog modeling extension (supporting REAL types and non-Boolean coils) allowed the corpus to be parsed for the first time by a semantic model checker.
Linear Triggers (v1.0.0): On the archived release containing linear-trigger non-termination bombs, ESBMC-LLB detected 149/150 (99%) malicious programs with zero false positives.
Nonlinear Triggers (Dev Snapshot): On a later version containing nonlinear arithmetic non-termination bombs (e.g., $i := i*i$ ), detection dropped to 49%. The SMT backend timed out when forced to reason about nonlinear arithmetic across loop unrolling.
Comparison: The authors note that on nonlinear analog non-termination, CFG-triage detectors (like PLC-Defuser) retain the edge, while semantic model checking leads on Boolean/integer logic and linear analog control.

5. Significance and Claims

The paper positions ESBMC-LLB not as a replacement for all existing detectors, but as a complementary approach that fills specific gaps in the security verification landscape:

Unbounded Guarantees: Unlike signature scanners or bounded model checkers, ESBMC-LLB can provide a formal proof that no bomb of a specific class exists across all scan cycles.
Automatic Trigger Synthesis: It does not just flag a program as malicious; it generates the exact input sequence required to detonate the bomb, aiding in forensic analysis.
Robustness to Obfuscation: It is immune to syntactic obfuscation techniques that defeat CFG-based triage.
Modest Limitations: The authors explicitly acknowledge that the approach is sound but not complete for all payload types. It is limited to payloads that either fail to terminate or violate a specified safety property. Furthermore, it struggles with nonlinear arithmetic in analog contexts, where it currently trails behind structural CFG-triage methods.

The work concludes that semantic model checking and CFG-triage are complementary: the former provides unbounded proofs and robustness for Boolean/integer and linear analog logic, while the latter remains superior for handling nonlinear analog non-termination. Bridging these approaches (e.g., via loop summarization or hybrid CFG-guided checks) is identified as a promising direction for future research.