TL;DR: My wife received a refurbished Cricut Maker as a gift, and she kindly allowed me to set it up and try it out.¹ I did, and while the machine itself appears well-made and reliable, the software is not good. It works—if you play by Cricut’s rules—but it’s not useful for general-purpose plotting. If we ever want more flexibility, then we’ll have to either buy something else or maybe replace the main board entirely.

🔗Cricut Design Space

To use the Cricut Maker (and many other Cricut products), users must install the Cricut Design Space (DS) software. This program is vertically integrated in the sense that it allows users to lay out their design, manage the connection to their machine, and step through the process of inserting material and changing tools. It’s analogous to a combined CAD/CAM package with a focus on art and design instead of strict engineering. I’m impressed at how user-friendly this main flow is, and it’s clear that the designers want to minimize the chance that a tech problem might cause someone to give up on their project.

Design Space also has microtransactions for individual vector assets. And it seems to only really work when connected to the net. And you can’t use it without an account. And it nags you a fair bit to sign up for their subscription service or engage with them on social media. To the extend possible, Design Space is tethered to Cricut’s servers such that the whole system only operates on their terms. It makes me sad that Cricut has taken advantage of their users this way.

Still, it’s the only practical way to get the machine going, so I decided to try to get it running on Linux. There isn’t a Linux build (Windows and macOS only),² and browsing to the download page on Linux calls up the macOS download. I wanted the Windows version so I could try Wine, but there isn’t any obvious way to switch to a different OS on the website. In the end I had to modify my browser’s user agent to trick the site into thinking I was on a Windows machine.

The reason I included “(Not Quite)” in the title of this post is that my attempts with Wine ultimately failed. The installer runs without errors on a 64-bit prefix and immediately launches Design Space. (The program is installed to $WINEPREFIX/drive_c/users/<user>/AppData/Local/Programs/Cricut Design Space/Cricut Design Space.exe.) But on launch, Design Space shows two buttons with apparently no text in them. I learned from a Reddit comment³ that this is due to missing fonts, which is easily resolved by running winetricks corefonts on the desired prefix. Upon relaunching, Design Space renders the text in the buttons. To log in (after first creating an account, of course), I had to click the “Having Trouble?” text, which seems to open something like a web browser inside Design Space to prompt for credentials. The normal flow—which asks the user to log in with their web browser and presumably sends them back with a token—doesn’t work here because the browser can’t talk to the Wine process in the expected way.

The failure comes when trying to connect to the machine. I thought this would be the easy part because the machine shows up as a serial device on Linux, and Wine symlinks it into the environment as a COM port. While it seems like Design Space only communicates with the machine using its serial abstraction, it fails to recognize the attached machine and spins forever. With certain debug message enabled, Wine says:

00b0:warn:setupapi:SetupDiSelectBestCompatDrv No compatible drivers were enumerated for device L"USB\\VID_20D3&PID_0015&MI_01\\512&256&1&4".

The USB vendor ID (VID) and product ID (PID) match the lsusb output for the machine, which indicates that it at least sees it. I don’t fully understand why it doesn’t work, but I think the problem is that Design Space is expecting to be able to use the Windows SetupAPI to interact with or configure this device, but Wine can’t provide the features it’s looking for. This causes Design Space to give up and (presumably) skip to the next available device. It repeats this forever in the hope that a new device will appear that meets its requirements. I don’t know nearly enough about Wine to say more than that or suggest a solution. For all I know, this may be fundamentally impossible due to the designs of Windows, Wine, or Design Space.

So, in the end, I had to virtualize Windows. (That’s the “not quite” part.) I downloaded a Windows ISO and ran through VirtualBox’s unattended installation without an activation key. This was relatively painless, although Windows chugs a fair bit with only two cores. I installed Design Space on the VM and set up USB passthrough. At last the machine worked, and I was able to complete the demo project as shown above, along with some other little tests. The default cutter and the fine-tip pen that come with the machine are a good pair and can quickly make some neat stuff. Not bad for a $400 machine brand new (and free in this case). It’s just a shame that the hardware is locked up behind such hostile software.

I installed Wireshark on the VM and used it to capture USB traffic while starting, running, and completing a simple job (cutting a 2” circle). This generated a lot of interesting data, most notably a handful of roughly 500-byte packets that probably contain the entire job, with the rest being status information or similar. To my surprise, the data isn’t in any obvious format, and I have a suspicion that it may be encrypted. This would be particularly galling because it would almost certainly be an anti-reverse engineering tactic, with the added thorn that it truly chains the machine to Cricut’s software without substantial hardware changes. It’s possible that the cryptosystem involves a round trip to the Cricut cloud service, which would raise the question of whether the user really even owns the machine they paid for. On the other hand, it’s quite possible that I just can’t see the pattern in the packet data, and in fact the messages are perfectly clear after applying the right decoder.

🔗Maker Hardware

I opened the machine’s enclosure, and I was pleased to find not only a sturdy and well-made set of internal assembly, but also that the control board appears to be entirely separable from the mechanical components. This is great because it leaves open the possibility of fully replacing the control board, at least in principle. The X and Y motors both receive power from ordinary press-fit connectors on the main board, along with what I assume are signal wires for the rotary encoders. The tool head connection is more complicated and delicate because it uses a ribbon cable, and it’s not clear whether the tool head has some computing hardware in it or is simply taking power from the main chip over the ribbon. The main chip itself appears to be some variety of PIC32.⁴ Power for the machine comes in through a barrel jack.

It might be fun to try to replace the controller by observing the signals on the existing one and replicating them. The board has dozens of test points, so instrumenting it might not be too hard and would be a good application for a logic analyzer. I think this is—for better and worse—the most realistic option for freeing this device, assuming Cricut hasn’t found a way to force some kind of integrity protection into passive electronic components. There have also been some efforts to create open firmware for this machine, which is probably the cleanest solution but is likely irreversible. I imagine Cricut has enabled whatever copy protection features are available on the microcontroller.

I had to remind myself throughout this short project that my goal was supposed to be only setting this machine up for my wife, but at every turn I felt like the Cricut engineers were telling me that any deviation from their prescribed path was absolutely forbidden. This is among the best ways to upset me, which I consider to be part virtue and part flaw. The healthiest thing for me to do is probably to just put this machine aside and look into open hardware clones.