Capsure RM200 hacking
Upgrade
So firstly lets try the upgrade route Adam talked about in his write-up. What we need to do is use fiddler or similar to intercept the http requests to the xrite download server and replace the serial number and chip id with ones for a generic 'standard' version of the device.
The xrite download site then uses this info to determine which firmware files to send back and annoyingly there's no unique 'per file' URL to use.
Since reasonably enough Adam hadn't shared specific serial numbers/chip id's after a bit of hunting around I had only managed to find a reference number for a "QC" version of the device.
Unfortunately once patched with that version download the handheld then just powered up with an invalid firmware failure and froze. ☹️
bother.
after asking around and some more hunting... a "base model" version serial number was located on Hungarian YouTube, 😁 and finally it updated, but it wasn't too happy at first... perhaps it was because of the earlier update. After resetting and clearing out all of the remnants of the QC install fandecks, going back to the original and then trying again we had success! It booted up and was now matching and recognising Pantone colours.
Although, this did mean I had three versions of the firmware I could compare and look at now too.
Software
What are the differences in the firmwares? Is the QC firmware for a completely different device?
Initially dumping the firmwares showed an amusing detail... there was a "SPEZIAL" serial number embedded in all of them:
I got excited thinking this would be a valid basic serial number, but unfortunately it was again a QC model serial.
Just looking at the firmwares side by side interestingly the cosmetic file is the largest, the standard slightly smaller and the QC version is the smallest. There are various different strings and descriptions in the firmwares, but without more hardware information disassembly doesn't help since the offsets are unknown and a few guesses (o.k. a lot of guesses) doesn't help.
One entertaining aside is that the QC firmware appears to have old log info in it at the end with yet another embedded serial number:
This appears to have been something used during testing since the log shows the device starting up in different modes (cosmetic/qc and normal) and with different firmware versions. Trying out this serial against the download just downloads the QC firmware again though. 😁
USB
Since updating the firmware from windows wasn't ideal it would be better to be able to do this from Linux along with downloading and uploading data... after capturing the USB traffic for the "sync" and firmware upload we can start playing with creating a python read script.
After a bit of kicking from pyusb and guessing/annotating what the binary usb command packets are (e.g. 0x77,0x22 -> read, 0x77,0x21 -> "end" and so on)... voila, we can extract file data.
I think I know enough info to kick off a firmware upload too, but I'll leave this bit of the experiment for a while until I know a bit more about the internals and file and memory mapping. I want to create a modified firmware to try uploading to make that worth bothering with.
But we need to know a bit more about this hardware before doing that.
Hardware
Ideally it would be nice to figure out a bit more about the firmware, although initial disassembly showed some interesting strings, knowing the base address would be needed to make any sense of it. so. time to crack it open.
We don't need no warranty...
OK lets get out the board and remove the screen module, we have a flash chip on the back. At a pinch we could just dump the flash chip directly, but that's always a fiddle/PITA.
We see some test pads... now those look like debugging contacts, however they aren't labelled. Can we work out how they connect? I take a picture of the board, and overlay a grid and start labelling/counting the pin numbers which must match the BGA soldered to the other side... (the letters are offset in this image, the full marked up jpeg was lost when my laptop crashed!)
And then. cross-referencing with the AT91 spec, I think I've got it:
After much careful soldering and threading I get a cable connected and routed out of the case:
Initially I try working with my jlink and a lot of daisy chained patch cables... but that doesn't work, I worry that the debug is disabled or needs some activation - I fallback to my much easier to connect (but a lot slower) "BusPirate" with it's easy to adjust test clamps:
and it recognises the JTAG! and the CPU chip! I try a few accesses, and I can dump the bootloader out to a file.... I don't seem to be able to run the firmware, but I'm not an openocd expert so for now I just grab random bits of memory.
The firmware is located up at 0x20000000 (I download that also just to confirm it's identical in content and structure to the file I have - it is), entering that base address into Ghidra, and it disassembles nicely now with the strings all cross referenced. There are so many "interesting" strings and messages, now with matching code. e.g. the "change serial number" code. 🤣
Now I know it works, I'll get the JLink connected and working since that's much faster and get the python access scripts working before digging into the firmware again.
