Wi-Fi Pineapple · Volume 7

Hak5 WiFi Pineapple Volume 7 — Generic Hardware Architecture

The SoC, the role-based radio model, the antennas, and the MediaTek / Qualcomm chipset landscape that underlies all four current models

Contents

SectionTopic
1About this volume
2The architecture pattern — networking SoC + dedicated radios
3The role-based radio model — the defining design
4The chipset landscape — MediaTek MT76xx and Qualcomm IPQ
5Radio count as the model differentiator
6Antennas, RF, and the bands
7Compute, memory, storage — and why they’re modest
8Power and thermal across the form factors
9Resources

1. About this volume

This is the generic hardware picture — the architecture pattern every WiFi Pineapple follows, before the per-model volumes (9, 12, 14) get into each model’s specific board. Understand the pattern here and the per-model hardware volumes become deltas against it rather than four from-scratch treatments.

All specs are research-baseline (docs.hak5.org / shop.hak5.org, 2026-05) — Hak5 iterates hardware revisions, so part numbers should be re-verified on acquisition. The architecture, though — networking SoC plus role-assigned radios — is stable across the whole line and the whole history.


2. The architecture pattern — networking SoC + dedicated radios

A WiFi Pineapple is not built like a laptop or a Raspberry Pi. It’s built like what it is — a piece of networking equipment — and that shapes everything:

   The Pineapple hardware pattern
   ════════════════════════════════════════════════

   ┌─────────────────────────────────────────────┐
   │  Networking SoC                             │
   │  (MIPS on Mark VII · quad-core ARM Cortex-A7│
   │   on Enterprise) — optimized for moving      │
   │   packets, not for general compute           │
   │                                             │
   │   ┌────────┐  ┌────────┐  ┌────────┐  ...   │
   │   │ radio  │  │ radio  │  │ radio  │        │
   │   │  (a)   │  │  (b)   │  │  (c)   │        │
   │   └───┬────┘  └───┬────┘  └───┬────┘        │
   │       │           │           │             │
   └───────┼───────────┼───────────┼─────────────┘
           │           │           │
        antenna     antenna     antenna
           │           │           │
        ROLE:       ROLE:       ROLE:
        management  PineAP      monitor / recon
        (your link) (rogue AP)  / injection

   The radios aren't interchangeable peripherals — they're
   ASSIGNED ROLES. That assignment is the whole architecture (§ 3).

The SoC is a networking SoC — silicon designed to move 802.11 and Ethernet frames efficiently, not to run general workloads. The Mark VII uses a single-core MIPS network SoC; the Enterprise steps up to a 717 MHz quad-core ARM Cortex-A7. Either way, the design priority is radio throughput and packet handling, not desktop-class compute. The Pineapple doesn’t need to be fast at computing — it needs to be good at being several Wi-Fi radios at once.


3. The role-based radio model — the defining design

This is the single most important hardware concept in the entire series, so it gets its own section:

A WiFi Pineapple has multiple Wi-Fi radios, and each one is assigned a role. That role separation is what lets the device attack and observe simultaneously — which a single-radio device fundamentally cannot do.

The three canonical roles:

RoleWhat that radio doesWhy it must be dedicated
ManagementCarries your connection to the device — the link your browser/SSH rides onIf your management link shared a radio with PineAP, configuring the attack would keep knocking you off the device
PineAPIs the rogue AP — runs the PineAP daemon, sends beacons/probe-responses, hosts the associations (Vol 3 § 6-7)The PineAP daemon needs dedicated radio access; it conflicts with that radio being in client mode (Vol 3 § 7)
Monitor / recon / injectionListens to the airspace (recon, probe logging) and injects (deauth)Monitoring must happen while PineAP runs — different radio, different job, same moment

Why a single-radio device can’t be a Pineapple: a single radio can be a rogue AP, or it can monitor the airspace, or it can carry your management link — but not all three at once. It has to time-slice, and time-slicing means the rogue AP flickers, the monitor misses frames, and your link drops. The Pineapple’s role-based multi-radio design is the thing that makes the full Vol 3 attack chain run concurrently and reliably. It’s the architectural reason the Pineapple is a category of its own and not “an ESP32 with attack firmware.”

   Single radio (e.g. a basic ESP32 tool):     Pineapple (role-based):
   ──────────────────────────────────────      ────────────────────────
   one radio, time-slicing:                    radio A: management  ── always
     ▓ rogue AP ░ monitor ░ mgmt ▓ rogue...     radio B: PineAP      ── always
   everything flickers, frames missed,          radio C: monitor     ── always
   management link unstable                     all three, concurrently, stable

