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.

[erickphd]

Eric Albert erickphd@aol.com

[donovan6000]

Wow, that sucks. Hopefully there's no issues with it in the future after you get it back. And feel free to take all the time you need. I'm just glad that there's someone willing to help in reverse engineering the printers, so there's no need for you to rush.

[erickphd]

No problem - I already sent the output test file as I got it back earlier this week. -Eric

Sent from my iPad

On Jul 21, 2017, at 12:27 AM, donovan6000 notifications@github.com wrote:

Wow, that sucks. Hopefully there's no issues with it in the future after you get it back. And feel free to take all the time you need. I'm just glad that there's someone willing to help in reverse engineering the printers, so there's no need for you to rush.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

I can't seem to find where you sent the output test file. I don't think github's email reply feature supports displaying attachments.

[erickphd]

OK, I attached it to the return email... but can send again of course. - 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: Fri, Jul 21, 2017 8:00 pm Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

I can't seem to find where you sent the output test file. I don't think github's email reply feature supports displaying attachments. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[erickphd]

OK, its just text (duh!) so I copied it below:

---

1: COM5 SC17061401010001 Connecting to COM5 Sending: M115 Response: wait wait wait e1

Switching device into bootloader mode Sending: M115 S628 Sending: M115 Response: e1

Device is using bootloader version: 1 Reading EEPROM Reading EEPROM failed

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: Fri, Jul 21, 2017 8:00 pm Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

I can't seem to find where you sent the output test file. I don't think github's email reply feature supports displaying attachments. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

Thanks. It looks like the bootloaders for the Micro+ differs from the Micro 3D's in that it periodically sends wait responses when it hasn't received a request for for a set amount of time. And it's either using a different kind of protocol or it's just being very picky about interpreting M115 as an M command.

Try out this one now. It removes leading wait text from all the received responses and just sends M instead of M115.

Also what color is your printer? The first 2 characters in the serial number have been used to indicate the printer's color for the Micro 3D printer, but the SC in SC17061401010001 isn't one of the know color codes: BK, WH, BL, GR, OR, CL, SL, PL.

[erickphd]

OK - here is the response from the new test:

Found 1 device 1: Micro+ COM5 SC17061401010001 Connecting to COM5 Sending: M Response: e1

Switching device into bootloader mode Sending: M115 S628 Sending: M Response: e1

Device is using bootloader version: 1 Reading EEPROM Reading EEPROM failed

The model code is for a clear unit, so I'm guessing that they now are using S to mean a Micro+ and I think a P for the pro. But the Pro only comes in black so far i think. - 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: Fri, Jul 21, 2017 11:30 pm Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

Thanks. It looks like the bootloaders for the Micro+ differs from the Micro 3D's in that it periodically sends wait responses when it hasn't received a request for for a set amount of time. And it's either using a different kind of protocol or it's just being very picky about interpreting M115 as an M command. Try out this one now. It removes leading wait text from all the received responses and just sends M instead of M115. Also what color is your printer? The first 2 characters in the serial number have been used to indicate the printer's color for the Micro 3D printer, the SC in SC17061401010001 isn't one of the know color codes: BK, WH, BL, GR, OR, CL, SL, PL. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[erickphd]

Also, forgot to mention that the + and Pro software (which currently is a nightmare) split out a "spooler" process that is by and large a machine diagnostic interface. So sending g codes and logging the returns is now easy - it also appeared in the Micro software at the last release (1.5.1, Windows, May 2017). However, as you probably know, the current +/Pro version does not support the original Micro, though they promise it will eventually. It also appears that they are using a different USB driver for the + and Pro, or at least they have set it up so it will not recognize the original Micro. - 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: Fri, Jul 21, 2017 11:30 pm Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

Thanks. It looks like the bootloaders for the Micro+ differs from the Micro 3D's in that it periodically sends wait responses when it hasn't received a request for for a set amount of time. And it's either using a different kind of protocol or it's just being very picky about interpreting M115 as an M command. Try out this one now. It removes leading wait text from all the received responses and just sends M instead of M115. Also what color is your printer? The first 2 characters in the serial number have been used to indicate the printer's color for the Micro 3D printer, the SC in SC17061401010001 isn't one of the know color codes: BK, WH, BL, GR, OR, CL, SL, PL. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

