How to Use This Lab

Each experiment follows the same shape so you can move quickly:

• Goal — what you should understand by the end.
• What it does — the tool and the protocol behaviour in plain language.
• Run it — the exact menu path or CLI commands.
• Observe — what to look for, and how to confirm it worked.
• Push further — a variation that deepens the lesson.

Two ways to drive THE BEAST: the on-device menu (screen + A/B buttons), and the CLI over USB. Most experiments use the menu; the CLI experiment at the end shows how to script the same behaviour and export captures.

Before You Start

• POOM flashed and booting to the main menu (target esp32c5, ESP-IDF v6.1.0).
• A second, disposable device you own to act as the target: an old phone, a spare laptop, or a lab access point. Never point these at production or shared networks.
• A microSD card inserted if you want to save captures (PCAP experiments write here).
• For CLI work: a USB cable and a serial terminal. POOM exposes the console over USB Serial/JTAG, so no extra adapter is needed.

THE BEAST at a Glance

The fifteen tools in this category, and the experiment that covers each:

Experiment 1 — SCAN CORE: Map the Air

Goal: build a baseline picture of the Wi-Fi around you before touching any attack tool. Every later experiment starts from a scan.

What it does: SCAN CORE runs POOM's advanced scanner (the poom_scanner_core module). It sweeps the 2.4 GHz channels, lists access points with their SSID, BSSID (MAC), channel and RSSI (signal strength), and gives you the channel analysis the attack tools need to target a specific AP by index.

Run it: THE BEAST → SCAN CORE → A. Let it complete a full sweep.

Observe: note the BSSID and channel of your own test AP. Attacks in POOM select a target by its index in this list, so identify which row is yours before continuing. Watch how RSSI rises as you move POOM closer to the AP.

Push further: run the scan in two rooms and compare which APs disappear. That is your first lesson in how channel and distance shape everything else in this lab.

Experiment 2 — PROBE REQ: Listen to What Phones Ask For

Goal: see the networks nearby devices are actively searching for.

What it does: when a phone's Wi-Fi is on, it periodically broadcasts probe requests — "is network X here?" — sometimes naming saved SSIDs. PROBE REQ passively sniffs these frames and prints the requesting MAC and any named SSID. Nothing is transmitted at the target; this is pure listening.

Run it: THE BEAST → PROBE REQ → A. Toggle Wi-Fi off and on on your own phone nearby and watch the probes appear.

Observe: some devices reveal saved network names in their probes. This is exactly the signal the KARMA experiment exploits — keep the SSIDs your phone probes for in mind for Experiment 4.

Experiment 3 — DEAUTH + DEAUTH DET: Attack and Detect

Goal: understand deauthentication, then immediately see it from the defender's side. Best run with two POOM units, or one POOM plus a second Wi-Fi capture tool.

What it does: a deauthentication frame is a management frame that tells a client it has been disconnected. Because classic Wi-Fi management frames are unauthenticated, anyone can forge them. DEAUTH scans, lets you pick a target AP by index, and sends a deauth broadcast against it (poom_wifi_deauth_scan_and_list then the attack loop). DEAUTH DET does the opposite: it monitors the air for a flood of deauth frames and flags the attack.

Run it:

1. On the defender unit: THE BEAST → DEAUTH DET → A.
2. On the attacker unit: THE BEAST → DEAUTH → A, wait for the scan, select the index of your own test AP, and start.
3. Watch your test client (the disposable phone/laptop) drop its connection, and watch DEAUTH DET raise an alert at the same moment.
4. Press B on the attacker to stop.

Observe: the pairing is the lesson. The same protocol weakness that lets the attack work is what the detector keys on (an abnormal rate of deauth frames). This is why 802.11w / Protected Management Frames exists.

Push further: enable PMF on your test AP if it supports it, and repeat. A client protected by 802.11w should ignore the forged frames — the clearest possible demonstration of the fix.

Experiment 4 — KARMA: The AP That Says Yes to Everything

Goal: see how a rogue AP can impersonate the networks a device is looking for.

