Hak5 WiFi Pineapple Volume 5 — The Firmware Foundation

Contents

Section	Topic
1	About this volume
2	OpenWrt — the base every Pineapple is built on
3	The Hak5 firmware stack — what’s layered on OpenWrt
4	Campaigns — the automation + reporting engine
5	Cloud C2 — remote command and control
6	Firmware lifecycle — updates, versions, “which is best”
7	The closed-firmware reality + what the community can still do
8	SSH and the OpenWrt layer underneath
9	Resources

---

1. About this volume

Every WiFi Pineapple — Mark VII, Pager, Enterprise — runs the same kind of software stack: a highly modified OpenWrt at the base, the Pineapple firmware (PineAP + the web UI + modules) layered on top, Campaigns for automation, and Cloud C2 for remote operation. This volume is the foundation for understanding all of it; the per-model volumes (9-15) then cover each model’s specific firmware build, version, and quirks.

The key conceptual point: the Pineapple is a hardware + firmware co-design. Unlike the ESP32 tools in this hub — where the hardware is generic and the firmware is swappable (Marauder, Bruce, Ghost ESP all run on the same board) — the Pineapple’s firmware is purpose-built for that hardware and is the product. There is no “alternative Pineapple OS.” The firmware is the Pineapple.

---

2. OpenWrt — the base every Pineapple is built on

OpenWrt is the well-known open-source Linux distribution for embedded networking hardware — routers, APs, gateways. It gives you a real Linux userland, a package manager (opkg), the wireless stack with mac80211 / cfg80211, hostapd for AP functions, and a build system for cross-compiling to MIPS/ARM network SoCs. It is the de-facto base for “I need a small Linux box that does Wi-Fi well.”

Hak5 builds every Pineapple on a “highly modified version of OpenWrt on purpose-built hardware.” That phrase carries weight:

• “Highly modified” — it is not stock OpenWrt with an app bolted on. Hak5 patches the wireless stack and hostapd (the lineal descendant of the original 2008 KARMA patches — Vol 2 § 2), customizes the kernel and drivers for the specific radios, and replaces the management UI entirely.
• “Purpose-built hardware” — the OpenWrt build is matched to that model’s exact SoC, radios, and board. A Mark VII build and an Enterprise build are different OpenWrt builds for different silicon.

   The Pineapple software stack
   ════════════════════════════════════════════════

   ┌──────────────────────────────────────────────┐
   │  Pineapple web UI  ·  modules  ·  Campaigns   │  ← what you operate
   ├──────────────────────────────────────────────┤
   │  PineAP engine  (Vol 3)                       │  ← the attack/recon core
   ├──────────────────────────────────────────────┤
   │  Hak5-patched hostapd + wireless stack        │  ← the KARMA lineage,
   │  (mac80211 / cfg80211, model-specific drivers)│     patched in
   ├──────────────────────────────────────────────┤
   │  Modified OpenWrt — Linux kernel + userland   │  ← the base OS
   │  + opkg, SSH (dropbox), the usual OpenWrt kit │
   ├──────────────────────────────────────────────┤
   │  Purpose-built hardware (per model, Vol 7)    │  ← MIPS or ARM SoC + radios
   └──────────────────────────────────────────────┘

Why OpenWrt and not something else: OpenWrt already solves the hard parts of being a Linux access point — the wireless stack, hostapd, the small-footprint userland, the cross-build toolchain. It’s also familiar to the networking-security community, which means an operator who SSHes in (§ 8) finds a system they recognize. Hak5 spends its engineering on the Pineapple-specific layer, not on re-solving “be a Linux router.”

---

3. The Hak5 firmware stack — what’s layered on OpenWrt

On top of the OpenWrt base, the Pineapple firmware adds the things that make it a Pineapple:

Layer	What it is	Covered in
The patched wireless stack	Hak5’s modifications to hostapd / the 802.11 path — the descendant of the 2008 KARMA patches — that let the device be any network	Vol 2 § 2, Vol 3
The PineAP engine	The coordinated sniffing + injection engine: recon, Allow Associations, beacon response, SSID-pool broadcast, capture, deauth, handshake capture, targeting	Vol 3 (the full catalog)
The web UI	The browser-driven management + operation interface — dashboards, recon views, PineAP config, client management	Vol 6
The module / app system	The extensibility layer — install modules to add capability to the web UI	Vol 6
Campaigns	The automation + reporting engine — scripted, scheduled audits → reports	§ 4 below
Cloud C2 client	The enrollment + remote-control hooks that connect the device to a Hak5 Cloud C2 server	§ 5 below
Recent feature set	Enhanced Recon, Automatic Handshake Capture, Improved Deauth, Management UI Firewall, WPA-Enterprise Attacks, Revamped Campaigns	per-model firmware volumes

