Aux-opsy / Stoatworks Labs

Platform index / Digital mixing console

Yamaha DM3

Nine years newer than the QL and sharing almost nothing with it but the parameter framework — and, crucially, the same DSP philosophy: the signal path is fixed-function on both, however different the host looks. In 2026 the entry gained a second axis the firmware analysis never touched: the DM3's live **control plane**, captured and driven against a real console -- the first hardware any part of this entry rests on.

PartialIntroduced 2023DM seriesLinuxNamed-component archiveDanteFPGARegister-configured DSPMBDF scenesSelf-describing payloadSCP remote controlYSDP discoveryHardware-tested

Hardware in our hands: Yamaha DM3, firmware V3.00 -- a control-plane bench session on 2026-09-15 (SCP, OSC and YSDP captured; the Dante-BabelBox SCP adapter run against the desk, reading and writing gain and phantom). The firmware/silicon analysis below remains file-derived, not bench-checked. · Last updated

The load-bearing finding. Two findings, two axes. On the wire (bench-tested): the DM3's remote-control protocol is SCP, a newline-delimited ASCII command set on TCP 49280, and it was captured, decoded and driven against a real DM3 -- head-amp gain and phantom read and written, each set echoed by an OK and an unsolicited NOTIFY to every other client, with the console self-describing all 177 parameters over prminfo. A cross-vendor bridge now ships speaking it (see the control section). Inside the box (file analysis only): the update package is a named-component archive (#YAMAHA MBDFArchive) carrying a full Linux rootfs, and the installer is a plain bash script with no checksum ceremony and no signature. The 3.8 MB component filed under DSP/ looks like a loadable DSP image and is not one — it is supervisor MCU firmware plus coefficient tables, so the audio silicon is register-configured exactly as on the QL.

Verdict. The contrast with the QL is the CPU and the OS, and not the DSP — which is where this entry was wrong until 2026-08-14. A Linux userland behind an unsigned script-driven installer is a materially different proposition from the QL’s µITRON image, but the signal path is fixed-function on both. Nine years apart, same answer. What changed in 2026 is orthogonal to all of that: the DM3's external control is now understood and bench-proven -- SCP over TCP is the real remote-control path (not the OSC port), it pushes live change notifications to every client, and an open cross-vendor bridge speaks it in a shipped, signed release. Reprogramming the box is still gated on naming the mixing silicon; controlling it no longer is.

Method

