[3MAR2016 Note: A much newer, better method has been developed and is documented in this post.]
A common question among commenters to this blog when I write about my Stratasys FDM 1600 is “how did you hack the cartridge?” Newer Stratasys machines such as the Dimension series (P-Class machines – I assume named after the Prodigy, which I think was the first Stratasys machine to use cartridges) don’t have plain old wire welding type spools like the old FDM series – instead, they have the filament stored in a large cassette. This is nice as it keeps the filament dry without having to keep it in a dry box and it makes loading in new material (or swapping colors) a breeze. On the down side (as many Stratasys owners have apparently discovered), Stratasys went the route of inkjet printer manufacturers and have ‘chipped’ their cartridges so that you can’t simply refill the cartridge with material and continue on. While this isn’t a hindrance to me and my old machine, I’ve still been curious to know if there’s a way around this (if I ever come across a Dimension for cheap, I’ll need a way to feed it as well). Note: I understand the big T-class machines (named after the Titan model, I assume) still use large spools, though I believe the spools also have a chip module (but hey, if you can afford to buy a T-class, the consumables cost probably isn’t a big concern).
Inside each Stratasys cartridge is a Maxim DS2433 one-wire EEPROM (in a SO-8 package) that the machine communicates with. This is a simple 4kb (that’s kilobits – only 512 bytes of storage) device, and reading/writing them is reasonably straightforward – a library most likely exists for 1-wire communication no matter what your microcontroller of choice is (Arduino enthusiasts, look here). Dumping the contents of one yields hexadecimal gibberish, unfortunately. What’s more, you can’t simply clone one of them, as each has a unique 48-bit serial number lasered onto the die at the time of production, and this serial (presumably) is used as the seed to encrypt/obfuscate the EEPROM data. This has been enough to dissuade most tinkerers from playing further with the system, though Bolson Materials may very well have cracked the code, as they are able to provide new EEPROMs with their cartridge refill spools.
Thanks to some hacking by the shadowy figure known as ‘Dervish’, it’s been found that only a small portion (12 bytes) of the EEPROM is dedicated to storing how much material is left on the spool. As a cartridge was used, the EEPROM was read out at various points and only bytes 0x58-0x63 changed over the life of a cartridge. Specifically, here’s the layout of data on the EEPROM as known thus far as a result of reading EEPROMs from several brand new cartridges:
0x00-0x41: scrambled data (commenter lgg2 noted that 0x28-0x2F is identical to 0x30-0x37, highlighted in purple)
0x46-0x47: scrambled data
0x48-0x4A: 0x55AA55 (highlighted in green)
0x4B-0x4D: scrambled data
0x4E-0x4F: 0x71BE, 0x72BE, 0x73BE, 0x74BE, or 0x75BE
0x50-0x51: scrambled data
0x58-0x63: filament remaining (scrambled data, highlighted in yellow) – on an unused spool, 0x62-0x63 is always 0x4BB9, but this gets modified (along with 0x58-0x61) as the cartridge is used. Perhaps 0x62-0x63 is an unencrypted checksum?
0x68-0x70: 0x535452415441535953 (‘STRATASYS’ in ASCII, highlighted in dark blue)
0x71-0x1FF: scrambled data
Simple enough, right? Just read in the EEPROM at 100% full, respool it with generic material when empty and write the 100% full data back to the EEPROM… Well, not quite. You can certainly use this respooled cartridge in a different machine, but not in the same one, as they remember what cartridges they’ve already used (that serial number on the EEPROM). This is where Dervish tore into the guts of the machine and began the really clever hacking. When you open up the side panel of a Dimension, here’s what you see (image taken from Brad Rigdon’s Print To 3D gallery):
Brad also has a nice video on youtube that shows the full workings of the machine. The electronics appear to be composed of 3 boards – the large PDB (Power Distribution Board) on the left, the SBC (Single Board Computer, just a PC) in the center right above the hard drive, and what appears to be a motion controller board (in the upper right, connected to the SBC via a 16-bit PC/104 header). As per the troubleshooting section of the Dimension/SST Service Guide, the motion controller board in the upper right is known as the ‘186 board’. The SBC pictured appears to be an Ampro P5v, though some Dimensions use a Nova-600. After connecting a keyboard and monitor to the SBC, Dervish found that the computer is running Linux (Red Hat 8, specifically – not Fedora 8, but the circa 2002 version with a 2.4.x kernel).
By rebooting the system he was able to enter single user mode (at the LILO prompt, enter ‘linux single’) and could change the root password to whatever was desired (type ‘passwd’ at the prompt, enter a new password, then enter again to confirm). After rebooting once more into standard mode as root with his newly minted password, he modified /etc/sysconfig/iptables to open up port 22 so that he could ssh into the system and hack remotely without having to be at the console itself (the sshd daemon does not run by default, so adding the line ‘/etc/init.d/sshd start’ to /etc/rc.local is also required). While he had been able to modify temperatures on the machine by using Stratasys’s ‘Maraca’ software (the CatalystEX software offers no ability to tweak the system), direct access to the SBC allows much greater control over process parameters such as adjusting rollback. All the configurations are stored within the /mariner/config tree (the hard drive image covers multiple models), and it can be tricky to determine which ‘gender’ (kona, lanai, spinnaker, oahu etc.) corresponds to a given machine, but noting which directory has the most recent modification date is a dead giveaway.
The holy grail turned out to be the discovery of an innocuous sounding file named ‘system.dat’ located in the root directory. This is where the Dimension apparently stores a list (in binary) of all the cartridge EEPROM serial numbers that it has seen before. Delete this file and the machine gets amnesia, allowing respooled cartridges (with the EEPROM rewritten to show 100% full) to be used again. I assume creating a cron job to delete this file periodically (or using rc.local to delete it on startup) would also work.
As far as I know, this constitutes the cutting edge of Stratasys hacking – I’ve heard rumors before of people having bypassed the cartridge EEPROMs, but this is the first concrete information I’ve seen on how to accomplish it. If anyone has further information, please leave a comment!