(NOTE: see update: cracked it in a 2nd attempt for more progress)
Last week (during the roundup of my thesis), my beautiful HP Probook 5310M decided to limit its usability by presenting me with a nice bios-screen, asking for my password.. I must have tried 1000.000 million passwords but of course, not the right one. My guess is that it became somehow corrupted. After just one year and 3 months, HP gave me the finger in terms of guarantee. So I had to give up and throw it in the corner of my room. I picked up my old lapop (A MSI) wich by the way is almost bullet proof, and reinstalled it to continue my thesis.
This weekend I had handed in my final version and could start trying to revive my beloved stylish Probook. I went to a friend and started unscrewing the thing,
I had ordered a Pirated Pirate-bus sniffer, basically a easy way to sniff various interaces and bus systems, beceause it was on the dubble-cheap, I had to solder the probes to it myself.
As one may or may not know, most bios chips are simple flash devices (kind of memory chips). Generally speaking, most of them utilize one of the two bus systems, I2C/two wire interface (interface 2 IC) or SPI (Serial PeripheralInterface). The buspriate can handle many bus interfaces including those two.
After completely having disabled my laptop
it was time time to hook the Pirate to the bios chip:
After all was connected we began our first experience with the bus-pirate:
Everything was working properly as the tool ‘Flashrom‘ Could recognize our chip as being a “MX25L1605”
Unfortunatly when we tried to read it using the commando:
“flashrom.exe -r dump.bin -p buspirate_spi:dev=com4” it took forever to complete. After enabling verbosity by adding parameter “-VVV” We saw a lot of errors passing by.
So this tool was not going to work 🙁 We head to reverse to using the terminal and entering commands for our self).
The data sheet of our bios chip had leared us that we could ask for the chip’s ID. To do so, we send this command after configuring the buspirate, to read the chip
[0x9f r:3] this commands send 0x9F and reads 3 bytes out of the SIO
in order to read the data-pages of the SPI-flash we started off with
[0x03 0x00 0x00 0x00 f:2048] this *should* read the first datablock, however the flash returns just 0x00’s
Refraining to the datasheet, I think HP put some encryption key’s in place in order to prevent us from dumping the flash :(.
to be continued..