The operational consequence: mis-assigning radio roles breaks the attack chain — and the role-assignment UI lives in Settings (Vol 6 § 3). The per-model volumes give each model’s exact role map; the Enterprise’s five radios allow role assignments the Mark VII’s three simply can’t (§ 5).


4. The chipset landscape — MediaTek MT76xx and Qualcomm IPQ

The Pineapple’s radios are commodity Wi-Fi chipsets — specifically the ones with excellent open-driver support in the security community. The docs note that “chipsets from Atheros and MediaTek have excellent support” — that driver-support quality is why these chipsets are chosen. A radio is only useful for monitor mode + injection if its driver supports those modes well, and the MediaTek MT76 family and the Qualcomm/Atheros lineage are the community’s well-trodden ground.

The chipsets across the current line (research-baseline):

ChipsetFamilyBandsUsed inNotes
MT7601UMediaTek MT76, single-band2.4 GHz b/g/nMark VIIOne of the Mark VII’s role radios
MT7610UMediaTek MT762.4 / 5 GHz a/b/g/n/ac (1×1)Mark VIIOne of the Mark VII’s role radios
MT7612UMediaTek MT762.4 / 5 GHz a/b/g/n/ac, 866 Mbps (2×2)MK7AC adapter (the +AC kit); Enterprise (×3)The “AC” workhorse — dedicated dual-band monitor + injection
Qualcomm IPQ4019Qualcomm integrated2.4 / 5 GHz 802.11ac Wave 2, MU-MIMO, TxBF, 1.733 GbpsEnterprise (Radio0/1)The Enterprise’s high-throughput radios — also effectively its SoC-integrated networking silicon

A few things to read out of that table:

  • The MT76 family is the spine. MT7601U, MT7610U, MT7612U — all MediaTek MT76. The Pineapple’s radio strategy is “use the well-supported MediaTek parts.”
  • MT7612U is the recurring workhorse. It’s what the MK7AC adapter is (the thing that gives a Mark VII 5 GHz — Vol 11), and it’s three of the Enterprise’s five radios. If you understand the MT7612U, you understand the dual-band-ac capability across most of the line.
  • The Enterprise mixes silicon. Two Qualcomm IPQ4019 radios (high-throughput, Wave 2, MU-MIMO) plus three MT7612U radios — five total, deliberately heterogeneous so different radios can take different roles at different performance tiers.
  • The Pager is tri-band (2.4/5/6 GHz) + Bluetooth — its exact radio silicon is a per-model research item (Vol 12), but the architecture point holds: a dual-radio array, role-assigned, plus a BT radio.

5. Radio count as the model differentiator

Once you have the role-based model (§ 3), the four models line up cleanly by radio count and capability — that’s the real spec axis:

   Radio count → what role assignments are possible
   ═══════════════════════════════════════════════════

   Mark VII        3 radios   ── mgmt + PineAP + monitor.
   (2.4 GHz native)            The classic three roles, exactly
                               filled. 5 GHz needs the MK7AC.

   Mark VII +AC    3 + MK7AC   ── the three, plus a dedicated
                               dual-band ac monitor/inject radio.
                               Now 5 GHz audit is real (Vol 11).

   Pager           dual-radio  ── a 2-radio array, tri-band
                   array + BT   2.4/5/6 GHz, plus Bluetooth.
                               Roles are tighter — it's the
                               portable, not the maximal (Vol 12).

   Enterprise      5 radios    ── 2× IPQ4019 + 3× MT7612U. Enough
                               radios to dedicate roles AND run
                               multiple PineAP/monitor instances,
                               cover more channels at once, and
                               handle ~100 clients (Vol 14).

This is why Vol 1 said the line is “a matrix, not a ladder.” The Mark VII fills the three canonical roles. The Enterprise doesn’t just “do the same thing faster” — five radios let it do things three radios can’t: monitor more channels concurrently, run more PineAP instances, dedicate a radio to client-population handling. The Pager goes the other way — fewer radios, but tri-band and pocket-sized. Radio count isn’t a quality score; it’s a capability shape.


6. Antennas, RF, and the bands

Antennas: the Mark VII ships with three high-gain antennas — one per radio. External, usually removable (RP-SMA-class), which means they’re an obvious mod target (Vol 18 — bigger antennas, directional antennas, different gain profiles). The Pager, being pocket-sized, integrates its antennas. The Enterprise, being rack-mount, has its own antenna array.

The bands:

