File Corrupted This Program Has Been Manipulated And Maybe It 39;s Infected By A Virus Or Cracked Fix

[Juan Navarro]

Iwork at a makerspace that's part of a larger institution. and the question came up when discussing allowing people to bring in, and print from, their own SD cards. If I'm wrong and it IS possible to get a virus, I need to know that ?

What I'm less sure of, is if it is possible for a malicious user to damage the printer by printing from a messed up gcode file. Will the printer blindly follow instructions that could damage the hardware? Can the gcode change settings on the printer that could cause problems later? If so, is there a way to check the files beforehand to mitigate this risk?

by all means i'm no expert however same goes for gcode downloaded from thingy/printables no? ... usually you download an STL/STEP and slice it for your 3Dprinter, because you have no idea how it was sliced or for what machine the provided gcode really is for.

I would say that you should only allow people to bring STL on SD/USBkey that are then scanned by your PC and sliced on provided PrusaSlicer with profiles made for your machine.

I guess there might be a way to see if file is ok just by looking at its text based content but that's way out of my league.

I look forward to see what the experts have to say. Certainly is an interesting topic.

For example you could overwrite all the default settings in eeprom easily. Its designed to be able to do that. You could put in gcode that would be likely to cause clogged nozzles, resulting in downtime while you try and unclog/replace stuff. You could probably damage the build plates by driving the hotend into it. That's just stuff that immediately comes to mind. I haven't spent time thinking what else could be done.

There was a discussion about this topic a few years ago on this forum. Someone checked that PrusaPrinters (now Printables) would deny upload some g-code files because they contain potentially malicious commands. It's basic, but checking g-code without an automated tool is possible.

Do someone know such a tool for end users?

It is pretty much given that most every non-trivial program has bugs. 3D printers have software/firmware (programs). Therefore all 3D printers have bugs. A subset of bugs are ones that could be exploited by an attacker to doing some malicious. And a subset of those can self propagate (virus) to other systems/media.

The risk from an SD card for 3D printers comes form three places that I can think of: the contents of the gcode files, the filesystem or some other meta data, the hardware. Any issue with a malicious gcode file would apply no matter now it was transferred to the printer. The more obvious malicious gcode risks come from controlling the printer in some sort of destructive or dangerous way (which would not be a virus). I am not aware of any SD card-based HW attacks. (I have heard of USB-based ones that can physically destroy what they are plugged into. Those would be a lot harder in an SD card due to the smaller size.) But, that would again, not be a virus. It is possible that something malicious on the sdcard (in gcode or elsewhere) could propagate to another system such as via the next sd card inserted: a virus. The risk of that depends on how well the software/firmware is written, how trusting it is (or the developers were) of user supplied data. By the way, such malicious code may or may not do anything bad (damaging) on the printer itself: the printer could just be used as a propagation vector.

After writing that and reading what I wrote, I feel Like I am saying you should toss all computers (including all 3d printers) in the nearest volcano. I am not. There are risks with everything, but we also have to live our lives.

Somethings to do that may reduce risk of any virus propagating from the printer to the next SD card: Use/recommend write-protectable SD cards and make them read-only (locked) when inserted into the printer (I am assuming the printer will be ok with that). Power off the printer between uses by different people (different SD cards) so that anything malicious in volatile memory will be cleared (only insert/remove SD cards when power is off).

The firmware for file handling is very basic on a prusa, propagating a file from printer to a different sd card is just not a factor. The only thing it writes is the power failure info. That's why I stated that a virus on the printer is pretty much impossible. Now a virus using the sd card to go from pc to pc - yes. In that way an sd card is no different from any other storage media. But a virus going from Sd Card 1> Printer>Sd Card 2 is just not going to happen. Going from Sd Card1>Pc>Sd Card 2 though is quite possible.

Again the 8 bit board and firmware is VERY basic, this simplicity and limited capability makes it much harder to do something complex like a virus. The risk is malicious gcode designed to damage the printer.

Insisting students/users bring in their own files to be sliced using the facilities of the Makerspace while sensible carries far more risks. All the usual ones of random data storage drives being connected to a normal computer. I would hope however that there would already be a policy in place for that.

