Building 3DSnickerStream: A Native
3DS Streaming App for Mac and Windows

The Problem: Streaming a 3DS Meant Booting Into Windows

Snickerstream by RattletraPM is a genuinely good tool — it streams a 3DS's two screens to a computer over Wi-Fi using the NTR and HzMod custom-firmware protocols. The problem was where it runs: Windows only, and not a native app even there. I use a Mac day to day, and I wanted to stream my 3DS while I was on it, not after switching machines.

I didn't want a compatibility-layer workaround either. I wanted a resizable window that behaves like a Mac window, controls that respond instantly, and colors that look like what's actually on the 3DS screen instead of whatever a translation layer decides to do to them.

So instead of trying to port the existing project, I built something new: a native SwiftUI app for Apple Silicon Macs first, then a matching native app for Windows using WPF and .NET. Neither is a copy of the original code — the NTR and HzMod protocols were reverse-engineered by reading the original project's AutoIt source, then re-implemented from scratch on each platform.

What It Does

Point it at a 3DS running NTR CFW (or HzMod) with remoteplay enabled, and both screens show up in a real, resizable window within a couple of seconds.

A few smaller things matter more than they sound: a playback FPS cap that limits redraw without touching what the 3DS actually sends, sharp/linear/smooth scaling with optional rotation, an ambient glow that lifts colors off whatever's on screen, and — maybe the most useful one — the app doesn't just show a black screen and give up if the 3DS doesn't answer immediately. It retries.

Two Native Apps, Not One Port

The macOS app is SwiftUI, built for Apple Silicon, using ImageIO and Core Graphics for JPEG decoding and a layer-backed view to keep both screens smooth. The Windows app lives on a separate branch and is WPF on .NET, published as a self-contained build via dotnet publish -c Release -r win-x64 --self-contained (the executable ships with its x64 and tessdata folders alongside it).

Neither one started from the original project's AutoIt codebase. Both were written fresh, each in the idioms of its platform — but both had to speak the exact same wire protocols the 3DS expects, because the 3DS side of NTR and HzMod isn't something you get to redesign.

That meant the actual work wasn't "port this app" — it was "figure out what bytes the 3DS is sending and expecting, twice, in two different languages, and make sure both implementations agree with real hardware."

Reverse-Engineering NTR: 84 Bytes and a JPEG Stream

NTR's remoteplay protocol isn't publicly documented anywhere I could find — the closest thing is the original Snickerstream's include/ntr.au3 AutoIt source, which builds and sends the handshake by hand. Reading it gave the shape of the protocol: connect to the 3DS on TCP port 8000, then send an 84-byte command packet carrying a magic number, a command ID, and the priority/quality/QoS settings the user picked.

Once the 3DS accepts that command, it starts streaming JPEG frames as UDP packets to the app on port 8001 — no acknowledgment, no retransmission, just a continuous stream. Each UDP packet carries a small header (frame id, which screen it belongs to plus a last-packet flag, and a packet index) followed by a slice of JPEG data. The app buffers packets by frame id until the last-packet flag shows up, concatenates the slices in order, and decodes the result.

// NTR handshake — simplified
struct NTRCommand {
  UInt32 magic = 0x12345678
  UInt32 seq
  UInt32 type
  UInt32 cmd    = 901          // remoteplay start
  UInt32 args[16]              // priority, quality, qos, screen mask...
  // padded to 84 bytes total
}

func sendHandshake(to socket: TCPSocket, quality: Int, priority: Int) {
  var packet = NTRCommand()
  packet.args[0] = UInt32(priority)
  packet.args[1] = UInt32(quality)
  socket.write(packet.serialized())   // 3DS:8000
}

// UDP frame reassembly — simplified
func onPacket(_ data: Data) {
  let header = parseHeader(data)      // frameId, screen, isLast, packetIndex
  buffers[header.frameId, default: []].append(data.jpegSlice)
  if header.isLast {
    let jpeg = buffers[header.frameId]!.joined()
    decode(jpeg, screen: header.screen)
    buffers[header.frameId] = nil
  }
}

There's no error correction anywhere in this. If a UDP packet drops, that frame just never completes and gets discarded — the next one arrives a few milliseconds later. It's a fragile-sounding design that works fine on a local Wi-Fi network, which is presumably why the original project never needed anything sturdier.

HzMod: The Beta Protocol

HzMod is the original project's second protocol, reconstructed from its include/HzMod.au3 source the same way. It works differently from NTR: the app connects to the 3DS on TCP port 6464, sends a packet with a CPU-limit value, a quality setting, and a start flag, then reads the response stream back over the same TCP connection.

The tricky part was the frame boundaries. The header layout I could reconstruct from the AutoIt source was ambiguous enough that trusting a parsed length field felt risky. The more robust fix: don't parse a header for framing at all — just scan the incoming byte stream for a complete JPEG, marked by the standard FF D8 start-of-image and FF D9 end-of-image bytes, and decode whatever's between them.

// HzMod framing — simplified
var buffer = Data()

func onBytes(_ chunk: Data) {
  buffer.append(chunk)
  while let start = buffer.range(of: [0xFF, 0xD8]),
        let end   = buffer.range(of: [0xFF, 0xD9], from: start.upperBound) {
    let jpeg = buffer[start.lowerBound..