Someone hands you a device. It has an antenna, maybe an FCC ID printed on the label, and no documentation. Or you are looking at a waterfall with a short burst around 433.92 MHz and nothing else to go on.
The tooling for this is excellent and it is everywhere: Catsniffer, rtl_433, Universal Radio Hacker, Sniffle, Proxmark3, srsRAN, Kismet, and a hundred more. What has been missing is the map. Which of those do you reach for first? Once you have bits, what is the next question? And when you write the report, how do you show that you did not skip the crypto layer entirely because the link layer was more fun?
That gap is what RFSAM is for.
What RFSAM is
RFSAM stands for Radio Frequency Security Assessment Methodology. It is an open, structured reference for RF research and auditing, built by PWNLabs together with Electronic Cats and released under CC BY-SA 4.0.
It does not claim to invent RF security. OSSTMM, Tarlogic’s BSAM and the whole SDR pentest lineage came first. RFSAM organizes that landscape into something you can navigate by. For Bluetooth at the link layer and above it defers to BSAM outright instead of duplicating it, and 17 of our controls point at the BSAM ids that already own that judgement.
Two axes: protocol and layer
Everything in RFSAM is indexed on two axes, so any control has exactly one place to live.
The protocol axis covers 15 technologies today: BLE, Bluetooth Classic, Wi-Fi, Zigbee and 802.15.4, Z-Wave, Thread and Matter, LoRa and LoRaWAN, sub-GHz ISM, RFID and NFC, UWB, GNSS, ADS-B, GSM, LTE and 5G NR.
The layer axis is a descent, from the open air down to whatever the device trusts:
| id | layer | what it asks |
|---|---|---|
IG | Info Gathering | identify the components, check known CVEs, before any RF work |
SP | Spectrum | what is transmitting, and can you see it at all |
PHY | Signal / PHY | waveform to bits |
LL | Link / Protocol | frames, addressing, identifiers |
CR | Crypto | pairing, keys, confidentiality, integrity |
AT | Attack | injection, replay, hijack, rogue infrastructure |
AP | Application | what the device trusts above the link |
Control ids follow RFSAM-<PROTOCOL>-<LAYER>-<NN>, so RFSAM-BLE-AT-01 is the first attack-layer control for BLE. The protocol and layer segments have to match the frontmatter fields, and validation fails if they do not. That is deliberate: an id you can cite in a report should never disagree with the content behind it.
Start with the Wayfinder
If you have a device in front of you right now, skip the reading and go to the Wayfinder. Pick a technology and it walks you down the descent, handing you the exact kit at each step: which radio, which software, why that one, and what it will not do for you.
All 15 technologies are mapped. Each layer entry names a primary tool, what it depends on, and the caveat that bites you in the field. For sub-GHz at the spectrum layer, for example, it tells you to point rtl_433 at 433.92 MHz to inventory what is on the air, and warns you that rtl_433 only names devices it already has a decoder for. An unknown gadget still shows energy but no decode, and then you fall back to the waterfall and URH.
Behind the Wayfinder sits a reference of 151 tools, hardware and software, each filterable by technology and linked to its source.
The Controls are the part you cite
51 controls are written today. Each one is a verification procedure with the same four sections: Mechanism (how the weakness actually works, with citations), Procedure (the steps), Field case (a real capture, not a hypothetical), and Remediation.
Every nontrivial claim carries a source you can check. Attacks are listed with their CVE where one exists, their impact, and their preconditions, and every reference key has to resolve to a real entry or validation rejects the file. Controls also share 29 reusable procedures, so “sniff and audit a BLE device” is written once and referenced from everywhere it applies.
A worked example
Take RFSAM-BLE-AT-01, live connection hijacking. It is rated critical, and it covers three documented families of takeover: jam-and-hijack (Btlejack), injection based takeover (InjectaBLE), and reconnection spoofing (BLESA, CVE-2020-9770).
The field case is an ELK-BLEDOM LED strip controller. Sniffing the vendor app setting a color revealed handle 0x000E and the payload format 7e 07 05 RR GG BB 10 ef. After hijacking the live connection, writing the learned command drove the strip to our color:
w 0x000e 7e 07 05 03 ff 00 00 10 ef
An LED strip is a harmless demo. The technique is unchanged against a lock or a medical device, which is exactly why the control ends with remediation rather than a victory lap: encrypt the link with LE Secure Connections, add application-layer command authentication, and enforce authentication on reconnection.
The control also records an implementation detail that cost us time. The decoder’s Access Address must be set to the connection AA only after reaching the CENTRAL state, with a flush first, because advertisements seen while initiating reset it to the advertising AA and silently break data PDU decoding. That kind of note is the reason to write field cases down.
It tells you what is missing
The Roadmap page carries a coverage heatmap: every protocol crossed with every layer, colored by what actually exists. Green cells have a control with a real field case, and 15 controls are marked verified today. Amber cells are the interesting ones: the Wayfinder already names the kit, but nobody has written the control yet.
We could have hidden that. Publishing it is the point. A methodology that pretends to be complete is worse than one that shows you its holes.
Contribute
RFSAM grows by pull request, and the amber cells are the best place to start.
git clone https://github.com/pwnlabmx/RFSAM.git
cd RFSAM && npm install
cp src/content/controls/_template.md src/content/controls/rfsam-zigbee-at-01.md
npm run validate && npm run build
Fill the frontmatter and the four body sections, make both commands pass, and open a PR. CONTRIBUTING.md has the full schema, the id rules and the criticality rubric. One rule matters more than the rest: wrong depth is worse than missing depth, so cite everything, and if you could not verify a claim, flag it inline instead of smoothing it over.
Read it at pwnlabmx.github.io/RFSAM, and the source lives at github.com/pwnlabmx/RFSAM.
Version 0.1 is a draft, and it will stay a draft until the heatmap is greener. Go break something, then tell us what we got wrong.
Happy hacking.