The only thing I can see that could be a problem is updates to settings to the printer that get changed through the G-code or something on the SD card that the reader can get infected with. Look at the M500 codes. They could over write the calibration settings of the printer. This is not something that a virus scanner would pick up.

The topic comes up every so often on the various Arduino fora. The MK3* series indeed uses an Arduino-type controller. (Not 100% sure of the New Improved SDPS MK4 board, but I suspect it is too.) The topic involves such subtopics such as can you write true self-replicating virii for Arduino-compatible systems?, can you use an Arduino-type board as a vehicle to propagate virii (Arduino, Peecee, Mac, etc.)?, and a more general what types of various malware can you write with/for the Arduino platform.

For the Prusa I3 series, I'm very confident that a malicious .gcode file could indeed be written. The first nasty trick I can think of is to simply slam the nozzle down into the build plate with maximum force possible. Extra points for repeating it over the entire surface of the build plate. I'm sure there are countless variations on the theme.

There are some examples of various malicious sketches (Arduino speak for an Arduino application) which will indeed 'brick' (render useless) some types of Arduino-compatible boards. Those I'm aware of are very specific to certain model boards and are not universal. Some of these nasty items are recoverable with various hard reset maneuvers.

Now, as to writing a genuine 'virus', as in self-replicating nastyware for the Arduino-type systems, that is difficult, among other things due to the fact that the Arduino does not have a standardized file system. Several file systems exist (I tend to prefer LittleFS for my projects), most of them incompatible with each other. ('You are trapped in a maze of twisty little file systems, all different.') ? There are various methods to use volatile and non-volatile file systems, on various fixed and removable media, again, nothing really standard.

One category of malware which has been demonstrated is along the line of using an Arduino-compatible board and sketch to infect an attached computer (plain vanilla Wintel Peecees tend to be the usual target) with various malware. I know two approaches to this, one is to misuse the 'autorun' method in Windows upon connection of a device, and another is to make the Arduino present itself as a keyboard/mouse and start keyboarding and mousing around.

Now, is it possible to write something nasty for the Prusa I3 series which would self-propagate a piece of malware using the SD card file system? I have not examined the code in depth, but if I understand it, the I3 cannot load an executable from the attached SD card. If I am correct, executables need to be uploaded via PS, or via the Arduino IDE or compatible uploaders. Therefore, any malware on the I3 series would most likely need to be disguised as a firmware update/upgrade.

I'm not sure what, if any, write capabilities the Prusa printers have to the SD card. (With LittleFS it's the standard c/c++ open/write/close functions.) I don't know what type of file processing functions they use on the Prusa. I also don't know of any, even experimental, file manipulation commands within any .gcode specifications.

Bottom line, I'm not too concerned at all WRT the Prusa printer becoming infected with Malware. I only use the Prusa-supplied firmware and I seldom, if ever, run any .gcode files that I did not personally slice.

I guess to add to my comment about an old laptop to scan the code SD card, you could also scan the gcode using the slicer and follow the tool path to see if it does anything strange. Takes more time but an option.

I used a program in the past for my laser etcher called Camotics. It showed a tool path. I have not had the time to get it up and running on my current computer. I wonder if it will show the tool path for 3D printer code.

When I was doing my printing at our local makerspace, before I got my own printer, the procedure was to book time on a machine on line, then go to the desk and check out a laptop (with Cura, FreeCad, etc.), check out a spool of filament if you did not bring your own, go to the lab and plug the laptop into the machine, pull up Cura, slice your print, and send it to the printer. You could probably finagle things to print a pre-sliced .gcode, but I don't remember anyone doing it.

I don't remember anyone even considering intentionally damaging a machine. The members there were not that type. The things that would take down a machine were things like the Blob Of Doom (they started a rule to never leave a machine unattended), dorking around with a machine, jams due to wrong filament/temperature/whatever, that kind of thing.

Now when you left a file for the staff to print as the workload permitted, it was more or less the same workflow. They would take your file on a thumb drive, put it in a laptop that had the queue of the day, slice it, and hand the thumb drive back to you. I don't think they would even accept a .gcode file.

3a8082e126