How much of our Bluetooth firmware reverse engineering work can now be automated with LLMs

The speakers had reverse engineered Realtek, Texas Instruments and Silicon Labs Bluetooth chip firmware by hand, and wanted to know how much of that work a large language model could take over. Local models were too weak on obscure Bluetooth facts, so they tested frontier models. They connected Claude Code to Ghidra through an MCP server that can run arbitrary Ghidra scripts, then packaged their prompts as a skill that locates spec-mandated code such as HCI command handlers, LMP and LLCP packet senders and receivers, and the structures the spec defines.

The main technique is what they call waypoints: code the specification requires must exist somewhere in the firmware, so prompts can point the model at it. Prompts are ordered by dependency and parallelized where possible. A self-improving loop failed to converge, so they instead tuned each category separately and stopped once it reached the known functions. Evaluation used five firmware images with known symbols, then seven unseen ones graded by two models cross-checking each other. Chips lacking Classic support or a separate HCI layer produced far fewer findings, because those layers were absent. A full run took roughly five and a half to eight and a half hours.

The practical takeaway is that a firmware analyst can save days of renaming and structure work by writing spec-derived prompts, validating them against binaries with known answers, and running results through more than one model. The authors suggest the same approach would suit other spec-driven firmware such as Wi-Fi, USB, NVMe or UEFI. The skills were released publicly.