Failing to unlock non-boot drive after reboot.

Hi,

I have Crucial MX100 SSD drive that's attached to a win7 computer via a SATA-USB3 adapter. the MX100 drive is OPAL2 compliant and therefore supports hardware encryption.

What I'd like to do is turn drive hardware encryption on and unlock the drive (using sedutil-cli.exe) after it's attached to (any) host computer that's already booted so I can read and write to it. When the drive is disconnected or the computer is rebooted the drive will then automatically lock. The drive will be used on different computers. I'm using the Feb 2022 version of sedutil-cli.exe (there's no file version info available under 'properties' in Windows for some reason).

I can enable drive locking using sedutil-cli.exe (command output below), read and write to the drive up until I reboot the computer. After that, Windows Disk Manager reports the drive as being un-initialised, and there's no drive letter mapped in Explorer. You'd expect this as the drive must be unlocked after a power cycle. So I enter the command below to unlock it (console with admin rights) but the drive still shows as un-initialised, even after 'Rescan Disks' and 'Refresh' in Disk Manager. Attempting to re- initialise the drive just hangs Disk Manager. The only way to get the drive back to a useable state is to run sedutil-cli.exe --PSIDrevert using the code written on the drive label, then reboot. The drive is then empty, data deleted.

sedutil-cli.exe --setLockingRange 0 rw password1 \.\PhysicalDrive1

There is an exact thread on this problem here but I don't see what I'm doing incorrectly.

https://github.com/Drive-Trust-Alliance/sedutil/issues/237

Is it possible to use a portable USB hard drive in the manner I'm describing? It would be nice to use the inbuilt hardware encryption. OS level encryption is so slow. I realise I'd have to carry a copy of sedutil-cli.exe around on another drive, or download it from Github. Fine with that. I'd also need Admin rights on the host computer to run the unlocking command, which would be an issue with computers that I don't own. That's a windows restriction. No way round that one.

Here are the commands I'm running and output.

C:\Windows\system32>C:_UserData\SoftwareArchive\sedutil-cli.exe --scan

Scanning for Opal compliant disks \.\PhysicalDrive0 12 SAMSUNG MZ7TD256HAFV-000L7 DXT04L6Q \.\PhysicalDrive1 2 Crucial_CT512MX100SSD1 MU01 No more disks present ending scan

C:\Windows\system32>C:_UserData\SoftwareArchive\sedutil-cli.exe --isvalidsed \.\PhysicalDrive1 \.\PhysicalDrive1 SED -2----- Crucial_CT512MX100SSD1 MU01

C:\Windows\system32>C:_UserData\SoftwareArchive\sedutil-cli.exe --query \.\PhysicalDrive1

\.\PhysicalDrive1 USB Crucial_CT512MX100SSD1 MU01 14200C224363 TPer function (0x0001) ACKNAK = N, ASYNC = N. BufferManagement = N, comIDManagement = N, Streaming = Y, SYNC = Y Locking function (0x0002) Locked = N, LockingEnabled = Y, LockingSupported = Y, MBRDone = N, MBREnabled = N, MBRAbsent = N, MediaEncrypt = Y Geometry function (0x0003) Align = Y, Alignment Granularity = 8 (4096), Logical Block size = 512, Lowest Aligned LBA = 0 SingleUser function (0x0201) ALL = Y, ANY = N, Policy = N, Locking Objects = 9 DataStore function (0x0202) Max Tables = 9, Max Size Tables = 94371840, Table size alignment = 1 OPAL 2.0 function (0x0203) Base comID = 0x1000, Initial PIN = 0x00, Reverted PIN = 0x00, comIDs = 1 Locking Admins = 4, Locking Users = 9, Range Crossing = N [Remaining output deleted]

C:\Windows\system32>C:_UserData\SoftwareArchive\sedutil-cli.exe --initialsetup password1 \.\PhysicalDrive1 method status code NOT_AUTHORIZED Session start failed rc = 1 EndSession Failed takeOwnership failed Initial setup failed - unable to take ownership

C:\Windows\system32>C:_UserData\SoftwareArchive\sedutil-cli.exe --PSIDrevert 527940C45C294B91E200000049C985EC \.\PhysicalDrive1 revertTper completed successfully

C:\Windows\system32>C:_UserData\SoftwareArchive\sedutil-cli.exe --initialsetup password1 \.\PhysicalDrive1 SID password changed takeOwnership complete Locking SP Activate Complete LockingRange0 disabled LockingRange0 set to RW MBRDone set on MBREnable set on Initial setup of TPer complete on \.\PhysicalDrive1

C:\Windows\system32>C:_UserData\SoftwareArchive\sedutil-cli.exe --EnableLockingRange 0 password1 \.\PhysicalDrive1

LockingRange0 enabled ReadLocking,WriteLocking

[Drive is now locked but still accessible - read and write from explorer.] [Cycle power on device.] [To unlock the drive enter the command below.]

C:_UserData\SoftwareArchive\sedutil-cli.exe --setLockingRange 0 rw password1 \.\PhysicalDrive1

LockingRange0 set to RW

[Microsoft Disk Manager shows disk as Unallocated, even after a rescan & refresh command.] [Cannot read or write to drive] [Rebooting doesn't change the drive status]

Thanks.

After doing the sedutil-cli --initialsetup password1 .\PhysicalDrive1 You should do also the following: sedutil-cli --setMBREnable OFF password1 .\PhysicalDrive1 in addition to sedutil-cli --enableLockingRange 0 password1 .\PhysicalDrive1 because the initialsetup subcommand sets the MBREnable to ON. It does also the MBRdone = ON, so you can access the data just after the first part (before the power cycle to the device). After the device is powered back, your data part is shadowed, and you didn't load anything to the shadow mbr part (no pba image was loaded). If you will keep the MBREnable = ON, as you are doing now, after the power cycle you will have to do: sedutil-cli --setMBRDone ON password1 .\PhysicalDrive1 in addition to: sedutil-cli.exe --setLockingRange 0 rw password1 .\PhysicalDrive1 because after the power cycle the MBRDone flag is OFF, which means the real data part of your device is still shadowed by the shadow mbr part, that contains nothing because the pba image wasn't loaded. So, the simpler way is to switch the MBR Enable to off, then the MBRdone flag does not matter, and the power cycle does not replace the disk real data part by the shadow mbr part. Good luck.

Hello JaBoMa,

I tried adding the MBREnable OFF command, and it worked... sort of.

sedutil-cli.exe --initialsetup password1 \.\PhysicalDrive1 sedutil-cli.exe --setMBREnable OFF password1 \.\PhysicalDrive1 sedutil-cli.exe --EnableLockingRange 0 password1 \.\PhysicalDrive1

At this point I could still read and write to the drive. On rebooting however, the OS (Win7) hung at the 'Starting Windows' screen for about 3 minutes. After logging in, Starting Microsoft Disk Manager took about 5 minutes to start, at which point the disk didn't even show up. Doing a disk rescan took about another 5 minutes at which point the disk showed up and I was prompted to re- initialise the disk. At this point sedutil-cli.exe could finally 'see' the disk using the --scan switch, and running the command below as Admin unlocked it. Performing another disk re-scan in disk manager got the disk to show up as an NTFS partitioned drive and I could access it via explorer.

sedutil-cli.exe --setLockingRange 0 rw password1 \.\PhysicalDrive1

There's something that Winodws doesn't like about a locked disk as the OS is loading / has loaded. I get the feeling that the Virtual Disk Service is just timing out, hence the delay on booting and disk manager. I can see why sedutil runs from a pre executable environment (PXE) to unlock OPAL disks before the OS boots now.

Not really an option for me and my use case. I'd have to reboot every computer I want to use this drive with to unlock it. And that's only an option if secure boot is turned off in the BIOS (it's not on many modern computers). Also means saving work, closing applications, local Admin rights... a lot of messing about. I'll have to search for another encryption method.

Thanks for the reply anyway.

Finally got this to work - reliably.

I stumbled across a PDF document on OPAL drives written by Johns Hopkins Applied Physics Lab for the TCG. A Practical Guide to Use of Opal Drives - Trusted Computing Group. Link below. It's written for those who are new to encrypted drives and want to know more about actual implementation. More practical than theoretical. Worth a read. Written for OPAL disk users.

http://develop.trustedcomputinggroup.org/wp-content/uploads/2019/05/Opal_Drive_Guide_v1_Final_20190515.pdf

The hanging issue I reported above occurred because Windows doesn't like drives it cannot write to, unless they're marked as read only to begin with. The issue is noted in the above paper. One solution is to enable the shadow MBR - which I originally did do, but that stops disk manager from seeing changes made to the drive after you unlock it, even if you re-scan all drives (for some reason). The solution to that is to disable the shadow MBR after you've unlocked the drive, then re-scan all drives to get windows to see the disk as a writeable HDD. Then you have to turn the shadow MBR back on again, so the OS won't hang the next time it boots.

Here are the commands that worked for me. Non-bootable OPAL HDD w/encryption hanging off a USB3 - SATA controller. All commands run from a CMD shell with admin rights. Already booted into Windows 7 x64. If you're logged in as non-Admin, right click on the CMD icon and select 'Run As Administrator. To encrypt the (non-boot) 2nd drive:

[1] sedutil-cli.exe --initialsetup password1 \.\PhysicalDrive1 [2] sedutil-cli.exe --EnableLockingRange 0 password1 \.\PhysicalDrive1

I'm using password1 as the super secret password to lock the drive - make this harder to guess... I'm locking PhysicalDrive1 as sedutil-cli.exe reports this as my Crucial MX100 OPAL drive. If you have more drives installed your HDD may have a different assignment. Use sedutil-cli.exe --scan to list all drives first. I received a NOT_AUTHORISED message after running the first command (--initialsetup) and had to revert the drive back to manufacturer spec. This wiped all data on the drive. I only got this error on first use of --initialsetup. All future uses went through without problem (you should only need to enable locking once though unless you repurpose the drive). The PSID string was found on the drive label. Remember to use ALL CAPITAL LETTERS and not enter any dashes ("-").

sedutil-cli.exe --PSIDrevert 537840C44C294B91E100000089C981EC \.\PhysicalDrive1

Partition and format the HDD in disk manager, as required (you'll lose all data on the drive) if that's not already the case. Then you'll see it in Explorer as a drive letter.

After a reboot (power cycle) the drive appears as un-initialised to Windows if you care to fire up disk manager (not required). To unlock the drive (from a CMD shell with admin rights..):

[3] sedutil-cli.exe --setLockingRange 0 rw password1 \.\PhysicalDrive1 [4] sedutil-cli.exe --setMBREnable OFF password1 \.\PhysicalDrive1 [5] Echo Rescan | Diskpart [6] sedutil-cli.exe --setMBREnable ON password1 \.\PhysicalDrive1

The drive should then show up in explorer as a drive letter (assuming you partitioned and formatted it as noted above before the reboot). I've tried unlocking the drive on a different computer using commands 3,4,5,6 and it works, but you'll need a copy of sedutil-cli.exe on the new computer and MSVCP140.dll which it relies on (part of the Microsoft Visual C++ Redistributable package for Visual C++ 2015 - free download). Remember that the drive may no longer be PhysicalDrive1 on the new computer..it depends on how many drives the new computer has installed, so be prepared to edit the above command lines. The same applies on your existing computer if you add a USB flash drive. It changes the PhysicalDrive numbers reported by sedutil-cli.exe --scan.

I've written a CMD script that prompts for all of the above to save script edits. If anyone wants it, just ask.

Drive-Trust-Alliance / sedutil

Failing to unlock non-boot drive after reboot. #390