CatSniffer puts LoRa, Sub 1 GHz and 2.4 GHz radios on one USB stick

One board covering three radio bands

CatSniffer is a piece of hardware rather than a program, and the design choice that defines it is breadth. The README describes it as an original multiprotocol and multiband board made for sniffing, communicating, and attacking IoT devices, designed as a highly portable USB stick.

The silicon is what makes that possible. Version 3 integrates the TI CC1352, the Semtech SX1262 and an RP2040, while V2 used a Microchip SAMD21E17 in place of the RP2040. The CC1352 is the multiprotocol and multi-band Sub-1 GHz and 2.4 GHz microcontroller, and the README quotes the vendor description of it supporting Thread, Zigbee, Bluetooth 5 Low Energy, IEEE 802.15.4g, IPv6-enabled smart objects through 6LoWPAN, MIOTY, Wi-SUN and proprietary systems.

The board can operate in three technology bands, which the README lists as LoRa, Sub 1 GHz and 2.4 GHz. That covers the range of low power radio protocols used by sensors, mesh networks and long range links, which is why it has become a common sight at hardware security events.

The positioning is a tool for IoT security researchers, developers and enthusiasts. The description is blunt about the third use case, since the board is for sniffing, communicating, and attacking IoT devices, but the legal note at the bottom of the README is equally clear about the intended use, which is to let product developers evaluate electronic components, circuits or software associated with the kit and decide whether to incorporate them in a finished product.

The protocol list defines the scope

CatSniffer is useful because of what it can receive, and the README lists that explicitly:

Thread
Zigbee
Bluetooth 5 Low Energy (BLE)
IEEE 802.15.4g
6LoWPAN (IPv6 over Low power Wireless Personal Area Networks)
Sub 1Ghz and patented systems
LoRa/LoRaWAN
Wi-SUN
Amazon Sidewalk
mioty®

Two entries in that list are worth a note. Amazon Sidewalk and mioty sit alongside the better-known families in that list.

The variety is the point, but it also has a cost in complexity. Every protocol family on that list has its own framing, its own addressing and its own quirks, and a sniffer that covers many of them is usually a sniffer that is not the deepest implementation of any one of them. The dedicated, protocol-specific tools listed later in the README are often better at their one job.

What the board gives you is the ability to switch between them with the same antenna, the same USB port and the same firmware flashing workflow, which is what makes it useful in a lab where you do not know in advance which radio your target actually speaks.

The board is a radio, the software is someone else's

One of the more interesting aspects of the project is that it deliberately does not insist on its own tooling for the analysis side.

The README lists the software the board can be used with, and it is a mix of vendor tools, community projects and the company's own. On the community side there is Sniffle, zigbee2mqtt and Z-Stack-firmware. On the vendor side there is SmartRF Packet Sniffer and the Ubiqua Protocol Analyzer. The README also names Wireshark and the company's own tooling in the separate CatSniffer-Tools repository.

That is a deliberate architecture choice for a research board. Sniffle, for instance, is a project from the same organisation and is listed in the README's own catalogue of supported software.

The practical consequence is that the hardware is not tied to a single toolchain that has to be trusted or updated in step with the board. If a new protocol appears and somebody writes a decoder for it, the board can probably run it, provided the radio can receive that band at all.

The trade-off is that you have to assemble the stack yourself. Sniffing is a two-part job, the radio part and the protocol decoding part, and this project takes care of the first while leaving the second to the wider ecosystem. The README says as much when it points out that you can write your own software for your specific needs.

Firmware and tools were split out of the main repository

The main repository is documentation and hardware, and the moving parts live elsewhere, which the README explains as a version control and issue tracking decision.

Firmware has moved to the CatSniffer-Firmware repository. The README says all CatSniffer versions are supported there, that you need to check what version you own, and that you select the proper branch to develop or release for just programming your board. Software moved to the CatSniffer-Tools repository for the same reasons.

