Driving a Marauder dev board from a Flipper Zero: inside flipperzero-wifi-marauder

The radio lives on a separate board, not in the Flipper

The flipperzero-wifi-marauder project is a Flipper Zero app, and almost everything about it depends on hardware it does not contain. The app itself is C code compiled into a Flipper application, an FAP, and its whole job is to talk to a connected dev board running Marauder FW. The project states that requirement plainly and points to a separate Flipper tree for the firmware install details. That division of labour shapes every decision in the repository. The Flipper side owns the menus, the text input, the validation and the screens stored under scenes/. The board side owns the radio. Someone who buys a Flipper Zero and installs this app alone gets a menu with nothing behind it.

That also defines who this is for. The audience is a person who already owns the Flipper Zero, already runs custom firmware on it, and already has or plans to build the separate development board that carries the Marauder firmware. For everyone else the FAP is inert.

Scenes and scripts: the menu is a thin layer

The repository layout is unusually legible about how the app is built. Top level entries include application.fam, which declares the app to the Flipper build system, plus a scenes/ directory, a script/ directory, assets/, docs/, file/, and the C sources that carry the app's name: wifi_marauder_app.c and wifi_marauder_app.h. There is also wifi_marauder_app_i.h, a custom event header in wifi_marauder_custom_event.h, and a dedicated UART module split into wifi_marauder_uart.c and wifi_marauder_uart.h. The screenshot names say what the user actually does: marauder-topmenu.png, marauder-script-demo.png and marauder-save-pcaps.png, meaning open a top menu, run a script, and store packet captures on the SD card.

Those three screenshots are the best available description of the scope. The app is a remote control and a capture sink, not an analysis suite. Nothing in the file list suggests a pcap parser, a decoder or a protocol inspector. If your workflow is opening captured traffic to dig into handshakes, this repository is the wrong place to look.

Installing the FAP means picking an artifact, not a package

Installation happens through the GitHub Actions workflow rather than a package manager. The workflow is linked as FAP Build, and the documented sequence is: sign in with a GitHub account, open the workflow, select the most recent run and scroll down to the artifacts. The app is built for the dev and release channels of both official and unleashed firmware, so you download the artifact that matches the firmware you actually run. The file you want is named esp32_wifi_marauder.fap, and it belongs under Apps/GPIO on the Flipper SD card, along with the rest of the GPIO apps.

Do the cleanup step first if you can. The documentation warns that on some firmwares an app of a similar name is already present and it should be deleted from Apps/GPIO to avoid confusion. That existing file is called ESP32CAM_Marauder.fap or similar. If you use qFlipper on Windows, extract the downloaded ZIP to your computer first, because qFlipper cannot accept a file dragged straight out of a ZIP archive.

For anyone who prefers a local build, the project also supports ufbt from a clone of the repository:

ufbt

That is the only build tool the project names, and no flags or environment variables are given for it. The project also does not publish install steps for the board firmware itself, so that part of the setup has to come from the separate Flipper tree linked alongside it.

Every command travels over UART to the board

The app's real transport is a serial link. wifi_marauder_uart.c and wifi_marauder_uart.h exist purely for UART work, sitting alongside wifi_marauder_validators.c and wifi_marauder_text_input.c, which handle what the user types and whether that text is acceptable before it is sent onward. The separation makes sense: a Flipper keypad is a poor way to enter long strings, so the app front ends a text entry layer and then hands a validated payload to the serial module.

What that produces is a small command channel. The Flipper menu is the controller, the board is the executor, and the script/ directory holds the sequences the app can fire off. The screenshot set confirms the split: a top menu for choosing, a script demo for running, and a save flow for pcaps. If the board is unplugged or running the wrong firmware, the menus still render on the Flipper screen. The failure appears as a script that does nothing, which is a poor diagnostic and the main reason to keep the board connected while you test.

