The First Flipper Zero App Built Only for Wardriving: SigRoam vs the Marauder Companion App

PINGEQUA Lab · Flipper Wardriving · 9 min read · Published 2026-09-02

Every Flipper Zero app that can wardrive today is a general-purpose network testing tool that happens to have a wardrive command buried in it. SigRoam is the first one built for nothing else.

The problem: wardriving tools are network testing tools wearing a hat

If you wardrive with a Flipper Zero today, you almost certainly use the [ESP32] WiFi Marauder companion app. It is excellent software and this article is not an attack on it — but look at what it actually is.

Open its source tree and count the screens. There are eight scene files dedicated to a script editor (script_edit, script_stage_add, script_select, and five more), plus text_input and user_input for typing raw commands, plus sniffpmkid_options for attack configuration. The screen you spend your time on is console_output — a scrolling terminal. (0xchocolate/flipperzero-wifi-marauder, source tree read 2026-09-02)

That is the correct architecture for what it is: a universal front-end that exposes every command ESP32 Marauder supports, from packet sniffing to deauth to Evil Portal. Wardriving is one command among dozens.

The same holds for the other Marauder controllers. Wraith, another Flipper Marauder front-end released in July 2026, describes its own design in one line: "Live serial console — the heart of Wraith." It lists wardriving alongside BLE spam, PMKID capture, Pineapple detection and WPA3 SAE sniffing. (at0m-b0mb/Wraith-FlipperZero, README read 2026-09-02)

A console is the right interface for experimenting. It is the wrong interface for wardriving, because wardriving is not an experiment. It is a single task you start once and then leave running for forty minutes while you are driving, walking, or otherwise not looking at the screen. What you need from the device in that window is not a command prompt — it is an answer to four questions: is it still scanning, is the GPS locked, how much have I collected, and is anything broken?

What SigRoam does differently

SigRoam throws away the command surface entirely. There is no text input, no script engine, no command list. The main menu has five entries, and the one you use is Dashboard.

Main menu — five entries, no command list

Dash tab — OK starts and stops the scan

Settings — baud, source, and feedback only

About — the receive-only rule, stated on-device

The Dashboard has four tabs, switched with left and right:

• Dash — unique BSSID estimate, AP and BLE counts, GPS fix count, bytes received, elapsed time. OK starts and stops the scan. That is the entire control surface for a wardrive session: one button.
• Strm — the most recent parsed records, scrolling past as they arrive.
• GPS — fix status, satellite count, coordinates. OK requests a fresh GPS sample.
• Sess — session and diagnostic counters, for when the numbers look wrong.

One detail that only matters if you have actually done this: pressing Back leaves the dashboard without stopping the scan. You can pocket the Flipper, navigate away, come back, and the session is still running. Stopping is deliberate and only happens with OK on the Dash tab. In a console-driven app, backing out of a running command is a much less predictable act.

Why "first" is a real claim, and exactly how far it goes

SigRoam is, as far as we can establish, the first Flipper Zero application built exclusively for wardriving. That is a narrower claim than "the first app that can wardrive," and the distinction is worth being precise about, because plenty of apps can wardrive.

What we checked, on 2026-09-02:

• The official Flipper Application Catalog lists roughly 120 apps in its GPIO category. None of them is a wardriving-specific app. The Wi-Fi-adjacent entries are esp32_wifi_marauder and ghost_esp (general-purpose scanner controllers), flip_wifi (a FlipperHTTP companion that scans and deauths), and gps_nmea (a GPS readout with no Wi-Fi role).
• The third-party Marauder controllers — the companion app, Wraith — are multi-tool front-ends in which wardriving is one feature among many, and all of them expose attack functions.
• There is a separate Sub-GHz wardriving ("subdriving") tradition on the Flipper, which is a different radio and a different activity from Wi-Fi wardriving.

So: not the first tool you can wardrive with. The first one where wardriving is the whole product and everything else was left out on purpose.

The four ways to control a wardrive in 2026

Stepping back, the real choice is not "which app" — it is where the control surface lives. There are four answers, and they suit different people.

The fourth row is not a joke — it is how a lot of wardrives actually fail. A board that silently lost its GPS fix ten minutes in produces a file full of networks with no coordinates, and WiGLE will not take it. The entire argument for having a control surface at all is catching that while you can still fix it.

If you are weighing Biscuit specifically, we covered flashing it onto Scout Lite hardware and what does and does not carry over in our Scout Lite + Biscuit DIY firmware guide. The two paths are architectural opposites rather than competitors — phone-as-screen versus Flipper-as-screen — and which one is right depends mostly on whether you want a phone in the loop.

The four failures SigRoam catches before you drive off

Most "my wardrive didn't work" reports are not software bugs. They are one of four physical-layer problems, and SigRoam was built to surface each of them on screen instead of failing silently.

