The Stagehand iPad App

The classic device-number contract is that the value claimed in the 0x02 packet (the D at byte 2e) becomes the device number that appears in every subsequent keep-alive and status packet. Stagehand is the only device this analysis has seen that breaks that contract: it claims 0x3a (decimal 58) but operates with a random number drawn from a high range on each launch.

The runtime number lives in byte 36 of the 0x06 keep-alive (the slot where a CDJ or mixer puts D). Across five cold-launches of the Stagehand app over the same captured Wi-Fi network, the observed values were 141, 211, 156, 190, and 199. That spread is consistent with a random integer drawn from roughly 0x80–0xff excluding the canonical CDJ slots (1–6) and the mixer slot (33). The reason for the mismatch is presumably to keep Stagehand visible-but-out-of-the-way: the symbolic slot 58 leaves a marker on the wire that any other device on the network can recognise as "a Stagehand instance is present", while the high-range runtime number guarantees no collision with player or mixer slots regardless of how many are connected.

A second piece of per-launch identity lives at byte 39 of the 0x0a announce and 0x02 claim packets: a 4-byte identifier field. Across the same five cold-launches the identifier was distinct each launch — but lagged by one launch: each launch’s announce contained the value that the previous launch had used in its claim. This suggests Stagehand caches the random identifier it picks once, uses it for the announce on the next launch, then picks a new one for that launch’s claim. The mechanism is curious but not load-bearing for any downstream protocol behaviour.

Stagehand presents two distinct MAC addresses on the wire:

Both values change between launches. The A9 binds its outgoing unicast UDP traffic to the protocol MAC’s IP, not to the link-layer MAC — so an arp lookup of the iPad’s IP will never return the MAC embedded in Stagehand’s protocol payloads, only the iOS Wi-Fi privacy MAC. This is harmless under normal operation but matters when MITM-ing the link: the bettercap target list must use the link-layer MAC, while any decoded 0x06 payload comparison must use the protocol MAC.

Byte 35 of every modern keep-alive is a per-product model code that AlphaTheta-era firmware appears to have added to the legacy Pioneer ProDJLink protocol. The dysentery-documented original CDJ keep-alive left this slot at 00; the CDJ-3000-compatible variant uses 64, and dysentery already flagged that "having the wrong value there can even cause CDJ-3000s set to player 5 or 6 to repeatedly kick themselves off the network". That CDJ-3000 special-case generalises: every modern AlphaTheta product appears to stamp its own code.

The values observed so far:

The numeric pattern (0x20 ASCII space, 0x31 ASCII '1', 0x64 ASCII 'd') does not seem semantic — likely just a per-product enum assigned by AlphaTheta engineering. Devices that stamp 00 are treated as legacy; devices that stamp anything else are treated as their specific product.

The only A9 → Stagehand packet that keeps the two-byte type field is the 100-byte paired keep-alive on port 50000. The first 54 bytes are byte-for-byte identical to the A9’s broadcast keep-alive — same MAC, same IP, same device number 21, same model-code byte 31. The next 46 bytes name the Stagehand peer the A9 is paired with.

The A9’s broadcast keep-alive itself is the legacy mixer keep-alive form with two AlphaTheta-era amendments: byte 34 is 03 rather than 02 (the modern mixer device-type marker), and byte 35 is 31 rather than 00 (the A9 model code).

The second-block header at byte 44 carries the unicast peer marker 3a in place of the A9’s mixer device number, then names the Stagehand peer with its protocol-layer MAC, its IP, the device type 05, and Stagehand’s model code 20.

The pairing is one-way: only the A9 emits this paired form. Stagehand’s own broadcast keep-alives never name the A9 in return. The A9 is keeping the record of "who I am serving"; Stagehand never asserts a partner.

The 266-byte 0x39 packet on port 50002 is where Stagehand sources every per-channel fader / EQ / trim / color / crossfader reading. It is broadcast at ~4 Hz with no apparent triggering by state changes; the per-control bytes update in place from one frame to the next.

The peer marker 3a and the constant 03 follow at bytes 1e–1f, then a length-like field len_r at bytes 20–21 (00 da at baseline = 218 — close to but not equal to the 232 bytes that follow it). The low byte of len_r at byte 21 also acts as a partial state-counter: it ticks on some control changes but not all (no change on EQ-Hi-cut or crossfader-position; jumped by 3 on a crossfader-assign flip). Bytes 22–23 (00 e6 at baseline) are unexplained.

The 584-byte 0x58 packet is the most active stream on the wire — ~30/sec, every second of the 103-minute idle capture and the 19-minute provocation capture. With no audio passing through the mixer, the body is almost entirely zero apart from a small structured prefix (02 24 00 00 00 00 00 a5 38 …​).

The rate, the size, and the fact that this is the only A9 → Stagehand stream that runs at audio-frame cadence (~30 Hz matches a typical VU-meter refresh) make per-channel level metering the strongest candidate for the body’s contents. But no live audio capture has been run, so this is unverified — hypothesis (strong).

A 40-byte 0x3b packet on port 50002 carries a 4-byte payload at byte 24. Across 1,465 instances in the 103-minute capture the only field that varies is byte 25, which behaves as a sequence counter that increments and wraps every ~32 ticks (and a couple of adjacent bytes that look derived from it). All other bytes are constant. So 0x3b is a heartbeat, not a state-carrying packet — it appears to keep the unicast channel warm even when no other A9 → Stagehand traffic is moving.