BandWhich modelsWhy it matters
2.4 GHzAll — native on every modelThe legacy band; congested; long range; the Mark VII’s only native band
5 GHz+AC Tactical (via MK7AC), Pager, Enterprise natively; Mark VII only with the MK7AC moduleWhere modern networks live — this is why the bare Mark VII’s 2.4-GHz-only nature is a real limitation, and why the +AC kit exists
6 GHzPager onlyWi-Fi 6E / 7 territory — the Pager is the only current model that reaches it
Bluetooth / BTLEPager only (BT 5.2 + BTLE 4.2)The Pager is the only model that treats BT as a capability

The practical RF takeaway: “what bands can it see and attack” is a primary model-selection axis. A 2.4-GHz-only Mark VII misses everything modern networks do on 5 GHz. That single fact is most of why Vol 1’s buy recommendation was the +AC Tactical kit, not the bare Mark VII.


7. Compute, memory, storage — and why they’re modest

The numbers look small by laptop standards, and that’s correct and intentional:

ModelRAMStorageCPU
Mark VII256 MB2 GB eMMCsingle-core MIPS
Pager256 MB4 GB eMMCpocket SoC (per-model — Vol 12)
Enterprise1 GB DDR3L4 GB eMMC717 MHz quad-core ARM Cortex-A7

Why modest is fine: the Pineapple’s job is to be radios and move frames — not to compute. The heavy compute in a Pineapple workflow happens off-device:

  • Cracking captured handshakes → host-side, on a real GPU (Vol 11, Vol 19). The Pineapple captures; it doesn’t crack.
  • Deep analysis of captures → host-side, in Wireshark / Kismet / custom tooling (Vol 19).
  • The Pineapple holds enough storage for capture artifacts and enough RAM to run PineAP + recon + the web UI concurrently — and that’s the design target.

The Enterprise’s step up (1 GB RAM, quad-core) isn’t for compute — it’s for scale: holding state for ~100 DHCP clients vs. the Mark VII’s 5-10, orchestrating five radios, running more concurrent Campaigns. More clients and more radios need more RAM and more cores; that’s the whole reason the Enterprise’s numbers are bigger.

The implication for tjscientist’s workflow: plan for the host-side toolchain (Vol 19) as part of the kit. The Pineapple is the capture and attack instrument; the laptop with hashcat and Wireshark is the analysis instrument. They’re a pair.


8. Power and thermal across the form factors

Power delivery is one of the cleanest ways the four form factors differ:

ModelPowerImplication
Mark VII / +ACUSB-C — bus power or a USB battery packTethered to a laptop, or run off a power bank for portability. Modest draw (it’s a networking SoC, not a hot chip).
Pager2000 mAh internal LiPo, USB-C charge, ~4 h runtimeUntethered — the whole point. ~4 hours is a real constraint: it’s a short-window-engagement device, and you charge before every outing (Vol 12-13).
Enterprise100-240 V AC mains, 50/60 HzPermanently powered — it’s rack-mount infrastructure, not a field device. AC power is a feature (always-on) and a constraint (it doesn’t go in a backpack).

Thermal: the Pineapple is a low-to-modest-power device — networking SoCs and Wi-Fi radios don’t dissipate like a CPU under load. The Mark VII in its small puck, the Pager in its pocket body, run warm-not-hot. The Enterprise is the one with real thermal design — five radios + a quad-core ARM in a metal enclosure is genuine heat, which is part of why it’s a metal rack-mount chassis rather than a plastic puck. Per-model volumes carry the specifics; the foundation point is: thermal scales with radio count, and the Enterprise is the only model where it’s a first-order design concern.

Figure 7.1 — A WiFi Pineapple Mark VII PCB: the networking SoC, the RF/radio sections, and the antenna connectors at the board edge — the role-based-radio architecture made physical. Image via Nets…
Figure 7.1 — A WiFi Pineapple Mark VII PCB: the networking SoC, the RF/radio sections, and the antenna connectors at the board edge — the role-based-radio architecture made physical. Image via Netscylla's Blog.

9. Resources

Hardware references

Within this series

  • Vol 5 — the firmware that’s matched to this hardware
  • Vol 9 / 12 / 14 — the per-model hardware deep dives (deltas against this pattern)
  • Vol 11 — the MK7AC adapter (the MT7612U that gives a Mark VII 5 GHz)
  • Vol 18 — antenna and hardware mods

Cross-tool

  • HackRF One / PortaRF deep dives — contrast: those are SDR (raw RF, any waveform); the Pineapple’s radios are fixed-function 802.11 chipsets. Different layer, different design philosophy.

This is Volume 7 of a 21-volume series. Next: Vol 8 is the operational-posture foundation — OPSEC, capture-data discipline, the device’s own attack surface, the pre-engagement checklist, and discovery-response — the practical companion to Vol 4’s legal line.