Reviving a Deactivated E-Waste Cricut Maker

While clearing out some trash, I stumbled upon a Cricut Maker abandoned in the e-waste bin. Upon inspection, the machine looked great cosmetically, though the rollers had completely perished. I suspected the degraded rollers were the sole reason for its disposal and decided to bring it home for a project.

I was well aware that Cricut is quite aggressive about locking or disabling their hardware, but I figured it was worth a shot for the sake of curiosity.

The Problem: A Digital Dead-End

As expected, the machine was locked. It is highly probable that the previous owner received a warranty replacement or a discount on a newer version, leading Cricut to deactivate this specific unit.

Initial Testing

Even when powering the device with $\text{12V}$ (despite the requirement of $\text{18V}$), the machine showed signs of life. It passed its internal self-test and communicated with the software, but I was met with the infamous warning:

"Machine deactivated"

---

The Investigation Phase

I attempted several strategies to bypass the lock, moving from hardware to software and finally to a "man-in-the-middle" approach.

Attempt Log

Strategy 1: Hardware Modification I disassembled the unit (a process not for the faint of heart) to see if I could rewrite the serial number on an EEPROM. No such chip existed, and the MCU was unsupported by my current debuggers.

Strategy 2: Network Manipulation I tried to intercept the communication between the software and Cricut's servers to spoof a "success" message or change the serial. However, the application's security measures—specifically certificate pinning—made this a frustrating path.

---

The Solution: USB Hardware Proxy

I shifted my focus to the physical communication between the cutter and the computer. Using wireshark, I captured the USB traffic and discovered that the machine uses USB CDC for communication. I quickly identified the specific packets containing the device's serial number.

The Implementation

I utilized an RP2040 (borrowed from Droppy) to act as a bridge between the Cricut and the PC.

Technical Hurdles:

• Clock Speed: I discovered the USB Host functionality fails unless the RP2040 is overclocked to 240MHz.
• Identity: I had to spoof the Vendor ID (VID) and Product ID (PID) to match the original Cricut unit.

The Logic: The proxy monitors packets. When it detects a packet of the correct length containing the serial number command, it swaps the original serial for a different one.

// Conceptual logic for the proxy
if (packet.length == SERIAL_LEN && packet.isCommand(GET_SERIAL)) {
    replace_bytes(packet, original_serial, fake_serial);
}
send_to_host(packet);

Interestingly, Cricut serials appear to be sequential, and their status is public on their own website. This reveals a security flaw: a stranger could potentially lock out another user's machine if they guessed the serial. I even found that I could use serial numbers that didn't exist on the status page at all.

---

Final Restoration

To get the machine fully operational, I completed the following:

• Clean the chassis.
• Replace the perished rollers.
• 3D print a custom enclosure for the RP2040.
• Reassemble the hardware.

Pro Tip: When installing new rollers, dip them in hot water to soften the material, making them much easier to fit.

Alternative Paths

While my hardware proxy works, it is arguably the least user-friendly method. Other viable options for those interested in exploring this include:

• Software Patching: Intercepting network traffic or patching the app to report a fake serial.
• Virtual Drivers: Writing a driver that mimics a Cricut USB CDC connection.
• Bluetooth Spoofing:
  • A driver that proxies the connection via Bluetooth.
  • A hardware Bluetooth proxy device.
  • Adding an MCU between the Bluetooth chip and the main MCU to rewrite the serial on the fly.
• Firmware Hacking: Analyzing the update process to patch the serial number directly in the firmware.

Legal Disclaimer

I will not be sharing the specific code used for the serial number replacement. I am not a lawyer, but I suspect this might not be exempt under Australian Copyright Law. However, the implementation is very similar to the standard examples found in the TinyUSB Arduino library.