Password change functions cause INVALID_PARAMETER with -n -h

[Tronic]

Trying to use the password hash to change SID and Admin1 passwords to plain text passwords (for compatibility with other tools), I get INVALID_PARAMETER. Apparently the password change functions somehow mishandle the hex hash mode. The hex hash works fine with other commands.

I solved this issue by hacking the source code to skip hashing of the new password, and then using the plain password as both old and new password on command line input. Notably the SID password change function already had support for skipping the hash, while the Admin1 change function always hashes the new password.

It would be good to have a separate option to specify which (or no) hashing to use with the new password, while allowing a different choice for the old password. Otherwise migration between different tools is extremely difficult if not impossible, without losing data anyway. I observe at least four different choices in use:

• Plain text (UEFI firmware Opal unlocking prompt)
• SHA-1 75000 iterations (original sedutil)
• SHA-512 75000 iterations (ladar fork)
• SHA-512 500000 iterations (ChubbyAnt fork)

[ladar]

@Tronic can you submit a pull request which adds these features? I agree, it would be nice if distros could ship, and a single CLI tool could handle working with different drives that use different PBA implementations. One idea I had was to have the code attempt all of the different possibilities where appropriate - for example with unlock attempts. In my opinion the slight increase in processing time is a feature, because it would mean anyone considering a brute force attack would have that many more permutations to consider. And in the same vein, adding the ability for a uer to set config/command line options for operations where the bulk strategy doesn't make sense.

I considered implementing something along these lines when I forked the code. I wanted the code to at least work with drives setup/using the original sedutil implementation, but ended up spending all the time I could afford trying to fix the screen resolution problem. And was worried that if I made a haphazard attempt, it would only lead to code which, if used improperly, could make disks permanently unreadable. And I definitely don't make it easy for someone to accidentally lose all their data because they used conflicting options/parameters without realizing the implications.

[Tronic]

@ladar Not likely, would need to dig into the code again (having forgotten all of it by now). Trying multiple options is risky because it easily locks the drive (you can only attempt a few passwords and then have to power cycle). I would rather see all tools end up with the same hashing, or at least with less than four different options.

Also, I recall not being able to unlock with UEFI prompt even with the plain text password, so no idea what that might require.

[ladar]

@Tronic I understand the issue with forgetting, as I have it too. But in terms of trying all the different possibilities, you shouldn't have to worry about a power cycle. Shutting down after three invalid attempts was actually something I added to the code. The original DTA version let you make as try and many times as you wanted. So having the code submit multiple values to a drive for each plaintext password entered by a user shouldn't create any new problems.

All a change like should mean is that whenever a user fat fingers a password, they'll have to wait slightly longer to try again. But even that this extra delay shouldn't be an issue, at least when it comes to supporting the DTA PBA, because the original code key derivation logic only used a few hash (I think it was 8) rounds, which any computer built in the past 10+ years can process instantaneously (by human time standards).

As for being able to unlock using the BIOS, I'm just guessing here, but it's you the drive in question followed the OPAL v1.0 standard. The original strategy worked this way, and (I think) most SATA drives with OPAL support use SATA commands to provide the password and unlock a drive. Of course NVME drives, and other types of post-SATA storage, don't use the SATA protocol, which is where OPAL 2.0 comes in. The new spec, paraphrased to the extreme, sets up the strategy used by PBA, where a user can load any bootable image they want, which then gets loaded by a locked drive, and can use any logic it wants to provide the unlock key the OPAL. If it works, the PBA partition disappears, and the encrypted storage/partitions are accessible. At this point the PBA can chainload, aka directly boot using one of the newly accessible partitions, or it can reboot, and boot normally using the MBR on the unlocked drive (instead of the MBR used by the PBA storage area. .

It's a geat idea, in theory, and opens up lots of opportunities for private companies to create PBAs with features that big enterprises need, like remote unlock/wipe supportk and auditing that were impossible with the original OPAL standard. But these same choices have pushed OPAL, and its benefits to a realm which is beyond the reach of most muggles.