ESP32-DIV: a multi-band wireless toolkit on the ESP32-S3

What ESP32-DIV actually is, and who reaches for it

The README describes ESP32-DIV as an open-source, multi-band wireless toolkit built on the ESP32-S3, covering Wi-Fi, BLE, 2.4GHz, Sub-GHz, IR, RFID/NFC and GPS from one handheld device with a touchscreen UI. That sentence is the whole pitch, and it also explains the audience. This is not a library you import into a product. It is firmware plus hardware: the repository carries an ESP32-DIV/ directory for the sketch, Libraries/, PCB/, Schematic/, Graphics/, docs/ and a Pre-compiled Bin/ folder.

The person who gets value here is already comfortable with ESP32 boards and wants one device that replaces a bench of separate radios. The Wi-Fi side alone lists eleven tools, from a packet monitor with optional PCAP logging to SD, through a beacon spammer and deauth attack, to a captive portal and a Karma attack. The BLE side lists nine, including a BLE Rubber Ducky that executes scripts from /ducky on the SD card, and a Skimmer Detect mode that scans for BLE signatures matching known card skimmer profiles.

The defensive entries matter as much as the offensive ones. Deauth Detector, Jamming Detector and Skimmer Detect are receive-side tools, and the Sub-GHz section labels the jamming detector as a receive-only monitor for car-fob jamming. If you are evaluating this project for a lab rather than a red-team kit, those three names are where to start reading. The README also carries a warning block stating the project is intended for educational and research purposes only and that unauthorized use may violate local laws. That is the only legal guidance in the README, and it is a disclaimer, not a usage policy.

How the toolkit is organised: one firmware, many radios

The architecture visible from the repository is a single firmware image that multiplexes several radio peripherals behind a touchscreen menu. The ESP32-S3 provides Wi-Fi and BLE natively. The 2.4GHz and Sub-GHz sections imply additional radio hardware, since the README lists a 2.4GHz scanner across 128 channels and Enhanced ShockBurst capture, which is NRF24 territory, alongside Sub-GHz replay, jamming and De Bruijn brute force. IR, RFID/NFC and GPS are separate peripherals again.

That means the project is really a menu system plus a set of drivers, not a single protocol stack. The Device & System section confirms it: Serial Monitor mirrors serial traffic on the TFT for field debugging, SD File Manager browses the card, Update Firmware flashes new firmware from SD, and Touch Calibrate handles the display. Those four entries exist because the device has to be usable without a laptop attached.

Storage ties the tools together. PCAP logging goes to SD, BLE Rubber Ducky scripts live in /ducky on SD, IR captures are saved to SD, Sub-GHz saved profiles are stored and managed, and the Wardriver logs GNSS position with Wi-Fi and BLE observations to SD. If you plan to use more than one mode in a session, the SD card is the shared state between them. The repository also ships a wigle.example.txt at the top level, which suggests the Wardriver output is meant to be compatible with WiGLE-style logging, though the README does not spell out the format.

One structural detail worth noting: the README points to a Wiki for the complete project story, in-depth tutorials and all the features. The README itself is a feature index. Anything about wiring, pin maps or build flags lives behind that link, and the README does not reproduce it.

Flashing ESP32-DIV without an IDE, and a first Wi-Fi scan

The README offers two entry points. The fastest is the browser flasher: the README states you can skip the IDE and flash directly from your browser at cifertech.github.io/ESP32-DIV. The repository also contains a Pre-compiled Bin/ directory if you would rather flash a binary yourself. The README does not document a rollback procedure, so keep a known-good binary before you overwrite anything.

If you prefer to build from source, the repository layout points at the Arduino toolchain: the ESP32-DIV/ directory holds the sketch, and Libraries/ holds the dependencies. The README does not list the exact board settings, so treat the following as the shape of the workflow rather than a verified recipe, and confirm the board target and partition scheme against the Wiki before you compile.

git clone https://github.com/cifertech/ESP32-DIV.git
cd ESP32-DIV
ls ESP32-DIV Libraries "Pre-compiled Bin"

That command sequence clones the repository and shows the three directories you will work with: the sketch, the libraries to install, and the pre-built binaries. If the sketch fails to compile, the missing dependency is almost always in Libraries/.

Once the device boots, the touchscreen menu is the interface. A reasonable first real use is the Wi-Fi Scanner, which the README says lists nearby networks with extended details. It is read-only, it needs no authorization beyond being in range, and it confirms that the display, touch input and Wi-Fi radio all work before you touch anything more aggressive.

# After flashing, the device boots into the touchscreen menu.
# Navigate to Wi-Fi > Wi-Fi Scanner to confirm the radio and display work.
# For packet captures, insert an SD card and enable PCAP logging
# in Wi-Fi > Packet Monitor.

The Packet Monitor is the next step up: the README describes a real-time waterfall graph across all 14 channels with optional PCAP logging to SD. If you want files you can open in Wireshark later, that is the mode to use, and the SD card has to be present before you start.

