Part 6 mapped the Flipper Zero's Sub-GHz capabilities across the spectrum below 1 GHz, tracing how ASK, FSK, and OOK modulation carry signals from garage doors to weather stations. That coverage was deliberately methodical: understand the signal before you touch the tool. This part takes that same discipline and applies it to a frequency band that gets far more traffic, far more complexity, and far less careful attention from the security research community.
2.4 GHz is not a protocol. It's a neighborhood, and it's crowded. Wi-Fi lives there. Bluetooth lives there. Zigbee lives there. And quietly, invisibly to most scanning tools, so do hundreds of millions of consumer devices built around a tiny transceiver chip that most practitioners have never deliberately studied. That chip is the nRF24L01+, and the protocol ecosystem it enables deserves its own chapter.
This part covers seven areas: what NRF24 actually is and where it comes from, how it differs from Wi-Fi despite sharing the same frequency band, where the security gaps live in real deployed hardware, which tools enable passive observation, how to build a controlled lab environment for research, documentation methodology for NRF24 findings, and how this knowledge connects to a broader defensive picture. Every section is oriented toward observation and understanding. None of it is oriented toward interference, injection, or anything that touches devices you don't own.
If you've been skipping NRF24 in your RF research workflow, this is the part that explains why that gap matters.
The Hidden Layer of 2.4 GHz: Why NRF24 Deserves Its Own Chapter
A Frequency Band With Many Tenants
The 2.4 GHz ISM band is one of the most contested slices of spectrum in everyday use. Wi-Fi 802.11b/g/n operates there. Classic Bluetooth and Bluetooth Low Energy operate there. Zigbee, used in smart home mesh networks, operates there. Microwave ovens leak into it. Baby monitors transmit across it. The band runs from roughly 2.400 GHz to 2.500 GHz, and in any populated building, it's genuinely full.
Most security practitioners who study wireless traffic in this band reach for Wi-Fi tools first. That's understandable. Wi-Fi is dominant, documented, and well-supported by everything from Wireshark to specialized hardware. But that focus creates a blind spot. A significant portion of the devices operating in this band don't speak Wi-Fi at all. They speak NRF24, and standard Wi-Fi tooling can't see them.
Why Security Researchers Often Overlook NRF24
NRF24 doesn't have a flashy CVE history the way Wi-Fi protocols do. It doesn't show up in enterprise threat models. It doesn't have a Wireshark dissector that most people know about. And because the devices that use it, wireless mice, keyboards, toy RC controllers, cheap sensor nodes, tend to be treated as peripheral and low-stakes, they rarely get audited.
That assumption deserves scrutiny. A wireless keyboard transmitting keystrokes over an unencrypted NRF24 link is not a low-stakes device. A sensor node broadcasting environmental data on a fixed, hardcoded address is not invisible just because it's small.
The goal of this part is to bring NRF24 out of the background and into deliberate focus. By the end, you'll understand the hardware, the protocol characteristics, the security posture of real deployed devices, and the tools available for passive, ethical observation in your own lab.
What NRF24 Actually Is: The Transceiver Behind the Curtain
Hardware Origins: Nordic Semiconductor and the nRF24L01+
Nordic Semiconductor is a Norwegian fabless semiconductor company, and the nRF24L01+ is one of its most widely deployed products. Released in the mid-2000s, the chip is a single-chip 2.4 GHz transceiver designed for ultra-low-power wireless applications. It's small, cheap to manufacture, and straightforward to integrate into microcontroller-based designs. Those three properties made it enormously popular.
The original nRF24L01 was succeeded by the nRF24L01+, which added support for a 250 kbps data rate and improved sensitivity. The "+" variant is now the dominant version in production hardware, though the naming is often used interchangeably. Clones of this chip, produced by various manufacturers in China and elsewhere, are available for well under a dollar per unit in volume. That price point has driven adoption into product categories where wireless connectivity was previously too expensive to include.
"The nRF24L01+ is one of those components that became infrastructure without anyone declaring it infrastructure."
How the Module Works at a High Level
The nRF24L01+ communicates with a host microcontroller over SPI (Serial Peripheral Interface), a synchronous serial protocol that uses four lines: SCK (clock), MOSI (master out, slave in), MISO (master in, slave out), and CSN (chip select). A fifth line, CE (chip enable), controls whether the module is in transmit or receive mode. This interface is well-documented and supported by libraries across virtually every microcontroller ecosystem.
The module operates across 2.400 to 2.525 GHz, divided into 125 addressable channels spaced 1 MHz apart. Data rate options are 250 kbps, 1 Mbps, and 2 Mbps. Lower data rates improve sensitivity and extend range; higher data rates reduce time-on-air and power consumption per packet. Most consumer devices default to 1 Mbps or 2 Mbps for latency-sensitive applications like mice and keyboards.
NRF24 uses a pipe-based addressing model. Each receiver can listen on up to six pipes simultaneously, each with its own address. Addresses are 3 to 5 bytes long. A transmitter sends packets addressed to a specific pipe address, and only receivers configured for that address will process the packet. This is the entirety of the "addressing" layer. There's no IP, no MAC address, no network stack.
Where You Find NRF24 in the Wild
The deployment footprint of NRF24-based hardware is genuinely large. Wireless mice and keyboards from dozens of manufacturers use it. RC toy vehicles use it. Game controllers for budget gaming peripherals use it. Home automation sensor nodes use it. Industrial telemetry modules use it. It shows up in weather station remote sensors, in wireless thermometers, in smart doorbells from smaller manufacturers.
That number includes clones, which are themselves a significant portion of total deployment. Many of the nRF24L01+ modules sold on hobbyist electronics platforms are not genuine Nordic Semiconductor products. They're functionally compatible in most cases, but firmware behavior can vary in ways that matter for security research.
NRF24 vs. Wi-Fi: Same Neighborhood, Completely Different World
Frequency Overlap Does Not Mean Protocol Overlap
This is the misconception that trips up practitioners who are comfortable with Wi-Fi tools and assume those tools give them visibility across the 2.4 GHz band. They don't. Sharing a frequency range is not the same as sharing a protocol. A Wi-Fi adapter in monitor mode captures 802.11 frames. It doesn't capture NRF24 packets. It can't. The two systems use different modulation schemes, different framing structures, and different everything below the physical layer.
Wi-Fi 802.11b uses DSSS (Direct Sequence Spread Spectrum) modulation. 802.11g and later use OFDM (Orthogonal Frequency Division Multiplexing). NRF24 uses GFSK (Gaussian Frequency Shift Keying), a narrowband modulation scheme that a Wi-Fi receiver isn't designed to decode. Your Wi-Fi chipset isn't ignoring NRF24 traffic because it's filtering it out. It's ignoring it because it literally cannot interpret the signal.
Stack Differences That Change Everything
The structural differences go well beyond modulation. Wi-Fi channels are 20 to 80 MHz wide depending on the standard and configuration. NRF24 channels are 1 MHz wide. A single Wi-Fi channel is wider than the entire operating range of many NRF24 deployments.
Wi-Fi operates within the OSI model. It has MAC addresses. It has association and authentication procedures. It has SSID beaconing. It has encryption negotiation via WPA2, WPA3, or their predecessors. All of that infrastructure exists to support a network model where multiple devices share a medium and need to identify each other reliably.
NRF24 has none of that. There are no MAC addresses. There are no beacons. There's no association handshake. There's no encryption negotiation because there's no built-in encryption to negotiate. The protocol is minimal by design: a transmitter sends a packet to an address, a receiver configured for that address picks it up, and an optional auto-acknowledgment mechanism confirms receipt. That's the entire stack.
Bluetooth also shares this band and is worth distinguishing separately. Classic Bluetooth and BLE both use frequency hopping spread spectrum, jumping across 79 channels (or 40 for BLE) in a pseudorandom sequence. That's yet another distinct approach, and it requires yet another distinct toolset to observe. The 2.4 GHz band contains at least four separate protocol ecosystems that don't interact with each other at the protocol level.
Why Your Wi-Fi Tools Will Not Help You Here
Tooling Scope Matters
Aircrack-ng, Wireshark with a Wi-Fi adapter, and standard monitor-mode capture setups are purpose-built for 802.11. They have no mechanism for decoding GFSK-modulated NRF24 traffic. Attempting to use them for NRF24 research produces no useful output. This isn't a configuration issue. It's a fundamental hardware and protocol incompatibility.
Studying NRF24 requires hardware that speaks GFSK and understands the NRF24 packet structure. That means an nRF24L01+ module, either standalone or connected to a capable host like the Flipper Zero. The tooling discussion comes later in this part, but the conceptual point is worth establishing clearly now: you need different hardware for different protocol ecosystems, even when those ecosystems share a frequency band.
Security Posture of NRF24 Devices: Where the Risks Live
Authentication Gaps in Low-Cost Hardware
The nRF24L01+ hardware itself provides no authentication mechanism. None. A receiver configured to listen on a specific pipe address will process any packet that arrives on that address. There's no challenge-response, no shared secret verification, no device pairing record that gets checked against incoming traffic. The pipe address is the only gate, and it's a very thin one.
This isn't a flaw in the chip design so much as a consequence of what the chip is optimized for: low power, low cost, low complexity. Authentication infrastructure takes code space, processing cycles, and design time. For a $0.80 component in a $15 toy, that overhead is rarely justified by the manufacturer.
That estimate reflects findings from independent security research published across multiple academic and practitioner sources over the past decade. The actual number is difficult to measure precisely because there's no registry of NRF24 deployments. But the pattern is consistent: cheap consumer devices using NRF24 frequently transmit data without encryption.
Encryption: Present in Spec, Absent in Practice
The nRF24L01+ spec doesn't prohibit encryption. Firmware can absolutely implement AES or any other cipher over the NRF24 payload before transmission. Some devices do this. Higher-end wireless peripherals from reputable manufacturers have moved toward encrypted protocols or migrated to Bluetooth with proper pairing. But in the commodity tier, encryption is the exception.
Wireless mice and keyboards are the most studied examples. Research going back more than a decade has demonstrated that many budget wireless input devices transmit keystrokes and movement data in cleartext or with trivially reversible obfuscation. The packets contain the actual key presses. Anyone with an nRF24L01+ module and appropriate software can observe them.
Research Context Only
The security gaps described here are documented to help practitioners understand what's deployed in their environments. Observing devices you own in a controlled lab is legitimate research. Observing, recording, or interacting with devices you don't own is not. That line doesn't move regardless of how easy the technology makes it.
The Commodity Clone Problem
The clone market complicates the security picture further. Genuine Nordic Semiconductor nRF24L01+ chips behave predictably according to the datasheet. Clones, which make up a substantial portion of modules sold through hobbyist and bulk electronics channels, sometimes don't. Firmware behavior can differ in subtle ways: different defaults for auto-acknowledgment, different handling of address matching, different power-on states.
For security research, this means that a clone module used as a test transmitter might behave differently from the genuine chip in the device you're studying. It also means that some deployed devices are built on clones with firmware quirks that create additional exposure beyond what the original spec would suggest. Fixed, hardcoded pipe addresses are common in clone-based products, making those devices identifiable across different environments simply by their transmission pattern. A device that transmits on the same address every time it powers on, regardless of location, is broadcasting a fingerprint whether or not the payload is encrypted.
Momentum: Tools for NRF24 Scanning and Passive Observation
The Flipper Zero NRF24 Application Ecosystem
The Flipper Zero doesn't ship with NRF24 capability built in. It gains that capability through community-developed applications available via the Flipper Application Catalog (FAC), the official community app distribution channel. The NRF24 application ecosystem has grown steadily and now includes several distinct tools suited to different research tasks.
All of these applications require the same hardware addition: an nRF24L01+ module connected to the Flipper Zero's GPIO header. The Flipper's GPIO pins provide SPI communication, power, and the CE line the module needs to operate. Without the physical module attached, the software has nothing to talk to. This is a wired, external connection. It doesn't require any modification to the Flipper itself.
Channel Scanner: Finding Active Frequencies
The NRF24 Scanner application sweeps all 125 channels sequentially and reports signal presence on each. The output is a channel activity map: a visual or numeric representation of which channels show traffic above the noise floor. A channel with active NRF24 traffic appears distinctly different from background noise. The signal has structure. It has timing regularity if the transmitting device is sending periodic updates, as most mice and sensor nodes do.
What the channel scanner tells you is where to look. It doesn't decode packet contents. It doesn't identify addresses. It answers the first question: is something transmitting here? In a typical home or office environment, you'll often find two or three active channels. In a lab with multiple test devices, you can use the scanner to confirm your test transmitter is operating on the expected channel before attempting any packet observation.
The distinction between a populated channel and a noisy one matters. Noise in the
Running the Scan: A Defensive Lab Walkthrough
Part 6 covered the physical wiring of the nRF24L01+ module to the Flipper Zero GPIO header and confirmed that the connection was stable enough to power the module without brownout artifacts. Now the hardware is ready. This section is about what you actually do with it.
Everything here assumes you're working against your own test transmitter. Not a neighbor's wireless keyboard. Not a device you found on the network. Yours. Hardware you flashed, hardware you own, hardware you can power off the moment you're done.
Step One: Channel Scan and Signal Mapping
Launch the NRF24 scanner application from the Flipper Zero app menu. The application sweeps all 125 available channels sequentially, from channel 0 at 2.400 GHz up through channel 124 at 2.524 GHz. Each channel is 1 MHz wide. The display renders a bar graph representation of detected signal energy per channel, updated continuously as the sweep completes each pass.
Signal strength indicators appear as vertical bars. A channel showing consistent, tall bars across multiple sweep cycles is almost certainly carrying real traffic. Noise floor activity looks different: scattered, inconsistent, never anchoring to a single channel for more than a pass or two. Learn to distinguish between the two before you start drawing conclusions.
Power on your test transmitter. Watch the display. One channel should light up with noticeably more consistent activity than its neighbors. That's your device. Note the channel number.
Step Two: Address Discovery Against Your Test Transmitter
Knowing the channel gets you to the right frequency. Knowing the pipe address gets you to the right device. In your Arduino test sketch, you configured a specific 5-byte address, something like 0xE7E7E7E7E7 or whatever value you chose. Configure the Flipper Zero scanner with that same address and lock it to the channel you identified in step one.
When the address matches, the scanner begins receiving packets. The display confirms reception: you'll see the pipe address echoed back, payload bytes displayed in hexadecimal, and a running packet count incrementing in real time. That confirmation is significant. It tells you the scanner is genuinely receiving and decoding traffic, not just detecting RF energy.
Step Three: Packet Observation and Logging
With address discovery confirmed, switch to logging mode. The application records channel number, pipe address, payload bytes, and packet arrival timestamps. Let it run for at least five minutes against your test transmitter transmitting at a fixed interval.
What you're looking for is pattern. A device transmitting every 8 milliseconds will show up as a highly regular packet stream. A sensor polling every 30 seconds produces a very different log. The packet interval is the most informative single metric in the log because it tells you how the device behaves without requiring you to decode a single payload byte.
Anomalies matter too. Occasional missed packets suggest range issues or interference. Erratic timing, where the interval varies by more than 10 to 15 percent with no obvious cause, can indicate firmware instability or a poorly implemented sleep/wake cycle. Neither is a security issue by itself, but both are worth noting in your documentation.
What the Data Tells You: Interpreting NRF24 Observations Defensively
Raw logs are just numbers until you apply a framework for reading them. The value of this lab work isn't the packet capture itself. It's what the capture tells you about how a device was designed, and whether that design reflects any meaningful security consideration.
Reading Channel Behavior as a Security Signal
A device that transmits on a fixed channel and never moves is called a static-channel device. Most inexpensive NRF24 peripherals work this way. The channel is hardcoded in firmware, set once at the factory, and never changed. That's not inherently catastrophic, but it does mean the device is trivially locatable. Any scanner running a standard sweep will find it in under a second.
Contrast that with devices implementing frequency hopping spread spectrum, where the transmitter and receiver jump through a predetermined channel sequence in sync. Hopping devices are significantly harder to observe passively because you'd need to know the hopping pattern to follow them. Most cheap NRF24 devices don't hop. They sit on their channel and wait.
What Address Patterns Reveal About Device Design
A hardcoded pipe address is a design decision with real implications. When a manufacturer ships ten thousand wireless keyboards all using the same 5-byte address baked into firmware, every one of those devices will accept packets from any transmitter configured with that address. The address isn't a secret. It's a label.
Security researchers documenting the MouseJack class of vulnerabilities found exactly this pattern across a wide range of wireless peripherals. The address was fixed. The channel was fixed. The payload was unauthenticated. The combination made those devices observable and, in some cases, influenceable by unauthorized transmitters.
Logging as Evidence: Why Documentation Matters
A log that records channel, address, data rate, and packet interval for every NRF24 device in your environment is an asset. It gives you a baseline. If something changes, you'll know. If a new device appears on a channel that was previously quiet, you'll see it.
Professional wireless security assessments include exactly this kind of passive inventory work. It's not exotic. It's methodical. Organizations that know what their devices transmit are in a fundamentally better position than those operating on assumption. The log you generate in this lab is the same artifact a professional would produce, scaled down to a single test device.
Criminal Abuse Theory: Understanding the Threat Model Without Enabling It
Understanding how something can be misused is not the same as enabling misuse. Security research requires both the technical knowledge and the ethical framework to keep those two things separate. This section covers the threat model. It does not cover attack payloads, exploitation techniques, or anything that would help someone harm a system they don't own.
Why Weak Wireless Peripherals Are Attractive Targets
Wireless peripherals sit at a strange intersection. They're physically close to sensitive work. They transmit continuously during use. And they're frequently the least scrutinized devices in an environment. A security team that has spent months hardening network infrastructure may have given zero thought to the wireless keyboard sitting three feet from the CEO's laptop.
Threat Awareness Disclaimer
This section describes documented vulnerability categories for defensive education only. No exploitation techniques, attack payloads, or methods for targeting devices you do not own are discussed here. Responsible disclosure exists for a reason, and researchers who find real vulnerabilities in real products report them to manufacturers.
The MouseJack vulnerability class, documented publicly by security researchers in 2016, demonstrated that a range of wireless mice and keyboards from major manufacturers were susceptible to unauthorized packet injection. The root cause was straightforward: the devices accepted packets from any transmitter using a matching address, with no authentication of the payload source.
The Unauthorized Command Problem
A device that cannot distinguish a legitimate controller from an unauthorized transmitter has no meaningful access control at the wireless layer. It trusts the address. If the address is fixed and discoverable through passive scanning, the trust model collapses.
"Authentication is not a feature you add later. It is a property you either design in from the start or accept you don't have."
Cheap IoT sensors using NRF24 often transmit environmental data, temperature readings, motion detection events, door open or close states, without any encryption. That data is readable by anyone with the right hardware and the patience to scan for it. For a sensor monitoring a facility's entry points, that's a meaningful exposure.
What Defenders Need to Know
Behavior leakage is the subtler threat. Even without decoding a single payload byte, packet timing tells an observer when a device is active. A wireless keyboard that transmits only when keys are pressed reveals, through its packet cadence, when someone is sitting at a workstation and typing. That's not a hypothetical concern. It's a documented inference channel.
The defensive takeaway is not to panic. It's to audit. Know which NRF24 devices exist in your environment, what channels they use, and what they're transmitting. That knowledge is the foundation of any rational response.
Hardening Recommendations: What To Do With What You've Learned
The lab exercise generates data. This section is about what to do with it. Observation without action is just an interesting afternoon. The goal is a set of concrete decisions about devices in your environment.
Auditing Your Own NRF24 Device Inventory
Start by running the channel scan in every environment where you have responsibility for security. Offices, labs, server rooms, any space where sensitive work happens. Log every channel showing consistent activity. Cross-reference those channels against your known device inventory.
Where to Start Your Audit
Prioritize spaces where wireless peripherals are used near sensitive data. Wireless keyboards and mice adjacent to workstations handling confidential information are the highest-priority audit targets. Cheap IoT sensors near physical access points are a close second.
If you find NRF24 activity you can't attribute to a known device, that's a finding worth investigating. It might be a forgotten peripheral. It might be something else.
Choosing Better Hardware for Sensitive Environments
In high-security contexts, wired peripherals are the correct answer. They transmit nothing. For environments where wireless is genuinely necessary, Bluetooth LE devices implementing proper pairing with authenticated connections are meaningfully more secure than static-channel NRF24 devices.
For custom NRF24 deployments, developers should implement AES encryption at the application layer. The NRF24L01+ chip doesn't provide encryption natively, but nothing prevents you from encrypting the payload before handing it to the radio. Rolling address schemes and channel hopping, where the protocol permits them, add meaningful friction to passive observation.
When to Replace vs. When to Isolate
Not every vulnerable device needs to be thrown out immediately. The question is proportionality. A wireless keyboard used in a public-facing reception area carries different risk than one sitting next to a workstation handling financial records.
For devices you can't replace right now, physical isolation helps. Dedicated frequency channels for NRF24 sensor networks, physical separation from sensitive work areas, and disabling receivers for peripherals that aren't actively in use all reduce the observable surface. Removal of unused wireless receivers is the simplest hardening step available and the most frequently skipped.
Your NRF24 Lab Checklist: Putting It All Into Practice
This checklist covers the complete lab sequence from hardware acquisition through final documentation. Work through it in order. Each step depends on the one before it.
Don't treat this checklist as a one-time exercise. The value compounds when you run it periodically, because environments change and devices get added without anyone updating an inventory.
What Comes Next: Bridging NRF24 Into the Broader Wireless Picture
How NRF24 Research Connects to the Rest of the Grimoire
NRF24 is its own ecosystem. It has its own channel structure, its own addressing scheme, its own tooling requirements, and its own distinct set of design patterns that carry security implications. You can't observe it with a generic 802.11 scanner. You can't reason about it using Bluetooth threat models. It demands its own attention, and that's exactly what this part of the series gave it.
The broader theme running through every part of this grimoire is the same: each wireless protocol has its own risk surface, its own toolset, and its own set of questions worth asking. NRF24 asks questions about peripheral security and IoT sensor design. Other protocols ask different questions. The methodology transfers even when the tools don't.
Carrying the Defensive Mindset Forward
Treat your NRF24 lab work as a repeatable baseline audit. Run it when you add new hardware. Run it when your environment changes. Run it periodically just to confirm that what you expect to be there is what's actually there.
Part 8 moves into a different frequency territory, looking at Sub-GHz protocols and the wide range of remote controls, sensors, and access systems that operate below the 1 GHz threshold. The tooling changes, the channel math changes, and the threat landscape shifts in some genuinely interesting directions. The defensive mindset stays exactly the same.