What it does: KARMA listens for the probe requests you saw in Experiment 2 and responds as if it were those networks, so a client configured to auto-join a remembered SSID may associate with POOM instead. The module discovers requested SSIDs and clones one into an active fake AP (poom_wifi_karma_start tracks discovered and currently-cloned SSIDs).

Run it: THE BEAST → KARMA → A. With your test phone nearby (and its Wi-Fi probing for a saved open network you control), watch KARMA pick up the SSID and clone it.

Observe: the cloned/active SSID display shows which network POOM is currently impersonating. Confirm your test device associates with POOM rather than the real AP.

Experiment 5 — SPAM WIFI: Flood the Network List

Goal: understand beacon frames by generating a lot of fake ones.

What it does: access points announce themselves with beacon frames carrying an SSID. SPAM WIFI transmits many beacons with fabricated SSIDs (poom_wifi_spam_start), so nearby devices show a flood of phantom networks in their Wi-Fi list.

Run it: THE BEAST → SPAM WIFI → A. Open the Wi-Fi settings on your own phone and watch the list fill with the fabricated names. Press B to stop, and confirm they vanish.

Observe: beacons are broadcast and unauthenticated, so a client cannot tell a fabricated SSID from a real one until it tries to connect. This is the same primitive KARMA and CAPTIVE build on.

Experiment 6 — CAPTIVE: Evil Twin Portal

Goal: see how a fake login page is served the moment a device joins a rogue AP.

What it does: CAPTIVE stands up POOM as an access point plus a DNS server and an HTTP server (AP+STA + HTTP + DNS). Any client that connects gets its DNS answers redirected to POOM, so opening any page pops the captive portal you serve. Portal HTML lives on the SD card under /portals (default root.html), and submitted data is written under /captive_data. POOM can hold up to 20 portal templates.

Run it:

1. Put a simple root.html in the /portals folder on the SD card (a plain "Wi-Fi login" page is enough for the lab).
2. THE BEAST → CAPTIVE → A to start the AP and portal.
3. Join that AP from your own test device and open any website. The portal should appear.

Observe: notice you never typed POOM's URL — the DNS redirect forces the portal. This is why connecting to unknown open Wi-Fi is risky: whoever runs the AP controls what "any website" resolves to. Review the captured submission under /captive_data to see exactly what a portal can harvest.

Experiment 7 — BLE SPAM: Bluetooth Pop-Up Storm

Goal: understand BLE advertising by rotating through vendor pairing payloads.

What it does: Bluetooth LE devices advertise constantly, and some ecosystems show pairing pop-ups when they see certain advertisement payloads. BLE SPAM cycles through a set of these payloads (poom_ble_spam_start rotates advertised identities and exposes the current name via callback).

Run it: THE BEAST → BLE SPAM → A. Keep a test phone/tablet nearby with Bluetooth on and watch for pairing prompts. The device screen shows the currently advertised label as it rotates.

Observe: the pop-ups come from the target OS reacting to advertisement data — POOM never connects to anything. Press B to stop the rotation.

Experiment 8 — TRACKER: Proximity and Tags

Goal: passively profile BLE devices and watch signal strength track distance.

What it does: TRACKER scans BLE advertisements and records a report per device (poom_ble_tracker stores a profile with identifying fields and signal data via a scan callback). It is a listening tool — useful for spotting trackers/tags and for understanding how RSSI reveals proximity.

Run it: THE BEAST → TRACKER → A. Bring a known BLE device (a fitness band, a tag, a headphone) toward and away from POOM.

Observe: the RSSI for that device rises as it nears and falls as it leaves. That single number is the whole basis of BLE proximity tracking — and the reason unwanted-tracker detection features exist on phones.

Experiment 9 — PCAP SNF: Capture Real Frames

Goal: record live radio traffic to a standard .pcap file you can open in Wireshark.

What it does: PCAP SNF drives POOM's capture pipeline (poom_pcap) across multiple radios — Wi-Fi, BLE and Zigbee / IEEE 802.15.4 — and writes frames out with metadata for offline analysis. The Zigbee/802.15.4 path is the one detailed in the sniffer menu (fixed channel or channel hopping).

