Capsure pwned

Capsure Hacking #3

Third post on this topic, see also post 1(JTAG connections) - and post 2 (USB decoding).

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 don't come from the ROM image they must be being read in from somewhere..

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

Flash! A-ah!...

Scanning through the NAND we can find where it holds various bits... the NAND has 128k pages, so we can jump up 0x20000 at a time, a single 64bit value first: 🤷

0002:0000 | FE FD 00 00 00 00 00 00 FF FF FF FF FF FF FF FF | þý......ÿÿÿÿÿÿÿÿ

at 0xA0000, we have a bitmap:

0009:FFF0 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000A:0000 | 42 4D F8 C5 01 00 00 00 00 00 36 00 00 00 28 00 | BMøÅ......6...(.
000A:0010 | 00 00 B0 00 00 00 DC 00 00 00 01 00 18 00 00 00 | ..°...Ü.........

Just the logo, nice. At 0xC0000 we have:

Aha, that's the ROM image, that's how our downloaded copy starts. The bootloader menu mentions 'page 128' being "calib data"... and sure enough at 0x100000 we have another chunk of data:

00FF:FFE0 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00FF:FFF0 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
0100:0000 | 08 00 00 00 3B 38 3D 26 00 00 00 FF 33 30 31 30 | ....;8=&...ÿ3010
0100:0010 | 30 34 33 37 34 31 00 00 00 00 00 00 32 30 32 30 | 043741......2020
0100:0020 | 30 33 30 37 20 32 31 3A 35 33 00 00 47 45 2D 47 | 0307 21:53..GE-G
0100:0030 | 65 6E 31 00 00 00 00 00 00 00 00 00 BC 02 00 00 | en1.........¼...

And in the "calib data" there we have the chipid (red) and serial number (blue)!.. along with a datestamp and some model info. 🎉

Fake Capsure RM200-QC

Now reading and writing the NAND without error, I'm confident to erase a page and update with id's with those ones I copied out of the firmware itself (see post 1)... 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... 🤷‍♂️

Since we decoded the USB instructions to upload firmware (see post 2), from trial and error we can now work out that the "commit" instruction after the end of the "firmware upload" sequence tells it where the upload is for:

  2 - is for the firmware block,
   3 - is for the 'calib data block', and it turns out
   1 - is for the bootloader (😱) - albeit worked out later, see below.

cmd(b"\x77\x13" # 'commit' chunk command
+ bytes([part]) # which 'partition' 1/2/3
+ total.to_bytes(4, "big") # bytes loaded
, dbg=1)

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

I 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 now, what can we do? Easy, I'll just piggy-back it.

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 have 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/fast enough or something.

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. Yeee haw. Desoldered, and inserted into the adapter on the ROM programmer and it now reads. 👍

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. The soldering cycle is getting tedious, and I certainly haven't got a SOIC socket I can use.

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! ah, this is promising.

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 on my "sacrificial hack" capsure, 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. 🤦

Later I add a little "boot override" mini-button into the side to avoid the tweezer necessity or opening the device in future. This might come in handy. (it did, I needed it a couple of times)

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)
but... also..
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

Obama Mic Drop Done Memes - Imgflip

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

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

Next challenge, can we upload a fandeck file directly from Python? (~75% figured out)

Previous updates...

Post1 - JTAGging Post2 - USBing ...

Search

Winging it

Capsure pwned

Capsure Hacking #3

Where's the memory

Flash! A-ah!...

Fake Capsure RM200-QC

Serialz 1.2.3.

Where's the bootloader

SAM-BA!

Pwned

Popular posts from this blog

seven month update

Tracking running Part #2

Capsure RM200 hacking