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:

mmu init

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...