Invalid G codes?

[erickphd]

Installed firmware on Micro then connected to MatterControl, latest stable version. Tried to run calibration cube. Job stalls after bed level and preheat. Log shows invalid G codes -
print_log.txt
Is this iMe firmware or MatterControl?

[donovan6000]

iMe doesn't have the M400 command implemented, and that's what's causing the problem.. It used to not send that command back when we were testing iMe with MatterControl, so it was never implemented. I can add it to iMe if there's no way to disable it in MatterControl.

[erickphd]

Thanks! I'll check with MatterControl and see if it can be disabled. I am using the Micro-specific profile that is labeled "iMe firmware on M3D." Will let you know what I find. However, as I'm sure you know, the meaning of this code is to wait until all sent moves are finished - wouldn't this be needed in the case of the Micro which is rather slow? I've sent in a support ticket to MatterControl because I can't find anything on their support pages about this or on their forum.

[donovan6000]

iMe will always finish the command that it's currently processing before running the next command, so sending an M400 command to it wont change it's behaviour. I added support for the M400 command in iMe's devel branch, and you can use M33 Manager to install a firmware from this file to use it.

[erickphd]

Thanks! I was in discussion with MatterControl/MatterHackers and they are putting a ticket in to add an M400 removal option... which should help for other machines in the future. I really appreciate the work you have done to free the Micro up to more open use. Any idea if the Micro+ could be done as well? They added an SD card and better temperature control for starters (thermistor in hot end). - Eric Eric Albert erickphd@aol.com

…

-----Original Message----- From: donovan6000 <notifications@github.com> To: donovan6000/iMe <iMe@noreply.github.com> Cc: erickphd <erickphd@aol.com>; Author <author@noreply.github.com> Sent: Sat, Jun 10, 2017 12:31 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55) iMe will always finish the command that it's currently processing before running the next command, so sending an M400 command to it wont change it's behaviour. I added support for the M400 command in iMe's devel branch, and you can use M33 Manager to install a firmware from this file to use it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

Glad I could help. Getting our own firmware to run on the Micro+ or M3D Pro printers first requires figuring out how to decrypt M3D's official firmware for each of those printer. This had to be done for the Micro 3D printer as well, and after doing that we can then reverse engineer their firmware and encrypt our own firmware.

M3D's official software comes with their encrypted firmware and a CRC32 of the decrypted firmware. The software sends the encrypted firmware to the printer, and the printer's bootloader uses a one-to-one loop up table to decrypt each byte it receives before writing the decrypted byte to its flash. The software then sends the CRC32 to the printer and the printer confirms it the contents in its flash match that CRC32 as a way to verify that the firmware was installed correctly.

I've been attempting to brute force the decryption byte permutation for the M3D Pro over the last few weeks, but it's similar to the travelling salesman problem in that there's factorial(255) permutations for me to try. After a couple weeks of optimizing my brute force algorithm, I'm still only about to compute approximately 302000 permutations per second which would still take trillions and trillions of years to try a them all. I am looking at increasing my throughput via the use of FPGAs and general purpose GPU computing, but I doubt that I'll ever be able to brute force it with the resources that I have available.

The reason I was able to figure out the decryption byte permutation for the Micro 3D printer is because I was able to leverage the way that it confirms if its flash contents match a provided CRC32 to give me the ability to brute force a single byte at a time. I can't do that same thing for the Micro+ or M3D Pro printers since I don't physically have access to those printers or know anyone who owns one yet.

[erickphd]

OK, I get the CRC32 for error checking but adding the encryption seems overkill although they clearly want to keep it proprietary. Thing is, for the most part their machine controllers are in practice functionally equivalent to a lot of other motion control boards for 3D printers. I do have a Micro+ clear edition. It uses an STM32 (not sure of spec yet) processor. I'm waiting for a Pro but at the rate they are having problems, they can't even get their client software stable so I'd rather wait. - Eric Eric Albert erickphd@aol.com

…

