Compatibility with BitLocker volumes

[Explorer09]

BitLocker in Windows 7 or later allows encrypting a FAT16, FAT32 or exFAT partition. When encrypting, an outer "discovery volume" will be created in place of the partition to be encrypted. This volume contains a BitLocker To Go Reader, files that map to the encrypted blocks, and serveral dummy files to stuff the directory entries so that the file system will appear to be full.

The discovery volume can be mounted like ordinary FAT32 partition (which is part of the design to let BitLocker To Go work in Windows XP and Vista). Because of this, usb_vaccine.cmd will interact with it, however we did not specify how the script should behave when it encounters a BitLocker encrypted volume. We didn't test usb_vaccine.cmd with such a volume yet, and the script's ordinary behavior may not give the best benefit to the volume.

Here are the potential problems specifically:

• usb_vaccine.cmd is designed to remove autorun.inf, and replace it with a (supposedly) read-only directory. However BitLocker "discovery volume" uses it for BitLocker To Go, the bad practice that usb_vaccine.cmd is designed to avoid. Combining with the fact that the directory is filled with dummy file entries, it might fail to create additional file entries that's needed to protect autorun.inf, Desktop.ini or other file names.
• The encrypted data is mapped to COV<space><4 decimal digits>.<space>ER files, which are required by BitLocker To Go Reader to read the encrypted data. The users have right to expect them to remain hidden to prevent their accidental deletion (which will break the functionality of the Reader but Windows 7 can still decrypt the volume without them). We need to offer a UI option the let user choose the behavior (to remain hidden or to reveal them).

To-dos:

• Test the discovery volume in Windows XP or Vista and see how many files we can stuff into the root directory entries, and whether the PAD<space><4 decimal digits>.<space>NG files really succeed in preventing our creation of additional files. Yes they do prevent us to create additional files on the volume, meaning that usb_vaccine.cmd would surely fail on it.
• Determine a default "policy" for usb_vaccine.cmd regarding BitLocker discovery volumes and implement it in the code. (No, we can't leave autorun.inf there untouched.)
• Potential new feature: Alter "%WinDir%\BitLockerDiscoveryVolumeContents" directory with what usb_vaccine.cmd will change on the root directory of every drive. That is, reveal BitLocker To Go MUI files that are hidden by default, remove autorun.inf, and add dummy autorun.inf and Desktop.ini directories.

[Explorer09]

Update (2018-Apr-03): Editing the template of BitLocker Discovery Volume Contents is more difficult than I think. "%WinDir%\BitLockerDiscoveryVolumeContents" is in fact only a temporary directory. The actual file map is "%WinDir%\WinSxS\FileMaps\$$_bitlockerdiscoveryvolumecontents_4ba1a520585d23cf.cdf-ms". Another interesting location is "%WinDir%\WinSxS\x86_microsoft-windows-s..ccessagent-binaries_31bf3856ad364e35_<version>_none_<16 hex digits>", which stores autorun.inf, BitLockerToGo.exe and Read Me.url.