1. The serial log is holding your pins

Flipper GPIO pins 13 and 14 are shared with the firmware's own serial log. If Settings → System → Log Device is not set to Off, the log owns the port and the app cannot open it. SigRoam detects this specific conflict and says so, rather than sitting there receiving nothing. This is the same pin-ownership problem we documented in the GPIO 15/16 vs 13/14 UART fix.

2. Your scanner has no power because USB is plugged in

The 5 V on pin 1 does not come from a permanent rail — it comes from the OTG boost converter. While USB is connected, the firmware defers OTG, so your scanner may simply have no power. SigRoam requests OTG and verifies the physical state before opening the port. The fix is to unplug USB and restart the app, which is much easier to act on than an unexplained blank dashboard.

3. You powered a 5 GHz board from the 3.3 V pin

Do not power the scanner from pin 9. It is limited to 150 mA, and a 5 GHz-capable ESP32 will exceed that on transmit peaks. This is a wiring rule rather than something software can fix, but it is the reason a board can appear to work and then reset mid-drive.

4. Something is connected, but it isn't Marauder

The Probe firmware menu entry sends info and reports what answered. That distinguishes "nothing is connected" from "something is connected but is not speaking Marauder" — two problems with identical symptoms and completely different fixes. If you have worked through our 8 fixes for Marauder wardrive failures, you know how much time that one distinction saves.

And when the parser and the reality disagree, the Raw log screen shows the unfiltered serial lines, including anything the parser did not recognise. A malformed feed stays inspectable instead of becoming invisible.

Receive-only is a product rule, not a missing feature

SigRoam never transmits attack traffic, and the project states that this will not change. Deauthentication and disassociation frames, WPA handshake capture, evil twin / karma / rogue AP, beacon and BLE spam, and password cracking are all permanently out of scope — the documentation is explicit that these are "not 'not yet implemented', but a product rule the project will not accept exceptions to."

Two practical consequences.

First, this is what wardriving actually needs. Wardriving is passive observation: the scanner listens for beacons that access points are already broadcasting and stamps them with a GPS position. It never needs to transmit. Tools that bundle wardriving with deauth are bundling two activities with very different legal profiles — see our overview of whether wardriving is legal for where that line sits.

Second, it keeps the app honest about what it is for. If you need offensive tooling, SigRoam tells you plainly that this is the wrong project and points you at Marauder's own front-ends. Nothing stops you from having both installed.

What you need to run it

SigRoam does not scan anything by itself. It is a front-end — the radio work is done by an external ESP32 board running ESP32 Marauder firmware (currently v1.15.1, released 2026-08-24), connected to the Flipper's GPIO header.

Any Marauder-compatible board should work, because the app speaks the Marauder serial protocol rather than targeting a specific product. GPS is technically optional — but without it, as the project's own documentation puts it, wardriving "only gives you counts, not locations," which is to say it is not wardriving.

SigRoam is developed against Scout Lite, which the project documentation calls "the reference board for this app: same serial protocol, same power budget, same GPS behaviour, no adapter wiring to figure out." The pin notes above assume it. It is also the board in the dashboard screenshot near the top of this article — that Scout: data ok line is a real Scout Lite reporting in.

If you are still choosing hardware, our ESP32-C5 board comparison covers what each option actually ships with, and the complete dual-band GPS wardriving guide is the place to start if this is all new.

Installing it

SigRoam v0.1 is published as a ready-to-install .fap, built by CI separately for each firmware. You do not need a toolchain.

1. Go to the v0.1 release page and download the file matching your firmware — sigroam-0.1-official.fap or sigroam-0.1-momentum.fap.
2. Connect your Flipper and open qFlipper, or mount the SD card directly.
3. Drop the file into SD Card/apps/GPIO/.
4. Set Settings → System → Log Device to Off — this step is not optional, see failure #1 above.
5. Launch it from Apps → GPIO → SigRoam.

Both files are built from the same source; they differ only in which SDK they were compiled against, so install the one matching the firmware you actually run.

If you would rather build from source, the project uses ufbt — ufbt to build, ufbt launch to install and run on a connected Flipper. The pure-logic layer (line assembly, parsers, model, Bloom filter) has host-side unit tests that run without a Flipper at all, including under ASan and UBSan, and CI builds against both the Official and Momentum SDKs on every push. Not every Flipper app publishes its test suite; we think it matters for something you will trust with a two-hour drive.

What comes next

SigRoam is the control layer. The scanner side is still stock ESP32 Marauder — a general-purpose firmware doing wardriving as one of its many jobs, which is exactly the mismatch this app was written to fix one level up.

We are working on a wardriving-focused scanner firmware to close that gap, so that both ends of the link are optimised for survey work rather than for general network testing. We are not going to put a version number or a date on it here, because we would rather ship it than promise it. Watch the repository if you want to know when it lands.

FAQ