Across the entire 103-minute capture, Stagehand sent only 14 unicast packets to the A9 — all 40 bytes, all sent in pairs ~10 ms apart, so 7 distinct commands. Each uses packet type 0x3a (the same value Stagehand stamps as its symbolic device number), names the A9 by its real device number 21 at byte 1e, and carries a 2-byte opcode followed by a 4-byte payload.

The opcodes observed were 00 b6, 00 b4, 00 a2, 00 b1, 00 b7. The clustering in the 0x00 b0–0x00 b8 range hints at a small command family, but only 00 b4 was sent more than once across the capture and no specific UI action was tied to any opcode by the original capture. Payloads (arg) are 4 bytes; values seen were 00 0a 00 00, 00 0c 00 00, 00 16 00 00, 00 09 00 00, 00 0b 00 00 — consistent with small integer parameter IDs rather than continuous control values.

The Stagehand UI does not let the operator drive A9 faders, EQ, trim, or crossfader from the iPad (verified by hands-on test), so these opcodes presumably address some other surface — channel-select / FX-toggle / cue-button latches, or the "input source" / "color FX" selectors visible inside 0x39. A scripted UI tour under MITM is still needed to map opcode → UI action.

A CDJ-3000 attached to a Stagehand-bearing network publishes three distinct names on the wire:

All three personas share the one physical MAC and IP. The naming swap is interesting because dysentery already documents the iPad-side 0x56 request flow under the assumption that the responder names itself the same as it does on the broadcast plane — for AlphaTheta-era CDJ-3000s talking to Stagehand, it doesn’t. A consumer that filters by name will need to recognise all three.

Once Stagehand has joined, the CDJ-3000 unicasts a 0x20-typed packet to the iPad on port 50004 at exactly 142.857 Hz (a precise 7.000 ms tick). The body carries a 24-bit monotonic counter and a small constant prefix; the counter increments every tick regardless of whether a track is loaded or playing.

The cadence and the steadiness make this look like a shared network timebase — a way for the iPad to derive a sub-millisecond clock reference from a participating CDJ, independent of the per-beat timing carried by 0x28. The choice of 7 ms specifically (vs. an obvious round number like 8 ms / 125 Hz or 10 ms / 100 Hz) is unexplained.

This is the same type byte and port that dysentery documents under Audio Timing for Touch Audio — the encoding may be related. Confidence: structurally consistent but not verified against the Touch Audio decoding.

The CDJ unicasts a 68-byte 0x0b packet at ~30/sec, which is one of two streams that share that type byte:

The 8 round-robin sub-types include slow event counters (one byte ticks ~once every 65 s per sub-stream), fast counters (two bytes change every packet — likely frame-cadence), and per-channel slots that stay mostly empty under single-deck capture but probably populate under multi-deck mix. None of this has been provoked.

Stagehand fetches waveform overlays, cue-colour palettes, and detailed track metadata from the CDJ-3000 via an 8-opcode request/reply protocol on port 50002. The iPad sends a 0x55-typed request, the CDJ replies with a 0x56-typed packet whose body type is tagged by the opcode that asked.

Two variants of the reply remain opaque: a 196-byte payload (entropy 6.22, vocabulary 85 distinct bytes) that is structurally consistent with a proprietary cue/loop list, and a 316-byte payload (entropy 7.19, exactly 16 AES blocks) that looks like AES-CBC ciphertext. The decryption key for the second one is presumably embedded in the AlphaTheta-Connect mobile app. Hypothesis (strong): paired cue-colour palettes correspond to memory-cue vs hot-cue, or primary-deck vs secondary-deck — they are structurally identical and distinguished only by a single byte at offset 39.

When a track loads on the CDJ-3000, the player unicasts a 2572-byte 0x3d packet to Stagehand carrying a denormalised metadata blob. Roughly the first ~150 bytes have been decoded: UTF-16-LE string slots for title, artist, album, genre, comment, and label, plus two varying 16-bit fields at offsets 0x2a/0x56 (mirrored — almost certainly the track ID) and 0x2e (purpose unknown).

The remaining ~2370 bytes are unmapped. The post-string region (offsets 0x900–0xa04) is the densest unknown zone and likely encodes BPM, key, length, hot-cue list, loop list, cue colour tags, rating, and file path — all the fields a "full" track tile would need to render. There is also a tag byte in the comment slot (03 for raw ASCII in one capture, 01 for UTF-16-BOM + UTF-16 in another) that suggests a TLV-style encoding for the comment, but the full encoding has not been pinned down.

A handful of small-packet types on port 50002 carry CDJ settings-panel content to Stagehand and Stagehand command writes back to the CDJ. These were the hardest to decode because they fire in clusters: each user-visible CDJ pref-write generates a 5–10 packet exchange across at least three of these types within ~50 ms.

Two of these are the Stagehand command channel: the route by which the iPad pushes CDJ preference changes and CDJ transport actions onto the wire. Phase 5 of the original analysis spent three weeks trying to find a TCP control channel for these commands; it turned out there is no TCP, just two UDP types that had been hiding in plain sight because earlier scans were marker-window-driven rather than transition-first.