Close

Decryption, Encryption, and CRC validation

A project log for Chitu 3D Printer Mainboard Hacking

Studying the encryption on Chitu's 3D Print controllers

jc-nelsonJ.C. Nelson 09/23/2019 at 23:190 Comments

Since my last update, I successfully added support for encrypting data such that round-trip produces identical files. Once I did this, I proceeded to make a minimal build of Marlin, figuring I could jump straight into working.

No dice. I can get the existing bootloader to flash data on. It turns out that it's storing data in the I2C eeprom regarding what's flashed, and won't re-flash the exact same firmware. You have to swap revisions to flash from one to the next, and I think the file key is what is used to figure out if it's the same thing. Since I use a known good file key right now, that doesn't work.

The resulting Marlin build flashes but never starts, and that lead me to notice a few details I hadn't seen before.

1. The Marlin build using STM32DUINO produces an NVIC with no reserved entries. I do not know why.

2. A super short firmware does NOT flash correctly. I don't know how many blocks are required, but an arduino sketch compiled for a generic F103 (which according to ST is bit-compatible) will not flash - it hits the error handler almost immediately.

3. There's a debug flag stored in ram at 0x2000000. If it's true, the bootloader traces operations. I have no way to enable it. I know the bootloader goes looking for a file that ends in .GCX but I don't know what it actually does.

4. Timer8 appears to be used to drive the speaker/buzzer.

The ST Arduino core doesn't have a variant for 103Z, so I have nothing to compare it to, yet, but I do see there's a feature request for a 103Z variant that's waiting.

So...right now, I need to do some round-trip tests I didn't think of before. I'll decrypt a known good firmware and re-encrypt it with a different file key. If this flashes on and boots up correctly, my encryption script is doing the right thing.

Now...if that's the case, what do we think is happening?

Well, with the M200 and Lerdge, I learned that the bootloader often interferes with the process of overwriting *everything* and re-initializing. I'll have to test a custom version which disables all interrupts (not needed in any normal boot up) and re-initializes, then turns on something like the onboard LED.

Discussions