Two methods on two axes. The firmware, silicon and container findings are static analysis of the V3.00 firmware package (167 MB) and the macOS DM3 Editor -- file-derived, not bench-checked. The control-plane findings are bench-measured: a live session against a real DM3 (firmware V3.00) on 2026-09-15, packet-capturing the Dante and control networks and running the Dante-BabelBox SCP adapter against the desk (reading and writing head-amp gain and phantom, watching the console's own change notifications). The scene-format findings have their own basis and are kept apart from the firmware ones: a record parser derived from a publicly downloadable Yamaha preset pack for the TF series, then run unchanged against the factory scenes the DM3 Editor itself ships, and checked against the editor's own parameter descriptors.

Artifacts examined

  • DM3_firmware_V3.00.bin — 167 MB, eleven named components
  • DM3 Editor.app (macOS)
  • DM3 Editor V3 — 21 parameter descriptors under Resources/Descriptor/mms_*.xml, 15 factory .dm3s scenes and 263 .dm3p presets, all shipped with the free editor
  • Yamaha's published Audix QuickPro preset pack for the TF series — 28 .tfp files, a public download, and the sample set the container layout was derived from and validated against
  • Packet captures from the 2026-09-15 bench session -- SCP, OSC, YSDP and the DM3 Editor's MMS sync, in the private stoatworks-labs/dante-captures repo (yamaha-dm3/, yamaha-dm3-editor/)
  • Dante-BabelBox v0.3.0 -- a shipped, signed cross-vendor Dante control bridge whose yamaha-dm3-scp adapter was validated against this console

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

ItemFindingConfidence
Application processorRuns a Linux userland — component 1 is an 88 MB rootfs tarballVerified
FPGAPresent — component 3, fab_V110.bin, 539 KB inflatedVerified
DSPNot a loadable DSP image, despite the filename. Component 4, DSP_V121.bin, 3.80 MB inflated, is several Cortex-M images plus coefficient and curve tables: the first word is 0x200081B8, a Cortex-M initial stack pointer, and the code is Thumb-2 throughout. Real content is ≈ 1.3 MB of the 3.8 MB partition, the rest zero padding. The data region fails the same code test used on the QL — monotonic non-decreasing runs of 10,235 / 4,097 / 4,096 words against 7 for known DSP code — and contains a literal descending ASCII ramp, i.e. a lookup curve. dsp_initPowerOnBootAll boots the MCUs; the audio silicon behind them is register-configuredVerified
Panel MCUComponent 2, DM3PN_V100.bin, 246 KB inflatedVerified
Audio networkingAudinate Brooklyn 3 plus a Broadway module — components 5 and 6Verified

Software architecture

ItemFindingConfidence
Container format#YAMAHA MBDFArchive — magic, a 16-byte model string at 0x24, then a fixed-size identifier field, then #FIRMWARE records of five BE u32 fields, three NUL-terminated strings (path / description / version) and a zlib payload, terminated by #END. Payloads were located by scanning forward to the zlib header rather than by trusting the length field, which was never fully decoded. See the DM7 for a field-by-field derivation of the same containerVerified
Main applicationapp_console.tgz, 64.8 MB inflated, V3.00Verified
InstallerA bash script. Untars to /tmp/update, walks /yamaha/firmware.new/, compares each component's version file against the installed one and copies only what changed, running a per-component .sh hook if presentVerified
BootloaderShipped as an updatable component — app_bootloader.tgz, V1.03Verified
Scenes and presets ride the firmware's own containerThe same #YAMAHA MBDF… container carries firmware archives, channel presets, scenes, list backups and user accounts as separate subtypes. The evidence that this is one family rather than a resemblance: a record parser derived from the TF preset pack walked a DM3 scene — a different subtype and a different model — with no changes at all. Records are a tag, a field name, a target naming an object type and index, and a payload, padded to a four-byte boundary and terminated by an #END tagVerified
The payload describes itselfThe payload is not an opaque packed blob: it carries its own schema inline, a block of collection and parameter records followed by values packed to that layout. Walking the schema of a real DM3 factory scene yields exactly 207 collections and 494 parameters — precisely what the editor's own mms_Mixing.xml declares — and the value block begins exactly where the walk ends. Two independent sources agreeing with nothing fitted between them is what makes this trustworthy rather than a plausible storyVerified
Field layout is per-model and has to be read, never assumedThe DM3's input-channel record is 473 bytes × 16 with the patch field at offset 100 and four bytes wide; the TF's is 515 × 40 with a one-byte patch at the same offset. Offsets are only correct if they are computed by summing each preceding collection's size × array length in document order and then looked up by name — the field's position is not a constant of the formatVerified
A preset is not a sceneWorth keeping straight, because they share a container and an extension convention: a .dm3p preset holds one channel strip and has no patch, no routing and no channel-name table, while a .dm3s scene holds console-wide state. Only the scene can produce a patch listVerified

Update path & security model

ItemFindingConfidence
Image signingNone — the installer performs no signature checkVerified
IntegrityNo checksum ceremony anywhere in the install path. A fixed-size field follows the model string in the archive header and was previously described here as a 16-byte digest; the Yamaha DM7 derivation of the same container gives a 20-byte identifier at 0x34 that is demonstrably not a digest of the image or any obvious sub-range. The DM3 source image is no longer in our possession, so which applies here cannot be re-derived — the field is recorded as unidentified rather than kept at a confidence it never earnedUnknown
EncryptionNone — every component is zlib, and unpacks with a 60-line scriptVerified

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.

Control & discovery

SurfaceFindingConfidence
Remote control -- SCPThe DM3's primary control surface: a newline-delimited ASCII command protocol on TCP 49280 (devinfo, get/set, prminfo, ss* scene ops). Head-amp gain (IO:Current/InCh/HAGain, whole dB 0-64) and phantom (48VOn) were read and written on a real DM3, each set confirmed by an OK echo carrying the value and an unsolicited NOTIFY broadcast to every other connected client. The console self-describes its whole parameter space over prminfo -- 177 parameters -- so no fixed table is needed. This is the same protocol family Yamaha's R Remote speaks to the R-series.Measured
Remote control -- OSCA second, weaker surface on UDP 49900 (/yosc:req/..., replies /yosc:ok/...). Reads work, but a set is unacknowledged and the console emits no unsolicited OSC, so there is no change feed. Reply values for 48VOn and the device-status fields come back as OSC int64 (h), not int32. Confirmed on the bench; SCP is the better transport for exactly these reasons.Measured
Discovery -- YSDPYamaha devices announce over UDP 54330 with a YSDP-magic datagram (sender IP + MAC, the service string _ypa-scp, manufacturer, model, unit-ID and name), and answer a controller's query the same way -- this is not Bonjour/mDNS, which is what a naive discovery would look for. R Remote and the DM3 both use it, and only one Yamaha control app can hold the port per host. Captured from the DM3 and R Remote.Measured
Editor sync -- MMS over TCPDM3 Editor mirrors the whole console over a third protocol: the MMS parameter framework serialized on TCP 50368, message tags EEVT (events/keepalive), MSTS, MPRC, MMIX, MVOL, MSCL, MSUP -- the same mms_*.xml framework the firmware carries, on the wire. A full ~3.3 MB state pull on connect, bidirectional keepalive while online, and live push of external changes (an SCP write made from another client) were all captured.Measured
Network identityThe Dante model presents three interfaces on Yamaha OUIs: the Linux host (control), the NETWORK jack, and the Broadway Dante module (Broadway-, the PTP leader). On a flat link-local network the NETWORK-jack address the beacon advertises is unreachable (dual-homed Linux); the address that answers is the one carried in the YSDP response, served via the Dante module's internal switch. Observed on the bench.Measured

These rows describe how the device is controlled and discovered on the network, observed by capturing traffic and running an open control client against a unit on our own bench. They document protocol shape and behaviour, not any exploit, bypass or circumvention technique.

What is programmable

  1. 1The Linux rootfs

    A conventional userland behind an unsigned, script-driven installer is a materially different proposition from the QL's µITRON image.

  2. 2The DSP supervisor MCUs

    What the update loads is Cortex-M supervisor firmware, not the signal path — so this rank buys far less than it appears to. The audio silicon behind those MCUs is register-configured, and its identity is still unknown; the DM3 service manual would settle it the way the QL's did.

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 component filed under DSP/ is not evidence that the DSP is loadable, and this page asserted for a week that it was. DSP_V121.bin is 3.8 MB, is named DSP, and is genuinely boot-loaded at update time by dsp_initPowerOnBootAll — every surface signal says loadable DSP image. It is several Cortex-M images plus coefficient tables. The tell is the first word, 0x200081B8: a Cortex-M initial stack pointer, not DSP code. The published verdict here was the exact inverse of the finding until 2026-08-14, and the underlying research had already reached the right answer — the error was in the transcription onto this site, which read the first half of the argument and stopped before the correction.
  • Size is not content. Real content is ≈ 1.3 MB of that 3.8 MB partition; the remainder is zero padding, and quoting the partition size makes the payload sound three times more substantial than it is.
  • The word "digest" was assumed, not derived. A fixed-size field after the model string was recorded here as a 16-byte digest at verified confidence. Nothing had checked it against the image, and the DM7 derivation of the same container family found a 20-byte identifier that is not a digest of anything. A field whose size is observed and whose meaning is guessed is unknown, not verified.
  • Hard-coding one model's field widths. Reading the TF's one-byte patch field as the DM3's four-byte word produced a column of plausible zeros rather than an error — the failure mode of a packed format is not a crash, it is a decode that looks fine. Sum the descriptor, look fields up by name, and check the summed total against the declared record size.
  • SCP, not OSC, is the DM3's real control protocol -- and the difference is not cosmetic. Over OSC a set is unacknowledged and the console pushes nothing, so an integration reads back a stale value after every write and never sees a change made anywhere else. Confirmed reads/writes and the live NOTIFY feed exist only on the SCP/TCP port (49280). Anyone who starts from the published OSC spec builds the weaker half and does not know it.
  • Discovery is YSDP (UDP 54330), not mDNS/Bonjour. A controller that browses Bonjour for the console finds nothing. And only one Yamaha control app can hold that port per host: with R Remote running, DM3 Editor silently will not go online -- an empty device list, or a Direct-IP connect that stalls forever on keepalive. On the bench that looked exactly like a network fault and was not; quitting R Remote fixed it instantly.
  • On a flat network the address the DM3 advertises can be the one you cannot reach. The Dante model is dual-homed; its NETWORK jack self-assigns a link-local address that does not answer when NETWORK and Dante PRIMARY share one segment. The address that actually answers is the one carried in the YSDP response, not the broadcast beacon.

Open questions

  • Which silicon actually performs the mixing, and how it is configured. DSP_V121.bin boots the supervisor MCUs in front of it, not the part itself.
  • The FPGA part has not been identified.
  • What the fixed-size identifier field after the model string contains. The DM3 image is no longer in our possession, so it cannot be re-derived here.
  • No board has been inspected, and the firmware and silicon claims (unlike the bench-measured control-plane rows) have not been checked on hardware.
  • Whether the DM3 emits Yamaha's MBC head-amp protocol when a real R-series stagebox is mounted to it. None was on the bench, so this is untested; with nothing mounted the console emitted nothing MBC-shaped, which is expected rather than evidence either way.
  • What the patch source codes mean. The DM3's patch word reads as an index in the high byte with a port type below it, two values have been seen, and none of it has ever been checked against a console's own patch screen. The field is located and its values are opaque — which is the honest state to leave it in rather than naming ports from two samples.
  • Whether the four-byte-boundary padding in the container is really alignment. Every sample pads by exactly one byte, which fits alignment and fits equally a length that excludes a terminator. A single sample whose payload length falls elsewhere modulo four would settle it, and none has turned up.

Status of this entry. Substantial findings recorded, but whole subsystems remain unexamined. Rows labelled Measured were read off a running unit; everything else on this page is derived from files and has not been checked against hardware.

← Back to the platform index