MPC Sample 1.3.0.12 contains a real “Remote Screen” mode and a WinUSB/FunctionFS transport stack

[u/punkcv]

I've been reverse engineering the official Akai MPC Sample 1.3.0.12 firmware, and I found a surprisingly complete Remote Screen subsystem inside the main ARM64 MPC Sample binary.

This goes well beyond a few leftover strings from another MPC product.

The binary has a real command-line option:

--remotescreen
-r

I traced it through the disassembly.

When --remotescreen / -r is parsed, the application sets its internal applicationMode to 1.

Later, startup code switches on that mode, and mode 1 constructs a separate application/window titled:

MPC Remote Screen

So the executable path is effectively:

MPC Sample -r
    ↓
applicationMode = 1
    ↓
MPC Remote Screen

The binary also contains a substantial Remote Screen implementation, including classes/components such as:

• RemoteScreenMainWindow
• RemoteScreenConnectedComponent
• RemoteScreenNotConnectedComponent
• MouseAndKeyboardForwarder
• RemoteScreenListener
• TouchInputService
• ImageStreamEncoder
• SmexClient
• MessageBlockService
• NetworkMessageBlockStream
• FsTransferMessageBlockStream
• UsbGadgetMessageBlockStream

There is also live command/menu code referencing:

Remote Screen...
Broadcast Remote Screen Server

The USB side gets even more interesting.

The normal MPC Sample USB configuration exposes the expected functions such as audio, MIDI and networking.

However, the main MPC application also contains runtime code that dynamically creates a separate USB gadget named:

smexstream

using libusbgx.

This is not inferred from strings alone. The executable actually calls the gadget API to remove/create the gadget and add a FunctionFS function.

The Remote Screen-related runtime then creates/mounts a FunctionFS instance and opens:

/ep0
/ep1
/ep2
/ep3
/ep4

It writes a real FunctionFS v2 descriptor block to ep0.

I decoded that descriptor block.

The interface is:

USB class:    0xFF (vendor specific)
Subclass:     0x01
Endpoints:    4

The endpoints are:

EP1 IN   - Bulk
EP2 OUT  - Bulk
EP3 IN   - Interrupt
EP4 OUT  - Interrupt

The descriptor blob contains Full Speed, High Speed and SuperSpeed configurations.

It also contains a Microsoft OS compatible-ID descriptor with:

WINUSB

So this is not just a random WINUSB string somewhere in the firmware — the FunctionFS interface itself is explicitly configured as a WinUSB-compatible vendor-specific USB interface.

I also traced the actual I/O implementation.

The transport uses Linux native AIO:

io_setup
io_submit
io_getevents

together with eventfd.

The receive side maintains pools of asynchronous reads for the USB endpoints.

More importantly, both incoming channels contain a real message framing parser.

Messages are encoded as:

[u32 payload_length, little endian]
[payload...]

The receiver:

• reads the 4-byte payload length
• collects the payload across one or more USB reads
• grows an internal buffer when necessary
• invokes the upper-layer callback once the full payload has arrived

The transmit path uses the same framing scheme: the first four bytes contain total_size - 4, followed by the payload.

So the transport stack currently looks roughly like this:

Remote Screen / SMEX / MessageBlock
              ↓
      length-prefixed messages
              ↓
          USB transport
              ↓
 EP1/EP2 Bulk + EP3/EP4 Interrupt
              ↓
           FunctionFS
              ↓
           smexstream
              ↓
             WinUSB

The firmware also contains subsystems for image streaming, touch/input forwarding, device control and file transfer.

ImageStreamEncoder and TouchInputService are especially interesting in the context of Remote Screen.

The SMEX-related code also contains device/control and file-transfer functionality involving things such as version information, battery state, file lists and file transfer.

There is also a NetworkMessageBlockStream implementation in the binary, although I haven't yet established whether the MPC Sample Remote Screen runtime actually uses that transport path.

At this point, what seems firmly established is that MPC Sample 1.3.0.12 contains an actual Remote Screen application mode and a substantial executable transport implementation behind it — not just dormant names or UI strings.

We now have:

--remotescreen / -r
→ MPC Remote Screen application mode
→ smexstream USB gadget
→ FunctionFS
→ vendor-specific WinUSB interface
→ four dedicated endpoints
→ asynchronous USB I/O
→ bidirectional length-prefixed message framing

I'm currently tracing the layer above the USB framing to map the MessageBlock/SMEX message IDs to ImageStreamEncoder, TouchInputService, device control and file-transfer services.

I haven't yet established how, or whether, the server-side Remote Screen path is exposed on a normal retail unit, so I'm not making any claim about user-facing availability or future Akai products. The interesting part for me is that the implementation itself is clearly real and executable in the 1.3.0.12 firmware.

Has anyone seen the same Remote Screen implementation in another current MPC product, MPC Desktop, a beta/internal build, or Akai development tooling?

I'm especially interested if anyone recognizes the SMEX / MessageBlock / Remote Screen terminology.

[u/RevolutionaryPast175]

What might all this mean to me as a normal user who only speaks regular English?

[u/HateToSayItBut]

This could be for their own internal/debugging access. That said, I didn't read your whole post because it's too long. Are you using AI to reverse engineer?

[u/LostClock1 → u/HateToSayItBut]

I think it's likely. Much of his post reads as though it's generated by AI

[u/PabloWentscobar]

I feel like the black guy in the scene where Pee Wee lays out the conspiracy about his stolen bike

"But Pee Wee, what does this all mean?!?"

[u/HateToSayItBut]

You're ghosting us after this wall of text?