The capture side follows the same path. Saved pcaps are pulled off the board and written to the SD card, which is why the save flow gets its own screenshot rather than being buried in a settings screen.

The firmware channel matrix is where installs go wrong

The most consequential decision in the whole install is picking the right artifact, and the project leaves you four combinations to get right: the dev and release channels, each for official and for unleashed firmware. The artifacts are built per channel, so a binary made for the dev channel of official firmware is not the same file as one made for the release channel of unleashed firmware. A build badge sits at the top of the project page, and each run publishes its own artifacts for you to choose from.

Nothing on the Flipper side detects a mismatch. The app is a small binary with a small footprint, so the likely symptoms of the wrong choice are an FAP that refuses to load or a UART exchange that produces no reply. This is the failure mode to expect first, and the one most worth ruling out before blaming the dev board or the firmware.

A second constraint is that the ESP flasher no longer lives here. The project states that the ESP flasher is now its own app, published as 0xchocolate/flipperzero-esp-flasher. If your goal is to put new firmware onto the board, this app is the wrong entry point and the sibling repository is the one to read.

Two sibling apps: controlling the board versus flashing it

0xchocolate maintains more than one app for this hardware, and the split matters when deciding what to install. flipperzero-wifi-marauder is the control surface. It presents menus, takes text input, runs Marauder scripts on the attached board and saves pcaps. flipperzero-esp-flasher is the maintenance surface: it writes firmware to the ESP32 side of the board, which is the step you need before the control app has anything to talk to.

The difference in approach is direct rather than a matter of degree. Flashing is a one time provisioning step, repeated only when firmware changes, and it is the kind of operation that wants a dedicated tool with a progress display. Driving the board is an ongoing session that happens every time you open the app, and it is the kind of operation that wants menus, saved scripts and a capture workflow. Having both on the same SD card is the normal arrangement.

Comparing this to the firmware that performs the radio work is more useful than comparing it to another app store. The project points to justcallmekoko/ESP32Marauder for more information on Marauder, and describes itself as the companion app for that firmware rather than a replacement for it. Anything you expect to find on the radio side, including how the board behaves, is outside the scope of this repository.

C, GPL-3.0, and a last push in September 2026

Implementation is plain C, with the headers and sources named after the app at the top level of the tree. That matters less for users than for anyone who wants to extend the app, since the Flipper build system consumes a .fam manifest and the app ships as a compiled FAP rather than as source you drop onto the SD card. The repository is licensed under GPL-3.0, which carries the usual condition that distributing a modified version means offering the corresponding source to those you hand it to.

The project is not archived. The last push was on 2026-09-15, and the three most recent tagged releases are v0.7.6 from 2025-09-28, v0.7.5 from 2025-08-14 and v0.7.4 from 2025-07-26. Read that spacing carefully. The last push came well after the newest tag, so the default branch named feature_wifi_marauder_app has moved on since the last downloadable release. The workflow publishes whatever the branch builds, which means an artifact you pin today is not a fixed binary across months, while the tagged releases are now roughly a year behind that branch.

Support runs through GitHub issues, with a wrinkle worth noting. The support link points at 0xchocolate/flipperzero-firmware-with-wifi-marauder-companion, a differently named issue tracker, so filing a bug against the wrong repository is an easy way to lose a day.

Editorial conclusion

Adopt this app if you already run a Marauder dev board alongside a Flipper Zero and want menus and script shortcuts instead of typing serial commands by hand. Do not adopt it as a standalone radio tool, as a pcap analysis suite, or as a way to get firmware onto the board, since flashing lives in a separate app. Before installing, confirm which firmware channel your Flipper is on, download the artifact built for that exact channel, and check that the board answers UART traffic before you blame the menus. The last push was on 2026-09-15 while the newest tag, v0.7.6, dates from 2025-09-28, so build from the branch if you need current code.

Frequently asked questions

Official sources

1. 0xchocolate/flipperzero-wifi-marauder on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases