Platform index / Digital mixing console
Behringer WING Compact
The only platform here being studied to build on rather than to understand — and the only one where the container format was analysed, found opaque, and then declared off the critical path.
The load-bearing finding. The .wingfw container is opaque but structured, and specifically not a block cipher: the index of coincidence is flat across every stride from 1 to 1024, so there is no repeating key — and all 171 constant runs of ≥64 bytes are 0xFF with not one 0x00 run. No block cipher leaves those.
Verdict. Hardware-wise the most open platform surveyed, and the only one where a full replacement OS is a coherent goal. Everything now rests on two cheap lid-off questions and one fuse.
Method
Static analysis of a vendor firmware image, plus published datasheets and standards. No hardware has been acquired, so every hardware row is provisional and marked accordingly. A written clean-room policy governs the project.
Artifacts examined
- A
.wingfwrelease image, version 3.1.1 (fullsize variant — nothing learned from it may be assumed to hold for Compact) - NXP i.MX 6 datasheet and reference manual
- Analog Devices and Efinix product documentation
No manufacturer firmware, binaries or documentation are redistributed here. Artifacts are referenced by name and version only. See the method and legal statement for the basis on which this analysis was performed and the boundaries it observes.
Hardware architecture
| Item | Finding | Confidence |
|---|---|---|
| SoC | NXP i.MX 6 series, ARM Cortex-A9, MAPBGA 624 | Public |
| Core count | 1 (Solo-class) on the Compact — to be confirmed by reading SCU config on hardware. Note that OpenWING's device tree for the fullsize WING is named imx6dl, i.e. DualLite and dual-core. That does not settle the Compact, but it does rule out assuming one answer across the family | Inferred |
| DRAM | 1 GB at architectural base 0x10000000. Size unconfirmed — read the part markings | Unknown |
| Boot flash | SPI-NOR, ~8 MB, s25fl064k-class. Unconfirmed | Unknown |
| DSP | 4 × Analog Devices ADSP-21489 SHARC — where the mixing actually happens | Inferred |
| FPGA | Efinix Trion T55 or T85 — the I/O fabric, not the mixer. Converter TDM, clock tree, AES50, StageConnect, AES/EBU and DSP links | Inferred |
| FPGA config | SPI slave from the i.MX 6 | Inferred |
| Network switch | Marvell 88E6085 behind the i.MX 6 FEC, RMII 100 Mbit fixed-link. Unconfirmed | Unknown |
| AES50 | etherCON, 100BASE-TX physical layer. Whether a discrete PHY sits behind each port is unknown and decides whether those ports could ever carry anything else | Unknown |
| Clock tree | Steerable (VCXO/DCO) or fixed crystals — unknown. This single question decides whether AES67 is possible on this hardware at all | Unknown |
| StageConnect | USB-C physical layer, 32 channels | Public |
| Panel | LVDS 1280×800, USB HID touch, motorised faders, per-strip colour scribble LCDs. Panel timings deliberately not recorded — they belong to the panel's datasheet | Unknown |
Software architecture
| Item | Finding | Confidence |
|---|---|---|
| Boot path | The i.MX 6 has a documented, public boot ROM with a USB serial-download path. This is the fact that makes the whole project viable | Public |
| Container | .wingfw, 38,873,600 bytes for the 3.1.1 fullsize release — no header and no magic. The image is not stationary, so averaging over it misleads: the head (0x00000000–0x00230000) measures entropy 7.9999 with an index of coincidence of 1.0000, exactly uniform on both, while the bulk beyond it measures 7.3006 and 3.0321. The split is the finding | Verified |
| Container — constant runs | 171 constant runs of 64 bytes or more, 92,706 bytes in total, and every one of them is 0xFF — not a single 0x00 run. No block cipher leaves those intact | Verified |
| Container — byte statistics | Histogram strongly skewed low: 0x00 at 5.6%, then 0x02, 0x01, 0x08 and 0x0f each around 2.6–3.0% against a uniform 0.39%. That rules out AES over the bulk. Index of coincidence flat across every stride 1–1024, so no repeating XOR key. No ECB structure | Verified |
| Container — negative sweeps | No squashfs, ELF, gzip, xz, zstd, UBI, JFFS2, cramfs, DTB, uImage, zImage or i.MX IVT magic — none plain, and none under 256 XOR constants, 256 additive constants, nibble swap, bit reversal or positional XOR. A brute-force deflate/zlib/LZMA sweep over the first 8 MB returned zero hits | Verified |
| Container verdict | Opaque but structured, and not a block cipher. Decoding it is never required in order to write a replacement OS | Inferred |
| Container — solved elsewhere | OpenWING ships wingfw_unpack, wingfw_repack and wingfw_verify, so the format is solved by someone. What is public is only a loader shim: the implementation and, in their words, "any secret constants" live in a separate private repository. So the honest status is not unsolved — it is unsolved here, solved and deliberately withheld there | Public |
| Measurement stack portability | The Stage 1 premise is verified in software: the DSP measurement code compiles for armv7-unknown-linux-gnueabihf with no linker, sysroot or system library, and all 133 of its tests pass on a 32-bit target. ARM code generation and VFP behaviour remain open — only qemu or the hardware settles those | Verified |
| DSP toolchain | ADI CrossCore — proprietary, licensed | Public |
| FPGA toolchain | Efinix Efinity — free, but proprietary | Public |
Update path & security model
| Item | Finding | Confidence |
|---|---|---|
| Secure boot | Unknown, and it is the project's kill criterion. If the i.MX 6 HAB fuses are burned closed, the platform is not open and the work stops. That an independent project boots its own Linux on a WING is strong practical evidence the answer is favourable, though it has not been confirmed for the Compact specifically | Unknown |
| Container | Obfuscated by a mechanism not identified here, and off the critical path. Not a block cipher, on the constant-run and index-of-coincidence evidence above | Unknown |
These rows describe how a platform validates a firmware image, because that is a structural fact about its architecture. They are not a vulnerability disclosure and no exploit, bypass or circumvention technique is published here. Licensing and entitlement mechanisms are out of scope throughout — seescope boundaries.
What is programmable
- 1The i.MX 6 boot ROM, over USB OTG
Publicly documented in the NXP reference manual, requires no cooperation from the stock software, and is also the recovery path — which is why it is the one route worth proving before anything else is attempted. Conditional on the HAB fuses.
- 2USB audio on the host port
A measurement path that sidesteps the converter, TDM and DSP problem entirely, so it can never be blocked by the hard part. Deliberately staged first for exactly that reason.
- 3The four SHARCs and the Trion fabric
Documented parts. Bringing them up from nothing, alongside AES50, is the mountain — and the whole open-ended schedule risk lives here.
- 4The stock update path
Ranked last on purpose. It needs the container solved, and the container is explicitly not on the critical path: writing a replacement OS never requires reading the manufacturer's image.
Third-party open projects
Independent open-source work on this platform, recorded because it is prior art and because in places it confirms or corrects findings above. These are other people's projects: the descriptions are ours, the work is theirs, and nothing from them is reproduced here.
OpenWING
The same team's port of their X32 work to the WING. Linux boots on the i.MX 6 and the surface is largely alive; the audio hardware is not. It is roughly where this project's Stage 0 and Stage 1 would end up, reached from the opposite direction.
- Working: Linux boots, screen, touch and network, USB, and buttons, encoders and faders at a basic level. The scribble-strip LCDs are understood.
- Not working, and explicitly listed as such: the Trion FPGA, all four DSPs, and the entire audio system — ADDA, StageConnect, AES/EBU and AES50. So no audio passes through it today.
- It resolves the largest open question on this page in principle: a WING will boot a third-party Linux, which is what the secure-boot kill criterion asks. It does not resolve it for the Compact specifically.
- Its
.wingfwtooling is the notable part — unpack, repack and verify all exist, but only as shims onto a private repository holding the implementation and constants.
Licence note: these projects are GPL-3.0. Facts about them — part numbers, what boots, what does not — are not copyrightable and are recorded freely. Their source is not a source for our own differently-licensed work, and no code from them is used in it.
Traps
Mistakes this analysis actually made, or came close to making. They are recorded because each one produces a plausible-looking wrong answer rather than an obvious failure.
- A 3-byte magic such as gzip's appears about 2.3 times by chance in 38 MB, and scanning 514 transforms means scanning 263 MB — expect roughly 16 coincidental hits. An early verdict called the firmware "a known container" on exactly that basis.
- Every negative sweep result needs a positive control. A broken sweep and a genuine absence look identical.
- Averaging a statistic over a non-stationary image hides the finding. Reported as one number the container looks like weak, uninteresting obfuscation at 7.37 bits/byte; split at 0x230000 it resolves into an exactly-uniform head and a visibly structured bulk, which is the whole result.
- Assuming that because we have not solved something, nobody has. The container was written up as an open problem while a public repository already contained working unpack and repack tools for it — with the substance moved to a private submodule, so the tooling is visible and the method is not. Checking what exists costs minutes and reframes the question from "can this be solved" to "is it worth re-solving".
Open questions
- Is the i.MX 6 serial-download path reachable, and are the HAB fuses unburned? Everything else is downstream of this.
- Discrete PHY behind each etherCON, or straight to fabric?
- Is anything in the clock tree steerable?
Status of this entry. Work in progress; the hardware inventory is not yet confirmed against a bench. Nothing on this page has been verified against physical hardware — no unit of this platform has been opened, connected to or modified.