Multiple improvements

[lexx9999]

Hi Gugli,

not sure if you're interested or not.. I made a couple of changes/improvements:

• Auto unlock on connect / on db open is default off (fixes This plugin badly misbehaves #10)
• Only try to unlock drives that exist on the system
• Prefer volume name over volume letter (security)
• Enumerate volumes (incl. drive letters, name, encryption status)
• Queue unlock in one thread instead of multiple parallel threads
• Reset KeeLocker settings
• .editorconfig added
• MIT license
• Improve custom drawn combobox
• Improved status on unlock (status label and title change for auto unlock)
• Remove the network path option since BitLocker drives must be directly connected
• Updated docs
• Use correct password if password was edited (also fill KeeLocker only when activated)

Source can be found here:
https://github.com/lexx9999/KeeLocker

If you're interested I'm going to create a PR, just let me know.

Possible improvement: Collapse the 3 comboboxes into a single one ( decide guid/letter based on regex )

And I also have a question:
During the API research did you figure out where to get the ID which is displayed for the recovery key identification?
(Which is the first part of the UUID displayed when creating the recovery key but not part of the volume guid itself)

[Gugli]

Nice work !

Since Keepass, and its plugins are pretty sensitive, I will have to review each change, and that will take some time.
I may reimplement certain features from scratch.
I may go even further the "use IDs not drive letters" direction. I will keep asc. compatibility, but the more I think about it, the less it seems useful to keep the drive letter option in the entry.
It seems much easier to enumerate drives it the entry-settings tab, as you did, (and show the drive letter and drive name for user-friendlyness), but only store the drive ID. No combo box or button to convert.
I can't find any valid use cases for keeping the option to match the drive by drive-letter.

Concerning the reverse-engineering of the API : I don't think I found anything about this. What I did is I breakpointed in "Win10 small white msgbox asking for the passphrase" and noted the syscalls for each case. I don't think this window can display the recovery-key ID.
The only way I remember seeing this ID is when creating the bitlocker drive, (or when bootdisk is under bitlocker, and some hardware has changed). Do you know of any way to display this ID while in windows ? It should be a good starting point for research.

I have some questions :
1 - I have never been able to reproduce or even understand issue #10. I'm not sure if changing the default solves it.
2 - Is there an issue with : "Queue unlock in one thread instead of multiple parallel threads" ? I think it should be faster with multiple DBs.

[lexx9999]

Thank you, same! Feel free to take and modify as you prefer.

1 - wrt. #10. My explanation is this:
User installed KeeLocker version 1.5 or earlier and created some entries. Some time after it was (automatically) updated to 1.6. During this process the unlock options where "automatically checked" because the defaults are enabled. But without any action of the user. Therefore user was upset.

2 - One reason is that threads are a limited resource (like pens,brushes,fonts) (not too limited though). You're right with parallel threads it will be faster, but there is also a higher chance that something goes wrong. There might be different entries in the same or multiple DBs which might conflict. Also the process of mounting has a number of effects onto a system so I am more on the being defensive side. Another side effect was that I had to create a set of changes first, which could be easily filtered.
Considering opening multiple DB's getting opened and a crazy user selecting unmount frequently some defensive action blocking might be better.
I have about 20 BitLocker drives in my db and I believe it's not a good idea to probe them all at the same time.

Just realized: I should probably disable automatic updates in my version to not get surprises.

Regarding drive letters:
It would be nice to keep some information field, especially when the drive is not mounted or not mounted to the current computer. Storing drive label and drive size might be more useful. But I had to start somewhere.
fyi: I was considering requiring the computer name to match if using the drive letter is preferred by the user, something like "L:\ @mycomputername" along with having multiple.

Finally the Id.. there are several places where it can be seen:
a) "bdeunlock.exe U:" where U is the drive (that the process explorer uses, then "more options" "enter recovery key". It displays a key-id, which is equal to the first part of the recovery key id. For a recovery key 1CFFF5FA-19EC-4442-8902-2AB918FF1311 it will display a key id 1CFFF5FA. I'm guessing it could show the full id there.
b) Using Shell as Administrator. "manage-bde -protectors -get U:" This will display the id as "Numerical password" and if unlocked it's value.
c) Using Powershell as administrator "Get-BitLockerVolume" i.e. "(Get-BitLockerVolume -MountPoint U).KeyProtector"
Guess the first variant is the best to start with.

