Skip to main content
added 561 characters in body
Source Link
Trish
  • 22.5k
  • 13
  • 51
  • 104

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.

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.

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.

added 2627 characters in body
Source Link
Trish
  • 22.5k
  • 13
  • 51
  • 104

You worry about the wrong command setPhysical Access is worse

TheIf 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 areis the M500M500 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.

You worry about the wrong command set

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

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.

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.

Source Link
Trish
  • 22.5k
  • 13
  • 51
  • 104

You worry about the wrong command set

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

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.