3D Printing with malicious intent

Question

I have a bit of an odd request. I am studying the vulnerability of 3D printers and would like to know if there is a way to disable the limit switches on, for example, an Ender 3 in the G-code.

Ideally, the exploit would be used by plugging in the malicious code via SD card into the 3D printer. I have found ways to change the nozzle temp and things like that, however, nothing on the limit switches.

If I were the manufacturer, I wouldn't implement the function, so if it's not possible it will not be a surprise. If that's the case, what would be some other options for tearing this thing up?

Answer 1

Ethics and justification:

If you have physical access to the device you could just... physically damage the device. Running arbitrary G-code is just more complicated

Most printer farms have a strict no outside G-code policy for good reason. Because direct physical access to the printer does not provide any security.

This is also a problem for CNC Mills and other equipment. The firmware is not there to protect you. If you ask the system to put the spindle into XYZ_POS, the device's job is to deliver your 300 dollar end mill into the part as expediently and directly as you have told it. It does not hold your hand.

As a result, it's probably best that no one run pre-compiled G-code. You should use an STL and generate your own G-code. Not only does it allow you to properly tune the print for your specific printer, but it prevents nasties from breaking your printer.

Do not test this on a system you do not own. You will face civil and criminal liability for any damages as a result of performing this on printers that are not your own. Additionally, I would question the value of your research provided that physical access to a device automatically makes it vulnerable; let alone running arbitrary code from an untrusted source.

To help your research: Most "secure" facilities prevent even touching a machine with external code. All code has to be generated on trusted and isolated machines by trusted persons. There is no guarantee that the "trusted" person can't manufacture a job that will crash their 300,000 dollar CNC mill and cause damage - but there are serious repercussions for doing so.

It's extremely difficult to "tear up" a printer by turning off the endstops.

You can disable physical endstops with a simple command M121.

However, this only does so much.

With M121, the printer is only really vulnerable before it has been homed. Most printers will auto home when starting a print, or refuse to print until they are homed. If issuing M121 then arbitrarily trying to ram it past an endstop, it will continue until it counts steps to the software endstop value [XYZ]_MIN_POS to [XYZ]_MAX_POS.

Older printers didn't have software endstops and would keep going until they were stopped or turned off. But this wouldn't explicitly cause damage as physical limitations would prevent it. Outside of old designs that do not physically limit the Z position - and crashing the nozzle into the printer.

Nowadays - the printer would crash into the axis limit and then stop because it would hit the software endstop (and funnily enough, be homed as a result - I have done this as an experiment on my own printers)

This would not damage the printer - just be annoying for a short time until it hits the software endstop.

You can however make it work like an older printer provided it does not have stall or crash sensing (like Prusas have by default) by issuing M211 S0.

This turns off the software endstops. And should allow it to continually try to reach the value programmed in the G-code. It should continue to count until it gets to XYZ_POS then finally stop.

Will this cause damage? Maybe. If the Z-axis is high and it can physically push its way into the printbed hard enough it can cause damage to the hotend. However, generally, most printers are designed (these days) that the Z-axis cannot go too far into the print bed and cause (too much) damage. Modified printers can be vulnerable if they modify the bed but do not physically limit the Z-axis from going down too far. Additionally, when the printer autohomes on print it usually will set zero to the endstop before the payload can be run, giving a home and only allowing excursion to the axis positives. When this happens, no damage can really occur outside of overheating the steppers/drivers and possibly damaging belts.

There are also some firmware protections to help protect the end-user (e.g. Prusa Crash Detection) - depending on the printer these may need to be circumvented as well.

How you can really tear up a printer? If you have physical access to it - you have total control over it. Simply being physically near it is enough for you to just throw it out a window. It's arbitrary to try to run any code. But if you're trying to research how a threat actor can mess up someone's printer?

Thomas Sandladerer made an excellent video on these vulnerabilities (specific to 3D printers) here:

In his video, he's speaking directly on the threat of running pre-formed G-code from public sources. (Something that you should not do - something that no one should do)

Conclusion:

In security, physical access to a system by an untrusted person or running untrusted code on a machine is not allowed.

For this vulnerability to be exploited, it requires a person to do things that they should not be doing - running generated G-code from an untrusted source. This includes from "friends" or even family.

