Wi-Fi Pineapple · Volume 9

Hak5 WiFi Pineapple Volume 9 — Mark VII: Hardware & Electronics

The 7th-generation baseline — single-core MIPS SoC, three role-based radios, the board, the ports, the antennas

Contents

SectionTopic
1About this volume
2The Mark VII at a glance
3The SoC and compute
4The three role-based radios
5Antennas and RF
6Ports, power, indicators
7The board and enclosure
8Mark VII vs Mark VII 2.0 — the hardware revisions
9Resources

1. About this volume

Vol 9 opens Phase 2 — the per-model deep dives — with the Mark VII, the 7th-generation baseline that everything else in the line is measured against. This volume is the hardware/electronics treatment; Vol 10 is the firmware + operation + mods + use cases for the same device.

Vol 7 (the generic hardware architecture) is the pattern; this volume is the specific instance. Read Vol 7 first if you have not — the role-based radio model, the networking-SoC-plus-dedicated-radios design, the chipset landscape — because the Mark VII is the cleanest, most stripped-down realisation of all of it. There is nothing extra on a Mark VII: it is the foundation made physical.

All specs here are research-baseline (docs.hak5.org / shop.hak5.org / community), since the Pineapple line is Aspirational — tjscientist does not own one yet. Verify against the actual unit on acquisition.


2. The Mark VII at a glance

┌─ WiFi Pineapple Mark VII ──────────────────────────────────┐
│ SoC        Single-core MIPS network SoC                    │
│ Memory     256 MB RAM · 2 GB eMMC                          │
│ Radios     3 role-based · MT7601U + MT7610U                │
│            2.4 GHz 802.11 b/g/n native                     │
│            5 GHz / 802.11ac via the MK7AC module (Vol 11)  │
│ Ports      USB-C (power + ethernet) · USB 2.0 host         │
│ I/O        3 high-gain antennas · 1 RGB LED                │
│ Power      USB-C — bus power or a USB battery pack         │
│ OS         Highly modified OpenWrt + PineAP (Vol 5)        │
│ Form       Small puck                                      │
└────────────────────────────────────────────────────────────┘

The Mark VII’s whole identity is in that box: it is deliberately modest. A single-core MIPS networking SoC, a quarter-gig of RAM, three small radios, one LED, a puck of plastic. It is not under-built — it is exactly built, for one job: be a web-UI-driven PineAP platform that an operator runs from a laptop. Everything heavy (cracking, deep analysis) is off-device by design (Vol 7 §7). The Mark VII is the front end; your laptop and a GPU box are the back end.