Where ESP32-DIV is the wrong tool

The first limitation is hardware. The README describes a device with a touchscreen, an SD card, Sub-GHz, IR, RFID/NFC and GPS radios, but the repository does not document which modules, which pins, or which board revision. The PCB/ and Schematic/ directories exist, so the information is presumably there in schematic form, but a reader who wants a parts list from the README will not find one. If you are not prepared to read a schematic or follow the Wiki, this project will stall at the hardware stage.

The second is that this is a menu-driven firmware, not a scriptable framework. There is no documented CLI, no API surface and no headless mode in the README. Every tool is reached through the touchscreen. If your workflow is automated testing in CI, or you want to drive the radio from a Python script, ESP32-DIV does not offer that path, and you would be better served by a library that exposes the ESP32 radio directly.

The third is legal and operational. The feature list includes deauthentication attacks, beacon spamming, probe flooding, BLE jamming, Sub-GHz jamming, Karma attacks and AirTag spoofing. Running any of those outside a controlled environment is a different activity from testing your own gear, and the README's warning does not draw the line for you. A team that needs a device with a documented acceptable-use posture will not find one here.

Finally, the README does not document rollback, recovery from a bad flash, or what happens if the firmware update from SD is interrupted. Update Firmware is listed as a tool, and the failure mode of that tool is not described.

ESP32-DIV against Flipper Zero and ESP32 Marauder

The two comparisons people search for are ESP32-DIV vs Flipper Zero and ESP32-DIV vs Marauder, and the difference in each case is architectural.

Flipper Zero is a finished consumer device with its own firmware and its own enclosure. ESP32-DIV is a firmware project plus PCB and schematic files, built on the ESP32-S3. If you want a device that arrives assembled and updates through a vendor tool, Flipper is the closer fit. If you want to modify the firmware, add a radio, or build the board yourself, ESP32-DIV is the one that hands you the PCB directory. The trade-off is time: ESP32-DIV assumes you can source parts and flash a board.

ESP32 Marauder is the closer comparison, because both are ESP32 firmware projects in the same space. The README positions ESP32-DIV as multi-band: Wi-Fi, BLE, 2.4GHz, Sub-GHz, IR, RFID/NFC and GPS. That breadth is the distinguishing claim. Marauder's focus, as its name suggests, is narrower. If your work is Wi-Fi and BLE only, the wider radio coverage of ESP32-DIV is hardware you pay for and do not use. If you need Sub-GHz replay, IR capture or RFID reads on the same handheld, the breadth is the reason to pick it.

There is also a version question in the search data: people look for ESP32-DIV v1 vs v2, and for v2 boards, cases and batteries. The README describes the project as ESP32-S3 based and does not break the feature list down by hardware revision. Anyone buying parts should treat the Wiki, not the README, as the source for which revision supports which radio.

Licence, maintenance and the cost of keeping up

The repository is MIT licensed, and the README repeats that in its badge line. MIT is permissive: you can reuse the code, modify it and redistribute it, provided the copyright notice and permission notice are preserved. That matters here because the project mixes firmware with PCB and schematic files, and the licence file at the top level is the one to read for the terms that actually apply. Nothing in the README separates the hardware design files from the code for licensing purposes, so if you intend to manufacture boards, read LICENSE and the repository contents yourself rather than assuming one licence covers every directory. This is not legal advice.

On maintenance, the last push to the default branch was on 2026-09-22, and the most recent release is v1.7.2 from 2026-08-06, preceded by v1.7.0 on 2026-06-12 and v1.6.0 on 2026-05-13. The release cadence across those three versions is roughly two months apart, and the repository is not archived. That pattern is consistent with a project that is still being worked on, but the README does not publish a support policy, a deprecation schedule or a compatibility matrix for older hardware revisions.

The upgrade cost is the part to think about before you commit. Firmware updates are delivered as binaries, including through the SD-card Update Firmware tool, and the README does not describe a rollback path. If a new release changes a tool's behaviour, your only documented recovery is to flash a binary you kept. Budget for that: keep the Pre-compiled Bin/ contents for the version you validated, and test a new release on a spare board before moving your working device.

Editorial conclusion

Adopt ESP32-DIV if you already build ESP32 hardware and want a single firmware image covering Wi-Fi, BLE, 2.4GHz, Sub-GHz, IR, RFID and GPS, and you accept that the repository ships firmware, PCB files and a wiki rather than a finished product. Do not adopt it if you need a supported appliance with a warranty, or if your work cannot tolerate a firmware whose tool list includes deauthentication, jamming and spoofing. Before flashing anything, verify that your board matches the ESP32-S3 target, that the TFT and touch controller are supported, and that you have written authorization for every network and device in range.

Frequently asked questions

Official sources

1. cifertech/ESP32-DIV on GitHub
2. License: MIT
3. Project website
4. README
5. Releases