Simon Says – Musings of a Technology CTO

Many people have asked over the years how exactly McAfee Endpoint Encryption for PCs, or it’s predecessor SafeBoot Device Encryption for PCs v5 chooses, or decides which language and keyboard to display in the pre-boot environment.

To understand this, it’s important to consider the localization configuration file on the client – [appdir]\Locale\Locale.ini:

About Locale.ini Files

    1 : [settings]
    2 : defaultlanguage=0001
    3 : defaultkeyboard=20401
    4 :
    6 : [Languages]
    8 : 0001=Lang.0001
   10 :
   12 : [Keyboards]
   14 : 10401=Keyboard.10401
   16 : 20401=Keyboard.20401
   18 : 0401=Keyboard.0401
   20 :
   22 : [LanguageIDMap]
   24 : 10401.Keyboard=10401
   26 : 20401.Keyboard=20401
   28 : 0001.Language=0001
   30 : 0401.Keyboard=0401
   32 :
   34 : [Lang.0001]
   36 : ;Name=Arabic
   38 : NameW=0627,0644,0639,0631,0628,064A,0629,0020,0028,0041,0072,0061,0062,0069,0063,0029
   40 : ID=0001
   42 : StringFile=0001.str
   44 : FontSection=Fonts.LatinASCII
   46 :
   48 : [Keyboard.10401]
   50 : Name=Arabic (102)
   52 : Mapfile=10401_E.MAP
   54 : OSK=10401_OSK.XML
   56 :
   58 : [Keyboard.20401]
   60 : Name=Arabic (AZERTY)
   62 : Mapfile=20401_E.MAP
   64 : OSK=20401_OSK.XML
   66 :
   68 : [Keyboard.0401]
   70 : Name=Arabic (101)
   72 : Mapfile=0401_E.MAP
   74 : OSK=0401_OSK.XML

The Locale.ini file defines the available language and keyboard options are available to the user. The sections are pretty self-explanatory:

[Settings] – defines the current selected language and keyboard. Note, in B5701 onwards, this is not set in the database side files, more on that later though.

[Languages] – the list of languages defined. In this file, there’s only one (with code 0001). The codes are defined by Microsoft, you can find lists of them all over the Internet. For example, US English is 0409. The language code is broken out in to high and low bytes. The low byte (01 for Arabic, or 09 for English) defines the root of the language, whereas the high byte (00 or 04) defines the variant – for example UK English is 0809, US English is 0409.

[Keyboards] – the list of defined keyboards, again like the languages Microsoft defines the layout ID’s, and you can find details on them on Microsofts GlobalDev site. The format is much the same, except there are two or three bytes, for example the US Dvorak keyboard has the id 10409, the Gaelic keyboard is 11809, and the standard UK English keyboard is 0809. Note the keyboard and language id’s are very closely related, with the same structure. The low byte of 09 always indicates English.

[LanguageIDMap] – this list defines the relationship between the EEPC pre-boot language and keyboard to those in Windows. For example the line 10401.keyboard=10401 means “If you discover on activation that Windows is using a keyboard with the Windows ID 10401, then choose the keyboard line from [keyboards] in this file referenced by the code 10401”.

This would mean that the ultimate keyboard section used would be keyboard.10401 (from the line 10401=keyboard.10401).

Yes, I know it seems superfluous to do all the reverse look-up etc, but imagine that there’s no reason to have to use the same naming convention throughout – you could have a [languageidmap] section called 0409.Keyboard=USEnglish, as long as there was an entry in [keyboards] called USEnglish=TheUSEnglishKeyboard, and an appropriate section called [TheUSEnglishKeyboard].

The rest of the file is comprised of sections defining each language and keyboard which are supported:

[Keyboard.10401] – this is a keyboard section. It has a Name, or a NameW which is what is displayed to the user in the pre-boot Options menu. If the text needs to be in Unicode, it’s spelt out as a series of char codes in NameW, if it’s just ASCII, then you can use Name instead. The MapFile entry gives the path to the corresponding .map file which defines the layout. These are created by McAfee, it’s not possible to create one yourself without their help. Finally, the OSK entry defines the XML file for the On-Screen Keyboard which matches this layout. Again, McAfee create these, but because they are simply XML, you can toy with them if you must.

About Language Detection