Note: The recovery key id is a UUID (which is a GUID), so it's likely that it is stored as binary.
https://learn.microsoft.com/en-us/windows/win32/api/guiddef/ns-guiddef-guid
I'm suspecting if Data1 of can be located the remaining part is just present next to it.

Just a moments ago I figured out bdeunlock depends on bdeui.dll BuiVolume::GetPasswordId and also bdeui.dll imports FveGetAuthMethodInformation from fveapi.dll.
Searching for FveGetAuthMethodInformation revealed https://github.com/gtworek/PSBits/blob/master/Misc2/FveKeyProtectorsDump.c which looks very promising.

Finally some ideas I had recently:
I was looking into notifications (classic bubble notifications don't work with win 10). There are the new toast notifications but I was too scared of .net version issues to start implementing anything. On the other hand a new (free float or docked window) which is automatically is shown if KeeLocker unlocks something could be nice.
From microsoft docs it looks like a lot of effort, with uncertain success.

[Gugli]

IIRC the plugin Keeagent uses notifications, but I don't know how they do it.

[lexx9999]

Thx for that tip. Found it ShowBalloonNotification
Hmm, it's still using Shell_NotifyIcon internally seems I messed up parameters in my test.

Updated my code so it can extract the UUIDs, see VolumeInfo.AuthGuids (FveGetAuthMethodGuids is enough to read out just the guids). The guids are not used yet. Since I typically have the guid as username for me the best solution would be:
compare username to with guids if username is a guid pattern. If password matches recoverykey pattern treat it as recovery key else as a password.
It also shows a notification now, but it's shown if any unlock was attempted not just when it was successful.

[lexx9999]

It seems much easier to enumerate drives it the entry-settings tab, as you did, (and show the drive letter and drive name for user-friendlyness), but only store the drive ID. No combo box or button to convert.

Don't forget, the drive might not be connected, either because unplugged or being on a different computer. In this case it's probably useful to have some info. On the other hand most users will have already some description as the entry title.

[Gugli]

Also, regarding threads :

While I agree that for CPU-intensive tasks, one should use as many threads as there are logical cores, I think when using threads to encapsulate IO-intensive blocking tasks, the amount of threads should be based on the underlying blocking resource (ex : 1 thread per blocking network socket is standard practice).

I suspect (but I might be wrong, this would need to be benched) that calls to Fveapi.dll (and thus the whole "UnlockVolume" function) are mostly blocking syscalls and IO-wait (drive reads), and not much CPU (cyphers are not very costly nowadays).

To me, the perfect solution would be to have one thread for each physical drive, but that would require to detect which partitions are on the same drive, and looks a bit overkill (for now).
Short of that, I still think that 1 thread for each call to fveapi.dll is a good compromise (unless of course, this leads to reproduceable issues).

IMHO, the best solution is ;

• On the main thread, spawn a thread to handle all drives unlock (given all relevant entries in all opened dbs)
• On this "all drives" thread : enumerate all currently available bitlocker drives, and match them with the entries we have. If 2 entries concern the same drive ID, select one (*)
• Spawn one thread for each effective call to "UnlockVolume".
• the "all drives" thread waits for all the "UnlockVolumes" threads to end, gather errors to report to the main thread, then ends.

(*) I don't see legit use-cases for having multiple entries with the same drive-ID and different passwords. So I believe that selecting any entry should be fine, and cover the case where the same credentials appear in multiple DBs (or multiple times in one DB ?).

[lexx9999]

Ok, I admit one thread might be to strict.
I would suggest one thread per BitLocker volume (by volume path) together with the "all drives" thread as you suggested. Unlock attempts could be even ordered by last modification time of the entry to archive a deterministic order. In this scenario the thread could be terminated as soon it detected the drive to be successfully unmounted.

Use cases are not only good cases.. I see these:

• Opening an old backup in parallel to an actual database
• Having a master db with all entries, and a reduced db with only limited entries (maybe a third one with just specific entries)
• Having a db which is synced and one which is not yet synced
• Also it's possible to have multiple recovery keys per BitLocker drive which might be stored in the same db, in the good case all valid but also fully or partially invalidated cases. Old entries should have unlock disabled, but real life is not perfect.

This might seem to be unlikely at first but not so, if using KeePass over years in multiple environments or partially sharing keys with other people (children for example).

Note: Just selecting one entry might not unlock the drive because it could be an outdated one.

My concerns about multiple parallel unlocks are also beyond the unlock process. Like explorer starting for the unlocked drive and applications reacting to the appearance of a new drive. One is not a problem, that's probably well tested, but what about four or more? I might be to defensive in this case as well.