DiskGenie review - How it works.

Welcome

• Hardware stuff
• Hacks
• Console hacking
• Security
  • DiskGenie review
  • Biosticks review
  • 'Secure' USB-HDs: review
  • Secustick review
  • BioSlimDisk Signature review
• Software
• Nabaztag
• About Spritesmods

How it works.

Let's start at the beginning: what does the hard disk contain? For debugging purposes I've interchanged the 250G HD that came with the enclosure for a 60G I had: if I had to hunt for bytes on the HD it's quicker to look through a smaller HD than a larger one. Exchanging the HDs was a breeze: insert the new HD, reset the device to the default pincode and it's usable. After that, I took out the drive again and put it in a normal, unencrypted SATA-to-USB-converter. One thing immediately jumped out on me: while the unencrypted converter showed me the 'true' size of 60G, the enclosure told me the HD was about 700M smaller:

In enclosure: 
spritesws kernel: sd 83:0:0:0: [sda] 115776576 512-byte logical blocks: (59.2 GB/55.2 GiB)
In unencrypted sata-to-usb-converter:
spritesws kernel: sd 84:0:0:0: [sda] 117210240 512-byte logical blocks: (60.0 GB/55.8 GiB)

What could be hidden in these bytes the controller stole away? Not much: there's about 700 bytes that actually get set. A quick search on the Internet reveals the controller is also used for drives without a hardware keypad: the controller is able to show a second, unprotected HD with the software used to enter the pincode in that case. It's probable that in that scenario, the 700M would contain the unprotected data and the few bytes that were changed by the firmware would be stuff like the parameters like retry count etc. In my opinion, it's a bit sloppy they left this 'feature' in the firmware of the INIC: the user basically can't access 700M of his HD this way.

In this case, the designers probably tore out the bit that received the password from the PC and replaced it by a routine that reads a password from the PIC. So, what would that password be? Sniffing the lines between the PIC and the INIC reveals that the communication happens over SPI, a fairly simple serial protocol. When the password entered on the PIC is correct, it sends a burst of data to the INIC, which then makes the HD accessible. The unlock command looks like this:

- 00 78 80 00 00 4B C4 A9 26 B3 86 67 D3 62 05 74 
  AD 61 70 8D 7A 7F FF FF FF FF FF FF FF FF FF FF 
  FF FF FF FF FF 
- 80 00 00 00 00 00 00 00

There's 16 bytes of seemingly random data inthere: resetting the drive to it's default settings makes these 16 bytes change. Strangely, changing the password doesn't change this sequence. From all this info (and a bit of experience with these kinds of encryption chips) we can guess what happens when a hard disk is used:

Hard disk full reset:

• The PIC resets the user-password to 123456
• The PIC generates a random key to send to the INIC-chip
• The INIC generates a random key to encrypt the HD with. It then encrypts that key with the key sent by the PIC, and writes the encrypted HD-key to the 'hidden' bit of the HD.

Hard disk unlocking:

• The user enters the password
• The PIC checks the password. If correct, it sends the INIC the random INIC-ky it generated before.
• The INIC uses the key received from the PIC to decrypt the HD-key, and checks if the decryption worked OK.
• The INIC uses the HD-key to decrypt the hard disk
• The user sees its data.

As a final check, I did the full-reset procedure on two different HDs. If the text above is correct, on entering the password the PIC should accept the pincode offered but should send the password for the last initialized HD to the INIC. If the first HD would happen to be in the enclosure, the INIC then wouldn't be able to decrypt its HD-key and refuse to work. That's exactly what happened: when I entered the password, the PIC seemed happy and lit it's green LED, but the HD wouldn't show up on my PC.

« Prev 3 Next »