I'm starting to think that the Micro+ uses the same Repetier protocol that the Micro 3D uses. I wonder if their Micro+ firmware is just a port of their Micro 3D firmware made to run on the STM32 microcontroller.

Well this test should give us some kind of results. This one sends the command to switch the printer into bootloader mode in both RepRap protocol and Repetier protocol so it should at least react to one of those. Also make sure that M3D's software, including the spooler, is completely closed when running the test programs. Their software could potentially try to communicate with the printer while the test program is which would definitely lead to some weird results in the output file.

I've been reverse engineering their latest Micro+/M3D Pro software, V1.7.0.74, to keep up to date about what changes they made. Their Windows drivers look like it should work with all 3 kinds of printers since it includes the correct USB VIDs and PIDs. Based on the past I wouldn't trust M3D's software engineers to get anything right the first time though, so they could have messed up the driver.

[erickphd]

OK, I've attached it to this email. All M3D software was not running at the time.

The latest due date for .75 is the end of July. They say not to use it for the Micro original and I think I did try once and it did not connect but that might have been the .72 edition. The current alpha release is so buggy I simply have abandoned trying to use it, and my Pro is still on the way. For sure the Micro software does not recognize the M+ and PRo. Supposedly they will support all generations in one program eventually, but they've also been advertising for software folks for several months. What are they writing this in?

-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: Sat, Jul 22, 2017 9:09 pm Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

I'm starting to think that the Micro+ uses the same Repetier protocol that the Micro 3D uses. I wonder if their Micro+ firmware is just a port of their Micro 3D firmware made to run on the STM32 microcontroller. Well this test should give us some kind of results. This one sends the command to switch the printer into bootloader mode in both RepRap protocol and Repetier protocol so it should at least react to one of those. Also make sure that M3D software, including the spooler, is completely closed when running the test programs. Their software could potentially try to communicate with the printer while the test program is which would definitely lead to some weird results in the output file. I've been reverse engineering their latest Micro+/M3D Pro software, V1.7.0.74, to keep up to date about what changes they made. Their Windows drivers look like it should work with all 3 kinds of printers since it includes the correct USB VIDs and PIDs. Based on the past I wouldn't trust M3D's software engineers to get anything right the first time though, so they could have messed up the driver. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

Lol M3D has always loved to boast about accomplishments that they haven't actually achieved. In one of their Kickstarter updates they mentioned how they were planning to release their first ever cross platform software release that supports Windows, macOS, and Linux that month, and that didn't actually happen for another 9 months.

Can you post the output file's contents directly here? Even viewing your replies in my email doesn't show any attachments. Turns out that one of the caveats of github's email reply feature is that it ignores email attachments :(

[erickphd]

Hi, Here’s a link to “output” in my Dropbox:

https://www.dropbox.com/s/djxu6lnz0bcb9na/output?dl=0

-Eric

Sent from my iPad

[erickphd]

Ok to be safe here it is on my dropbox folder

https://www.dropbox.com/s/djxu6lnz0bcb9na/output?dl=0

Looks like we got some data this time. -Eric

Sent from my iPad

On Jul 22, 2017, at 10:21 PM, donovan6000 notifications@github.com wrote:

Lol M3D has always loved to boast about accomplishments that they haven't actually achieved. In one of their Kickstarter updates they mentioned how they were planning to release their first ever cross platform software release that supports Windows, macOS, and Linux that month, and that didn't actually happen for another 9 months.

Can you post the output file's contents directly here? Even viewing your replies in my email doesn't show any attachments. Turns out that one of the caveats of github's email reply feature is that it ignores email attachments :(

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

Awesome! :) That confirmed that we can read/write to the printer's EEPROM. The only part that I don't like it this part.

Verifying flash CRC32
Response: 

It should have responded with ok\r. The receiving response function probably timed out before the printer had a chance to reply though. So try this one now. It just hangs indefinitely until it receives a response from the printer when verifying the flash CRC32 so that we can see what it actually replies with.

[promise8000]

Hello @donovan6000, thank you for your all great work 👍

Here is the decryption table for the M3D Pro:

