Method & legal status

1. Purpose: understanding and interoperability

The purpose of this work is to understand how digital mixing consoles are built, and — where a project follows from that understanding — to obtain the information necessary for an independently created device or program to interoperate with existing equipment.

Concretely, the questions each teardown sets out to answer are:

• Where does the audio processing actually happen — a general-purpose CPU, a fixed-function DSP, or FPGA fabric?
• What is the real silicon, as opposed to what the marketing implies?
• How is firmware packaged, delivered and validated?
• Is there any part of the signal path a third party could legitimately extend?

The fourth question is the one that motivated the work. Several of our own audio processing projects raised an obvious question — could this run on a console? — and answering it honestly required knowing what was inside the consoles. Two of the four teardowns answered no, and said so.

2. How the work was done

In every case the material examined was lawfully obtained and already in our possession: firmware update packages published by manufacturers for their own customers, software installed under a valid licence on our own machines, service manuals, and publicly available component datasheets and standards.

The techniques used were:

• reading plain-text scripts, configuration files and build metadata;
• extracting string tables and embedded build paths;
• listing and demangling symbol tables and C++ RTTI type names;
• statistical analysis of container files — entropy, byte histograms, index of coincidence, run-length structure;
• disassembling a limited number of functions to establish which offsets are compared against which constants;
• cross-referencing all of the above against manufacturer service manuals and component datasheets.

3. Two terms, used precisely

Two terms are commonly attached to work of this kind. Neither accurately describes most of what is published here, and neither is claimed loosely.

This is not black-box analysis

Black-box analysis means observing only a system's external behaviour — packets on the wire, inputs and outputs — without inspecting its internals. The findings here come substantially from inspecting vendor binaries. Calling that black-box would be false.

This is not, in general, clean-room analysis

"Clean room" is a specific organisational control: one team examines the original and writes a specification containing no expressive material from it, and a second team — which has never examined the original — implements solely from that specification. Where no implementation exists, no such separation has been established, and no clean-room claim is made. The one project that doescontemplate an implementation operates under a written clean-room policy, described in §7.

4. What is claimed instead

• Analysis of lawfully obtained, vendor-distributed binaries and documentation, performed to extract the ideas, functional interfaces and interface specifications necessary to understand the platform and to achieve interoperability. Under both EU and US law those elements are not themselves protected by copyright.
• No manufacturer source code was seen, obtained or used. No NDA, developer agreement, OEM agreement or SDK was in effect or relied upon. No confidential material of any kind was accessed.
• No manufacturer code is reproduced. These pages record facts about silicon, wire formats, constants, identifiers and structure. Where a vendor identifier is quoted — a symbol name, a build path, a numeric constant — it is quoted as a factual finding, in the minimum amount required to describe the interface, and not as copied expression.
• No firmware, binary or manual is redistributed. Artifacts are referenced by filename and version only. Nothing on this site will help anyone obtain manufacturer software they are not already entitled to.

5. Scope boundaries

These are hard boundaries, not preferences.

1. No analysis of licensing, authorisation, entitlement or DRM.

   If such a mechanism is encountered, analysis stops and the finding recorded is only that it exists and roughly where. This happened on one platform in the index, and the analysis stopped there. Interoperability exceptions are broad; anti-circumvention exceptions are not, and the two must never be conflated.

2. Nothing that enables unlicensed use of any product.

   No key algorithms, no entitlement bypasses, no methods for obtaining paid features without paying for them.

3. No exploits, and no modification instructions.

   Where a page records that a platform validates firmware with a CRC and no signature, that is a structural fact about its architecture — the same class of fact as which SoC it uses. It is not a vulnerability disclosure, and no bypass, forged image or circumvention technique is published here.

4. No redistribution of manufacturer material.

   No firmware images, no extracted binaries, no scanned manuals, no artwork. Analysis tooling in our own repositories takes the path to an image from an environment variable and ships no image.

5. Nothing sourced from another project's code under an incompatible licence.

   Where prior open-source work exists on a platform we are building on, its source is treated as off-limits and its factual claims are re-derived from datasheets or our own measurements. Where that policy was breached before it existed, the affected facts are marked unconfirmed rather than quietly kept.

6. Legal basis

Reverse engineering for interoperability is expressly protected in the jurisdictions that matter here. What follows is a summary of the basis on which the work proceeds. It is not legal advice, and any project moving to commercial release should take its own.

Samba, WINE, ndiswrapper and a long list of comparable projects rest on exactly this basis.

7. The clean-room control, where an implementation is contemplated

Most of this index is documentation with no implementation attached. One project is different, and it carries a written policy that binds the repository:

1. Specification phase. Analysis of vendor artifacts produces a specification stated in terms of observable behaviour: byte layouts, constants, state machines, timing. It records no source code, no decompiled output, and no algorithm expression copied from a binary.
2. Review gate. Before handoff the specification is reviewed for anything expressive rather than functional, and such material is removed or restated.
3. Implementation phase. Implementation proceeds from the specification alone, by a person or agent that has not examined the vendor binaries, with that separation recorded.
4. Provenance record. Every implementation commit traces to a specification clause, and every clause traces to the evidence that produced it.

Until step 3 has actually been performed and recorded, no clean-room claim is made about any code. Where source material from an incompatibly licensed project was read before that policy existed, the fact is recorded openly and every parameter tracing to it is marked unconfirmed until independently re-derived.

8. Confidence labelling

Every technical claim on this site carries one of four labels. They are used strictly, and a claim without evidence does not get promoted because it sounds likely.

Each platform page also carries a Traps section recording mistakes the analysis actually made. They are published because each one produces a plausible-looking wrong answer rather than an obvious failure — which makes them more useful to a reader than the findings that went smoothly.

9. Trademarks and affiliation

All manufacturer and product names on this site are the trademarks or registered trademarks of their respective owners. They are used here foridentification only — nominative use, in a factual description of the products they name.

Stoatworks Labs is not affiliated with, endorsed by, sponsored by, or acting in cooperation with any manufacturer named on this site. Nothing here is an official source of information about any product, and no manufacturer has reviewed it.

Opening a console, modifying its firmware, or connecting unapproved equipment will in all likelihood void its warranty and may render it unusable. Nothing here is a recommendation to do any of those things.

10. Corrections

This is research, and research has errors in it. Some claims here rest on a single artifact; at least one platform's source image is no longer in our possession and its findings currently cannot be re-derived. That is stated on the page rather than hidden.

If you are a manufacturer, an engineer, or anyone else who can show that something on this site is wrong, we want to fix it — and a correction from someone who actually built the thing is worth more than any amount of static analysis. Corrections are published, not quietly edited away.

Contact: stoatworks-labs.com.