Capsure pwned

Capsure Hacking #3 

So after the Capsure USB hacking, and with a little more knowledge (which can be a dangerous thing*) (*see later) what can we do with access to the flash memory?

The bootloader has a built in "view NAND" tool (see end of last post), in there we can see the contents but there's no direct download/upload option, *but* we now have a JTAG connector on this board added in the first post. How hard can it be? 
I pull out a full memory dump, I *think* this means I've got a copy of everything. (*see earlier 'danerous thing' comment) so blunder ahead.  

Where's the memory 

We have a little bit of knowledge from the datasheet which I've been poring over:

So what can we change? What effect will it have? I'd been intrigued by that QC firmware I'd accidentally installed earlier which complained about FW incompatibility, and looking at the full memory dump where we found those old log messages containing what appeared to be testing serial numbers and chipids....

Initially I had considered changing the ROM we uploaded and removing/changing that chipid check code, but since I can manipulate the serial and chip data directly in memory, I can get the QC firmware running by jumping to the start.

Now since we know the ids are in memory, but not in the RAM, but were in the full memory dump, they must be somewhere else.

We now know about the NAND memory and how that's accessed/addressed by the chip, and we can view it.

So can we use the JTAG with OpenOCD to peel it out? (time passes) I start adding the basic options in a new openocd config file and yay! we can probe the chip:

But reading attempts fail.
So we can start disassembling the boot image we've downloaded to see how that interfaces with the NAND. 

Following the code breadcrumbs, we can find the strings mentioning the NAND, from there find the code that outputs that string, which is immediately followed by the code that configures and talks to the NAND... and here we can see various AT91 registers being written to, working through them we make progress...  

But still have some read errors.

Finally after another round of register checking and getting the ECC flags sorted out, we can dump the NAND out in full, all 256Mb. 

Final OpenOCD Nand settings

Fake Capsure RM200-QC 

Now reading and writing without error, I'm confident to erase a page and update the chipids with the ones I copied out of the firmware itself... and reboot....

And voila! we have a QC firmware up and running on a 'Cosmetic' Capsure! Does a little dance, doesn't understand why rest of family aren't as impressed... 🤷‍♂️

Serialz 1.2.3.

With further experimentation and testing it turns out we don't need a valid serial number or matching chipid, all we need to do to get an alternative firmware working is to change the initial digit of the serial number. "Base/standard" models  start with a "1", QC models start with a "2" and cosmetic devices start with a "3" (in fact I also found a serial for a base model that started with a zero) 🤷‍♂️.

As for the "Chip-Id" it turns out that's actually a unique code that's taken from the onboard temperature chip, I guess that was just a simple way to get a guaranteed tamper proof unique code for free!

 

 

So that explains why the id's start with 3B and have that checksum digit. 

Where's the bootloader 

OK so now we have a full memory dump of the device, and a full dump of the NAND contents, and we have a copy of the bootloader. I assume I can now just hack anything I want to and can always recover. yeah?

Will we be able to modify the bootloader and upload that? I'd misread/misunderstood the datasheet somewhat and had assumed that "SRAM" is some sort of non-volatile memory. I am an idiot. anyway.... extracting the bootloader into a separate file and uploading the bootloader, we now have a brick.

Ah. OK more reading flashing, restarting, memory wiping, image uploading, then reading the datasheet *properly* about the boot process.... there must be another memory on here somewhere. A closer inspection of the board reveals a cheeky little SOIC-8 serial flash tucked away in the corner.

We need to talk to this thing directly, what can we do?

Flash Datasheet

SOIC-8 Flash

 

 Fly leads to a SOIC8

BusPirate wired up

Initial attempts at soldering on fly leads and connecting with BusPirate are fruitless.
The signals look good going out, but the chip's just returning FFFFFFs...

Scope showing data and clock signals

Time for drastic action - I've made multiple interim attempts at restarting the bootloader upload process, but don't seem to be getting anywhere. At this point I realise I've actually got a ROM programmer with a proper "in-circuit" clip, so switch to give that a try instead, perhaps the BusPirate isn't *specific* enough.

But with no success with that either, the CPU or other components must be interfering with talking to the chip in-circuit... There's no other option (I think), time to take the chip off.

Circuit board missing a SOIC8 chip

OK now we can read and write to the flash, there seem to be some issues with the bootloader image I'd initially uploaded, so I try making a fresh one from one of the memory dumps I've taken, and reflash the chip.... and solder it back on but the cleaned up bootloader still doesn't start up. Hmm.

SOIC8 soldered back on.

The datasheet mentions the bootloader having its size in a specific location, so I wonder if that's correct given the file size is slightly larger, so I give that a go... and I've got another brick, but now when connecting to a PC a USB device is being enumerated, and appears as a serial device!

SAM-BA!

     Bus 001 Device 057: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader 

Oooh, and I've read about that in the datasheet... so I give the SAM-BA utility a go, after trying a couple of different versions and telling it different chip models, and flash settings, I can talk to the Flash! I can flash the chip in-circuit! OK we're good.

Reading about the "AT91SAM9262 dev kit", it talks about a jumper to force this boot process.... and there is a little jumper pad next to the flash that grounds the !RESET line, that should do the trick. That will force the CPU to fail to read the flash and fallback to the next available boot which in this case will be the on ROM SAM-BA boot.... 

shorting the pins

 
I test this theory and yes, we can now force a SAMBA boot on these units. It's time to crack open another device and get a fresh boot ROM, we don't need no warranty...

Downloading the ROM with the Atmel SAM-BA utility and we can get a clean fresh boot image... and it becomes clear what and where the differences were and why the copy taken from SRAM hadn't worked.

SAM-BA Utility

Amusingly... we can also find the fonts used in the bootloader in here...

But this also answers the mystery of why one time I'd tried to upload a bootloader I'd ended up with a blank screen of coloured boxes! The bootloader *had* actually worked, but I had a blank font because I hadn't copied that over into the flash. 🤦

Pwned 

So what have we learned? Well...

• we can upload and download the NAND flash with jtag
• we can programmatically get into the bootloader
• we can manipulate the serial number and load up arbitrary ROM images to run
• we can fully control and access the bootloader flash and
• we have a method to get the handset into boot recovery (albeit with a jumper and opening the device) 
• we can upload a ROM over USB
• we can upload a bootloader over USB 
• we can upload arbitrary images to the screen. 😁
• we can download and upload to the NAND over USB.

i.e. we now have complete control over the firmware, memory and bootloader over USB without needing to open or solder anything.

and we've got the start of a python utility library that can be used to do all these hacks and modifications without having to solder JTAG or open up the device.

Our Python utility functions

 

 

(Link to the python library in development....)

* Hat tip to Richard Burton for helping and spotting many of the USB command features!