We have acquired a bunch of BIOS locked Toshiba Portege R100 laptops. Since they are enterprisey laptops, we cannot just reset their password by unplugging the CMOS battery. The aim is to uderstand the laptop boot process better, with an immediate goal of writing a keygen for its' challenge/response mechanism, allowing us to actually boot them and use them as a lightweight Internet access platform. As a long-term goal we're thinking of porting Coreboot to them.
We have so far dumped the BIOS from the FWH memory on board, reverse engineered it enough to find out it uses the EC (a Renesas M306K9FCLRP 16-bit micro) in order to check the password and password reset response. After procrastinating for a couple of years we now have the flash dump of the EC, which we are now reverse-engineering. Project Logs. at 00:29. 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.
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. 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. 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.
Pc serial number =66055521H challenge code = 9TWMD-T6R3W-YWREC-EPAW6-MUETW RESPONSE CODE = i had a disgruntled - Answered by a verified Tech Support Specialist.
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. 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!
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: 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. That was easy. Now, onto reverse-engineering M16C code.
at 21:23. Some progress has been made the past few days on the actual Renesas EC chip. A detailed log will probably follow in the upcoming few days, once I get the chance to take a few pictures and screenshots.
In 2014 I etched a PCB to mount the EC on after desoldering it from the mobo. I know this, because it says 'q3k delineavit 2014'.
It is now 2016, and I finally managed to hook it up to a bus pirate and issue it a few Standard Serial I/O commands. As predicted, though - it is locked. However, the next step is to use my shiny new ChipWhisperer to take a snap a few powertraces while we feed it data. First things first, I will have to figure out how to make the chipwhisperer talk this weird synchronous-UART protocol that the EC bootrom uses. By the way, the chip is a Renesas M306K9FCLRP. at 09:25.
Redford did a whole lotta work reverse engineering the BIOS code and figured out that most of the interesting stuff (password check, challenge/response for lost password) is actually done by something off the main x86 processor. We figured out that it's probably the EC/KBC (Embedded/Keyboard Controller) which we found earlier on the laptop mainboard. The controller is a generic microcontroller, with a bit of a twist - it's a pretty obscure one. It's labeled as a TMP87PH48, which is a programmable version of the TMP87CH48. Never heard of it? As it turns out, it's based off the “TLCS-870' architecture, which is kind of like-ish to a weird Z80. We quickly skimmed through some specs we found for the CPU core itself, decided that it's probably powerful enough to run password verification code, and started figuring out what to do next.
Usually, the CH48 model is a mask-ROM model. Thankfully, our laptop shipped with the PH version, which is one-time programmable by the user. And, thanks to that, it actually contains a programming and verification interface. As it turns out, if you pull one of its' pins low, it can be treated as a generic PROM chip. This means we can read out the code from the chip just by asserting a 15-bit address on a port and reading out 8 bits of data on another port. Since I didn't have an oldschool (EE)PROM programmer on hand, I quickly hacked together my own, the result of which can be seen in the picture at the beginning of this article - most of the jumper cables are address and data lines, some are just used to strap other pins to +5V and GND (a requirement from the chip datasheet). The home-etched board contains the EC from the laptop, soldered out with a Hot Air gun, then soldered into the board.
The design of this (generic) board was done in KiCAD. The programmer/reader interface is very basic - just a Spartan6 FPGA with a bit of Verilog to receive an address (one byte, then multiplied by 0xFF) over UART from a PC, then reply with 256 bytes of data read from the EC starting from the requested address. The code is available. A quick and dirty Python script dumped all 32kbytes of memory a few times to check for read errors. The code could've easily be written for a microcontroller with a lot of I/O pins (or with a I/O multiplexer) - I just had an FPGA on me, so that's what I chose.
And, of course, a cheap EEPROM programmer would also do the job. And then, after all of this, we saw dumps.
Bitflipped, but statistical analysis will help us with this. As far as I know, Redford has already combined 16 read passes into one file which shows a high likelyhood of 100% accuracy. Now for more reverse engineering. We still don't know where the actual password is stored - this uC does not have any nonvolatile memory. Enjoy this project?
Share Discussions. Hi, This might not be relevant if the full port replicator doesn't have a parallel port, but. So, back in the day, I used to support a lot of Toshiba laptops for users which were, erm, prone to forgetting their passwords often enough.
There was a parallel port dongle that I hacked together off of an ASCII art diagram found somewhere on the internet. It worked across all of the models we came across. The dongle was nothing more than a bunch of wires that connected a few inputs to a few outputs on the port, and the BIOS checks this upon startup. Has anyone tried this? I'd say it stands a decent chance of working. I don't remember the original source where we found this information, but the first google match reveals this page: 'To make it you will need a 25 pin DB25 plug, take the plug apart and join these pins using some old cable;Pins: 1-5-10, 2-11, 3-17, 4-12, 6-16, 7-13, 8-14, 9-15, and 18-25' Seriously, this worked like a charm back in the day.
Are you sure?. This system is almost certainly using an ASM based legacy BIOS. Could you no-op out the failure to match path to get the BIOS to execute the success path? Do you have any idea how the EC communicated to the host? Is it SMBUS, LPC, or something else? There may be a password reset or manufacturing defaults jumper that can clear passwords somewhere on the board. If you know how the BIOS communicates with the EC, you may be able to locate the PW clear routine and trace it back to the GPIO used on the ICH4.
Toshiba Challenge Code Keygen Music 2016
Then you can trace the physical pin to a land or test point on the board (hopefully). That's just my 2 cents. All my experience is communicating with BMCs on servers from the BIOS. Mobile systems and their ECs are a mystery to me:( Are you sure?.
We want to leave the BIOS as-is, unpatched - especially as we have more of these laptops and we don't want to have to modify every one of them. The EC hangs off the LPC bus. Redford has some extra info on the protocol used, but IIRC the C/R was fully deferred to the EC. The reset-pin-from-password-routine method is interesting, we didn't think about it. However, would a manufacturer leave this when a C/R setup is already present and provides the same functionality for service people? Anyway, we have the EC dump now so we should be able to make more progress:). Are you sure?.
Almost all my experience is with servers so this information may not be relevant to your problem. On some systems, a GPIO would be used to sense a pull up or down as the signal to reset a user password. Even if the jumper was not populated, the BIOS would still check the GPIO on every boot. At least that's the case with older systems. I was thinking you might be able to get a dump of the bios code and see if it is checking a GPIO being used as a PW clear signal. But is is possible the jumper could have been tied to the EC. I would suspect the signal is still there but would require schematics to find without a massive RE effort.
It seems like that is what you are doing:) Are you sure?. Interesting project, I have worked in a couple of Toshiba laptops that use this Challenge/Response (C/R) as a way to reset system password.
Apparently the Admin and User Passwords are stored in the Flash chip, and most likely a backup is also stored on one of the EEPROM memories close to the EC/KBC. In a Toshiba that uses the C/R algorithm there are usually 2 eeproms, a 24C02 and a 24C08, being the 24C08 (1kB) where the password is also stored in my experience. Not too long ago read some information at webpage regarding one of the eeproms: 5.
Modify the data read out. Write FF to address 0x10-0x17 and 0x20-0x27 (to remove the User Password); write FF to address 0x28-02F and 0x38-0x3F (to remove Administrator Password), then update the data to the EEPROM.This worked for me halfway, I was able to remove and set a new User Password in a Toshiba Satellite U200/U205, but whatever change I made to try to clear Supervisor Password (set eeprom area where Admin password is stored to 00's or FF's), it always returned to their original values, so that's why I guess a copy of this password is stored in bios chip as a backup.
If you have many locked Toshiba R100's, I would get an unlocked Toshiba R100 computer and make a copy of bios chip and eeproms, then use these dumps in one of the locked computers to reprogram the bios TSOP chip and eeproms, I think it may work, otherwise there's no reason for Toshiba to protect their bios updates for these computers that use the C/R algorithm. What these bios updates have in common is that they have a.COM file extension, it's compressed and is not an executable. Also some time ago found some other information in regarding Toshiba portable computers that use the C/R algorithm: 'Current models use Challenge method: at password prompt, press keys one by one: CTRL, TAB, CTRL, ENTER.
Computer will respond with PC Serial number and Challenge code. You have to respond with Response code. Challenge method have at least 3 modifications. 1) for laptops like Qosmio F10, all algorithm located inside BIOS except one calculation on the other side. 2) for laptops like Tecra M4, core of algorithm hidden inside of EC/KBC chip with encrypted firmware. 3) the same laptops but with corrupted eeprom contents which connected to EC/KBC.
Good luck with the project, I'm looking forward for any progress. Are you sure?.