# Bruce firmware for ESP32: what it does and how to flash it

> Bruce is an ESP32 firmware that bundles WiFi, BLE, RF, RFID, IR and NRF24 tooling behind a device menu. It targets M5Stack, LILYGO and similar boards, and the README points to a web flasher or esptool.py for installation.

**BruceDevices/firmware** — Predatory ESP32 Firmware

- Repository: https://github.com/BruceDevices/firmware
- Website: https://bruce.computer
- Stars: 6,868 · Forks: 2,280
- Language: C++
- License: AGPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/brucedevices-firmware

## What Bruce is and who the firmware is built for

Bruce is an ESP32 firmware image, not an application you install on a desktop. The README describes it as "a versatile ESP32 firmware packed with offensive-security tools, built to make Red Team operations fast and portable." The audience is narrow and explicit: people doing wireless and RFID testing on handheld hardware, plus the hobbyist crowd that already carries M5Stack or LILYGO devices. The README names M5Stack, LILYGO, RockBase IoT and Elecrow as supported vendors, and calls out the Cardputer, Sticks, M5Cores, T-Decks and T-Embeds by name. The feature list is grouped by radio: WiFi, BLE, RF, RFID, IR, FM, NRF24, plus a JavaScript interpreter, QR codes, SD card management, a WebUI, Megalodon and BADUsb. That grouping is the whole product. There is no server component, no cloud account and no subscription mentioned in the README. You flash a board, and the tools live on the device. If you do not own one of the listed boards, the project has nothing for you.

## How the ESP32 firmware is organized: radios, menus and modules

The mechanism visible in the README is a menu-driven front end over per-radio modules. Each top-level feature maps to a hardware path. WiFi covers connect, AP mode, deauth, EvilPortal, wardriving, TelNet, SSH, RAW sniffer, TCP client and listener, host scanning with TCP port scanning, Responder, ARP spoofing and poisoning, and Wireguard tunneling. RF exposes a config block where you set RF TX pin, RF RX pin, RF module, and RF frequency; the module list includes the RF433 T/R M5Stack unit and the CC1101 sub-GHz module. RFID has its own config with PN532 and PN532Killer as supported modules, and the README marks tag emulation as unchecked, so that path is not implemented. IR lets you set Ir TX pin and Ir RX pin and replay NEC, NECext, SIRC, SIRC15, SIRC20, Samsung32, RC5, RC5X and RC6. NRF24 lists a jammer and a 2.4G spectrum, with Mousejack unchecked. The pattern across all of these is the same: pick a radio, point it at a pin or module, then run an action. That means two things. First, the firmware is only as capable as the modules you attach, so a bare board with no CC1101 or PN532 does less than the feature list suggests. Second, pin configuration is a user-facing setting rather than a fixed board definition, which is what lets one firmware image span many boards but also what makes a wrong pin assignment a silent failure.

## Installing Bruce: web flasher, esptool.py and M5Stack routes

The README states the easiest path is the official web flasher at bruce.computer/flasher. That is a browser-based flow, so there is nothing to build locally. The alternative is to download the latest binary from releases or actions and flash it with esptool.py. The README gives this exact command:

```sh
esptool.py --port /dev/ttyACM0 write_flash 0x00000 Bruce-<device>.bin
```

Replace the port with your own serial device and the filename with the binary that matches your board. Note the offset: the README writes at 0x00000. Do not reuse an offset from another ESP32 project without checking, because a wrong offset produces a board that does not boot.

For M5Stack hardware the README offers two more routes. If the device already runs M5Launcher, you can install Bruce over the air through that tool. Otherwise you can use the m5burner tool from M5Stack's download page, search for 'Bruce', and burn it to the matching device category. The README adds that official builds are uploaded by the user named "owner" and carry photos, which is the project's own way of distinguishing its images from third-party ones.

After flashing, the first thing to check is that the main menu renders and that a radio you actually own responds. A WiFi scan is the cheapest confirmation. If the menu appears but RF or RFID does nothing, the pin and module settings under the RF and RFID config menus are the first place to look, not the firmware version.

## Where Bruce firmware falls short

The README's own checkbox list is the most honest limitation document. Under RFID, Emulate tag is unchecked. Under FM, FM Spectrum, Hijack Traffic Announcements and Config are all unchecked. Under NRF24, Mousejack is unchecked. Those are advertised feature areas with gaps, and a reader who skims the headings without reading the boxes will overestimate what ships. There is a second, structural limitation: the firmware depends on external radio modules for several of its headline capabilities. The CC1101 and PN532 are separate purchases and separate wiring jobs. The README does not document a rollback procedure, so once you flash a board there is no stated way back to the stock firmware through this project's instructions. The AGPL-3.0 licence is also a real constraint for anyone embedding this in a product rather than using it personally; the repository carries LICENSE and THIRD_PARTY.md files, and the README does not attempt to summarize their terms. Finally, the offensive features are legally sensitive in most jurisdictions. The README frames the project around Red Team operations and does not include an authorization or compliance section, which means that judgement sits entirely with the user.

