Ethics and justification: ------------------------- If you have physical access to the device you could just... physically damage the device. Running arbitrary Gcode is just more complicated Most printer farms have a strict no outside Gcode 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 Gcode. You should use an STL and generate your own Gcode. 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's 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][1]. However, this only does so much. With [M121][1], the printer is only really vulnerable before it has been [home][2]d. Most printers will [auto home][2] when starting a print, or refuse to print until they are [homed][2]. If issuing M121 then arbitrarily trying to ram it past an endstop, it will continue until it counts steps to the [software endstop value][3] [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][3]. This turns off the software endstops. And should allow it continually try to reach the value programmed in the Gcode. 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][2] on print it usually will set zero to the endstop before the payload can be ran, 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: https://youtu.be/RKdsp2vrmag In his video, he's speaking directly on the threat of running pre-formed Gcode 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 Gcode 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's 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 gcode.** [1]: https://marlinfw.org/docs/gcode/M121.html [2]: https://marlinfw.org/docs/gcode/G028.html [3]: https://marlinfw.org/docs/gcode/M211.html