---

8.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.

Figure 8.1 — The Marauder firmware on-device. Source: github.com/justcallmekoko.

8.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.1 page 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.

8.3 Community Deauther forks

Several active forks of Spacehuhn’s repo exist. The interesting ones:

Table 1 — 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.

8.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.

8.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.

8.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.

8.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.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)

8.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.

8.10 Decision matrix

Table 2 — 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

Recommended default: stay on Spacehuhn 2.6.1 (or upgrade to 2.7.x via Vol 9 procedure). 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.

8.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.