ESP32-BlueJammer is an ESP32-based hardware project that generates broadband 2.4GHz interference against Bluetooth, BLE, WiFi and RC links, documented here strictly for educational and authorized RF-security research.

EmenstaNougat/ESP32-BlueJammer sits in an unusual corner of the security-tooling landscape: it is not software you run against a network, but a complete hardware/firmware ecosystem built around the ubiquitous ESP32 dev board and a pair of nRF24L01+PA+LNA transceiver modules. With over 8,500 stars, it is one of the most visible DIY RF projects on GitHub, and it deserves documentary attention precisely because it demonstrates how cheaply broadband 2.4GHz disruption can be produced — a fact defenders and device vendors should understand. This writeup analyzes the repository as published, for educational and authorized research framing only.

The README is explicit and repeated about legality: 'Jamming is ILLEGAL! Educational purposes only!' appears front and center, and the author reiterates that the hardware 'is not intended for illegal use' next to every PCB variant. That framing matters, because the device's core function — deliberate radio interference — is a criminal offense in most jurisdictions regardless of intent, under regulations administered by bodies like the FCC in the United States. The only legitimate contexts for building or studying this are shielded RF laboratories, Faraday-caged test benches, and formally authorized resilience testing where spectrum use is controlled.

Technically, the design works by saturating the shared 2.4GHz ISM band with noise and unnecessary packets — effectively a physical-layer denial of service. The ESP32 drives two nRF24L01+PA+LNA modules, one on the HSPI bus and one on VSPI, letting the firmware sweep or flood channels faster than a single radio could. Because Bluetooth (79 channels, 2.402–2.480 GHz), BLE (40 channels, 2.400–2.4835 GHz), WiFi (14 channels, typically 20/22/40 MHz wide) and many RC drone links (channels 1–125, 2.400–2.525 GHz) all overlap in the same spectrum, a single broadband interference source degrades all of them simultaneously.

The firmware distribution model is interesting from an analysis standpoint. Rather than shipping source that users compile, the author distributes prebuilt .bin images organized by target: Bluetooth_80_CH, BluetoothLowEnergy_40_CH, a combined Bluetooth-BluetoothLowEnergy_40-80_CH build, Bluetooth-WiFi_14-80_CH, WiFi_14_CH, and 2.4GHzRemoteControl(Drones etc.)_1-125_CH. A convenience web flasher (ESP32-BlueJammerFlasher on pages.dev) lets users select a Generic or 0.96 OLED firmware variant and write it over a USB data cable, while advanced users can flash the binaries with any tool of their choice. We deliberately do not provide build or flashing walkthroughs here — the educational value is in understanding the architecture, not operating it.

The Combo-Channel-Select_BT-BLE-WiFi-RC firmware is the most instructive piece of the user interface design. Operation begins immediately on power-up with no start button, and the ESP32's Boot button cycles between modes. Feedback is layered redundantly: a 0.96" I2C OLED shows the current operation channel, a status LED blinks once for BT, twice for BLE, three times for WiFi, four times for RC, and serial output prints the corresponding State lines. That triple-redundant feedback tells you the author expects the device to be used in bench scenarios where you want to know exactly which mode is radiating at any moment — a lab-instrument mindset rather than a covert-operations one.

On the hardware side, the bill of materials is deliberately commodity-grade: an ESP32 dev module (the ESP32-32U with a CP2102 USB-UART is recommended), two nRF24L01+PA+LNA modules, and 10-100uF decoupling capacitors to stabilize the nRF24's notoriously noisy power draw — a well-known practical detail in nRF24 projects. Optional additions include the OLED, a status LED with a 4.7kOhm resistor, a TP4056 charging module with a 3.7V Li-Ion cell and JST PH 2.0 connector for portable power, and an IPEX-to-SMA-F pigtail for a third antenna attached to the ESP32's own radio, which the README claims improves long-range interference stability.

The antenna discussion is one of the more candid sections of the README. The author states both nRF24 antennas are effectively required for usable range, quotes 20–30 meters with stock Chinese 2.4GHz antennas and 'over 30 meters' on newer Bluetooth versions, and notes that larger router antennas or a 2.4GHz amplifier can extend this. Range claims from a project author should always be treated skeptically — real-world performance depends heavily on the environment and victim receiver quality — but the order of magnitude is plausible for PA+LNA modules and is consistent with independent nRF24 range testing in the hobbyist literature.

Beyond the core build, the repository documents a custom ESP32-RF DIY-PCB that integrates the dev board, two nRF footprints, the OLED, LEDs and slide switches, with a specified resistor network (R1 = 1kOhm, R2/R3/R5/R7 = 47kOhm, R4/R6 = 100kOhm) and a 3D-printed case sized for a 7x5.5cm proto board closed with M3x16 screws and nuts. The author has also spun off an ecosystem: BlueJammer-V2, a BW16-BlueJammer variant, and ZeroWave, a Flipper Zero adaptation — a sign of sustained iteration rather than a one-shot proof of concept.

From a defensive perspective, this class of device is simultaneously trivial to detect and hard to mitigate. A broadband noise source raises the noise floor across every 2.4GHz channel at once, which is a distinctive signature in any spectrum capture — normal traffic is modulated and structured, whereas jamming output looks like uniform elevated energy. Wireless intrusion-detection systems and monitor-mode captures (airodump-ng-style tooling) will show every channel degrading simultaneously rather than a single AP or client misbehaving. Because there is no handshake to fail or packet to fingerprint, detection is an RF-spectrum problem, not a protocol-analysis one.

The genuine defensive takeaway for product teams is resilience engineering: how does your IoT gadget, wireless keyboard, BLE sensor, or drone controller behave when the 2.4GHz band is saturated? Does it fail safe, retry gracefully, or lock up? Testing those questions in a shielded enclosure with controlled interference is a legitimate and valuable exercise, and it is the only context in which a project like ESP32-BlueJammer has a lawful home. Deploying it against networks, neighbors, drones, or any infrastructure you do not own is illegal radio interference, full stop, and nothing in this analysis should be read as licensing that use.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Inside ad_attack_architecture: mapping the Active Directory attack path from recon to domain dominance


• Inside EBurst: credential auditing across Exchange endpoints


• oss-scanner for automated vulnerability auditing of open-source repositories