How We Reverse-Engineered the MakerBot Replicator+ Protocol

A MakerBot Replicator+ is a precision machine — steppers, a heated bed, a closed-loop extruder, a camera, a real industrial-design enclosure. None of that degrades because a company stops shipping updates. What actually dies when a hardware vendor discontinues a product isn't the hardware; it's the software that knows how to talk to it. MakerBot ended support for MakerBot Print and MakerBot Desktop on the Replicator+, and that was enough on its own to turn a functioning printer into a brick, because the printer speaks a protocol MakerBot never published.

OpenBot exists to undo exactly that. This isn't an unusual problem, either — manufacturers discontinue software, vendors disappear, APIs get shut off, and perfectly functional equipment gets stranded behind an integration nobody maintains anymore. The engineering question is always the same one: can the missing software boundary be reconstructed safely enough to put the hardware back to work? For the Replicator+, that meant answering something more specific first: what, precisely, does the MakerBot Replicator+ protocol expect to hear over the network? This post is about how we answered it — reading the printer's own firmware source, cross-checking independent reverse-engineering projects, and testing every call against a real printer before trusting it. The detailed notes live in the repo's PLAN.md (§1.1, §1.5, and the Phase 0 hardware-verification log); this is the version with the story attached.

The problem: a protocol with no spec

The Replicator+ listens on a JSON-RPC 2.0 interface over two TCP ports, discoverable over UDP broadcast and mDNS. None of that is documented anywhere MakerBot published. Third-party tools had gotten partway there before — enough to discover a printer and print a file — but Wi-Fi configuration in particular stayed out of reach. Getting the rest of the picture meant either sniffing traffic blind and inferring the protocol from the wire, or finding a better starting point. There was one: the printer's own control software turned out to be sitting in a public firmware dump, in plain Python.

Step 1: reading the printer's own firmware

The Replicator+ and the Replicator Mini+ share the same "Birdwing" platform and the same control daemon, called kaiten. A GitHub repository, charely6/Makerbot-5gen-plus, contains firmware extracted from a Mini+ (version 2.6.3) — and kaiten ships as plain, unobfuscated .py source, running on Python 3.4. That's an unusually direct starting point for reverse engineering a closed device: no disassembly, no symbol recovery, just source code to read.

Two files did most of the work. usr/include/kaitenstub.hh is an auto-generated stub that lists every remote method kaiten exposes and its parameters — that's where wifi_scan, wifi_connect, wifi_forget, set_static_ipv4, change_machine_name, and the rest of the RPC surface came from. And kaiten's own dbus.py is the implementation behind those methods: it shows that networking runs through connman over D-Bus, what each call actually returns, and its error codes — for example, error 56 when wifi_connect is called while the printer is tethered by Ethernet, and error 50 if the target access point disappears mid-connect.

Step 2: why Wi-Fi needed the encrypted port

kaiten enforces privilege levels per connection, and some methods are marked require_secure. wifi_connect is one of them — along with authorize, reauthorize, and a handful of others. Those calls only work over kaiten's TLS-wrapped port; the plaintext port answers everything else, but rejects them outright.

That split explains two things at once. First, why older third-party tools could discover and print to a Replicator+ but couldn't touch its Wi-Fi settings — if a client only ever spoke to the plaintext port, every require_secure call was always going to fail. Second, it explains the printer's own pairing UX: authorize once over TLS, which prompts a physical knob-press on the printer and returns a durable credential, then reauthorize silently on every later connection with no knob press needed. The security boundary isn't the knob — it's the TLS port. The knob is just how a human grants the first credential.

Step 3: cross-checking against independent projects

Firmware source tells you what the code says it does, not necessarily what a specific unit in the field actually does — so before trusting any of it, we checked it against other people's independent work. tjhorner/makerbot-rpc, garfield-arlene/queue3d, and charely6/makerbot-gen5-api are each open-source, community-built clients for this printer family, built by different people, at different times, with different amounts of access to real hardware. Where they agreed with each other and with the firmware source — discovery, the pairing handshake, JSON-RPC framing, file transfer — that convergence was a strong signal. queue3d in particular had already tested camera streaming and an OrcaSlicer-based slicing pipeline on real Replicator+ hardware, which filled in details the Mini+ firmware source alone couldn't confirm.

The one thing we deliberately didn't do was assume the Mini+ and the Replicator+ are identical just because they share a codebase. They run the same underlying kaiten platform, but machine_type and hardware configuration differ between them. Every method pulled from the Mini+ firmware source got treated as a hypothesis, not a fact, until it was confirmed against the printer OpenBot actually needed to support.

Step 4: testing every call against the real printer

That confirmation step was a small script, tools/probe.py, run directly against a real Replicator+ (firmware 2.6.2) and built to exercise every method OpenBot's first release depends on, one at a time, with the result recorded before anything got built on top of it.

• network_state and wifi_scan both worked as documented — the scan turned up three networks, including one with a hidden SSID.
• Calling wifi_connect over the plaintext port was refused outright, with an explicit RPC error rather than a silent failure. Over the TLS port, the identical call succeeded.
• A real wifi_connect joined the test Wi-Fi network while the printer stayed reachable over Ethernet the whole time, then answered again at its new address — presenting the same certificate OpenBot had already learned to trust.

The refusal on the plaintext port looked like this:

{"jsonrpc": "2.0", "error": {"code": -32604, "message": "privileged information on unsecure channel"}, "id": 7}

One behavior the firmware source never revealed, because it's a runtime quirk rather than something the code declares: with both Ethernet and Wi-Fi connected, network_state only ever reports the Ethernet link. Read that one field naively and the printer's Wi-Fi status simply disappears the moment a cable is plugged in. OpenBot's network screen works Wi-Fi status out separately instead of trusting that single field — a fix that a testing pass caught and a protocol document alone couldn't have.

Why the hardware didn't have to die with the software

None of this — steppers, heated bed, closed-loop extruder, the frame — degrades because a vendor loses interest. The software that used to be the only way to talk to the device is usually a lot smaller and more legible than the hardware it controls, and it's often still visible: shipped as readable source in an old firmware image, discussed in a forum thread, partially reconstructed by someone else who hit the same wall years earlier. None of that guarantees a clean answer. It does mean the work is usually a matter of reading carefully, cross-checking more than one source, and verifying everything against the real device — not reverse-engineering from nothing.

What actually goes obsolete first, almost every time, is the thin layer of software that used to be the only way to talk to the device.

A Replicator+ that still prints perfectly well shouldn't become e-waste on a timeline set by a company's product roadmap rather than the printer's own condition. That's the same argument that applies to a lot of hardware we see in client environments — label printers, scales, older scanners, purpose-built devices from vendors who've since moved on — that still work fine but have lost the software that used to drive them. If you have equipment like that, don't assume replacement is the only option: show us the device and the software it used to depend on, and we can usually tell pretty quickly whether there's a practical path back in.

The full write-up on what OpenBot does day to day — slicing, camera, shared server mode, and the Ender-3 side of things — is in the project case study. The protocol notes themselves, including the appendix listing every method pulled from kaitenstub.hh, are in PLAN.md in the GitHub repository.