-----Original Message----- From: donovan6000 <notifications@github.com> To: donovan6000/iMe <iMe@noreply.github.com> Cc: erickphd <erickphd@aol.com>; Author <author@noreply.github.com> Sent: Sun, Jun 11, 2017 1:15 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55) Glad I could help. Getting our own firmware to run on the Micro+ or M3D Pro printers first requires figuring out how to decrypt M3D's official firmware for each of those printer. This had to be done for the Micro 3D printer as well, and after doing that we can then reverse engineer their firmware and encrypt our own firmware. M3D's official software comes with their encrypted firmware and a CRC32 of the decrypted firmware. The software sends the encrypted firmware to the printer, and the printer's bootloader uses a one-to-one loop up table to decrypt each byte it receives before writing the decrypted byte to its flash. The software then sends the CRC32 to the printer and the printer confirms it the contents in its flash match that CRC32 as a way to verify that the firmware was installed correctly. I've been attempting to brute force the decryption byte permutation for the M3D Pro over the last few weeks, but it's similar to the travelling salesman problem in that there's factorial(255) permutations for me to try. After a couple weeks of optimizing my brute force algorithm, I'm still only about to compute approximately 302000 permutations per second which would still take trillions and trillions of years to try a them all. I am looking at increasing my throughput via the use of FPGAs and general purpose GPU computing, but I doubt that I'll ever be able to brute force it with the resources that I have available. The reason I was able to figure out the decryption byte permutation for the Micro 3D printer is because I was able to leverage the way that it confirms if its flash contents match a provided CRC32 to give me the ability to brute force a single byte at a time. I can't do that same thing for the Micro+ or M3D Pro printers since I don't physically have access to those printers or know anyone who owns one yet. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

Awesome, you have a Micro+ and you'll eventually have an M3D Pro!!! :) You want to help crack their encryption?

The microcontroller in both the Micro+ and M3D Pro printers is the STM32F070CB. M3D's firmware for those printer's is most likely using the microcontroller's builtin CRC calculation unit like they did with the Micro 3D's ATxmega32C4 microcontroller. Page 13 of the STM32 family CRC application notes shows that the only configurable setting for the STM32F0 series is the initial CRC32 seed value, so we'll have to figure that out first.

The trick with the Micro 3D printer is that it could return the CRC32 of its flash contents. So the initial CRC32 seed could be determined by erasing the flash which sets it to all 0xFF, getting the CRC32 of that from the printer, and then brute forcing a file that's the same size as the flash all filled with 0xFF values using all 4294967295 possible seed values until a CRC32 that matches the one that the printer returned was obtained. It turned out that M3D used the ATxmega32C4's default seed value, 0xFFFFFFFF, so I'm leaning toward them using the STM32F070CB's default seed value, 0xFFFFFFFF, as well. But we wont know until we test it. However M3D did changed one thing about their Micro+ and M3D Pro printer which complicates things a little bit. The printer can no longer return the CRC32 of its flash contents, but instead can verify that a provided CRC32 stored in its flash simulated EEPROM matches the CRC32 of a section of its flash contents. So that just makes it so that we'll have to brute force the CRC32 seed by sending our guesses to the printer and seeing which ones confirms that the currently guessed seed was correct.

Unfortunately page 14 of the STM32F070CB EEPROM emulation application notes states that the write endurance of the microcontroller's flash is a reliable for up to 10000 times. Since the guessed CRC32 values have to be written to the microcontroller's flash simulated EEPROM, then each guess we made will slowly diminish the reliability of the microcontroller's flash eventually. Knowing that the worst case scenario is that it'll take 4294967295 guesses just brute force the seed value makes me feel uneasy about that flash endurance.

I'll try to get some Micro+ CRC32 brute forcing software ready for you to run in the next couple of days if your interested in helping :)

[rytz]

M400 is pretty important to the way MatterControl's macro features, so it's not really something we'd like to be able to disable. If the firmware can support M400 that would probably be best.

[erickphd]

Ryan: thanks; a change was made in iMe recently to ignore those codes because for the Micro it is not needed, but was not implemented yet to ignore. - Eric Eric Albert erickphd@aol.com

…