Figure 9.1 — The WiFi Pineapple Mark VII. The 7th-generation baseline and the unit the rest of the line is measured against — a small USB-C-powered puck with three high-gain antennas. Photo: Hak5 (…
Figure 9.1 — The WiFi Pineapple Mark VII. The 7th-generation baseline and the unit the rest of the line is measured against — a small USB-C-powered puck with three high-gain antennas. Photo: Hak5 (shop.hak5.org).

3. The SoC and compute

The Mark VII is built on a single-core MIPS network SoC — the class of processor that runs consumer and small-business routers. Paired with 256 MB of RAM and 2 GB of eMMC storage.

Why MIPS, why single-core, why modest — the design rationale from Vol 7 §2/§7, made concrete:

  • MIPS is the router-SoC architecture. The Pineapple’s firmware base is OpenWrt (Vol 5), and OpenWrt’s home is exactly this class of MIPS networking silicon. Choosing a router SoC means choosing a mature, well-supported software foundation — the radios, the network stack, the driver support are all solved problems on this platform. A more exotic processor would mean re-solving them.
  • Single-core is enough for the job. The Mark VII’s job is: drive three radios, serve a web UI, run the PineAP engine, run Campaigns. None of that is compute-bound. The PineAP engine is doing protocol work (responding to probes, managing associations — Vol 3), not number-crunching work. A single MIPS core keeps up with it.
  • 256 MB / 2 GB is enough for the job. RAM holds the running firmware, the web UI server, the recon state, the PineAP daemon’s working set. eMMC holds the firmware image, modules, Campaign definitions, captures-in-progress. Neither is generous — and neither needs to be, because the heavy artifacts (large packet captures, handshake-cracking) move off-device.
   The Mark VII compute envelope
   ════════════════════════════════════════════════════════

   ON the Mark VII (what the modest SoC handles fine):
     • driving 3 radios + role assignment
     • the PineAP engine — probe response, association mgmt
     • the web UI server
     • recon state, client tracking
     • Campaigns — scripted audit orchestration
     • capture-in-progress buffering

   OFF the Mark VII (what the modest SoC deliberately does NOT do):
     • cracking captured handshakes  -> a GPU host (Vol 19)
     • deep packet-capture analysis  -> Wireshark on your laptop
     • bulk long-term capture storage -> your machine

   The SoC is sized for the FRONT-END job. If a workflow
   feels compute-starved on a Mark VII, that is the design
   telling you the work belongs off-device — not a defect.

The operational consequence: a Mark VII never feels “slow” doing what it is for, and you should never try to make it do what it is not for. The compute ceiling is a design boundary, not a limitation to fight.


4. The three role-based radios

This is the heart of the Mark VII, and the cleanest example of Vol 7 §3’s role-based radio model in the whole line. The Mark VII has three radios, and the firmware assigns each a role:

RoleWhat that radio doesVol 3 / Vol 7 reference
Managementyour connection to the device — the radio you reach the web UI overVol 7 §3
PineAPbeing the rogue AP — running the PineAP engine, answering probes, hosting SSIDsVol 3 §6-8
Monitorrecon and injection — listening to the airspace, capturing, deauthingVol 3 §4-5, §9
   The Mark VII's three radios, assigned
   ════════════════════════════════════════════════════════

   +-- radio 1 --+  +-- radio 2 --+  +-- radio 3 --+
   | MANAGEMENT  |  |   PineAP    |  |  MONITOR    |
   | you <-> web |  |  rogue AP,  |  | recon,      |
   | UI          |  |  probe resp |  | capture,    |
   |             |  |             |  | deauth/inj  |
   +-------------+  +-------------+  +-------------+

   This separation is WHY a Pineapple can attack and observe
   AT THE SAME TIME — the thing a single-radio device
   fundamentally cannot do (Vol 7 §3). Three radios = three
   simultaneous jobs.

The chipsets (research-baseline): the Mark VII’s radios are built on the MediaTek MT76 family — an MT7601U (a 2.4 GHz single-band part) and an MT7610U (a dual-band-capable 1×1 part). The exact chipset-to-role mapping should be confirmed against the actual unit, but the operational fact is fixed: the Mark VII’s built-in radio coverage is 2.4 GHz. All three role-assignable built-in radios operate in the 2.4 GHz band.

The 5 GHz gap. This is the single most important hardware fact about the bare Mark VII: it does not do 5 GHz natively. Modern Wi-Fi — most current APs, increasingly WPA2/WPA3 networks — lives on 5 GHz. A 2.4-GHz-only Pineapple can recon and attack 2.4 GHz all day, but a 5-GHz-only target network is invisible to it. The fix is the MK7AC adapter — a USB MT7612U dual-band module that plugs into the USB 2.0 host port and adds a 5 GHz / 802.11ac monitor-and-injection radio (Vol 11 is the whole volume on it). The MK7AC is why the recommended first purchase is the Mark VII + AC Tactical kit and not the bare Mark VII (Vol 1 decision tree, Vol 16).


5. Antennas and RF

The Mark VII has three high-gain external antennas — one per built-in radio. They are removable (the standard SMA-class connector arrangement of this device class), which matters for two reasons:

  1. Antenna mods. Removable antennas mean the operator can swap in higher-gain or directional antennas for a specific engagement — covered in Vol 18 (the mods catalog). A directional antenna on the monitor radio, for instance, focuses recon on a specific direction.
  2. The legal note. Antenna gain affects effective radiated power, and effective radiated power is regulated (Vol 8 §5, Vol 20 §5). A high-gain antenna mod is a power decision as much as a range decision, and “transmissions don’t stop at the property line” applies harder with more gain.

The built-in three-antenna array gives the Mark VII solid 2.4 GHz coverage in all three roles simultaneously. When the MK7AC is added (Vol 11), it brings its own two high-gain RP-SMA antennas for the 5 GHz side — so a fully-kitted Mark VII + AC is a five-antenna device.


6. Ports, power, indicators

USB-C — power and ethernet over one connector. The Mark VII’s USB-C port carries both power and an ethernet interface. That is the connector you power the device through (from a host’s USB port, a wall adapter, or — for untethered operation — a USB battery pack) and the connector that carries the management network when you reach the web UI over USB ethernet.

USB 2.0 host port. A standard USB-A host port. Its single most important use is the MK7AC adapter (Vol 11) — the 5 GHz module plugs in here. It also accepts other USB Wi-Fi adapters and USB storage, within the modest power budget the Mark VII’s SoC can supply over it.

The RGB LED. One RGB status LED. It signals device state through colour/pattern — boot, ready, activity, error. It is the Mark VII’s only on-device output (contrast the Pager, Vol 12, which has a whole feedback subsystem). On a Mark VII engagement the LED is the only thing the device itself tells you; everything else is in the web UI.

Power and untethered operation. Because the Mark VII is USB-C powered and modest in draw, a USB battery pack runs it untethered — which is the basis of the field/wardriving use cases (Vol 10 §8, Vol 17 §2). It is not an integrated-battery device (that is the Pager — Vol 12); untethered Mark VII operation means “Mark VII plus a power bank in the bag.”

   The Mark VII's I/O surface — all of it
   ════════════════════════════════════════════════════════

   USB-C ---------- power IN + ethernet (the management net)
   USB-A (host) --- the MK7AC 5 GHz module / USB Wi-Fi / storage
   3x antenna ----- the three built-in 2.4 GHz radios
   1x RGB LED ----- the device's only on-board status output

   That is the entire physical interface. Everything else —
   every control, every readout — is in the web UI, reached
   over the USB-C ethernet (or the management radio, §4).

7. The board and enclosure

The Mark VII is a small puck — a compact plastic enclosure sized to be pocketable and unobtrusive, with the three antennas as the only thing that makes it look like more than a USB gadget. Inside: the MIPS SoC, the RAM and eMMC, the three radio sections with their RF front-ends and antenna network, the USB-C and USB-A interfaces, the LED.

The board layout follows the Vol 7 §2 pattern — a networking SoC at the centre, three radio sections each with its own RF path to an antenna connector, the USB interfaces. It is not a complicated board, because the Mark VII is not a complicated device; the complexity of a Pineapple is in the firmware (Vol 5, Vol 10), not the silicon.

[FIGURE SLOT — Vol 9, § 7] A Mark VII with the enclosure opened, or a board shot, showing the SoC + the three radio sections + the antenna connectors. Source: Photo Helper web search “WiFi Pineapple Mark VII teardown” / “Mark VII PCB”, or tjscientist’s own unit once acquired. (A representative Mark VII PCB image is in the foundation volumes — Vol 7 Figure 7.1.)

The puck form factor is a deliberate operational choice: small enough to deploy discreetly, plant, or carry; not so small that the three radios and their antennas have no room. The Pager (Vol 12) trades some of this for an on-device screen and battery; the Enterprise (Vol 14) abandons it entirely for a rack chassis. The Mark VII’s puck is the “bring it in a bag, run it from a laptop” form factor — the field-pentest default.


8. Mark VII vs Mark VII 2.0 — the hardware revisions

Hak5 has shipped a Mark VII 2.0 — a hardware refresh of the Mark VII. What a 2026 buyer needs to know:

  • It is the same device, refreshed — same role-based three-radio architecture, same web-UI-driven operating model, same firmware family. A “Mark VII 2.0” is a Mark VII; skills, payloads/Campaigns, and the entire Vol 10 operating treatment transfer.
  • The revision is incremental, not architectural — the kind of refresh that updates components and addresses production realities, not one that changes what the device is. (The exact component deltas are a research-baseline item — confirm against the actual unit and the current Hak5 product page.)
  • Firmware tracks the device family, not the revision — the Mark VII firmware (Vol 10 §3) — currently the 2.0 firmware line with Enhanced Recon, Automatic Handshake Capture, Improved Deauth, the Management UI Firewall, WPA-Enterprise Attacks, and Revamped Campaigns — runs on the Mark VII hardware family.

Buyer takeaway: in 2026, “WiFi Pineapple Mark VII” from Hak5 means the current hardware revision, and the recommended purchase is the Mark VII + AC Tactical kit (Vol 11) regardless of revision — because the MK7AC and the field kit matter more to capability than the revision delta does. The revision is a “confirm what you received” detail for the unit’s inventory record, not a buying-decision axis.

doc-audit note. When a Mark VII is acquired, the hardware revision, the exact radio chipset-to-role mapping, the SoC part number, and the firmware version should be read off the actual unit and recorded in MY_GEAR/inventory.yaml — at which point the research-baseline qualifiers throughout this volume can be replaced with bench-verified facts.


9. Resources

This is Volume 9 of a 21-volume series. Next: Vol 10 covers the Mark VII in operation — first boot and setup, the firmware build, the recon/PineAP/Campaigns workflows, detailed operating instructions, Hak5 and community mods, and the use cases where the Mark VII fits.