<h2>Ethics and justification:</h2>
<p>If you have physical access to the device you could just... physically damage the device. Running arbitrary G-code is just more complicated</p>
<p>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.</p>
<p>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.</p>
<p>As a result, it's probably best that <strong>no one</strong> 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.</p>
<p>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.</p>
<p>To help your research: Most &quot;secure&quot; 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 &quot;trusted&quot; 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.</p>
<h2>It's extremely difficult to &quot;tear up&quot; a printer by turning off the endstops.</h2>
<p>You can disable physical endstops with a simple command <a href="https://marlinfw.org/docs/gcode/M121.html" rel="noreferrer"><code>M121</code></a>.</p>
<p>However, this only does so much.</p>
<p>With <a href="https://marlinfw.org/docs/gcode/M121.html" rel="noreferrer"><code>M121</code></a>, the printer is only really vulnerable before it has been <a href="https://marlinfw.org/docs/gcode/G028.html" rel="noreferrer">home</a>d. Most printers will <a href="https://marlinfw.org/docs/gcode/G028.html" rel="noreferrer">auto home</a> when starting a print, or refuse to print until they are <a href="https://marlinfw.org/docs/gcode/G028.html" rel="noreferrer">homed</a>. If issuing <code>M121</code> then arbitrarily trying to ram it past an endstop, it will continue until it counts steps to the <a href="https://marlinfw.org/docs/gcode/M211.html" rel="noreferrer">software endstop value</a> <code>[XYZ]_MIN_POS</code> to <code>[XYZ]_MAX_POS</code>.</p>
<p>Older printers didn't have software endstops and would keep going until they were stopped or turned off. But this wouldn't <em>explicitly</em> 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.</p>
<p>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)</p>
<p>This would not damage the printer - just be annoying for a short time until it hits the software endstop.</p>
<p>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 <a href="https://marlinfw.org/docs/gcode/M211.html" rel="noreferrer"><code>M211 S0</code></a>.</p>
<p>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.</p>
<p>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 <a href="https://marlinfw.org/docs/gcode/G028.html" rel="noreferrer">autohomes</a> 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.</p>
<p>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.</p>
<p>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?</p>
<p>Thomas Sandladerer made an excellent video on these vulnerabilities (specific to 3D printers) here: <div class="youtube-embed"><div>
                <iframe width="640px" height="395px" src="https://www.youtube.com/embed/RKdsp2vrmag?start=0"></iframe>
            </div></div></p>
<p>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 <strong>no one</strong> should do)</p>
<h2>Conclusion:</h2>
<p>In security, physical access to a system by an untrusted person or running untrusted code on a machine is not allowed.</p>
<p>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 &quot;friends&quot; or even family.</p>
<p>I won't tell you how to &quot;really tear up&quot; 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.</p>
<p>The lesson here is simple: <strong>Just don't run pre-compiled G-code.</strong></p>

CC BY-SA 4.0
2022-01-11T11:47:56.157Z
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!
0scar
CC BY-SA 4.0
2022-01-11T12:29:22.447Z
If you want to tear up a printer, I suggest a hammer.
user10489
CC BY-SA 4.0
2022-01-11T14:01:02.573Z
Disabling endstops usually just causes the printer to lose track of the origin when the printer tries to go past the end stop.
Perry Webb
CC BY-SA 4.0
2022-01-11T20:18:30.603Z
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.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2022-01-13T05:50:24.313Z
@R..GitHubSTOPHELPINGICE Thomas's video that I submitted in my answer demonstrates this concept. :)
OneWasNotEnough
CC BY-SA 4.0
2022-01-11T11:14:23.820Z
2022-01-11T19:17:47.233Z
2022-01-11T19:17:47.233Z
OneWasNotEnough
<h2>Physical Access is worse</h2>
<p>If you really want to brick a printer, physical access allows to destroy any printer physically.</p>
<p>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 <em>looks</em> and <em>feels</em> the same but contains neither <a href="https://3dprinting.stackexchange.com/questions/8466/what-is-thermal-runaway-protection">Thermal Runaway Protection</a> 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 <em>firmware update</em> to your modified version!</p>
<p>You see, Physical Access means any malicious person can turn a printer into what accounts to a timebomb, but as <a href="https://3dprinting.stackexchange.com/a/18722/8884">0scar</a> points out, it takes no malicious intent to mess up a printer - just being bad at maintaining or using it.</p>
<h2>Network Access suffices</h2>
<p>Let's for the sake of argument assume all we have is <a href="https://3dprinting.stackexchange.com/questions/10573/what-is-a-printer-console-terminal">remote terminal access</a> to the printer. No necessarily video feedback, just terminal access, for example via <a href="https://3dprinting.stackexchange.com/questions/tagged/octoprint">Octoprint</a>. 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 <strong>never</strong> be public access!</p>
<h3>With the right Terminal, Altering the EEPROM is easy</h3>
<p>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 <em>Physical Access is worse</em>.</p>
<h3>You worry about the wrong command</h3>
<p>Now, the worst command that with bad intent is very likely to destroy printers is the <a href="https://marlinfw.org/docs/gcode/M500.html" rel="nofollow noreferrer"><code>M500</code></a> 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.</p>
<p>For example, <code>M301</code> 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.</p>
<p>Due to the problems <code>M500</code> (and <code>M301</code>) 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 <strong>NEVER</strong> run G-code that you didn't compile yourself.</p>
<p>Besides the <code>M500</code> and M301, even the totally normal group of <code>M201</code> to -<code>M203</code> can really mess up a printer in not necessarily a permanent fashion without <code>M500</code>... 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.</p>
<h2>Blocking Malicious G-code</h2>
<p>Some companies, fearing accidental <code>M500</code> 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.</p>

