3
$\begingroup$

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?

$\endgroup$
6
  • 3
    $\begingroup$ Have you done basic research, like examining the list of gcodes recognized by the ender3? $\endgroup$
    – user10489
    Jan 11 at 0:33
  • 2
    $\begingroup$ I don’t think we should be using 3D Printing Stack Exchange to develop a public blueprint for hackers to destroy people’s 3D printers $\endgroup$ Jan 11 at 0:38
  • 5
    $\begingroup$ I think it is important to be aware that a gcode can set your temperature to something that can damage the printer. But by the same token, I don't think you should be printing gcode from someone else that hasn't run through your own slicer with your own fine tuning for your printer. $\endgroup$
    – user10489
    Jan 11 at 6:07
  • 2
    $\begingroup$ @ChinchillaWafers the information on how to do it is already public as every Gcode and their functions are available from the Firmware vendor's website: marlinfw.org/meta/gcode The threat vector is from unsecured web interfaces primarily. But physical access to the printer will not prevent blatant misuse and abuse. If a hacker has physical access to your printer - you have bigger problems than someone trying to run malicious gcode. Additionally, schools might like to know "how" a student can destroy a printer and what to look for. (Hard rule of no outside Gcode fixes this threat.) $\endgroup$ Jan 11 at 9:30
  • 2
    $\begingroup$ Just my thoughts... I'm tempted to upvote this question, purely for its audacity, as well as its usefulness in making people aware that you could totally shaft a printer if care is not taken with the (G-)code used. Also, it has resulted in a very useful answer (and hopefully others to come). The other negative votes, if given due to a distaste for the topic, I think may be a little unfair - if this were on Meta then yes distaste may be demonstrated by down voting, but on the main site downvotes should be for lack of research, etc. and it seems like the OP has at least done a bit of research. $\endgroup$
    – Greenonline
    Jan 11 at 12:36

3 Answers 3

7
$\begingroup$

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.

$\endgroup$
5
  • 3
    $\begingroup$ Thanks for not providing a manual to tear up a printer! I can think of a couple of ways, but refrained to answer to have a dedicated landing page for people that want to destroy other peoples' machines. Very elegantly answered by dodging/bending/interpreting the question to not running pre-compiled G-code which is very good advice!. Welcome to 3DPrinting.SE! $\endgroup$
    – 0scar
    Jan 11 at 11:47
  • 2
    $\begingroup$ If you want to tear up a printer, I suggest a hammer. $\endgroup$
    – user10489
    Jan 11 at 12:29
  • $\begingroup$ Disabling endstops usually just causes the printer to lose track of the origin when the printer tries to go past the end stop. $\endgroup$
    – Perry Webb
    Jan 11 at 14:01
  • 1
    $\begingroup$ The most sure way to cause significant damage is probably to print a solid block of plastic then slowly lower the hotend into it while continuing to extrude. This does not rely on bypassing endstops because the object you're hitting isn't part of the printer but something dynamically created. $\endgroup$ Jan 11 at 20:18
  • 1
    $\begingroup$ @R..GitHubSTOPHELPINGICE Thomas's video that I submitted in my answer demonstrates this concept. :) $\endgroup$ Jan 13 at 5:50
3
$\begingroup$

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 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.

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.

$\endgroup$
2
$\begingroup$

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...

$\endgroup$
1
  • 1
    $\begingroup$ Poor printer! I hope you could rescue it. $\endgroup$
    – Trish
    Jan 11 at 19:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .