DSTIKE Hackheld · Volume 8
DSTIKE Hackheld Volume 8 — Other Firmwares
What else you can run on the same hardware — Marauder-ESP8266, ESPurna, Tasmota, NodeMCU, ESPHome, community Deauther forks
Contents
| Section | Topic |
|---|---|
| 1 | Firmware-as-decision |
| 2 | ESP8266 Marauder |
| 3 | Community Deauther forks |
| 4 | ESPurna |
| 5 | Tasmota |
| 6 | NodeMCU + Lua |
| 7 | ESPHome |
| 8 | Custom Arduino / PlatformIO |
| 9 | MicroPython on ESP8266 |
| 10 | Decision matrix |
| 11 | What’s next |
1. Firmware-as-decision
The Hackheld is a generic ESP-12 platform from a software standpoint — anything that builds for esp8266:esp8266:generic (Arduino) can run on it. Choosing a firmware is choosing a feature set, a UI metaphor, and a maintenance posture. The Spacehuhn Deauther (Vol 5) is the most-tested option for the Hackheld specifically, but it’s not the only sensible one.
2. ESP8266 Marauder
JustCallMeKoko’s ESP32 Marauder firmware (the headline ESP32 pentest platform) has an ESP8266 port — feature-reduced but real. Repo: github.com/justcallmekoko/ESP8266Marauder.
What it adds vs Spacehuhn:
- More attack types — including PMKID capture (in addition to deauth / beacon / probe).
- A more polished CLI command set.
- Marauder ecosystem compatibility — companion FAPs on the Flipper, web tools at marauder.io, shared community.
- Active development (Spacehuhn’s pace is slower).
What it removes:
- The web UI. ESP8266 Marauder is CLI-first; no
http://192.168.4.1page server in the same way. - The educational onboarding — Spacehuhn’s firmware ships a clean introductory experience; Marauder assumes you know what you’re doing.
Verdict for the Hackheld specifically: Marauder-ESP8266 is a meaningful upgrade if you mostly drive the device from a computer (CLI + Flipper companion FAP). It’s a downgrade if you mostly drive it standalone (Marauder’s button-driven on-device UI is less polished than Spacehuhn’s).
Flashing procedure (Vol 9 has details): web flasher at marauder.io → “ESP8266” → pick the matching board variant → flash. Backup your Spacehuhn settings first.
3. Community Deauther forks
Several active forks of Spacehuhn’s repo exist. The interesting ones:
| Fork | What it adds |
|---|---|
| DSTIKE’s own fork | The variant pre-flashed on Hackheld units; tracks upstream + adds DSTIKE-specific A_config defaults. Usually one minor version behind upstream. |
| Arc1z’s evil-portal fork | Adds a captive-portal evil-twin feature — when a victim connects to the SoftAP, a fake login page is served. Not officially supported. |
| Various educational forks | Slow-attack-rate-only versions for classroom use; remove ability to attack at high rate. |
None of these adds capabilities the underlying ESP8266 doesn’t support. They add UX or feature shape on top.
4. ESPurna
github.com/xoseperez/espurna — a serious-IoT firmware for ESP8266 / ESP32 boards. Smart-plug heritage; aimed at home automation.
Relevant to the Hackheld: turns it into a persistent Wi-Fi sensor / agent, not a pentest tool. You could write your own ESPurna plug-in to capture Wi-Fi data and report to an MQTT broker. Useful for the “wardriving without an operator” use case — leave a Hackheld powered on at home logging beacons to your home network’s MQTT.
Wouldn’t recommend as a default — but a legitimate platform choice if you want a robust IoT framework.
5. Tasmota
tasmota.github.io — Theo Arends’ firmware, originally for Sonoff smart switches; now supports ~3000 ESP-class devices. Like ESPurna, it’s an IoT framework.
The Hackheld is not officially listed as a Tasmota target, but it’s a generic ESP-12 and the firmware will build for it. Same caveat as ESPurna: not a pentest tool, but a viable substrate if you want the Hackheld to play in your home-automation ecosystem.
6. NodeMCU + Lua
nodemcu.com — The original Lua-on-ESP8266 firmware (predates Arduino-on-ESP8266). Lua is interpreted, garbage-collected, slow but very easy.
Use case: rapid scripting prototyping. You can SSH into the device’s Lua REPL over the serial console and write code interactively. Great for learning the platform; not great for production firmware.
Relevant note: the Spacehuhn firmware uses far less RAM than NodeMCU does — Lua’s interpreter consumes a big chunk of the 80 KB DRAM, leaving very little for custom code on the Hackheld.
7. ESPHome
esphome.io — YAML-driven firmware generator. You write a .yaml config describing your device’s behaviour; ESPHome generates and flashes a custom firmware. Home Assistant integration is the killer feature.
Could turn the Hackheld into a “Wi-Fi monitoring sensor” tile in Home Assistant. Niche but real.
8. Custom Arduino / PlatformIO
The catchall: build your own firmware from scratch using the Arduino-ESP8266 core, ESPAsyncWebServer, Adafruit_SSD1306, etc. Vol 10 and Vol 11 are the detailed walkthroughs.
This is the answer when you need exactly a feature the existing firmwares don’t have. Examples:
- A capture-handshake-and-upload-to-S3 firmware
- A Wi-Fi geofencing device that triggers an action when a specific MAC enters range
- A “deauth-but-only-against-my-own-test-devices” firmware with hardcoded MAC allow-list
- A Wi-Fi mapping device that logs to SD (would need SD card hardware, which the Hackheld lacks)
9. MicroPython on ESP8266
micropython.org — Python 3 syntax on the ESP8266. Faster than NodeMCU’s Lua but still substantially slower than compiled C++. Same memory-pressure caveats as NodeMCU.
Use case: rapid Python prototyping. Same niche as NodeMCU+Lua, different language.
10. Decision matrix
| Firmware | Use it for | Avoid if |
|---|---|---|
| Spacehuhn Deauther (default) | Day-to-day deauth / beacon / probe work; learning the platform; using the web UI | You want PMKID capture or Marauder-ecosystem features |
| ESP8266 Marauder | CLI-first pentest work; Flipper-driven attacks; PMKID capture | You want a polished on-device UI |
| ESPurna / Tasmota / ESPHome | Persistent IoT-style data collection; Home Assistant integration | You want a pentest tool |
| NodeMCU + Lua / MicroPython | Rapid scripting / learning the chip | You need full memory for custom code |
| Custom Arduino / PlatformIO | A feature none of the above has | You can solve it by configuring Spacehuhn or Marauder |
My recommendation for Jeff’s unit: stay on Spacehuhn 2.6.1 (or upgrade to 2.7.x via Vol 9 procedure) as the default. Keep a known-good Marauder-ESP8266 binary in apps/_archives/ so the swap is easy. Build custom code from scratch in apps/ for specific projects (Vol 10 / Vol 11), but don’t replace the stock firmware with a hand-rolled one unless there’s a clear reason.
11. What’s next
→ Vol 9 — Firmware Update Procedures — every flashing path: web flasher, esptool, Arduino IDE upload, recovery from a bricked state, downgrade procedures. The “how to switch between any of the firmwares in this chapter” reference.