CC BY-SA 4.0
2022-01-11T20:11:18.497Z
2022-12-17T10:06:31.733Z
2022-12-17T10:06:31.733Z
Trish
<h2>Potential threat?</h2>
<p>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.</p>
<h2>Would it destroy a printer?</h2>
<p>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.</p>
<h2>Limited to malicious intent?</h2>
<p>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...</p>

CC BY-SA 4.0
2022-01-11T19:59:42.100Z
Poor printer! I hope you could rescue it.
Trish
CC BY-SA 4.0
2022-01-11T14:59:13.587Z
2022-01-11T17:40:45.583Z
2022-01-11T17:40:45.583Z
0scar
<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>

CC BY-SA 4.0
2022-01-11T00:33:07.537Z
Have you done basic research, like examining the list of gcodes recognized by the ender3?
user10489
CC BY-SA 4.0
2022-01-11T00:38:43.960Z
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
ChinchillaWafers
CC BY-SA 4.0
2022-01-11T06:07:53.617Z
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.
user10489
CC BY-SA 4.0
2022-01-11T09:30:22.517Z
@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: https://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.)
OneWasNotEnough
CC BY-SA 4.0
2022-01-11T12:36:56.313Z
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.
Greenonline
CC BY-SA 4.0
2022-01-11T22:17:07.240Z
The question actually poses a good thought start for "how to mitigate risks and design a threat model to protect your print farm" - though framed as 'can one make this to damage the printer?'
Trish
<marlin><safety>
3D Printing with malicious intent
newatthis
# 3D Printing with malicious intent

(Asked by: username_0 on 2022-01-10)

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?

**Tags:** marlin, safety
> **Comments:**
> **username_1**: Have you done basic research, like examining the list of gcodes recognized by the ender3?  
> **username_2**: 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  
> **username_1**: 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.  
> **username_3**: @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: https://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.)  
> **username_4**: 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.  
> **username_5**: The question actually poses a good thought start for "how to mitigate risks and design a threat model to protect your print farm" - though framed as 'can one make this to damage the printer?'  

---

## 3 answers

### Answer by username_3 on 2022-01-11. Score: 10

## 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`](https://marlinfw.org/docs/gcode/M121.html).

However, this only does so much.

With [`M121`](https://marlinfw.org/docs/gcode/M121.html), the printer is only really vulnerable before it has been [home](https://marlinfw.org/docs/gcode/G028.html)d. Most printers will [auto home](https://marlinfw.org/docs/gcode/G028.html) when starting a print, or refuse to print until they are [homed](https://marlinfw.org/docs/gcode/G028.html). If issuing `M121` then arbitrarily trying to ram it past an endstop, it will continue until it counts steps to the [software endstop value](https://marlinfw.org/docs/gcode/M211.html) `[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`](https://marlinfw.org/docs/gcode/M211.html).

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](https://marlinfw.org/docs/gcode/G028.html) 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.**

> **Comments:**
> **username_6**: 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!  
> **username_1**: If you want to tear up a printer, I suggest a hammer.  
> **username_7**: Disabling endstops usually just causes the printer to lose track of the origin when the printer tries to go past the end stop.  
> **username_8**: 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.  
> **username_3**: @R..GitHubSTOPHELPINGICE Thomas's video that I submitted in my answer demonstrates this concept. :)  

---

### Answer by username_5 on 2022-01-11. Score: 3

## 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](https://3dprinting.stackexchange.com/questions/8466/what-is-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](https://3dprinting.stackexchange.com/a/18722/8884) 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](https://3dprinting.stackexchange.com/questions/10573/what-is-a-printer-console-terminal) to the printer. No necessarily video feedback, just terminal access, for example via [Octoprint](https://3dprinting.stackexchange.com/questions/tagged/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`](https://marlinfw.org/docs/gcode/M500.html) 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 by username_6 on 2022-01-11. Score: 2

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

> **Comments:**
> **username_5**: Poor printer! I hope you could rescue it.  

---

