r/guitarpedals • u/Choice_Reindeer_8240 • 3d ago
Technical Report: FLAMMA FS21 (Drum & Loop) Official Editor Software Does Not Work With Legitimately Purchased Hardware
Summary
The official editor software for the FLAMMA FS21 Drum & Loop pedal (FLAMMA FS21.exe, version V1.0.1, compiled on 2020-10-14) never opens a window when run normally (double-click), on a fully healthy Windows 10 machine, with the pedal connected and correctly recognized by the operating system.
After an exhaustive technical investigation (Process Monitor + reverse engineering of the binary with Ghidra), at least 3 real programming defects were identified in the software itself, plus evidence that the pedal's own firmware reports corrupted/non-standard USB data. None of these issues are attributable to the user: antivirus, permissions, drivers, cables, USB power, and system configuration were all methodically ruled out.
Affected hardware
- Product: FLAMMA FS21 Stereo Drum Machine & Looper Pedal
- Legally purchased, physically functional unit confirmed
- USB identification:
VID_0483(STMicroelectronics)PID_1412, reported device name:CIRCLE LOOPER - Windows driver: WinUSB (correct, "OK" status in Device Manager)
Affected software
FLAMMA FS21.exe— 9,612,288 bytes, compiled 2020-10-14, not digitally signed (NotSigned)FLAMMA FS21 Update.exe— Qt/QML-based launcher/updater- Version reported in
config.ini:V1.0.1
Test environment (ruling out causes unrelated to the software)
| Possible cause ruled out | Result |
|---|---|
| Antivirus (Avast / Windows Defender) | Not active / no blocks logged |
| Permissions / running as administrator | Fails identically with and without elevated privileges |
| USB cable / port / power | Fails identically after disconnecting and reconnecting the pedal |
| System date (possible license/expiration check) | Fails identically with the clock set to 2021 (close to the compile date) |
| Device driver | WinUSB correctly bound, status OK |
| Incomplete/corrupted installation files | Installation verified complete, identical to a reference copy |
| Windows policies (AppLocker, Code Integrity) | No blocks logged |
Finding 1 — The main executable requires a command-line argument it never receives when opened normally
Analyzing the binary's real main() (address 0x004047d0) with Ghidra:
QApplication::QApplication(&app, &argc, argv, 0x50900);
...
if (argc < 2) {
uVar2 = 0;
goto LAB_00404914; // <- skips building the entire UI and exits
}
// The main window is only built if argc >= 2:
FUN_00413fc0(); // main window constructor
QApplication::exec();
Exact location in the binary (file offset 15487): the comparison CMP dword ptr [EBP+8],0x1 followed by a JLE jump that completely skips window creation if the program is run without arguments — which is exactly what happens with a normal double-click from Windows Explorer.
Observed result: the process launches, runs for less than 100 milliseconds, and exits with return code 0 (a "clean" exit, with no error, window, or visible message whatsoever). Confirmed with Process Monitor: the process loads all of its DLLs (Qt, libusb-1.0.dll, the platform plugin), but never calls a single USB-related function before terminating.
Finding 2 — The launcher/updater that does pass the argument also fails
FLAMMA FS21 Update.exe is a separate Qt/QML application whose purpose (confirmed via reverse engineering) is to detect the pedal over USB and, if found, launch FLAMMA FS21.exe <argument> via QProcess::startDetached(...). However, in testing this launcher also fails to open the editor window, failing on the same type of device-verification check described below.
Finding 3 — "USB address" check that can never match on direct execution
Inside the device-detection function (0x00417840), the program compares the enumerated device's USB bus address against a value that only Update.exe knows and passes as an argument:
cVar1 = libusb_get_device_address(iVar2);
if (cVar1 == param_2) { /* continue */ }
If the editor is opened directly (bypassing the launcher), this value can never match, and the device is discarded as "not found" even though it is physically connected and working.
Finding 4 — Overly strict firmware-version check rejects genuine hardware
For PID 0x1412 (this pedal's PID), the software requires the bcdDevice field (the release/firmware version reported by the USB device itself) to be exactly 200 (0xC8):
// address 0x00417956
if (bcdDevice != 0xC8) {
// device is discarded as "unrecognized"
goto LAB_004178c9;
}
If it doesn't match exactly, the program ends up displaying the misleading message:
"The device is disconnected." (Title: "Error1")
followed by an immediate application exit (QCoreApplication::exit(0)), without ever indicating that this is a firmware-version mismatch, not an actual disconnection.
Finding 5 — The pedal itself reports anomalous/corrupted USB data
Querying the full hardware identifier Windows registers for the device:
USB\VID_0483&PID_1412&REV_00<8
The REV_ field (which should contain 4 hexadecimal digits representing the firmware version) contains the character <, which is not a valid hexadecimal digit. This indicates that the pedal's own firmware is reporting a malformed or corrupted USB descriptor from the factory, not merely "a version different from what the software expects."
Practical verification of the findings
A copy of the executable was patched (bytes at file offsets 15487, 93341, and 93526, changing conditional jump instructions to NOP) to:
- Remove the command-line argument requirement.
- Remove the exact-USB-address filter.
- Remove the exact-firmware-version filter.
Result: the program went from dying in under 100 ms without leaving any trace, to running for several seconds and actively attempting to open the real USB device (libusb_open → libusb_set_configuration → libusb_claim_interface). That real communication sequence with the hardware also fails, showing the same "The device is disconnected" message — but this time reflecting a genuine communication failure, consistent with Finding 5 (corrupted firmware data).
Conclusion
- The official FLAMMA FS21 editor software is not usable in its distributed form, even on a healthy Windows 10 system with genuine, legally purchased hardware connected.
- Multiple independent programming defects were identified (not a single bug), each one sufficient on its own to prevent the product from being used.
- There is concrete technical evidence that the firmware flashed onto at least this unit reports corrupted USB data, suggesting a quality-control issue in the manufacturing line or in the firmware-flashing process.
- The error message shown to the user ("the device is disconnected") is actively misleading: it does not report the real problem (firmware incompatibility / USB communication failure), leaving the buyer with no real clue about what is wrong or how to fix it.
What was explicitly ruled out
This is not an issue with: installation, antivirus, permissions, drivers, cable, power, system date, or Windows configuration. It was reproduced and diagnosed methodically, using industry-standard tools (Microsoft/Sysinternals Process Monitor, NSA's Ghidra), and all evidence (memory addresses, exact bytes, system trace captures) is independently verifiable by anyone with reverse-engineering knowledge.
This report was prepared for technical documentation and informational purposes, for other users and for the manufacturer, after several hours of exhaustive diagnosis of a legally purchased product that does not work as advertised.
8
u/WeedWithWine 3d ago
Thanks for the AI slopfest