Bitlocker Boot Screen configuration

Is it possible to customize the screen that appears when bitlocker is unable
to load the
key from a USB device?(e.g. "Insert...") Or is this part of WINLOAD.EXE?

Thanks
Christian Schindler

> Is it possible to customize the screen that appears when bitlocker is unable

> to load the
> key from a USB device?(e.g. "Insert...") Or is this part of WINLOAD.EXE?

No. There is no customization possible of that workflow at all.

Thanks!

"Jesper" <Jesper@discussions.microsoft.com> wrote in message
news:46B6DC58-F218-4763-87A8-9B9AA30CA416@microsoft.com...

>
> No. There is no customization possible of that workflow at all.

Jesper wrote in response to Christian Schindler:

At any rate, it would be part of BOOTMGR, not WinLoad. WinLoad in inside the
encrypted partition, so it should be decrypted first...

> No. There is no customization possible of that workflow at all.

I do not know if that is what you meant, but there is already some grade of
customization, that is to be language independant. A quick look at
Bootmgr.exe.mui of any language pack shows there is a .xsl resource (of type
23), which has the translated versions of those messages. Apparently, the
template Christian is refering is named "fve-bad-external-key-file".

What I do not know is how much of it is "user-customizable".
At first sight I did not notice any specific certificate inside those .mui
or elsewhere in the language pack (which seemed to me strange or at least
unexpected); so perhaps they are checksumed within Bootmgr.exe, for example
with the SHA1 hashes for all the .mui stored inside the main .EXE
(obviously, no customization; but no flexibility for MS either.)

Another possibility is that the loaded .mui is "trusted" or "measured" in
the same way as the other files used in the boot (I mean, much like BCD
should be measured; in terms fo the reference article
http://blogs.msdn.com/si_team/archiv...-Security.aspx,
we are at "OS Boot" times.)
In that case, I guess there is a good grade of possible customization of the
resource, in as much as after any modification, the new measure should be
registered for unlocking the BitLocker partition (no difference here with
the case where the user is changing e.g. her multiboot configuration: after
any alteration of the core boot files, she must "validate" the changes
against BitLocker, giving the recovery password and resactivating.)

Another possibility that I do not give much credit, but is still possible
(particularly from the examination of the messages inside the said
resource), is that the .xsl resource is not considered as determinant with
regard to the secured boot process, so any modification would be accepted
without even sinaling. Of course in such a case there is quite a wide grade
of possible customization.


But I did not actually test my ideas, so treat with a large dosis of salt.


Antoine