EC firmware dumped

A project log for Reverse engineering Toshiba R100 BIOS

We are reverse engineering the BIOS and EC firmware of an old laptop in order to create a keygen for their password recovery mechanism.

q3kq3k 01/04/2017 at 00:293 Comments

After another long hiatus, I've come back to this project. Let's break this thing!

I've etched a new board that lets me access important pins (serial TX, RX, CLK, BUSY ; RST and power lines) without having to fiddle with the previous hacky breakout board.

New breakout board.

I've then attached an STM32F303RE on a Nucleo board as a general interface board to the EC's serial and reset. I also attached a ChipWhisperer with a shunt sensor board to the EC's power line. And finally, I added an oscilloscope to the voltage shunt and a logic analyzer to serial lines, for good measure.

Final attack rig.

After checking connectivity to the bootrom and that I was getting power traces, it was time to dive in.

The EC has a 7-byte ID code that it keeps in flash. This code is used by the built-in bootrom to allow/deny access to the flash via the 'Standard Serial I/O' protocol for programming (selectable via M0/M1 straps). If the programmer does not provide the code, no flash dump/write access is allowed.

Location of ID Check bytes in flash.

The serial protocol is synchronous. The clock comes from the programmer, and the EC exposes a Busy line used to synchronize whether its' ready to receive commands.

Stanard Serial I/O protocol description.

To unlock the flash, the programmer sends 12 bytes: a command prefix (0xF5), the address of the ID code (?, 0x0FFFDF), the length of the ID code (?! 7) and 7 bytes of ID code.

After the programmer sends the ID code check function, another command (0x70) can be used to check whether the ID code verification succeeded.

I at first tried power trace side-channel analysis attack (since I had a ChipWhisperer laying around gathering dust) when the bootloader checks the password, but my makeshift shunt probe was just too noisy.

Makeshift shunt probe. With free ground loops for extra noise!

So, before having to redesign the makeshift probe into something more useful, I figured it might be easier to try a simpler timing attack first. I quickly made the STM32 measure the time between the last bit of the code sent and the time until the busy line got deasserted again (which takes quite a bunch of cycles after the last ID byte received, hmm). Just looking at the data directly didn't make me optimistic, as all the results were jittery at first glance. However, I sent over the data (50 measurements per first byte, iterating over 256 values) to Redford. To my surprise he was able to find an outlying byte - 0xFF!

Average time (in US, vertical) per byte (0-255, horizontal).

After running the measurements a few more times, we were quite sure that the timing was indeed different when the first byte of the key is 0xFF. I then disconnected the EC from its' 16MHz crystal to a signal generator, which I clocked down to a 666KHz square wave. With the chip now running slowly, I was able to quickly discern the time difference when measuring the time-until-not-busy for each possible byte of the key:

Timing differences when handling different bytes, with a downclocked controller.

After bruteforcing the rest of the bytes, one at a time, I was able to find out the key: 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0xFF, 0x00.

How anticlimactic. But yes, after making my STM read bytes from the EC reliably, we now have a flash dump of the EC.

Sample bytes of the dumped firmware.

That was easy. Now, onto reverse-engineering M16C code.


mister.isckanderov2013 wrote 09/29/2022 at 22:48 point

Hello! great article, please share the code, there is the same MCU.  mail

  Are you sure? yes | no

KINDERBueno wrote 09/17/2022 at 13:18 point

Can u share this mec dump ? i need for my dead R100.

  Are you sure? yes | no

aniello wrote 01/03/2021 at 13:29 point

really interesting

  Are you sure? yes | no