The “recent feature set” line is worth noting now: Hak5 ships meaningful firmware features over the life of a model. Enhanced Recon, Automatic Handshake Capture, Improved Deauth, the Management UI Firewall (a defensive hardening of the device’s own management interface — important, see Vol 8), WPA-Enterprise Attacks, and Revamped Campaigns are all relatively recent additions. The per-model volumes track which firmware version a given model is on and what it exposes.

---

4. Campaigns — the automation + reporting engine

Campaigns is the feature that makes the Pineapple a professional instrument rather than a manual hacking toy.

What it is: a Campaign is a scripted, repeatable, schedulable wireless audit. Instead of an operator manually clicking through recon → PineAP → capture → review, a Campaign runs a defined workflow — on demand or on a schedule — and emits a report.

Why it matters across the hat-colors (Vol 4):

• Pentest (Vol 4 § 5) — a Campaign report is engagement evidence. It goes into the deliverable. Repeatability means a follow-up audit can be compared against the baseline.
• White-hat audit — “run the wireless audit every week and tell me if anything changed” is a Campaign on a schedule.
• Blue team (Vol 4 § 7) — a scheduled recon Campaign watching your own airspace is a standing intrusion-detection sweep that produces a paper trail.

The shape of a Campaign: define what it does (recon scope, which PineAP behaviors, capture targets), define when it runs (on-demand or scheduled), let it run, collect the report. Hak5’s “Revamped Campaigns” is a recent overhaul of this engine — the per-model firmware volumes cover the current UI.

The discipline reminder: a Campaign that includes active PineAP techniques (Vol 3 right-of-the-line) is still bound by Vol 4’s authorization rule. Automating an attack doesn’t authorize it. A Campaign scoped via Source/Target MAC to authorized assets is a pentest tool; a Campaign doing broadcast-target PineAP on a schedule is automated unauthorized access.

---

5. Cloud C2 — remote command and control

Hak5 Cloud C2 is Hak5’s self-hostable command-and-control server for their gear — not just Pineapples, but the whole Hak5 fleet. For the Pineapple specifically:

What it does: you enroll a Pineapple into a Cloud C2 server (you run the server — it’s software you host). Once enrolled, you can command and control the device remotely over the internet — view its recon, drive its PineAP, pull its captures, manage it — without a local connection to the device.

Why it exists: the deployment shapes that need it —

• A Pineapple left on-site during a multi-day engagement, operated remotely.
• An Enterprise rack-mounted permanently, managed from elsewhere.
• A fleet of Pineapples across multiple sites, managed from one console — this is the agency/firm use case the Enterprise is built for, and Vol 19 covers fleet operation.

Enrollment is uniform: per Hak5, a Mark VII (or any model) “enrolls into Hak5 Cloud C2 the same way as any other Pineapple.” The C2 relationship is a platform feature, not a per-model one.

The security weight of C2: Cloud C2 is, by definition, a remote-access channel into a device whose entire job is intercepting Wi-Fi. That makes the C2 server itself sensitive infrastructure — Vol 8 § OPSEC treats the C2 server, its enrollment tokens, and its network exposure as part of the engagement’s attack surface. A compromised C2 server is a compromised fleet of interception devices.

---

6. Firmware lifecycle — updates, versions, “which is best”

tjscientist asked “what firmware is available and which is best.” The honest answer for the Pineapple is different from the ESP32 tools:

There is one firmware per model: Hak5’s. Unlike the ESP32 world (Marauder vs Bruce vs Ghost ESP — a real choice), the Pineapple has no alternative-firmware ecosystem. The firmware is the product. So “which firmware is best” collapses to “run the current stable Hak5 release for your model.”

The lifecycle:

• Hak5 ships firmware updates over a model’s life — bug fixes and genuine new features (the § 3 “recent feature set” arrived this way).
• Updates are delivered through the device (web UI update flow) — the per-model volumes cover the exact mechanism.
• Newer is generally better here — because there’s only one firmware line per model, updates are pure improvement, not a fork choice. The exception is the standard one: don’t update into an active engagement; lock to a known-good version for the engagement window, update in maintenance time (the same discipline as every other tool in this hub).