-----Original Message----- From: Ryan Lutz <notifications@github.com> To: donovan6000/iMe <iMe@noreply.github.com> Cc: erickphd <erickphd@aol.com>; Author <author@noreply.github.com> Sent: Mon, Jun 12, 2017 2:05 pm Subject: Re: [donovan6000/iMe] Invalid G codes? (#55) M400 is pretty important to the way MatterControl's macro features, so it's not really something we'd like to be able to disable. If the firmware can support M400 that would probably be best. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[erickphd]

Yup although the Pro seems like it will be another month or so until I get it. I'm out of town for the next two weeks but in early July I would be willing to give the M+ a try - hoping that we don't crash the flash of course - but I think it might be a safe assumption that they stuck with the default CRC seed. - Eric Eric Albert erickphd@aol.com

…

-----Original Message----- From: donovan6000 <notifications@github.com> To: donovan6000/iMe <iMe@noreply.github.com> Cc: erickphd <erickphd@aol.com>; Author <author@noreply.github.com> Sent: Sun, Jun 11, 2017 11:07 pm Subject: Re: [donovan6000/iMe] Invalid G codes? (#55) Awesome, you have a Micro+ and you'll eventually have an M3D Pro!!! :) You want to help crack their encryption? The microcontroller in both the Micro+ and M3D Pro printers is the STM32F070CB. M3D's firmware for those printer's is most likely using the microcontroller's builtin CRC calculation unit like they did with the Micro 3D's ATxmega32C4 microcontroller. Page 13 of the STM32 family CRC application notes shows that the only configurable setting for the STM32F0 series is the initial CRC32 seed value, so we'll have to figure that out first. The trick with the Micro 3D printer is that it could return the CRC32 of its flash contents. So the initial CRC32 seed could be determined by erasing the flash which sets it to all 0xFF, getting the CRC32 of that from the printer, and then brute forcing a file that's the same size as the flash all filled with 0xFF values using all 4294967295 possible seed values until a CRC32 that matches the one that the printer returned was obtained. It turned out that M3D used the ATxmega32C4's default seed value, 0xFFFFFFFF, so I'm leaning toward them using the STM32F070CB's default seed value, 0xFFFFFFFF, as well. But we wont know until we test it. However M3D did changed one thing about their Micro+ and M3D Pro printer which complicates things a little bit. The printer can no longer return the CRC32 of its flash contents, but instead can verify that a provided CRC32 stored in its flash simulated EEPROM matches the CRC32 of a section of its flash contents. So that just makes it so that we'll have to brute force the CRC32 seed by sending our guesses to the printer and seeing which ones confirms that the currently guessed seed was correct. Unfortunately page 14 of the STM32F070CB EEPROM emulation application notes states that the write endurance of the microcontroller's flash is a reliable for up to 10000 times. Since the guessed CRC32 values have to be written to the microcontroller's flash simulated EEPROM, then each guess we made will slowly diminish the reliability of the microcontroller's flash eventually. Knowing that the worst case scenario is that it'll take 4294967295 guesses just brute force the seed value makes me feel uneasy about that flash endurance. I'll try to get some Micro+ CRC32 brute forcing software ready for you to run in the next couple of days if your interested in helping :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

Thanks! That gives me plenty of time to get everything figured out. I'll keep you updated.

[donovan6000]

@erickphd Sorry this took so long. Here's a program that's to test if communicating with the Micro+'s bootloader works and that reading/writing to the printer's EEPROM works. While the printer is connected to your computer, run the Test Windows, Test macOS, or Test Linux file depending on the operating system that your using. The program just creates a file called output in the same directory as the executable that contains some debug output. Upload that file here so we can see if everything is working so far.

Thanks again!

[erickphd]

No problem - just got back recently and will try and let you know. - Eric Eric Albert erickphd@aol.com

…

-----Original Message----- From: donovan6000 <notifications@github.com> To: donovan6000/iMe <iMe@noreply.github.com> Cc: erickphd <erickphd@aol.com>; Mention <mention@noreply.github.com> Sent: Tue, Jul 4, 2017 12:35 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55) @erickphd Sorry this took so long. Here's a program that's to test if communicating with the Micro+'s bootloader works and that reading/writing to the printer's EEPROM works. While the printer is connected to your computer, run the Test Windows, Test macOS, or Test Linux file depending on the operating system that your using. The program just creates a file called output in the same directory as the executable that contains some debug output. Upload that file here so we can see if everything is working so far. Thanks again! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[erickphd]

Hi - didn't forget about this but when I unpacked my plus unit and plugged it in, the blue smoke genie departed the chassis - or more specifically, it appears that I've had an infant mortality on some part of the power supply in the board. I only used it for less than an hour when this happened. I finally got an RMA and returned it for repair (takes a week to accomplish), sent both ways at my expense. I hear it takes them two weeks on site to return, but not sure. With any luck it will be back before the end of July. Will let you know. - Eric Eric Albert erickphd@aol.com

…

-----Original Message----- From: donovan6000 <notifications@github.com> To: donovan6000/iMe <iMe@noreply.github.com> Cc: erickphd <erickphd@aol.com>; Mention <mention@noreply.github.com> Sent: Tue, Jul 4, 2017 12:35 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55) @erickphd Sorry this took so long. Here's a program that's to test if communicating with the Micro+'s bootloader works and that reading/writing to the printer's EEPROM works. While the printer is connected to your computer, run the Test Windows, Test macOS, or Test Linux file depending on the operating system that your using. The program just creates a file called output in the same directory as the executable that contains some debug output. Upload that file here so we can see if everything is working so far. Thanks again! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.