Argthtjtr

In sedutil-cli a

sedutil-cli --PSIDrevert <password> <device>

"Reset the device to it’s factory defaults using the SID password. If the locking SP is active this command ERASES ALL DATA, requires the SID password" By which I assume it returns all the SIDs to the MSID (manufacturer default, queryable from interface), and creates a new DEK if the locking system was in use. That's the easy one.

My question is do the other revert commands return the given pasword to the MSID? For example:

sedutil-cli --reverttper <password> <device>

Says it 'Reset(s) the device to it’s factory defaults using the SID password. If the locking SP is active this command ERASES ALL DATA, requires the SID password' Does this revert the LockingSP and AdminSP SIDs back to MSID as well, or do they keep their present values. Similarly does:

sedutil-cli --revertLockingSP <password> <device>

just deactivate the locking system (and cryptographically wipe any locked data), or does it wipe the SID/password for the locking SP as well? These would make the jargon make more sense (reverting a system to it's starting state) but that doesn't make it true. Being able to return to a wiped unlocked state with one or two steps given the password would greatly simplify re-provisioning.

By experimentation if I use an installer as a live system and run:

sedutil-cli --revertnoerase oldpassword /dev/sda

sedutil-cli --reverttper oldpassword /dev/sda

It puts the drive into a state where I can run

sedutil-cli --initialsetup newpassword /dev/sda

Since initialsetup wasn't given the old password, the only way this would work is if the SIDs had been reset to the MSID that it could pull from the interface.

However, when running:

sedutil-cli --revertnoerase newpassword /dev/sda

sedutil-cli --activateLockingSP oldpassword /dev/sda

sedutil-cli --activateLockingSP newpassword /dev/sda

Only the second activation works. So --revertnoerase keeps the LockingSP SID and just deactivates it, only working if you know the existing password instead of setting a new one.

So, on a system where the AdminSP SID is known, but the drive is too deeply embedded to get easy physical access, the drive can be reverted using the password.