Language: English
Modern IoT firmware is a largely unexplored attack surface, and manual analysis doesn't scale. In this talk, we present a pipeline that combines core computer science fundamentals with large language models to automate vulnerability discovery in firmware binaries.
In this talk, we describe how we built a pipeline that combines computer science fundamentals with LLMs to find bugs in firmware. We use LLMs as an operator for detecting vulnerability patterns, a kind of "vuln smell", and walk through how we built the pipeline using control flow graphs, Ghidra internals to extract pseudo-C code, and build taint analyzes pipeline, and how crafting the right prompts with the right context lets even Gemini Flash detect bugs or at least give meaningful hints, and of course our pitfalls, and why LLMs better than fuzzing in case of firmware and MORE.
Attendees will leave with a practical understanding of how to build LLM-assisted binary analysis pipelines and how prompt engineering decisions directly impact bug-finding accuracy.
Actually, the core of this framework is simple: give the LLM the right input, get valuable output. Of course, you can just feed raw assembly and say "find bugs make no mistakes, my buddy", but the result will not be the same, as instead, we give the LLM structured, meaningful context
First of all, the pipeline starts by manually extracting the firmware using a CH341A programmer from the SPI chip, then headless Ghidra runs on the binary and exports decompiled C code, the call graph, and buffer facts per function, including frame size, how far each stack buffer sits from the saved return address, and whether copy sizes are constants or variables (all buffer sizes to give LLM context rightly, which will analyze buffer overflow bugs). That call graph gets loaded into angr, which re-checks every call edge using VEX block disassembly for accuracy, falling back to Ghidra's data where angr can't resolve a target.
We then define "sources" user-controlled, like recv(), read(), fgets(), and sinks like memcpy(), strcpy(), system(), and sprintf(), which are dangerous functions, or functions of memory corruption bugs, and a BFS walk traces every path from a source to a sink within a configurable depth, producing a list of candidate vulnerability chains ready to feed into the LLM.
In case of "sources", we also define manually which argument (buffer, handle ...), or return data should be tainted.
For each candidate chain, the decompiled C of every function in that chain gets sent to an LLM with a structured prompt asking one question: Does attacker-controlled data actually reach the dangerous argument without a bounds check, and will it lead to vulnerability? The prompt includes the computed buffer facts as a trusted block of real numbers, because Ghidra's type declarations are sometimes wrong! and we don't want the model reasoning over bad data. Extended thinking is enabled, which lets the model dynamically decide how much reasoning it needs for deeper multi-step taint analysis across the full chain. For the model itself, we preferred Gemini Flash (you can use other LLMs, I preferred to use an average LLM, then frontier Claude Opus, or Mythos :(, because it is too expensive)
Result: less false positives, clear bugs, but still checking whether the bugs are exploitable or not. In the near future, we have plans to build MCP to check the proof-of-concept on hardware also. But right now, we are still checking manually.
Project uses
Ghidra: headless binary analysis, decompilation, call graph extraction
angr: VEX block disassembly for call edge recovery
pyvex: VEX IR inspection (angr's IR layer)
Gemini 2.5 Pro / Flash-Lite: LLM taint analysis
Project rebuilt to make routine work as little as possible. And make a focus more on exploitation
Probably the idea is not new and unique, but I want to share the process and pipeline, and probably get new ideas, and improve the project.
I am a security researcher specializing in low-level security, reverse engineering, vulnerability research including embedded devices and IoT. I have spoken at cybersecurity conferences including BSides Prague, KazHackStan, Positive Hack Talks, Cyberkent.