## Bruce compared with Flipper Zero firmware

The closest point of comparison in the README is Flipper Zero, and the project leans on it deliberately. The RF section links its custom sub-GHz feature as "replay payloads like Flipper," and the IR section uses the same phrasing. The RF REAPER devkit description mentions Flipper Zero and iButton header compatibility. The difference in approach is hardware. Flipper Zero is a single closed hardware target with a fixed radio set; Bruce is one firmware that spreads across many ESP32 boards from M5Stack, LILYGO, RockBase IoT and Elecrow. That trade shows up in the config menus. Because Bruce runs on so many boards, it exposes RF TX pin, RF RX pin, RF module and RF frequency as settings you may have to adjust, whereas a single-target device can hard-code those. The upside is cost and availability: if you already own a Cardputer or a T-Embed, you are not buying a second handheld. The downside is that support quality varies by board, and the README does not publish a compatibility matrix beyond the vendor and model names it lists.

## Building from source and the Docker build path

The repository is a PlatformIO project. The top level contains platformio.ini, build.py, src/, include/, lib/, boards/ and several custom partition CSVs (custom_4Mb.csv, custom_4Mb_full.csv, custom_8Mb.csv, custom_16Mb.csv), which is what you would expect for firmware that has to fit different flash sizes. There is also a docker-compose.yml that defines a platformio_build service, building from docker/Dockerfile.ci with the repository mounted at /work. The environment block in that file shows an optional override, PIO_ENVS=m5stack-cplus2, and sets PLATFORMIO_CORE_DIR=/root/.platformio. The service command is bash docker/run_all_envs.sh, so the intended flow is to build every environment rather than one. Two named volumes, pio_home and pio_build, persist the PlatformIO core and the .pio build directory between runs. If you only want to run Bruce, this path is unnecessary; the README's flasher route is shorter. Building from source matters when you are patching a feature or targeting a board that has no prebuilt binary in releases. The README does not document the build steps beyond pointing at releases and actions, so the docker-compose.yml file is the concrete starting point rather than the prose.

## Release cadence, licence and what upgrading costs you

The release history shows 1.15 on 2026-05-25, 1.16 on 2026-07-24 and 1.16.1 on 2026-08-11, with the last push to the repository on 2026-09-18. That is a steady cadence of roughly every one to two months across the visible releases, and the repository is not archived. The practical upgrade cost is low if you use the web flasher or M5Launcher, because both replace the image without a toolchain. It is higher if you build from source, because you are rebuilding every PlatformIO environment through the Docker service. Configuration you set on the device, such as RF TX pin, RF RX pin, RF module, RF frequency and the IR pins, is the part to check after any upgrade, since a fresh image may not carry the same settings forward and the README does not describe a migration path. On licensing, the repository is AGPL-3.0 and ships LICENSE and THIRD_PARTY.md. The README does not explain what that means for redistribution, and this article is not legal advice. What can be said plainly is that AGPL-3.0 is a copyleft licence with network-use provisions, so anyone planning to ship Bruce inside a product or expose it as a service should read LICENSE and THIRD_PARTY.md before assuming the terms are permissive.

## Conclusion

Bruce suits red teamers and hardware tinkerers who already own a supported M5Stack, LILYGO, RockBase IoT or Elecrow board and want a menu-driven toolset without building it themselves. It is the wrong choice if you need a long-term guaranteed support window, if you cannot accept AGPL-3.0 obligations, or if your hardware is not on the supported list. Before flashing, verify the exact device binary name in the releases, the flash offset your board needs, and whether an M5Stack device can be updated through M5Launcher or m5burner instead of a wired flash.

## FAQ

### How do I install Bruce firmware on an ESP32 board?

The README says the easiest route is the official web flasher at bruce.computer/flasher. Alternatively you can download the latest binary from releases or actions and flash it locally with esptool.py at offset 0x00000.

### Which boards does Bruce firmware support?

The README lists M5Stack, LILYGO, RockBase IoT and Elecrow products, and names the Cardputer, Sticks, M5Cores, T-Decks and T-Embeds as devices it works well with.

### Is Bruce firmware free to use?

The repository is licensed AGPL-3.0 and includes LICENSE and THIRD_PARTY.md files. The README does not summarize the licence terms, so read those files if you plan to redistribute it or run it as a service.

### Does Bruce firmware support NFC tag emulation?

No. The RFID section of the README lists Emulate tag as unchecked, while read, clone, write, erase, save and load are checked.

### Can I update Bruce firmware over the air on an M5Stack device?

The README states that if you already use M5Launcher to manage your M5Stack device, you can install it with OTA. Otherwise you can burn it from the m5burner tool by searching for 'Bruce'.

## Sources

- [BruceDevices/firmware on GitHub](https://github.com/BruceDevices/firmware)
- [License: AGPL-3.0](https://github.com/BruceDevices/firmware/blob/main/LICENSE)
- [Project website](https://bruce.computer)
- [README](https://github.com/BruceDevices/firmware/blob/main/README.md)
- [Releases](https://github.com/BruceDevices/firmware/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/brucedevices-firmware