When the EEPC/DEPC client activates (that is, when the pre-boot code is installed into the MBR, NOT when the product is installed), the client goes through a one-time analysis of the Windows language and keyboard, and tries to match them to a pre-boot language and keyboard by using the [LanguageIDMap] section of Locale.ini.

The matching runs through several levels of detail trying to get a match:

1. Exact ID to ID match
2. Two Byte Match
3. 00 + Low Byte Match

So as an example, if the current Windows Language is 10425 (Estonian Dialect), the client manager will look in the [LanguageIDMap] first for 10425, if not found it will look for 0425, and then if that isn’t found it will look for 0025. You can see if you browse the individual definition files for many of the languages (in the EEM/Languages directory of your Admin install), many only define the last match situation (0025 for Estonian for example). This means that any Estonian dialect will resolve down to the one language file. Other languages can be more complex, for example Chinese (0004) – you can see there are defined mappings for 0804, 0404, 0c04, but also a mapping for 0004. This catches any other Chinese variant that is detected and in this case, resolves it to Simplified Chinese.

the Keyboard detection follows the same logic.

After activation, this automatic detection is never performed again, well, not until the pre-boot code is deactivated and reactivated anyhow.

There is a script which reproduces the logic of this initial state, which can be run on a currently active machine. The script (FixLocale) looks up the Windows Language and Keyboard ID’s, then by walking through the client locale.ini file it tries to pick the most appropriate one for the user – following the logic the client would have performed during the initial activation. You can get a copy of FixLocale from CTOGoneWild

About Merge INIs

You can see that on a typical client with many language sets assigned, the Locale.ini file is quite complex – this is because each individual language merges its own Locale.ini file on top of the existing client one. You can find these individual locale.ini files in each language directory on your EEM install (and of course in your Administration Database). As each language is installed on the client, its personal Locale.ini file is laid down on top of the existing one. Of course there should be no overlap apart from the section names, so there should never be any collisions.

conversely, when you remove a language, its unique entries are removed from the client Locale.ini file. This can have unexpected results.

One thing to note is with builds prior to 5701, each language assumed that it should be the one to be displayed if applied to a machine post activation. For example, if you had an existing active machine and you ticked the Spanish language set – the machine would download the new files and switch into Spanish.

The behaviour was because each language set itself to be the default. (the [settings] section on the individual Local.ini file contained definitions for Default Language and DefaultKeyboard). Build 5701 has this removed, so applying a new language to an existing active client just installs the choice for that language, it does not activate it.

“Wrong Language” Problems – how they occur and how to fix them.

“The client is set to use the wrong language!” – If you end up in the position that the wrong keyboard and language are displayed, simply click the Options button in the pre-boot screen (after cancelling the login prompt), and then click Options and pick the correct language and keyboard.

“One of my language choices is missing!” – Assuming the file group is indeed connected to the machine (and you can see evidence of it downloading in the client log), if the one you want is missing, you may have to increase the revision of the language locale.ini file (just find it in the file group in EEM, open it, and click apply to increment its revision number). It will then get merged back into the client side “master” Locale.ini file again.

“All my language/keyboard choices on my clients disappeared!” – Things like deploying a custom theme to a client can overwrite the client’s locale.ini file removing all the choices – if the theme Locale.ini is NOT a merge ini, then it will just replace the client side one removing all the settings. To switch themes, the theme locale.ini must also be a merge ini file. To add the languages back in, just increment the version of each of their locale.ini files (assuming you didn’t untick them from the client?)

“I deployed a new language to my clients, now they are all in Russian!” – There is a script which reproduces the logic of the initial detection, which can be run on a currently active machine. The script (FixLocale) looks up the Windows Language and Keyboard ID’s, then by walking through the client locale.ini file it tries to pick the most appropriate one for the user – following the logic the client would have performed during the initial activation. You can get a copy of FixLocale from CTOGoneWild

“The client picked the wrong keyboard/language for the preboot” – Remember that the detection is only done during activation, so if the language set was deployed after, it’s not going to work anyway. Next, check your keyboard/language ID (use WMI to get it, or the FixLocale script) against the [languageidmap] section of Locale.ini on the client – most likely there’s no match for your keyboard/language combination. If there’s a close language or keyboard, you can edit the appropriate locale.ini file in your language file groups to add the mapping in, or contact  your McAfee Platinum support person to get them to help you do it.