I won't tell you how to "really tear up" a 3D printer as there are a plethora of horror stories out on the internet of printers catching fire let alone the threat of running some random code on your printer. How to do it is publicly available. You just have to figure it out yourself.

The lesson here is simple: Just don't run pre-compiled G-code.

Answer 2

Physical Access is worse

If you really want to brick a printer, physical access allows to destroy any printer physically.

If you really want to mess it up only via a remote command later, you would not just run arbitrary G-code, you'd replace the firmware with one that looks and feels the same but contains neither Thermal Runaway Protection nor a Maxtemp. This way, the machine would just try to heat to arbitrary temperatures as commanded - making it possibly a fire hazard. In the worst case, installing bad Firmware is as simple as inserting a prepared SD and having the printer run a firmware update to your modified version!

You see, Physical Access means any malicious person can turn a printer into what accounts to a timebomb, but as 0scar points out, it takes no malicious intent to mess up a printer - just being bad at maintaining or using it.

Network Access suffices

Let's for the sake of argument assume all we have is remote terminal access to the printer. No necessarily video feedback, just terminal access, for example via Octoprint. This is sufficient to send arbitrary G-code, and some combinations can be outright devastating - which is why remote print servers are usually password secured and should never be public access!

With the right Terminal, Altering the EEPROM is easy

If you have remote access and can use a terminal that allows directly altering the EEPROM, changing fundamental values like the position of the endstops or the size of the printer quite easily. Repetier Host for example can do that, but usually uses a direct physical cable - which gets us back to Physical Access is worse.

You worry about the wrong command

Now, the worst command that with bad intent is very likely to destroy printers is the M500 command to save altered values into the EEPROM. This can result in problems if G-code before the command contains code that changes basic settings that are not firmware locked.

For example, M301 with nonsensical values can force very bad PID-setting that could result, depending on how they are set up, in massively overshooting the target temperature, regularly tripping Thermal Runaway Protection or just bad prints. With Particular bad settings and with disabled TRP, one might actually turn the printer into a fire-hazard.

Due to the problems M500 (and M301) can cause, Prusaprinters/printables does not allow to upload any g-code that contains this command, but the best protection against this command is to NEVER run G-code that you didn't compile yourself.

Besides the M500 and M301, even the totally normal group of M201 to -M203 can really mess up a printer in not necessarily a permanent fashion without M500... unless they are used to destroy the printer outright. Which can totally be done by setting ludicrous speeds and acceleration, then telling the printer that its printhead is at a height well above the bed (besides that it was just a few millimeters away) and slamming down with maximum force to pierce a hole into the bed. But as many of the feedrate commands (like M203) are used in normal prints, it's hard to spy such commands - and thus nigh impossible to spot beforehand.

Blocking Malicious G-code

Some companies, fearing accidental M500 or other setting-altering commands, have disabled EEPROM. This however makes maintenance much harder, but prevents altering critical settings at all - they are now fixed in the firmware and have to be altered by recompiling and uploading an altered firmware. If done properly and combined with proper physical access control to the ability to upload firmware (e.g. sealed maintenance panel) can pretty much prevent malicious G-code to have any effect.

Answer 3

Potential threat?

I can imagine that this is a potential threat for printers that are operated in an environment where there are lots of people using the printer where there is access to the SD card (e.g. schools, libraries or maker spaces). It would literally take a file on the SD card to be run the next time the printer boots to change settings through G-code. As you can imagine, it is quite easy to change the coordinates of the origin - this has been discussed in previous questions - but also speeds, endstop state and acceleration values for instance.

Would it destroy a printer?

Yes, it can. Lead screw motion is stronger than belts, the latter will just skip, but lead screws may do some serious damage depending on the printer construction (I've had my unintentional fair share of that). But, the most obvious problem is the time that is needed to fix the problem; re-calibrating and repairing.

Limited to malicious intent?

No, managing an Ultimaker 3 Extended for a staff association I can talk from experience that it doesn't take malicious code, or intent, to mess up a printer. Working from home due to COVID-19 measures (my work needs those who can work at home to stay at home, in order to allow those who operate machines and test equipment to go to work and comply with the x people per y square meter rules that the government laid out) I have been away from the UM3E to find it in a terrible state a year later. It appeared that there have been people, that had no experience in slicing, using the wrong type of materials for slicing with respect to that was loaded into the machine... (we operate non-Ultimaker materials, so the material is not recognized by the RFID reader). The printer is now under lock and key...