Classroom Nano - Hands‑on security education

BLEShark Nano as a Classroom Tool for Security Education

Cybersecurity education has a persistent problem: the gap between theory and practice. Students can read about WPA2 handshakes, HID injection, and BLE advertising for weeks and still have no intuition for how these things feel in practice. Watching a lab video is better than reading a textbook, but neither replaces doing it yourself on real hardware.

The challenge for educational institutions is budget and safety. Wireless security labs require either expensive commercial equipment or consumer gear with significant setup overhead. And anything involving deauth or injection raises legitimate concerns about students accidentally affecting networks outside the lab environment.

The BLEShark Nano addresses both problems to a significant degree: it is cheap enough for a class set, self-contained enough to minimize setup overhead, and designed with explicit feature controls that make sandboxed lab use practical.

Why hardware matters in security education

Abstract concepts become concrete the moment a student sees them happen in real time. Reading that "deauth attacks disconnect WiFi clients" is one thing. Watching a connected laptop drop off a network because of a packet sent from a device the size of a lighter is another. The latter creates a mental model that sticks.

This is not just pedagogical preference - it is how security intuition develops. The field is full of experienced practitioners who can tell you that they first understood a concept not from reading about it but from accidentally triggering something unexpected in a lab. The experiential path to understanding is faster and more durable than the text-based path for most people.

Hardware labs also surface details that labs-on-paper omit. Real radio behavior introduces timing variability, signal noise, interference from neighboring devices, and client behavior differences that you cannot simulate in software. Students who only learn from simulated environments consistently underestimate the complexity of real-world wireless environments.

The cost case

Traditional wireless security lab options:

  • Commercial wireless security appliances: Enterprise-grade hardware for pentest labs can run $500-$2,000+ per device. A class of 20 students with shared equipment is logistically complex.
  • Raspberry Pi + WiFi adapter setup: Around $60-80 per student setup, requires OS configuration, driver installation, and management overhead. Works well but has significant setup time per deployment.
  • Virtual labs (no hardware): Free to scale, but students cannot perform real radio operations. Simulated WiFi scanning and packet capture with pre-canned results teaches the workflow without teaching the reality.

The BLEShark Nano at $36.99+ is the lowest cost per student for a self-contained device that performs real radio operations. For a class of 20, a full class set with the 16-node Shiver pack (the largest available configuration) covers both individual device work and coordinated multi-node exercises. No OS setup required, no driver installation, OTA updates handled over WiFi.