Run it: THE BEAST → PCAP SNF → A. Choose the mode (start with Zigbee if you have a 2.4 GHz smart-home device to watch), pick a channel or hopping, and let it capture to SD.

Observe: pull the .pcap onto a computer and open it in Wireshark. Correlate what you captured with what you did in earlier experiments — you should be able to find beacon and deauth frames from Experiments 3 and 5.

Experiment 10 — NET SCAN: Map a LAN, Then ARP

Goal: enumerate hosts on a network POOM has joined, and understand ARP spoofing.

What it does: once POOM has an IP on your test LAN, NET SCAN sweeps the local subnet with ARP requests and builds a host list (IPv4 + MAC), optionally probing common TCP/UDP ports and grabbing an SSH banner (poom_wifi_arp). The same tool underpins ARP spoofing, where forged ARP replies redirect a victim's traffic through the attacker.

Run it: join POOM to your own test network first (Settings → Wi-Fi, or store credentials via CLI), then THE BEAST → NET SCAN → A.

Observe: the discovered hosts are the same ones your router sees. ARP has no authentication, which is exactly why spoofing works and why the scan is so easy — every host answers "who has this IP?" honestly.

Experiment 11 — HTTP LOAD: Stress a Server You Own

Goal: generate controlled HTTP/HTTPS load and read the result.

What it does: HTTP LOAD fires many HTTP or HTTPS requests at a configured target using a worker pool (poom_http_load_test / poom_https_load_test). It is a stress/benchmark tool for a server you control.

Run it (CLI is easiest here):

cfg-wifi-set <ssid> <password>      # join your test network
cfg-load-target-set <host> <port> <path> <workers> <scheme>
cfg-load-get                        # confirm stored config
cfg-load-start                      # begin the load test
cfg-load-stop                       # stop

Observe: watch your own server's request log and latency climb as workers increase. Raise workers gradually to feel the difference between load testing and a denial of service — the line is intent and ownership.

Experiment 12 — DIAL TV: Talk to a Smart TV

Goal: discover DIAL-capable devices and understand a real consumer protocol.

What it does: DIAL (Discovery And Launch) is the protocol phones use to find and launch apps on smart TVs and streaming sticks over the LAN. DIAL TV discovers these devices on the network POOM has joined and exercises the launch endpoints.

Run it: with POOM on the same test LAN as your own TV/streaming device, THE BEAST → DIAL TV → A.

Observe: the device is discovered without any pairing step — DIAL trusts anything on the local network. That trust model is the whole point: if a device is on your Wi-Fi, it can already talk to your TV.

Experiment 13 — CLI & CLI WEB: The Control Surface

Goal: drive THE BEAST from a keyboard so experiments are repeatable and scriptable.

What it does: the CLI is a REPL exposed over USB Serial/JTAG. It gives you command history (↑/↓), help to list every command, and Ctrl+C to cancel a running command. CLI WEB exposes the same command interface over the network so you can drive POOM from a browser.

Run it:

1. THE BEAST → CLI → A (or connect over USB and open your serial terminal).
2. Type help to see the full command set.
3. Use ↑/↓ to replay commands; Ctrl+C to stop a long-running one.

A first scripted flow — store credentials, then run an 802.15.4 capture:

help
cfg-wifi-set MyLabAP labpassword
cfg-wifi-get
cfg-154-start
cfg-154-ch 15
cfg-154-rssi
cfg-154-stop

Observe: the config commands (cfg-*) persist settings to POOM's secrets store, so the menu tools pick up the same Wi-Fi and load-test targets you set here. The CLI is not a separate mode — it is another door into the same modules.

Where to Go Next

You have now driven every tool in THE BEAST as a controlled experiment. The through-line: most of these attacks work because early Wi-Fi and BLE management traffic is unauthenticated — and most defenses (PMF/802.11w, forgetting open networks, network isolation) close exactly the gap each experiment opened. From here, dig into the protocol detail in the Technologies Matrix, or move to the NFC Security Lab for the contact-less track.