How one hacker unbricked a cloud-killed Cricut Maker

What happened

A researcher going by xssfox published a detailed walkthrough of how she resurrected a Cricut Maker that had been rendered useless by a Cricut account deactivation. The machine — a mid-range craft cutter that retails around $400 new — powered on, spoke to Cricut's cloud, was told the associated account was locked, and then refused to cut. No hardware was broken. The silicon was fine. The motors worked. The device simply would not run because a server on the other side of the internet said no.

xssfox's approach reads like a textbook embedded-security exercise. The Cricut Maker runs on an STM32 microcontroller. She pulled the firmware off the chip via SWD, loaded it into Ghidra, and traced the code path that handles the activation response from Cricut's API. The lockout logic turned out to be exactly what you'd guess: a boolean check on the server's reply that gates whether the cut command executes. Patching a single conditional branch — replacing the failure path with a jump straight to the happy path — was enough to turn a bricked device back into a working one. She reflashed the modified firmware and the machine cut vinyl again.

The post went to the top of Hacker News with 164 points and a comment thread that split cleanly between people cheering the repair and people asking the obvious follow-up: why does a $400 hunk of metal and stepper motors need permission from a server in the first place?

Why it matters

Cricut is not the villain of a single story — it's a data point in a much longer trend. In 2021 the company tried to move unlimited-upload accounts behind a subscription and had to back down after user backlash. Peloton has bricked treadmills over safety recalls. Spectrum-branded routers stop working when you cancel service. Sonos has orphaned entire product generations by pushing app updates the old hardware can't run. HP prints a magenta error when a third-party toner cartridge shows up. The through-line is that "ownership" of a networked device increasingly means "license to use, revocable at vendor discretion," and the enforcement mechanism is almost always a trivial server check that a competent embedded engineer can defeat in an afternoon.

The technical takeaway from xssfox's post is that most of these locks are not real security. They are policy expressed as code, and the code is running on hardware the user physically owns. STM32 readout protection is bypassable with known techniques. Firmware signing is rare on consumer craft hardware. Once the binary is in Ghidra, the activation check is usually a single function that returns a bool. The Cricut lock, per xssfox's disassembly, was not obfuscated, not signed, not attested — just a plain `if (activated)` that anyone with SWD, a soldering iron, and a weekend can flip.

That matters because it reframes the debate. When a vendor argues that server-side activation exists for "security" or "integrity," they mean the security of their business model, not the security of the user or the device. The Cricut lock protects Cricut's revenue, not the Maker's motors — and the moment someone with a JTAG probe cares enough to look, the fig leaf falls off. The right-to-repair conversation has spent years arguing about spare parts and service manuals. The next front is going to be firmware, and cases like this one are the reason.

Community reaction on HN leaned hard toward the ethical clarity of the repair. One top comment: "If the device is in my house and I own it, running my own firmware on it is not piracy — it's the definition of ownership." Others pointed to the growing catalog of hobbyist forks — Klipper for 3D printers, Marlin, custom firmware for Ender machines, OpenWrt for routers — as evidence that when vendors abandon or lock hardware, the community routes around them. Cricut is the newest entry on that list, not the last.

What this means for your stack

If you ship hardware with a cloud dependency, xssfox's post is worth reading as an adversarial threat model. Your activation check is not a moat. If your product's continued function requires a server heartbeat, three things are true whether you like them or not: your users will eventually be locked out by a bug, an account issue, or your own strategic pivot; a subset of those users will reach for a screwdriver; and the write-up they publish will teach the next hundred users how to do the same thing without soldering. The Cricut post is now the reference implementation for that class of unlock.

The practical hardening path, if you're determined to keep cloud gating, is well-understood but expensive: secure boot with a hardware root of trust, signed firmware, disabled debug ports fused off in production, and attestation that ties the activation response to a device-unique key. Most consumer hardware ships none of these because they add BOM cost and engineering time that product managers can't justify against a lockout feature nobody in marketing wants to explain publicly. The result is a widening gap between what vendors promise about control and what the hardware actually enforces.

If you're on the other side — a developer, a maker, or someone with a drawer of dead smart devices — the more useful takeaway is that the toolchain for this kind of work is now genuinely accessible. A ST-Link clone costs $3. Ghidra is free. STM32 pinouts are documented. The barrier is patience and a willingness to void warranties that are, in these cases, already voided by the vendor's own decision to stop honoring them.

Looking ahead

The interesting question is not whether more people will unlock more devices — they will — but whether the legal and normative framework catches up. Section 1201 of the DMCA still technically criminalizes circumventing access controls even on hardware you own, though the Copyright Office has granted narrower and narrower exemptions for repair over the past decade. Expect Cricut-style unlocks to become the exhibit A of the next exemption cycle. And expect at least one vendor, watching write-ups like this one climb Hacker News, to quietly conclude that a $2 secure element is cheaper than the reputational cost of being the next Cricut.