Bluetooth Low Energy Security Testing, Consolidated: Introducing Caeruleus

Caeruleus is a single Go binary designed to consolidate the fragmented and decaying tools used for Bluetooth Low Energy (BLE) testing on Linux. It provides a unified workflow for the entire BLE lifecycle, including scanning, enumeration of services and characteristics, reading/writing data, fuzzing, and running structured security assessments. The tool integrates functionalities previously spread across disparate tools like bettercap, gatttool, and various custom scripts.
The primary value proposition is streamlining the process by replacing the cumbersome manual stitching together of separate tools, which previously required users to manually pass data between terminals. Caeruleus improves usability through features like a health check (`caeruleus doctor`), structured output formats (JSON, JSONL, text), and daemon/batch modes for scripting. It also incorporates security-focused assessment workflows that leverage existing secret detection mechanisms, such as checking for unauthenticated access and fuzzing writable characteristics.
The tool is designed to be agent-friendly, supporting structured output that LLM agents can easily parse, and it includes an Agent Skills-compatible skill, positioning it as a central hub for BLE security analysis.

* Caeruleus is a single Go binary built on the BlueZ stack for Linux.
* It covers the entire BLE lifecycle: scanning, enumeration, reading/writing/notifying characteristics, fuzzing, and security assessments.
* Traditional BLE testing relies on stitching together deprecated tools like hcitool, bettercap, gatttool, and custom scripts.
* Caeruleus consolidates these functions into one tool with consistent command structures.
* It supports structured output in text, JSON, and JSONL formats via the -o flag.
* Features include `caeruleus doctor` for checking stack health and `caeruleus scan` for device discovery.
* Specific capabilities include reading/writing handles, capturing notifications, fuzzing writes, connection parameter reporting, and discovering unauthenticated data exposure.
* The tool includes daemon mode (`caeruleus serve`) and batch mode (`caeruleus batch`) for scripting efficiency.
* It integrates Praetorian’s Titus for detecting secrets in read values exposed over unauthenticated links.
* Caeruleus can be used with LLM agents via structured output formats.

The narrative positions Caeruleus as a necessary evolution from the previous, fragmented state of BLE security tooling. The core pattern observed is the resistance to complexity—the accumulation of ad-hoc solutions that mandate manual integration for basic tasks. This leads to a cognitive burden where security assessments become process management exercises rather than focused analysis. Caeruleus directly addresses this by enforcing a unified abstraction layer built on BlueZ, which shifts the focus from managing tool dependencies to executing high-level assessment workflows.
The shift towards structured, machine-readable output—JSON/JSONL—is a systemic move that acknowledges the rise of automated analysis, making the results consumable by agents and scripts rather than just human review. This aligns with the broader trend in offensive security tooling toward API-like interfaces, where tools emit verifiable results rather than raw terminal dumps. The embedding of secrets detection (Titus) directly into the workflow represents an attempt to bake defensive checks into the assessment process itself, moving vulnerability discovery closer to automated remediation vectors.
The limitation noted—that Caeruleus only operates as the central layer and cannot perform active sniffing or AITM attacks—highlights a deliberate demarcation between passive/configuration-based assessment and active penetration testing capabilities. This establishes a boundary: it is an excellent framework for understanding protocol implementation and configuration flaws, but not a full adversary simulation tool. The implication for agency is that consolidating tools provides power in configuration space, but true control over the physical layer requires separate expertise; this suggests a necessary division of labor between infrastructure analysis and active exploitation.
What must be questioned is whether this consolidation inherently simplifies complex adversarial scenarios or merely abstracts away complexity until the error occurs elsewhere in the chain. If an agent relies on Caeruleus for an end-to-end assessment, does that reliance create a brittle point if the underlying assumptions about BlueZ or the specific BLE implementation are flawed? How does the move from human-driven scripting to agent-driven execution change the responsibility for verifying the integrity of the overall methodology?