The LNK9 is a Cyber-Physical System: a successful authentication does not return a token, it mechanically releases the trigger sear. We score findings on kinetic and trust-anchor outcomes, not the classical CIA triad. Every privileged operation flows through one encrypted BLE command — so the §1 BLE air-interface and §2 cryptographic protocol are the spine; the other ten surfaces are defense-in-depth around it.
Retail LNK9 + Charger + public app, no privileged access. “What can a real-world attacker do with a unit bought from a dealer?” Findings here carry the highest inherent-risk weight.
Debug-unlocked test units, signed builds, firmware, and cryptographic protocol docs. “What can a motivated insider with full access exploit?” Starts the day after the consented-access bundle lands.
Where the 58 tests live. The spine (§1 BLE + §2 crypto) decides the whole security model; the rest is defense-in-depth.
Findings and reports as they land. Filter by phase, surface, or severity.
The baseline-hunt story: from “which radio is the gun?” to a confirmed ID and the trackability finding. Four diagrams, full evidence chain.
The gun broadcasts a static public MAC + unique UUID + Lodestar company-id: passively trackable with a $15 dongle. Severity High.
Open report →Local static audit of the Lodestar app (Flutter, com.xari.lodestar v2.0.15). Score 65/100; recovered the BLE command contract; 7 findings.
Open report →Each app finding → concrete fix + effort + priority + owner. 7 items, 5 quick wins.
Open report →Lodestar shipped a hardened, obfuscated build. We re-picked it with the same one command: symbols renamed, but the BLE contract + endpoints + secrets came out identical.
Follow-mode nRF capture of the re-pairing handshake to answer Just Works vs LESC and characterise the SMP exchange.
Design review of the application-layer BLE command protocol against the documented spec (operations, key derivation, nonce/freshness). Gray-box.
This is the story of the first Phase-1 test against the Lodestar LNK9: how we went from “we don’t know which radio out of dozens is the gun” to a confirmed identification and a concrete, evidenced security finding — in a single session, passively, without ever touching the firing path.
The objective of this first test was narrow and honest: find the gun on the air, prove it is the gun, and assess what it exposes to a passive attacker. We met it, and along the way confirmed one control working well (the command channel is encrypted) and one that needs work (the device is passively trackable). Every step below is backed by SHA-256-hashed evidence.
The LNK9 advertises with no device name and hides among dozens of phones, earbuds and speakers. Rather than guess, we used differential capture: photograph the ambient radio with the gun off and far, freeze that as “known noise”, then bring the powered gun in. Whatever appears new is the candidate.
The gun stood out instantly as the only new device carrying a hardware-vendor address and a unique service UUID — everything else was classifiable noise (Apple’s rotating private addresses, Bose/Samsung gadgets by their standard UUIDs).
We did not rely on a single signal. Three independent sources converged on the same device:
16/26/36 b438e5-…-b841-….36b438e5-… and manufacturer company ID
0x0F47 (Lodestar Technology).b841
characteristics, live on the hardware.Three sources agreeing is identification beyond reasonable doubt: 00:80:E1:27:12:28 is the LNK9.
✓ Verified, not inferred. The company ID 0x0F47 is registered to
Lodestar Technology Inc. in the authoritative Bluetooth SIG company_identifiers.yaml
registry (checked 2026-06-12), and our own capture shows the gun broadcasting it on the air — a public
record anyone can cross-reference. Full provenance in the trackability finding.
Before the finding, the credit where it is due. We connected and tried to read every proprietary command and telemetry characteristic without authentication. Every one was refused with “Insufficient Encryption.”
That is a control working exactly as intended: an unpaired attacker at radio range cannot read or drive the gun’s command channel. This is why the tracking finding below is rated High and not Critical — the attacker can find the gun, but not operate it. The next phase examines the pairing step that guards that encryption.
While powered, the LNK9 broadcasts a three-layer fingerprint in every advertising packet, readable by any passive receiver with no pairing: a static public MAC that never rotates, a unique service UUID, and the Lodestar company ID. The Bluetooth privacy feature (rotating resolvable addresses) is not in effect.
Defeating it requires fixing all three channels — rotating the MAC alone is pointless while the unique UUID and company ID still betray the device.
The fingerprint turns the safety product into a tracking beacon. An adversary with a $15 dongle at a doorway, parking garage or checkpoint can — passively and undetectably — detect who is carrying an LNK9, geolocate them by signal strength, and re-identify the same person across days because the address never changes. From there: targeting, ambush, or theft of the weapon.
No pairing, no connection, no transmission — just listening to unencrypted broadcasts. It scales to a sensor mesh across a building or a city.
Short term (firmware, current hardware):
Medium term: bake per-unit private addressing into factory provisioning, and gate the radio so it advertises only while authenticating or talking to the app — silence when holstered.
We will verify by re-running this exact hunt: the on-air address must be random and must rotate, the advertisement must no longer carry the UUID or company ID, and the app must still connect.
The LNK9’s command channel is properly encrypted — but while powered it broadcasts a permanent, unique radio fingerprint that lets anyone passively detect and track who is carrying the firearm; the fix is a firmware privacy update across three advertising fields.
After the first round of findings, Lodestar shipped a hardened, obfuscated companion build — internally, affectionately, the “Strike Back.” We re-ran the exact same single command we used the first time. This is what came back.
The honest headline up front: the obfuscation is real and competent — it genuinely makes reading the app’s logic harder. But it protected none of the things an attacker actually comes for. The sensitive material walked straight back out, byte-for-byte identical.
We compared the obfuscated libapp.so against the original. Two findings, side by side:
package: dropped 1,588 → 9) and shrank the binary’s unique strings by ~42%. Reversing the
control flow is now meaningfully harder. Credit where due.Authorization: Bearer
scheme all survived unchanged.Obfuscators — Dart --obfuscate and Android’s R8/ProGuard — rename identifiers:
classes, methods, fields, symbol paths. They do not encrypt string literals or touch
resources. Everything that matters here is exactly that:
So the score was identical: 65/100, the same seven findings, the same contract — from the “hardened” build, in one pass.
Obfuscation is good hygiene against casual reverse-engineering. It is not a secret-protection control, and treating it as one creates false confidence. Concretely: the passive-trackability finding (BLE-006) and the app-exposure findings (MOB-001) stand entirely unchanged against the hardened build. Nothing we reported in round one was mitigated by this release.
Obfuscation can stay — just stop asking it to guard secrets. The real mitigations:
The hardened build renamed the code but left the BLE command contract, the endpoints, and the secrets fully recoverable in a single command — “Strike Back” hardened the reading, not the secrets, and every round-one finding still stands.