The File Portal (accessible via WiFi when connected to the BLEShark's AP) handles all configuration and data management through a browser. Students do not need command-line skills to use the device for introductory labs, though they need them to make sense of the PCAPs and data the device produces.

What the BLEShark Nano teaches

Grouped by concept:

WiFi protocol mechanics:

  • Beacon frames: running a WiFi scan shows SSIDs, BSSIDs, channels, signal strength, and security types - the exact data that lives in beacon frames. Students can correlate what they see on the screen with what they read about beacon frame structure.
  • Deauthentication: performing a deauth test against a controlled AP on a closed network demonstrates management frame behavior concretely. Students see why unauthenticated management frames are a vulnerability.
  • WPA2 handshake capture: capturing a 4-way handshake and exporting it as a PCAP that students then open in Wireshark bridges the conceptual (EAPOL, ANonce, SNonce, PTK) to the visual.
  • AP spam: broadcasting a set of custom SSIDs and watching them appear on student phones makes beacon injection tangible.

Bluetooth Low Energy:

  • BLE scanning: discovering advertising devices, reading manufacturer data, understanding what BLE devices broadcast passively.
  • BLESpam: broadcasting BLE advertisements that trigger iOS, Android, or Windows popup notifications demonstrates how BLE advertising works at a practical level and why phones respond to it.
  • Bad-BT (HID injection): pairing as a Bluetooth keyboard and executing a DuckyScript payload demonstrates the HID trust model. Writing a safe payload (open Notepad, type a message) makes the concept real without risk.

Infrared:

  • IR capture and replay: capturing a TV remote signal and replaying it demonstrates modulation, carrier frequency, and protocol basics in a hands-on way that is intuitive and low-stakes.
  • TV-B-Gone: understanding how a brute-force approach to IR remote codes works (cycle all known codes until one works) teaches the concept of enumeration attacks in an accessible context.

Networking concepts via captive portal:

  • Captive portals: deploying a captive portal demonstrates DHCP, DNS hijacking, and HTTP redirect mechanics. Students connect to the BLEShark's AP, get redirected to the portal page, and see how the redirect works.

A sample 90-minute wireless security lab

This is a structured lab suitable for a university security module or bootcamp. All activity targets student-owned devices and BLEShark hardware in a closed lab environment - no testing against external networks.

gantt
    title 90-Minute Wireless Security Lab
    dateFormat mm
    axisFormat %M min
    section WiFi Fundamentals
    WiFi scanning and beacon analysis :a1, 00, 20m
    section WPA2 Attack Chain
    Handshake capture and cracking     :a2, after a1, 25m
    section BLE Security
    BLE scanning and BLESpam           :a3, after a2, 20m
    section HID Attacks
    Bad-BT and HID injection           :a4, after a3, 20m
    section Wrap-Up
    Debrief and discussion             :a5, after a4, 5m

Figure: Structure of a 90-minute wireless security lab using the BLEShark Nano, covering WiFi, BLE, and HID attack demonstrations.

Prerequisites: Students have read about WPA2 handshakes, deauth attacks, and BLE basics. Lab is conducted on an isolated lab router with no corporate network connection.

Part 1: WiFi scanning and beacon frame analysis (20 min)

  1. Students power on their BLEShark Nanos and run a WiFi scan.
  2. Each student records the SSIDs, BSSIDs, channels, and security types visible from their seat.
  3. Instructor demonstrates that the lab router's SSID is visible with WPA2 security. Students note the BSSID (router MAC address) and verify it against the documented router.
  4. Instructor opens a Wireshark PCAP of beacon frames (pre-captured). Students identify the fields they just saw in the BLEShark UI within the raw frame data.
  5. Discussion: what information is visible to anyone nearby? What does your home network reveal?

Part 2: WPA2 handshake capture (25 min)

  1. Instructor's laptop connects to the lab router.
  2. Students initiate handshake capture on the lab router's SSID via their BLEShark.
  3. Instructor disconnects and reconnects to the lab router, generating a handshake.
  4. Students download the captured PCAP from their BLEShark's File Portal.
  5. Students open the PCAP in Wireshark. Identify the four EAPOL frames. Find ANonce, SNonce, and MIC fields.
  6. Run Hashcat against the PCAP with a provided wordlist (the lab router password is in the wordlist). Students crack the password.
  7. Discussion: why does this attack work? What does WPA3 SAE do differently?

Part 3: BLE scanning and BLESpam (20 min)

  1. Students scan BLE on their BLEShark. Identify all advertising devices in the room - other student devices, phones, laptops, the instructor's devices.
  2. Students record manufacturer data and note how much device information is available passively.
  3. Instructor demonstrates BLESpam (iOS and Android popup modes) against their own phone. Students observe the popup behavior.
  4. Discussion: what does this tell us about BLE privacy? What would you change about BLE advertisement design to improve privacy?

Part 4: Bad-BT / HID injection (20 min)

  1. Instructor demonstrates Bad-BT on their own laptop: pairs the BLEShark as a Bluetooth keyboard, executes a DuckyScript payload that opens Notepad and types "This is an HID injection demo."
  2. Students pair their BLEShark to their own laptop (with consent) and execute a provided safe payload from the File Portal.
  3. Students modify the payload (change the typed text or add a DELAY) using the on-device DuckyScript editor and re-run it.
  4. Discussion: what would it take to stop this? What operating system controls exist? What physical controls?

Debrief (5 min): Connect the practical demonstrations to the theoretical framework. What vulnerabilities did we just demonstrate? What mitigations exist for each?

All activities in the lab above target devices and networks explicitly set up for the lab and owned by the instructor or the students themselves. This is the key legal boundary: testing against your own equipment or equipment where you have explicit written permission.

Practical measures to keep the lab within bounds:

  • Use a dedicated lab router with no connection to the institutional network.
  • Include a consent form in lab materials - students acknowledge they may be the target of BLE or WiFi demonstrations during the lab.
  • Deauth and AP spam should only be directed at the lab router or lab devices, never at the institutional WiFi.
  • In EU regions, deauth is disabled in BLEShark firmware per the Radio Equipment Directive - this is enforced at the firmware level, so EU classrooms do not need to manage this restriction manually.
  • BLESpam activities should be on a separate BLE-only lab segment or clearly demonstrated by the instructor only, with student devices as willing recipients.

The BLEShark's sandboxed design helps here: it does not automatically attack everything around it. Features are manually triggered. Students have to deliberately select a target and initiate an action. This is meaningfully different from tools that operate continuously or automatically.

Advanced lab scenarios

For students who have completed the introductory lab and want more:

Shiver mesh lab: With a Shiver mesh pack, students deploy multiple nodes across the lab space and coordinate a multi-channel scan. Seeing how coordinated channel partitioning gives fuller spectrum coverage than a single device demonstrates the value of distributed systems for security monitoring. Students can also experiment with multi-node captive portal deployment for A/B portal testing exercises.

Custom captive portal design: Students write their own captive portal HTML, upload it via the File Portal, and deploy it on the lab AP. This teaches HTML, social engineering principles, and the technical mechanics of how portal pages work. What design elements make a portal look more trustworthy? More urgency? Less suspicious? This is directly applicable to security awareness training design.

DuckyScript payload development: Students write their own DuckyScript payloads with specific objectives: open a specific URL in the browser, lock the workstation, check system information. This teaches scripting fundamentals in a context where the result is immediately visible.

Setup and logistics

For a class set:

  • BLEShark Nanos charged via USB-C before the lab. The 500mAh battery lasts through a 90-minute lab without needing charging cables at seats.
  • OTA updates can be pushed before class via any WiFi network - connect each device to the lab WiFi, trigger OTA, update. The multi-network WiFi configuration (settings for up to several networks) means you can pre-configure lab WiFi credentials for all devices during setup.
  • DuckyScript payloads for the Bad-BT lab section can be uploaded ahead of time via the File Portal, so students start with a working payload rather than building from scratch.
  • Lab handouts should include the BLEShark menu navigation reference since students will be navigating the OLED UI without prior experience.

The BLEShark Nano starts at $36.99. For educational institutions interested in class sets, the Shiver packs (3/5/7/12/16-node configurations) provide volume pricing. The combination of low cost, zero-setup operation, and breadth of features makes it a practical choice for any security education program that wants to get students interacting with real radio hardware.

Get BLEShark Nano - $36.99+

Back to blog

Leave a comment