The versioning story is long and shaped by hardware revisions. The README lists the versions the board has passed through, CatSniffer v1.2, v1.3, v2.0, v2.1 and v3.1, and says the company decided to keep support for each version while accepting that newer versions will have more features than the first ones. The tags in the repository follow suit, with v3.3 published on 2026-09-22 after v3.2 and v3.1 in September 2024, and the last push to the main repository was on 2026-10-14.

One detail explains why the repository looks tidier than you might expect. The README states that the different firmwares are inside the repository and not in the release section, to keep a proper track of the compiled and source files. So the binaries and the sources for each board version travel together in the firmware repository, and the release tags on the main repository track documentation and board revisions rather than shipping you a flashable image.

Practically, the workflow is: identify your board version, pick the matching firmware branch, and flash.

Flashing and building need three toolchains

Programming the board is designed to need no extra hardware, which is the part that makes it approachable.

The README states that the board auto programs through the bootloader from TI, as long as it is not disabled in the code, that no external programmer is needed, and that it can be debugged with cJTAG through the default pin. That is a real convenience for a portable device, because the usual alternative is a separate programmer held against a pad on the board.

The bridge chip handles the USB side. CatSniffer uses the Microchip SAMD21E17 on V2 and earlier, and the RP2040 on V3 and later, as a USB-UART bridge to talk to the CC1352 chip, and the README notes it is not necessary to install a manual driver, with exceptions possible. The supported operating systems are Windows and Linux.

The rest of the board is deliberately generic. There is an SMA port for an antenna of your choice, which matters for the sub-GHz bands where the antenna is most of the performance story, general-purpose LEDs, and reset buttons for the RP2040, SAMD21 and CC1352, plus a boot button for the CC1352 and one more for general purpose.

Building the firmware yourself is where the effort goes. The prerequisites are the Arduino IDE for the RP2040 or SAMD21E17, CCS version 10.2 for the packet sniffer firmware as tested, the SimpleLink CC13x2 and CC26x2 SDK, and Python 3. The README is explicit that it has been tested with CCS 10.2, which is a specific and dated statement.

It is a developer kit, with the paperwork that implies

CatSniffer is sold as hardware, and the repository reflects that in its structure and its paperwork.

The README carries a note that is worth reading in full. The kit is designed to allow product developers to evaluate electronic components, circuits or software associated with the kit to determine whether to incorporate them in a finished product, and software developers to write applications for use with the end product. It is a developer product, and when assembled it may not be resold or otherwise marketed unless all required FCC, or any other local authority, equipment authorisations are first obtained. Operation is also subject to the condition that the product must not cause harmful interference to licensed radio stations and must accept harmful interference.

That paragraph is the practical boundary of the project. The board transmits, and a transmitting device carries regulatory obligations that a receive-only piece of test equipment does not.

The repository is organised like a hardware project. The top level holds cases/, hardware/, pcaps/, poc/ and workshops/, alongside CONTRIBUTING.md, SECURITY.md, REWARDS.md and the licence file. The workshops directory corresponds to the training content from the company's security event workshops, which the README says is public.

Contributions have their own process, with a Contribution Manual and a contributor licence agreement referenced from the README, so the licensing situation is a custom one and the files themselves are the place to read it. And the security posture is stated with a SECURITY.md, which is the file to consult about how to report a problem in the hardware or the firmware.

Editorial conclusion

CatSniffer suits IoT security researchers and product developers who need one device that can listen to several low power radio standards and drive them, and it suits anyone who wants to test their own firmware against real traffic rather than a simulator. It is the wrong choice as a general purpose radio for anyone who only needs one protocol, since the price of the flexibility is a board with two processor families and three toolchains, and it is the wrong choice if you need a turnkey product rather than a developer kit. Before you order one, check which hardware version you are buying, because the USB bridge differs between V2 and V3 and the firmware branches follow the version, and read the equipment authorisation note in the README if you intend to assemble or resell anything.

Frequently asked questions

Official sources

1. ElectronicCats/CatSniffer on GitHub
2. Issues
3. Project website
4. README
5. Releases