Part 7 took the Flipper Zero through its subGHz capabilities: reading, recording, and replaying signals in the 300 to 900 MHz range, with a hard focus on understanding what those signals are before doing anything with them. That foundation matters here, because Part 8 moves into a different frequency neighborhood entirely. The 2.4 GHz and 5 GHz bands are where most of your daily life runs. Wi-Fi, Bluetooth, smart home sensors, wireless earbuds, mesh networks, IoT devices you forgot you installed. The Flipper Zero cannot reach those bands on its own. That's what the ESP32 module is for.
This part covers the full workflow: connecting the ESP32, confirming it's configured correctly, running Wi-Fi and BLE scans, reading the output intelligently, and turning raw scan data into a documented wireless inventory. Everything here is oriented toward knowing what's in your environment. Not disrupting it. Not intercepting it. Knowing it.
What the ESP32 Module Brings to the Flipper Zero
From Single-Protocol Tool to Wireless Swiss Army Knife
The Flipper Zero ships with a lot of capability baked in, but 2.4 GHz Wi-Fi and Bluetooth Low Energy are not among them. The ESP32 Wi-Fi development board fills that gap. It connects physically to the Flipper's GPIO header, a row of pins on the top edge of the device that exposes power, ground, and serial communication lines. The ESP32 board sits on those pins, draws power from the Flipper, and communicates back and forth over a serial UART connection. No soldering required for most commercial modules. It's a clean physical interface.
This is not a built-in feature. The ESP32 is an add-on module, and it requires its own firmware to be flashed before the Flipper can use it. The most documented and community-supported firmware path is ESP32 Marauder, which provides a structured set of scanning and logging commands accessible through a companion app on the Flipper itself.
The Four Capabilities That Matter for Reconnaissance
Once the module is connected and flashed, four capabilities become available that the Flipper cannot perform alone. First, Wi-Fi scanning: passive discovery of nearby access points, including SSID, BSSID, channel, signal strength, and encryption type. Second, BLE scanning: discovery of Bluetooth Low Energy devices that are actively advertising their presence. Third, serial control: the Flipper sends text commands to the ESP32 over UART, and the ESP32 executes them and returns results, which the Flipper logs to SD card. Fourth, custom firmware support: the Marauder firmware is open, documented, and actively maintained, which means the capability set is not static.
The ESP32 extends the Flipper's reach into both the 2.4 GHz and 5 GHz bands. That coverage matters because those are the frequencies where your router, your neighbors' routers, your smart TV, your thermostat, and dozens of other devices operate. Knowing what's broadcasting in those bands is the starting point for any honest wireless security review.
Configuring Your ESP32 Board Before You Scan Anything
Confirming the Right Firmware Is Installed
Before a single scan runs, the firmware situation needs to be confirmed. Connect the ESP32 module to the GPIO header, power on the Flipper, and navigate to the GPIO section of the main menu. From there, open the WiFi Marauder app or whichever ESP32 companion app your firmware version supports. The app will attempt to establish communication with the module immediately. If the firmware version appears on screen, communication is working. If nothing appears, or if you see a connection error, the firmware on the ESP32 may be outdated, missing, or mismatched with the app version.
Reflashing the ESP32 is straightforward when you approach it correctly. The ESP32 Marauder project maintains a web flasher tool that works from a browser over USB. Connect the ESP32 directly to your computer, not through the Flipper, open the flasher, select the correct board variant, and flash. The process takes under two minutes. Doing this before troubleshooting anything else saves significant time.
UART, Baud Rate, and SD Card Verification
UART stands for Universal Asynchronous Receiver-Transmitter. It's the serial communication protocol that carries commands from the Flipper to the ESP32 and results back. For this to work, both devices need to agree on the same baud rate, which is the speed at which data is transmitted. The default for ESP32 Marauder is 115200 baud. If the Flipper app is set to a different rate, commands will appear to send but results will be garbled or empty. Check the app settings and confirm the baud rate matches before assuming there's a hardware problem.
Before Every Scan Session
Run through this mental checklist: ESP32 firmware confirmed, UART active, baud rate set to 115200, SD card inserted and formatted as FAT32, correct app open on the Flipper. One missed item causes the whole session to produce nothing useful.
The SD card is the other critical piece. Scan results don't persist in memory. They write to the card. If the card is missing, full, or formatted incorrectly, the scan runs but the output disappears when you power down. Format the card as FAT32 before relying on it for logging.
Selecting the Correct App on the Flipper
The Flipper's app ecosystem has multiple ESP32-related tools, and loading the wrong one wastes time. For Marauder-compatible workflows, the correct app is the WiFi Marauder app, available through the Flipper app catalog. Confirm the app version is current and matches your ESP32 firmware version. Version mismatches between the app and firmware are the most common source of configuration failures.
Understanding Wi-Fi Defensive Discovery
Why Scanning Your Own Network Is a Security Practice
Most home networks and small-office networks have never been fully audited. Devices get added, old routers get replaced but not decommissioned, IoT hardware ships with default SSIDs that never get renamed, and guest networks get enabled once and forgotten. The result is an environment where nobody actually knows everything that's broadcasting. That's not a dramatic security failure. It's just what happens when networks grow organically over years without documentation.
Wi-Fi scanning changes that. A passive scan captures beacon frames, which are packets that access points and some other devices broadcast continuously to announce their presence. Capturing beacons doesn't require connecting to any network. It doesn't associate with anything. It just listens.
What a Clean Scan Looks Like Versus a Concerning One
A clean scan of a well-managed home network shows a small number of SSIDs, all of which the owner recognizes, spread across channels that don't overlap unnecessarily, with encryption types that reflect current standards. A concerning scan shows unfamiliar SSIDs, devices broadcasting on unexpected channels, encryption types that suggest old hardware, or duplicate SSID names with different BSSIDs.
Channel congestion is also visible in scan output. The 2.4 GHz band has three non-overlapping channels: 1, 6, and 11. When a scan shows eight networks all parked on channel 6, that's both a performance problem and a signal that nobody in that environment is managing channel selection intentionally. Rogue SSIDs and forgotten IoT devices both appear in scan output the same way legitimate access points do. That's the point. Passive scanning doesn't distinguish between yours and someone else's. It shows everything in range, and sorting through that output is where the actual security value lives.
Running a Wi-Fi Scan and Reading the Output
Identifying Your Own Access Points
Open the WiFi Marauder app on the Flipper, confirm the ESP32 is communicating, and select the scan option from the command menu. The ESP32 will sweep available channels and return a list of detected access points. Each entry includes several fields worth understanding before you try to act on them.
SSID is the human-readable network name. BSSID is the hardware MAC address of the access point, and it's the more reliable identifier because SSIDs can be duplicated. Channel tells you which frequency slice the network is operating on. RSSI is received signal strength, expressed as a negative number where values closer to zero indicate a stronger signal. Encryption type tells you the security protocol in use: WPA3, WPA2, WPA, WEP, or open.
To identify your own access points, log into your router's admin panel and find the BSSID listed there. Compare it against the scan output. Every access point you own should be accounted for. If your router runs a guest network or a separate 5 GHz band, those appear as separate entries with their own BSSIDs. Document all of them.
Reading Channel Congestion Data
The 2.4 GHz band supports channels 1 through 11 in North America, but only channels 1, 6, and 11 are non-overlapping. When scan output shows heavy clustering on a single channel, network performance in that environment degrades for everyone on it. From a security standpoint, channel congestion is also a signal: environments with many overlapping networks and no channel discipline tend to have less overall network management, which correlates with other gaps.
If your own access point is sitting on a congested channel, that's actionable information. Most router admin panels allow manual channel selection. Moving to a less crowded channel improves performance and is a direct result of running this scan.
Spotting Unknown SSIDs and Duplicate Names
Unknown SSIDs in your scan output deserve attention even if they seem harmless. An SSID you don't recognize could be a neighbor's network, a forgotten IoT device, or something worth investigating. The distinction between those possibilities starts with RSSI. A very strong signal from an unknown SSID suggests the source is physically close.
Evil-Twin Indicators
If your scan shows two entries with identical or near-identical SSIDs but different BSSIDs, that warrants immediate investigation. A duplicate SSID with a different MAC address is a classic indicator of an evil-twin access point, which is a device configured to impersonate a legitimate network. In your own environment, confirm every BSSID against your router hardware before dismissing a duplicate as noise.
Old IoT devices are a frequent source of unexpected SSIDs. Smart bulbs, cameras, thermostats, and similar hardware often broadcast their own SSIDs during setup mode, and some continue broadcasting indefinitely if they were never fully configured. Default names like "ESP_XXXXXX" or manufacturer-branded SSIDs that you don't recognize are worth tracing back to physical hardware.
Documenting Wi-Fi Findings for Your Wireless Inventory
What to Record From Every Scan Session
Raw scan output saved to the SD card is useful, but it's the starting point. A text file full of scan results from a single session doesn't tell you much on its own. What makes it useful is structure and continuity. Every scan session should produce a record that captures the same fields consistently: SSID, BSSID, channel, encryption type, RSSI, and the date and time of the scan.
The goal is a wireless inventory document: a living record of every known access point and device in your environment, updated each time you scan. Known entries get confirmed. New entries get flagged for investigation. Entries that disappear from scan output prompt questions about what changed. This is the same discipline that network administrators apply at larger scale. There's no reason home and small-office environments can't operate with the same awareness.
Timestamped sessions matter specifically because wireless environments change. A neighbor installs a new router. An IoT device comes online. A guest network gets enabled. Scanning once and calling it done misses all of that. Scanning monthly and comparing results catches it.
Cross-Referencing Scan Data With Router Logs
The Flipper scan output shows what's broadcasting. Your router's admin panel shows what's connecting. Those are different views of the same environment, and comparing them catches things that neither source reveals alone.
Log into your router admin panel and pull the connected devices list. Cross-reference every BSSID in your scan output against the MAC addresses in the router's list. Devices that appear in your scan but not in your router's connected devices list are either not on your network or not currently associated. Devices that appear in your router's connected list but weren't in your scan output may be connected via wired Ethernet or may have been out of range during the scan.
Flag any BSSID in your scan output that looks unfamiliar even if the SSID seems recognizable. SSID names can be spoofed or duplicated. BSSIDs are harder to fake in a way that passes scrutiny when compared against documented hardware. Router logs can also confirm whether a detected SSID has ever successfully authenticated to your infrastructure, which is a useful data point when investigating an unknown entry.
BLE Scanning: Finding What Is Advertising Near You
How BLE Advertising Works and Why Devices Broadcast
Bluetooth Low Energy operates differently from classic Bluetooth. Devices don't need to be paired or connected to be detectable. BLE devices broadcast advertising packets on three dedicated channels: 37, 38, and 39, which sit at the edges and middle of the 2.4 GHz band to minimize overlap with Wi-Fi traffic. These packets go out continuously, on a schedule determined by the device's advertising interval, which can range from a few milliseconds to several seconds depending on the device's power constraints and use case.
The reason devices advertise is practical. A fitness tracker needs to be discoverable by a phone. A smart sensor needs to announce its presence to a hub. A BLE beacon needs to push its identifier to any receiver in range. Advertising is how BLE devices say "I'm here and I'm available." The side effect is that any receiver, including the Flipper ESP32, can hear those announcements without the advertising device knowing it.
This is entirely passive. Running a BLE scan does not connect to any device, does not initiate any handshake, and does not send any data. It listens to what's already being broadcast.
What the Flipper ESP32 Captures in a BLE Scan
A BLE scan from the ESP32 module returns several fields for each detected device. Device name, when present, is the human-readable label the device broadcasts. MAC address is the hardware identifier. RSSI indicates signal strength and gives a rough sense of physical proximity. Advertising interval reflects how frequently the device is broadcasting. Manufacturer data is an optional field that some devices use to include vendor-specific information in their advertising packets.
MAC Address Randomization
Many modern BLE devices, particularly phones and newer wearables, use randomized MAC addresses that change periodically. This is a privacy feature designed to prevent passive tracking across locations. For documentation purposes, it means you
Part 7 walked through Wi-Fi scanning fundamentals: reading SSID lists, interpreting signal strength, and documenting access points against a baseline. BLE is the next layer. It's quieter than Wi-Fi, often overlooked, and full of devices broadcasting information about themselves to anyone willing to listen.
Identifying Known Smart Devices in Your Environment
Run a BLE scan from the ESP32 app and the first thing you'll notice is volume. A typical home with a handful of smart devices returns a list that feels too long. Fitness trackers, wireless earbuds, smart bulbs, door sensors, thermostats, and the occasional neighbor's device bleeding through a shared wall all show up together.
Start with what you recognize. Most BLE devices advertise a device name alongside a MAC address and sometimes a manufacturer data field encoded in the advertisement packet. Your Nest thermostat will identify itself. Your Tile tracker probably will too. Cross-reference names against every smart device you've deliberately installed, then set those aside. What remains is where the work starts.
Manufacturer data is worth parsing even when device names are generic. A string that starts with Apple's company identifier narrows the field considerably. Same with entries flagged to Texas Instruments or Nordic Semiconductor, both common in IoT hardware. These identifiers don't tell you exactly what the device is, but they tell you what family it belongs to.
Tracking Advertising Behavior Over Time
Advertising interval is a behavioral signal that most people ignore. A device broadcasting every 100 milliseconds is aggressively asserting its presence. A device broadcasting every 10 seconds is doing the minimum to stay discoverable. Frequent advertisers are often designed to be found quickly, which is useful for pairing but also means they're constantly announcing themselves to every scanner in range.
Run scans at different times. Some devices only advertise during specific states. A smart lock might only broadcast when it's been triggered into pairing mode. A printer might go silent after 30 minutes of inactivity. Scanning once and calling the list complete misses everything that's state-dependent.
"A device you can't see during a Monday morning scan might be broadcasting loudly on Saturday afternoon when someone's phone woke it up."
This is why timing matters. Build a habit of scanning at varied intervals across the week rather than treating a single session as authoritative.
Documenting Unknown BLE Devices
Flag anything that appears consistently across multiple scans but can't be attributed to a known device. Consistent presence rules out transient signals from passing phones or vehicles. If a MAC address shows up every time you scan, something in your environment owns it.
Forgotten smart devices are a real risk. A previous tenant's sensor. A smart plug that got moved to a drawer and never unpaired. A fitness device that belonged to someone who no longer lives there. These things keep advertising indefinitely as long as they have power.
Document unknown BLE entries the same way you'd document an unrecognized access point: MAC address, device name if present, manufacturer field if available, advertising interval, and signal strength. Your BLE inventory and your Wi-Fi inventory belong in the same document. Together they form a complete picture of your wireless environment. Separately, each one has blind spots.
Marauder-Compatible Workflows for Reconnaissance
The default ESP32 app on the Flipper Zero covers a lot of ground. But WiFi Marauder covers more of it, and does so with considerably more detail in the output. It's a community firmware project built specifically for ESP32 boards, designed to expose the full depth of what the hardware can observe about nearby wireless activity.
This section covers only the passive scanning and inventory commands. Marauder includes functions that go well beyond passive observation, and those aren't what this series is about. The goal here is documentation and auditing.
What Marauder Firmware Adds to the Scanning Workflow
Flashing Marauder onto your ESP32 replaces the default firmware with a command-driven interface that communicates over serial. You interact with it through the Flipper Zero's UART bridge, sending commands and receiving structured text output. The learning curve is real. The first session will feel unfamiliar. By the third or fourth, the output format starts to read naturally.
The key passive commands are scanap, scansta, and scanble. Each targets a different layer of the wireless stack, and running all three gives you a more complete picture than any single scan can provide.
Using Scan Commands Defensively
scanap discovers access points. The output includes SSID, BSSID, channel, RSSI, and encryption type for every AP in range. This is the same information the default app surfaces, but Marauder's formatting is more verbose and better suited to logging. Each field is labeled explicitly, which makes parsing the output in a spreadsheet significantly easier.
scansta discovers stations: devices connected to or probing for networks. This is where Marauder earns its reputation. Probe requests reveal the SSIDs a device has previously connected to, which means a laptop sitting in your bag might be broadcasting the names of every network it's ever joined. That's useful intelligence for an auditor. It's also exactly why probe requests are worth understanding from a privacy standpoint.
scanble enumerates BLE advertising devices with more detail than the default scanner, including raw advertisement data that the standard app doesn't surface. For attributing unknown devices, this additional data is often the difference between a dead end and a positive identification.
Marauder supports saving scan output directly to an SD card. The command syntax varies slightly by firmware version, but the general pattern is to initiate a scan, let it run for a defined interval, then write the buffer to a file. Review those files later at a desk rather than trying to parse them in the field.
Hardening Your Wireless Environment Based on What You Find
A scan that produces a document and nothing else is an interesting exercise. A scan that produces a document and then drives action is a security practice. The inventory you've built across this part of the series only has value if you do something with it.
Firmware Updates for Every Device You Discover
Start with firmware. Every device on your Wi-Fi and BLE inventory list needs to be running current firmware. This is tedious. It's also the single highest-return action you can take after a scan.
Manufacturers patch known vulnerabilities in firmware updates. Devices running firmware from two years ago are running with two years of unpatched exposure. Smart bulbs, thermostats, door sensors, and routers all ship firmware updates that most users never apply because the update prompt is buried in an app most people open twice a year.
Firmware Update Priority
Work through your device inventory in order of network access. Routers and access points first, then devices with persistent network connections, then peripheral sensors and accessories. Don't skip anything. A smart plug with outdated firmware is still a network-connected device.
Removing Default Passwords and Weak Configurations
Default credentials are a known quantity. Router manufacturers publish default usernames and passwords in their documentation. So do smart device manufacturers. So does the internet, in searchable databases that anyone can query in under a minute.
Every device that shipped with a default password needs a new one. This includes the router admin panel, any smart home hub, IP cameras, and network-attached storage. Use a password manager. Generate credentials that aren't variations on the device name or your home address.
While you're in each device's admin panel, disable features you don't use. Remote management enabled on a router you never administer remotely is an open door. UPnP enabled on a router in a home with no devices that require it is another one. The scan results tell you what's active. The admin panels tell you why.
Segmenting IoT Devices Onto a Separate Network
Network segmentation is the most structurally sound thing you can do after completing an inventory. Place every IoT device on a guest network or a dedicated VLAN, isolated from the devices that hold your actual data.
A compromised smart bulb on a flat network can probe every other device on that network. A compromised smart bulb on an isolated IoT segment can probe other smart bulbs. The blast radius shrinks dramatically.
Enable WPA3 on every network where it's supported. Your scan output already shows encryption types for every access point in range, including your own. If your router is still broadcasting WPA2 and supports WPA3, that's a configuration change worth making today.
After hardening, review router logs periodically. Unexpected reconnection attempts from devices you've removed or reconfigured are worth investigating. Hardening isn't a completed state. It's a practice that requires periodic confirmation.
Building a Repeatable Wireless Audit Routine
One scan tells you what exists right now. A series of scans, compared against each other, tells you what's changing. The second kind of information is more useful for security purposes, and it only comes from consistency.
How Often to Scan and What to Compare Against
For home environments, a monthly scan is a reasonable cadence. For small offices with higher device turnover and more people connecting personal devices, weekly is more appropriate. The goal isn't to scan constantly. It's to scan often enough that new devices don't go unnoticed for extended periods.
Compare each new scan against your documented baseline. New SSIDs, new BLE advertisers, new stations probing for networks: any of these appearing between scan sessions are worth investigating before being added to the trusted inventory. The question isn't whether the device is malicious. The question is whether you know what it is and why it's there.
Integrating Flipper Scans With Broader Network Monitoring
Flipper scan data doesn't have to live in isolation. Router admin panels show connected devices with MAC addresses that cross-reference directly against your scan logs. Network monitoring apps like Fing or a self-hosted Pi-hole instance add persistent visibility between scan sessions.
A simple spreadsheet works for most home environments: date, location, device count, new devices found, actions taken. Archive scan files from the SD card with timestamps in the filename. Six months of scan logs is a meaningful historical record. It shows you when a device appeared, how long it's been present, and whether it's behaved consistently.
Schedule the next scan before you close this one. It takes thirty seconds and it's the only thing that keeps the cadence from slipping.
Your ESP32 Wireless Audit Checklist
The checklist is cumulative by design. Earlier items gate later ones. A scan you can't save to SD card is a scan you can't compare next month. A device list you haven't cross-referenced with your router panel is an incomplete inventory. Work through it in order.
What Part 9 Covers: Infrared and the Devices That Still Trust It
Part 8 covered a lot of ground. ESP32 configuration, Wi-Fi scanning, BLE enumeration, Marauder workflows, hardening steps, and the audit routine that ties all of it together. The wireless inventory you've built across this part of the series is a real document now. It has device names, MAC addresses, encryption types, advertising behaviors, and a baseline to compare future scans against.
Before You Move On
Complete your wireless audit before starting Part 9. The infrared reconnaissance work in the next installment is more useful when it's layered onto a documented wireless baseline. You want to know what's already in your environment before you start mapping how those devices respond to IR commands.
Part 9 turns to infrared. It's older than Wi-Fi and BLE by decades, and a surprising number of devices still rely on it as their primary control interface. Televisions, projectors, air conditioners, receivers, and a long tail of consumer electronics all accept IR signals from anyone pointing a transmitter in the right direction. There's no pairing. There's no authentication. There's just signal and response.
The grimoire approach is cumulative. Every part of this series builds on the one before it. The wireless inventory you finish today becomes the context that makes Part 9's IR mapping meaningful.