const uint8_t romDecryptionTable[] = {0xF7, 0x52, 0x16, 0x78, 0xC6, 0xCA, 0xA4, 0xFA, 0x7A, 0x7B, 0x90, 0xF1, 0x12, 0x9E, 0x91, 0x40, 0xDC, 0x4B, 0xCB, 0xB3, 0xB9, 0x23, 0x7C, 0xE9, 0x87, 0x67, 0x01, 0x8B, 0xFD, 0x7F, 0x46, 0xFF, 0xAA, 0x06, 0x3B, 0x53, 0xAD, 0xCE, 0x4C, 0x4A, 0xA3, 0x8A, 0xE2, 0x62, 0x42, 0x2D, 0x36, 0x1E, 0x74, 0xD9, 0xEB, 0xB4, 0x4E, 0xED, 0x66, 0x71, 0xA1, 0x73, 0xD1, 0xA5, 0x1D, 0xE6, 0x6E, 0x43, 0xCD, 0xBE, 0x02, 0x48, 0x17, 0xD8, 0x54, 0x11, 0x27, 0x89, 0x72, 0x3D, 0x35, 0x38, 0x68, 0xD4, 0xE8, 0x98, 0x0D, 0x25, 0x31, 0x95, 0xBD, 0xA7, 0x26, 0xBB, 0xB6, 0xE4, 0xC4, 0x44, 0xF9, 0x2F, 0x1C, 0xB5, 0xFE, 0x33, 0xEE, 0x20, 0xB8, 0x1A, 0x21, 0x81, 0x19, 0xF3, 0xAB, 0x29, 0x05, 0xDB, 0x8C, 0xDD, 0xD7, 0x80, 0x97, 0xF2, 0x85, 0x63, 0x5C, 0xFC, 0xEC, 0x45, 0xA8, 0xF4, 0x92, 0x32, 0x07, 0xC5, 0xA2, 0x4F, 0x5D, 0x41, 0x22, 0xCC, 0xE7, 0xC0, 0x9B, 0x00, 0x79, 0xC3, 0x70, 0x4D, 0x5A, 0x58, 0x59, 0x2B, 0x08, 0x47, 0xD0, 0xC1, 0x3A, 0x96, 0x1B, 0xD3, 0x6B, 0x8F, 0x24, 0x6C, 0x0E, 0x94, 0xB0, 0x60, 0x8E, 0xF6, 0x9C, 0x10, 0xBF, 0xE3, 0xCF, 0x2E, 0x50, 0xD6, 0xEA, 0xB1, 0x2A, 0x09, 0xAF, 0x3E, 0x82, 0x83, 0x18, 0xF0, 0x39, 0xBC, 0x04, 0xAC, 0xA0, 0xDE, 0x55, 0x75, 0x3C, 0x5B, 0x0F, 0x65, 0x7D, 0xDA, 0xC8, 0xE1, 0xC2, 0xC9, 0xF5, 0x37, 0xB7, 0xC7, 0x9D, 0x8D, 0xD2, 0x0C, 0xEF, 0x3F, 0xE5, 0x15, 0x7E, 0x14, 0x5F, 0x57, 0xA6, 0x6A, 0x49, 0x2C, 0xF8, 0x6D, 0x9F, 0x1F, 0x9A, 0x5E, 0x88, 0x99, 0xFB, 0xD5, 0x51, 0x64, 0xB2, 0x56, 0x13, 0x84, 0x34, 0x0A, 0x76, 0x69, 0xE0, 0x86, 0xAE, 0x6F, 0xA9, 0x30, 0x03, 0x77, 0xDF, 0x61, 0x28, 0x93, 0xBA, 0x0B};

The code loads at address 0x08006000

[erickphd]

OK, here it is: https://www.dropbox.com/s/5h2qurp3iw1340k/output?dl=0

Looks like it responded with "ok" at the end.

And apparently someone in this thread sent the decryption table for the Pro? - 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: Sat, Jul 22, 2017 10:57 pm Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

Awesome! :) That confirmed that we can read/write to the printer's EEPROM. The only part that I don't like it this part. Verifying flash CRC32 Response:

It should have responded with ok\r. The receiving response function probably timed out before the printer had a chance to reply though. So try this one now. It just hangs indefinitely until it receives a response from the printer when verifying the flash CRC32 so that we can see what it actually replies with. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

Sorry guys. Got kinda busy the last few days.

@promise8000 Awesome!!! That really helps a lot! Were you able to read the microcontroller's flash via the SWD debug pins? Or did you do something else to get access to the chip's firmware? Could you upload the chip's entire 128KB of flash here so that we can see where the bootloader, firmware, and simulated EEPROM are all located? The firmware updating mechanism only updates 0x18000 bytes of flash for the M3D Pro's main firmware, so there's still 0x8000 bytes that I want to see.

