<p>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.</p>
<p>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.</p>
<p>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?</p>

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