My Passport Initio INIC-1607E thinks password is set when not using any password.

[jgan96]

I tried to decrypt a My Passport with the Initio INIC-1607E chip but it keeps asking for a password. I verified in the SA of the drive that no password is set.

Let me know if you want any of the SA modules.

[andlabs]

Hmm.. I'll have to remember which modules had which data I needed. Could you dump the last sector in the meantime? I wonder if we have finally found a drive that uses the 128-bit default key instead of the 256-bit one...

[jgan96]

dev3_lba976773167_1.zip

Seems to be empty, do you want the last full sector?

[andlabs]

Yes, that's what I meant. reallymine can do it with the dumplast command; if you already did that, you can use the --disk-size option (before dumplast) to tell reallymine to continue the search.

[jgan96]

last_sector.zip

[andlabs]

That isn't the key sector; keep searching. Most of its bytes are 0 :/

[jgan96]

I dumped that using dumplast. This I got from DMDE; it's the last full and then consecutive last partially full.

last_sectors.zip

[jgan96]

Ok, I used decryptkeysector with the 128-bit key and here is what I got:

$ sudo $GOPATH/bin/reallymine decryptkeysector /dev/sda decryptedkey.bin 03141592653589792B992DDFA23249D6 sector at 0x7470A01000 bridge type Initio

decryptedkeysector.zip

[andlabs]

Yep, so this is likely an AES-128 based drive. Glad to know these actually do exist! :D We can continue going from here.

In the meantime, when I mentioned the --disk-size option, you could take the sector at value and pass it back to reallymine to continue the search from there; for example, reallymine --disk-size 0x7470A01000 dumplast. I'm not sure why I didn't put this in the README; did I?...

[jgan96]

Do you need me to run dumplast again?

[andlabs]

No, I was just clarifying what I meant earlier. I'll be able to look at this file over the weekend.

[jgan96]

Did you ever manage to look into this issue?

[andlabs]

Okay sorry, I only managed to get a chance to look now.

The file you decrypted and the file you got with DMDE is still the ones with all-zeroes, which is very strange... Unless

406d 6f76 4cbe 9146 ac83 f776 6848 5d62

is itself the key. I wouldn't know, though. (You can find out by using dumpfirst and then the decryptfile subcommand and the Initio pattern swaplongs decrypt swaplongs.)

I should probably make a dumplast which is like dumpfirst that just dumps the last N sectors from the drive as one continuous block. In the meantime, can you run this?

sudo $GOPATH/bin/reallymine decryptkeysector -disk-size 0x7470A01000 /dev/sda decryptedkey.bin 03141592653589792B992DDFA23249D6

[jgan96]

It didn't let me use the -disk-size arg, but here it is without.

decryptedkey.zip

[jgan96]

I also tried to decrypt the first two sectors using sudo $GOPATH/bin/reallymine decryptfile '/media/middle/UNIVERSE/17297 antonio garrett/dev4_lba0_2.bin' decryptmbr.bin '406d6f764cbe9146ac83f77668485d62' 'swaplongs decrypt swaplongs' but there was still no partition table.

[themaddoctor]

can you send the encrypted MBR? use "dumpfirst", I think. or dd if=/dev/sdX count=1 of=start.bin where X is the correct letter for the WD drive

[themaddoctor]

406d6f764cbe9146ac83f77668485d62 cannot clearly be the key. It's what you get when you 'decrypt' all zeroes.

[themaddoctor]

Also, that thing called last_sectors is not encrypted, and not a keyblock. Is this a drive where the encryption chip is on the same PCB as the disk controller, and not a removable board?

[andlabs]

That's that same invalid last sector again. Perhaps this is one situation where we have to use the VSCs?... Only other suggestion I can make is to dump the last 50 or so MB and upload it somewhere...

[themaddoctor]

It's also possible that this one doesn't use encryption, but only a password lock.

How do we know it has an Initio chip? Did jgan96 disassemble it?

This command in linux will list the encryption modes supported by the device (change "sdf" to the one matching the drive) (the drive must be in the original enclosure): sg_raw -r 1k /dev/sdf c0 45 00 00 00 00 00 30

The results look like this:

Received 18 bytes of data: 45 00 00 00 20 00 00 20 30 f4 f0 3e 00 00 00 02 E... .. 0..>.... 10 20 .

Byte 15 (starting from 0) is the number of modes (here 2). The following bytes are the supported modes. Here, it supports 10 = AES 128 ECB and 20 = AES 256 ECB. Other possibilities are in table 3 in the "got HW crypto?" paper.

What troubles me is how did he get "last_sectors", which is not encrypted, unless either the drive is not encrypted, or he is using the Initio USB bridge and it is not locking him out? jgan96, if you are listening, is your drive in the original enclosure? Does the USB bridge come off? If so, have you put it into a new enclosure (or into a desktop)? Exactly where was the disk when you dumped "last_sectors"? Can you also dump the first few sectors and send them?

[themaddoctor]

Or maybe its the tail end of the VCD. But my VCD doesn't contain "ChineseContextMenu".