I'd looked at the Chitu series of print controllers long before, back when I was first working on getting Marlin running on the Malyan M200, and concluded a couple things:
1. They were overpriced.
2. I didn't have one working project, so I sure as heck didn't need a second.
Recently someone contacted me on facebook and offered me the mainboard from a Tronxy X5SA, which is closely related to the Chitu Mini F, an STM32F103 board with an TFT LCD. The board has a blown driver, so, after warning that this whole project might dead end with no results, OR by me killing the board, I said sure.
And I began hacking.
If, when I did the M200, it was in the dark, each discovery new, and the lerdge, an evolution, I came to the table this time with a fair set of knowledge. Warning - as before, these logs will probably start out heavy on hex dumps.
Speaking of which...let's look at the firmware updates from Chitu
443D2D3F 72F7BA97 2BA26ECA 1EA57353 36FB727A 8BA9727A 97A1727A BBA9727A D3D2727A 0F45DA21 43687C75 76707372 72727272 72727272 C774737A 4F64033F DB255F65 D5FD717B E775737A A754737A 2DFB727A 6D932BC5 44422D4A 34F77479 2CFB727A 2DFB727A 2DFB727A A3B413B3 5CC5D028 07EE787F'mmu init'
At this point, I can spot an NVIC in my sleep. More importantly, I know to look for the block of reserved addresses
Let's compare to a nice dump from an STM32F103 firmware (the Malyan M200...shock!)
38300020 B9610108 DD5E0108 F15E0108 195F0108 1B5F0108 1D5F0108 00000000 00000000 00000000 00000000 1F5F0108 215F0108 00000000 235F0108 CBE90008 41630108 41630108 41630108 41630108
See those zeros? I don't have a full corresponding block of...anything that could be that.
But I do have a couple of suspicious DWORDS. Those 0x72s follow a common rule - if you think something is XOR'ed or substituted, the one that there's the most of is probably zero. Or an XOR key.
So I ran the code through a quick XOR script.
Out the other side, buried in fragments of garbage:
That's a very specific string, and mmu initialization is something you do when dealing with SRAM. But the NVIC is still garbage, and we still have fragments of other strings.
Switching to other Chitu firmware images, we rapidly see that the first DWORD is constant - probably a signature.
The second DWORD, however, changes, and the high byte of it corresponds to whatever the 00 XOR is.
The same thing repeats, in that if I XOR a rom image with its fifth byte, I get fragments of strings that make sense:
See that last one? It's printing a string with a CR/LF.
So, we know it's an XOR. We know it's not always the same key. And that's what we know to start...