Also can you confirm if the M3D Pro has 2 STM32F070CB microcontrollers? One for the main firmware and one for the secondary firmware. Or is one of the chips a different microcontroller? Could you also upload the second microcontroller's entire flash here too if your able to get access to it?

I was able to verify that your keys are correct for decrypting both the M3D Pro's main and secondary firmwares. That also led me to confirm that M3D LLC is using the microcontroller's builtin CRC32 functionality to generate the CRC32 used in verifying if the firmware was flashed correctly.

So here's the CRC32 parameters:

• Input Reflected: false
• Output Reflected: false
• Polynomial: 0x04C11DB7
• Initial Value: 0xBCAD558B (Only for M3D Pro's main firmware. Works on all 3 released M3D Pro main firmwares, so it's definitely correct. Doesn't work with M3D Pro's secondary firmware, and probably wont work with the Micro+. If i knew the max size of the M3D Pro's updatable secondary firmware then I could guess this value for the M3D Pro's secondary firmware. So far I've tried the sizes 0x18000, 0x19800, and 0x20000, but none of those are correct)
• Final Xor Value: 0x00000000

@erickphd Contrary to what we were hoping, M3D LLC is using non-default CRC32 initial values for the M3D Pro's main firmware, so they probably did the same thing for the Micro+. One of the ideas I had incase they didn't use the default value was to try to guess it with a timing attack, but I think USB CDC packets are transmitted at fixed intervals which would make that ineffective when a timing attack would require nanoseconds of accuracy for it to work on the STM32F070CB microcontroller running at 48MHz. We'll wait to see what @promise8000 says about how he accessed the Pro's firmware before deciding how to proceed with the Micro+.

[erickphd]

OK, cool. @donovan6000 so if I got an SWD debugger connected and software like CooCox should I be able to dump the flash on the Micro+?? I'm far more familiar with JTAG and non-ARM micros but it looks like this is just a variant for ARM hardware. I can do a little probing to see if they brought those pins out on the board somewhere for connection. - Eric

As my box is clear,

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: Fri, Jul 28, 2017 1:17 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

Sorry guys. Got kinda busy the last few days. @promise8000 Awesome!!! That really helps a lot! Were you able to read the microcontroller's flash via the SWD debug pins? Or did you do something else to get access to the chip's firmware? Could you upload the chip's entire 128KB of flash here so that we can see where the bootloader, firmware, and simulated EEPROM are all located? The firmware updating mechanism only updates 0x18000 bytes of flash for the M3D Pro's main firmware, so there's still 0x2000 bytes that I want to see. Also can you confirm if the M3D Pro has 2 STM32F070CB microcontrollers? One for the main firmware and one for the secondary firmware. Or is one of the chips a different microcontroller? Could you also upload the second microcontroller's entire flash here too if your able to get access to it? I was able to verify that your keys are correct for decrypting both the M3D Pro's main and secondary firmwares. That also led me to confirm that M3D LLC is using the microcontroller's builtin CRC32 functionality to generate the CRC32 used in verifying if the firmware was flashed correctly. So here's the CRC32 parameters:

Input Reflected: false Output Reflected: false Polynomial: 0x04C11DB7 Initial Value: 0xBCAD558B (Only for M3D Pro's main firmware. Works on all 3 released M3D Pro main firmwares, so it's definitely correct. Doesn't work with M3D Pro's secondary firmware, and probably wont work with the Micro+. If i knew the max size of the M3D Pro's updatable secondary firmware then I could guess this value for the M3D Pro's secondary firmware. So far I've tried the sizes 0x18000, 0x19800, and 0x20000, but none of those are correct) Final Xor Value: 0x00000000

@erickphd Contrary to what we were hoping, M3D LLC is using non-default CRC32 initial values for the M3D Pro's main firmware, so they probably did the same thing for the Micro+. One of the ideas I had incase they didn't use the default value was to try to guess it with a timing attack, but I think USB CDC packets are transmitted at fixed intervals which would make that ineffective when a timing attack would require nanoseconds of accuracy for it to work on microcontroller running at 48MHz. We'll wait to see what @promise8000 says about how he accessed the Pro's firmware before deciding how to proceed with the Micro+. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[erickphd]

FYI: from the discord channel:

"sorry to hear that. you faced the sudden-death problem which happened to me and several other forum members. internal firmware is bricked.....just don't consider to buy or upgrade to a Micro+ , at least for now. there is this sudden-death problem on Micro+ firmware that bricks your printer one day out of nowhere. In the forum and discord, there are a bunch of examples and users suffering this problem."

Eric Albert erickphd@aol.com

[donovan6000]

@erickphd I was just about to give up on this since I thought that we needed either the decryption keys or initial CRC32 value to be able to brute force the other, but I think I finally thought of a way to brute force the decryption keys without having to know the initial CRC32 value!

So try out this program and upload the resulting output file. The program will stop if it goes past 80% of the total number of writes that the micrcontroller's flash can endure, so you'll still have 2000 writes left if that happens. Also, it could potentially take up to 5 minutes to brute force each byte, so the program might be running for 20+ hours. I'm pretty sure it'll hit the 80% write endurance limit within the first 2 hours though.

[donovan6000]

Oops, the last program I posted didn't allow an encrypted byte to be equal to its decrypted value since that didn't happen with the Micro 3D's firmware encryption. However it does happen with the M3D Pro's encryption, so it might also happen for the Micro+'s. So run this program instead (fixing more issues. I'll post the new program soon).

[erickphd]

OK - will run it this weekend for sure and upload the results. - 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: Fri, Aug 18, 2017 1:09 pm Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

Oops, the last program I posted didn't allow an encrypted byte to be equal to its decrypted value since that didn't happen with the Micro 3D's firmware encryption. However it does happen with the M3D Pro's encryption, so it might also happen for the Micro+'s. So run this program instead. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

Thanks. I've been making some progress on guessing a lot of the alphanumeric character's encryption keys today, so don't run any programs until I post a new program in a few hours that includes all the new found keys :)

[donovan6000]

Here the newest program (program removed since we don't need anyone else to run it)

[erickphd]

Running now - it is taking about 2.5 minutes per key.

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: Sat, Aug 19, 2017 3:13 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

Here the newest program. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[erickphd]

OK - here is the output file. Stopped at 8037 writes so didn't get them all.... - 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: Sat, Aug 19, 2017 3:13 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

Here the newest program. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

Hopefully it got a good amount of them. Otherwise we might have to find another Micro+ owner to find the rest.

Can you paste the contents of the output file here? Email attachments still aren't working with github.

[erickphd]

I keep forgetting github doesn't play well with attachments, even text ones....

Found 1 device 1: Micro+ COM5 SC17061401010001 Connecting to COM5 Switching device into bootloader mode Sending: M115 S628 Sending: M115 Response: B007 Device is using bootloader version: 7 EEPROM Contents: 0x3D 0x16 0x3A 0x78 0x3E 0xD8 0x84 0x9E 0x00 0x04 0x9C 0x72 0x3E 0x75 0xC2 0x8F 0x3F 0x19 0x99 0x9A 0xBF 0x13 0xEF 0xDB 0xBE 0xA1 0x80 0xB6 0xBF 0x23 0x95 0x0B 0xBF 0x8A 0xDA 0x0F 0x00 0x00 0x00 0x0F 0x00 0x02 0x00 0x73 0x45 0x45 0xF9 0x89 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x45 0xE1 0x00 0x00 0x00 0x01 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x06 0x0F 0x1C 0xD4 0x00 0x00 0x00 0x06 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0xE6 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x41 0xC3 0x92 0xC7 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x53 0x43 0x31 0x37 0x30 0x36 0x31 0x34 0x30 0x31 0x30 0x31 0x30 0x30 0x30 0x31 0x00 0x01 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x31 0x37 0x8C 0x0C 0x30 0x36 0x8C 0x0C 0x31 0x34 0x8C 0x0C 0x0C 0x0C Flash CRC32 in EEPROM: 0x9E84D83E Verifying flash CRC32 Response: ok Starting to brute force keys 0x07 = 0x1A 0x08 = 0xAD 0x09 = 0x0D 0x0A = 0x8B 0x0B = 0xE9 0x0C = 0x72 0x0D = 0x05 0x0E = 0x0B 0x0F = 0x01 0x10 = 0x87 0x11 = 0x5F 0x12 = 0x14 0x13 = 0x53 0x14 = 0xED 0x15 = 0x2E 0x16 = 0xD5 0x17 = 0x77 0x18 = 0x3A 0x19 = 0x6E 0x1B = 0xB4 0x1C = 0x54 0x1D = 0x59 0x1E = 0xD2 0x1F = 0x70 0x20 = 0x02 0x21 = 0x15 0x22 = 0x79 0x23 = 0x9F 0x24 = 0x08 0x25 = 0xCB 0x26 = 0xA0 0x27 = 0xE8 0x28 = 0xBE 0x29 = 0xFC 0x2A = 0xE7 0x2B = 0x10 0x2C = 0x0E 0x2D = 0x3F 0x2E = 0xDD 0x2F = 0xAC 0x30 = 0x48 0x31 = 0x7B 0x32 = 0x0F 0x34 = 0x52 0x35 = 0x4F 0x36 = 0xFE 0x37 = 0x6F 0x38 = 0xD1 0x39 = 0xA4 0x3A = 0x6B 0x3B = 0xB6 0x3C = 0x1C 0x3D = 0xD7 0x3E = 0x74 0x3F = 0xA6 0x40 = 0x4B 0x41 = 0x19 0x42 = 0x3D 0x43 = 0x4C 0x44 = 0x7F 0x46 = 0x60 0x47 = 0xF2 0x48 = 0x8A 0x49 = 0x62 0x4A = 0x90 0x4B = 0x89 0x4C = 0xBD 0x4E = 0xF6 0x4F = 0x9B 0x51 = 0xFD 0x53 = 0x26 0x54 = 0x18 0x55 = 0x13 0x56 = 0x85 0x57 = 0xDA 0x58 = 0xFA Stopping at 8037 writes to flash 164 keys missing 8037 writes to flash occured Decryption Keys: 0xD6, 0x68, 0xD8, 0x7D, 0x5A, 0xD4, 0x1E, 0x1A, 0xAD, 0x0D, 0x8B, 0xE9, 0x72, 0x05, 0x0B, 0x01, 0x87, 0x5F, 0x14, 0x53, 0xED, 0x2E, 0xD5, 0x77, 0x3A, 0x6E, 0x00, 0xB4, 0x54, 0x59, 0xD2, 0x70, 0x02, 0x15, 0x79, 0x9F, 0x08, 0xCB, 0xA0, 0xE8, 0xBE, 0xFC, 0xE7, 0x10, 0x0E, 0x3F, 0xDD, 0xAC, 0x48, 0x7B, 0x0F, 0xE3, 0x52, 0x4F, 0xFE, 0x6F, 0xD1, 0xA4, 0x6B, 0xB6, 0x1C, 0xD7, 0x74, 0xA6, 0x4B, 0x19, 0x3D, 0x4C, 0x7F, 0xBB, 0x60, 0xF2, 0x8A, 0x62, 0x90, 0x89, 0xBD, 0x8D, 0xF6, 0x9B, 0xB7, 0xFD, 0xCE, 0x26, 0x18, 0x13, 0x85, 0xDA, 0xFA, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x42, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0xFF, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x66, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x?? Encryption Keys: 0x1A, 0x0F, 0x20, 0x??, 0x??, 0x0D, 0x??, 0x??, 0x24, 0x??, 0x??, 0x0E, 0x??, 0x09, 0x2C, 0x32, 0x2B, 0x??, 0x??, 0x55, 0x12, 0x21, 0x??, 0x??, 0x54, 0x41, 0x07, 0x??, 0x3C, 0x??, 0x06, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x53, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x15, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x18, 0x??, 0x??, 0x42, 0x??, 0x2D, 0x??, 0x??, 0x79, 0x??, 0x??, 0x??, 0x??, 0x??, 0x30, 0x??, 0x??, 0x40, 0x43, 0x??, 0x??, 0x35, 0x??, 0x??, 0x34, 0x13, 0x1C, 0x??, 0x??, 0x??, 0x??, 0x1D, 0x04, 0x??, 0x??, 0x??, 0x??, 0x11, 0x46, 0x??, 0x49, 0x??, 0x??, 0x??, 0xF1, 0x??, 0x01, 0x??, 0x??, 0x3A, 0x??, 0x??, 0x19, 0x37, 0x1F, 0x??, 0x0C, 0x??, 0x3E, 0x??, 0x??, 0x17, 0x??, 0x22, 0x??, 0x31, 0x??, 0x03, 0x??, 0x44, 0x??, 0x??, 0x??, 0x??, 0x??, 0x56, 0x??, 0x10, 0x??, 0x4B, 0x48, 0x0A, 0x??, 0x4D, 0x??, 0x??, 0x4A, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x4F, 0x??, 0x??, 0x??, 0x23, 0x26, 0x??, 0x??, 0x??, 0x39, 0x??, 0x3F, 0x??, 0x??, 0x??, 0x??, 0x??, 0x2F, 0x08, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x1B, 0x??, 0x3B, 0x50, 0x??, 0x??, 0x??, 0x45, 0x??, 0x4C, 0x28, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x25, 0x??, 0x??, 0x52, 0x??, 0x??, 0x38, 0x1E, 0x??, 0x05, 0x16, 0x00, 0x3D, 0x02, 0x??, 0x57, 0x??, 0x??, 0x2E, 0x??, 0x??, 0x??, 0x??, 0x??, 0x33, 0x??, 0x??, 0x??, 0x2A, 0x27, 0x0B, 0x??, 0x??, 0x??, 0x14, 0x??, 0x??, 0x??, 0x??, 0x47, 0x??, 0x??, 0x??, 0x4E, 0x??, 0x??, 0x??, 0x58, 0x??, 0x29, 0x51, 0x36, 0x8B

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: Sun, Aug 20, 2017 2:57 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

Hopefully it got a good amount of them. Otherwise we might have to find another Micro+ owner to find the rest. Can you paste the contents of the output file here? Email attachments still aren't working with github. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

@erickphd Awesome, so we know 92 / 256 keys now! I'll start asking around on some of the M3D related forums to try to get a few more people to help us get the remaining keys.

Also have you received your M3D Pro yet? it'd be nice to be able to verify that this new brute force method also works on it.

[erickphd]

OK cool... I've been out of the loop on this with work overload last two weeks. So it looks like it would take 2 more machines to get the rest?

My M3D Pro arrived but I've not done much with it yet.... - 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: Sun, Aug 20, 2017 9:24 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

@erickphd Awesome, so we know 92 / 256 keys now! I'll start asking around on some of the M3D related forums to try to get a few more people to help us get the remaining keys. Also have you received your M3D Pro yet? it'd be nice to be able to verify that this new brute force method also works on it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[donovan6000]

I got the rest of the decryption keys last week! Now can you run this program while your Micro+ is connected to your computer? The program should extract all the contents of all the printer's nonvolatile memory, like its bootloader and option bytes, to an output file. Send me that output file when it's done. The whole process should take about 3 minutes. Also let me know if the printer's front LED flashes when the program finishes. I guessed on which pin the LED is connected to, so I want to know if I'm right.

If this all works then it shows that we've gotten to the point where we can successfully run our own firmware on the printer, and we'll have access to the printer's bootloader so there's nothing else that's hidden from us.

[erickphd]

It worked! https://www.dropbox.com/s/5h2qurp3iw1340k/output?dl=0

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: Thu, Sep 14, 2017 2:11 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

I got the rest of the decryption keys last week! Now can you run this program while your Micro+ is connected to your computer? The program should extract all the contents of all the printer's nonvolatile memory, like its bootloader and option bytes, to an output file. Send me that output file when it's done. The whole process should take about 3 minutes. Also let me know if the printer's front LED flashes when the program finishes. I guessed on which pin the LED is connected to, so I want to know if I'm right. If this all works then it shows that we've gotten to the point where we can successfully run our own firmware on the printer, and we'll have access to the printer's bootloader so there's nothing else that's hidden from us. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[erickphd]

and to be clear, the light flashed when the program finished! Eager to see the next phase! - 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: Thu, Sep 14, 2017 2:11 am Subject: Re: [donovan6000/iMe] Invalid G codes? (#55)

I got the rest of the decryption keys last week! Now can you run this program while your Micro+ is connected to your computer? The program should extract all the contents of all the printer's nonvolatile memory, like its bootloader and option bytes, to an output file. Send me that output file when it's done. The whole process should take about 3 minutes. Also let me know if the printer's front LED flashes when the program finishes. I guessed on which pin the LED is connected to, so I want to know if I'm right. If this all works then it shows that we've gotten to the point where we can successfully run our own firmware on the printer, and we'll have access to the printer's bootloader so there's nothing else that's hidden from us. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[THansen123]

How can I help! -Tom

[jgueydan]

Has this gone any further with the M3D Micro+?