“Which is best” across models is a different question — that’s Vol 16’s model comparison. Within a model: current stable Hak5 firmware, full stop.

The version-tracking job: the per-model volumes (9-15) record what firmware version each model ships with and what features that version exposes — and a doc-audit pass (the project’s audit skill) should re-check those, because Hak5 iterates and a deep dive’s firmware claims age.

---

7. The closed-firmware reality + what the community can still do

The Pineapple firmware is closed. Hak5’s modified OpenWrt + PineAP is not open-source the way OpenWrt itself is. You cannot fork the Pineapple OS, you cannot build it from source, you cannot swap it for a community distro. This is a real constraint and it should be stated plainly:

• You are dependent on Hak5 for firmware updates, bug fixes, and new features. A model’s useful life is partly tied to how long Hak5 supports it (and Vol 2 § 5 noted Hak5’s history of supply-chain-driven generation changes).
• You cannot audit the firmware the way you can audit open firmware — you’re trusting Hak5’s implementation of an interception device.

What the community can still do:

• Modules. The module/app system (Vol 6) is the sanctioned extensibility surface. The community writes and shares Pineapple modules. This is where community contribution lives.
• The OpenWrt layer. SSH into the device (§ 8) and you’re in a real OpenWrt system — you can install opkg packages, run standard Linux tooling, script against the device. The base is open even though the Pineapple layer is not.
• Host-side everything. Captures come off the device; all the analysis tooling (Vol 19) is open and community-driven.
• Hardware mods. Antennas, batteries, cases, cooling — the physical layer is wide open. Vol 18 is the mods catalog.

So “the community” contributes at the module, OpenWrt-package, host-tooling, and hardware layers — just not at the core-firmware layer. That’s a meaningfully different openness profile than the ESP32 tools, and it’s a factor in the Vol 16 buy analysis.

---

8. SSH and the OpenWrt layer underneath

For an engineer like tjscientist, the most important practical fact in this volume: you can SSH into a Pineapple and it’s a real OpenWrt box.

The web UI is the intended operating surface, and for most work it’s sufficient. But underneath, every Pineapple runs OpenWrt with an SSH server (dropbear), and SSHing to the management interface drops you into a familiar Linux environment:

   ssh root@<pineapple-management-ip>

   # You land in OpenWrt. Available to you:
   #   - opkg          install OpenWrt packages
   #   - the wireless stack — iw, iwconfig, the wlanN interfaces
   #   - hostapd / wpa_supplicant config
   #   - standard Linux: cron, scripting, tcpdump, scp for pulling captures
   #   - the Pineapple's own filesystem layout, logs, capture directories

What this is good for:

• Pulling captures for host-side analysis (Vol 19) — scp the .pcap / handshake files off.
• Scripting beyond what the web UI exposes — cron jobs, custom capture workflows.
• Debugging — when the web UI says something cryptic, the OpenWrt logs say what actually happened.
• Understanding the device — the radio role assignments (Vol 7), the interface naming (wlan0/wlan1/…), the PineAP daemon’s actual process — all visible from the shell.

The caution: SSH is also a management-surface attack vector. The recent firmware’s Management UI Firewall exists partly to harden the device’s own management interfaces. Don’t expose the Pineapple’s SSH/management interface to untrusted networks; treat it like any other root-shell-on-the-internet risk. Vol 8 § OPSEC covers the device’s own attack surface.

---

9. Resources

The firmware base + stack

• OpenWrt: https://openwrt.org — the open-source base
• Hak5 docs (Pineapple firmware + features): https://docs.hak5.org/wifi-pineapple/
• Hak5 Cloud C2 docs: https://docs.hak5.org/cloud-c2

Within this series

• Vol 3 — the PineAP engine that sits on this stack
• Vol 6 — the web UI + module ecosystem (the top of the stack)
• Vol 7 — the purpose-built hardware the firmware is matched to
• Vol 8 — the device’s own attack surface (management UI, SSH, C2 server)
• Vol 19 — host-side tooling + Cloud C2 fleet operation
• Per-model volumes (9-15) — each model’s specific firmware build + version + quirks

Cross-tool

• ESP32 Marauder Firmware deep dive — the contrasting model: generic hardware, swappable open firmware. Useful to understand what the Pineapple’s closed co-design trades away and gains:

This is Volume 5 of a 21-volume series. Next: Vol 6 covers the web UI and the module/app ecosystem — the surface you actually operate the device through, how modules extend it, and what the community module landscape looks like.