Hello trid users,
some days ago just for interest i inspect efi executables starting with MZ
magic. Afterwards i look for other MZ-executables on my systems. Such
samples with MUI file name extension are Multilingual User Interface
resource library.
First i inspect German samples ( inside de-DE sub directory ) in SysWOW64
directory on Windows systems.
These samples are only described by exe-win.trid.xml as "Win32 Executable
(generic)" or as "Generic Win/DOS Executable" by exe-generic.trid.xml (See
appended output/386-de/output/trid-v.txt).
For comparison reasons i also run other identifying tools on such examples.
The file command identifies these examples as "PE32 executable (DLL)" and
"Intel 80386, for MS Windows" (See appended 386-de/output/file-5.39.txt).
So i run tridscan on samples and i generate a trid definition file
mui-386.trid.xml. All my samples still start with typical Windows executable
phrase that is also found in other trid definitions exe-*.trid.xml. That is
expressed by XML pattern block like:
<Bytes>4D5A90000300000004000000FFFF0000B80000000000000040
<ASCII> M Z . . . . . . . . . . . . . . . . . . . . . . @</ASCII>
<Pos>0</Pos>
In my fist attempts i get in Global strings sections lines like:
<String>E'N'D'E</String>
<String>E'I'N</String>
These are generated because the first MUI samples contain German words like
ENDE or EIN encoded as UTF-16 strings. But when inspecting more examples
these lines vanish. So there exist no language specific strings inside the
trid definition in the final trid definitions.
When inspecting more examples also more garbage string vanish like:
<String>I'N'T'E</String>
<String>N'T'E'R</String>
<String>R'I'N'G</String>
<String>S'T'R'I</String>
<String>E'R'E</String>
<String>E'R'N</String>
<String>E'S'T</String>
Also many short nil pattern vanish like:
<Pattern>
<Bytes>0000</Bytes>
<Pos>714</Pos>
</Pattern>
<Pattern>
<Bytes>0000</Bytes>
<Pos>722</Pos>
</Pattern>
All samples contains the same DOS stub. That is expressed inside global
string section by line like:
<String>THIS PROGRAM CANNOT BE RUN IN DOS MODE.</String>
and in front block section by XML construct like:
<Bytes>0000000E1FBA0E00B409CD21B8014CCD21546869732070726F6772616D2063616E6E6F74
<ASCII> . . . . . . . . . . . ! . . L . ! T h i s p r o g r a m c a n n o t
<Pos>61</Pos>
All samples contain the Microsoft "Rich"-header at the beginning. That is
expressed inside global string section by line like:
<String>RICH</String>
and in front block section by XML construct like:
<Bytes>52696368</Bytes>
<ASCII> R i c h</ASCII>
<Pos>160</Pos>
According to Portable Executable documentation the COFF header starts with 4
byte signature "PE\0\0" and typically this signature is still near the
beginning. Afterwards comes 2 byte machine types in little endian
format. For Intel 386 this value is 0x014c. That gives in ASCII the Letter L
after 4 byte signature. That is expressed in trid definition by line like:
<String>PE''L</String>
Unfortunately i found no web site with precise file format specification,
but on Brian Cryer's Web about the mui file extension some basis information
are found. That is now expressed by line like:
<RefURL>
http://www.cryer.co.uk/file-types/m/mui.htm</RefURL>
Because the MUI file format is extended from DOS MZ executable, the file
command use mime type "application/x-dosexec" (see appended
386/output/file-i-5.39.txt). According to Wikipedia for Portable
executables (PE) an own mime type is used. That is now expressed by line
like:
<Mime>application/vnd.microsoft.portable-executable</Mime>
Most (75171 of 80376=93%; probably containing duplicates) of my inspected
samples have version resource and this contains assignments for ProductName,
ProductVersion, FileDescription, FileVersion, InternalName and
OriginalFilename. Furthermore the filename consist of the original
executable or library name with appended mui file name extension (like
Journal.exe.mui or EppManifest.dll.mui). This information is stored as
UTF-16 string. That is expressed inside global string section of
mui-386.trid.xml by lines like:
<String>O'R'I'G'I'N'A'L'F'I'L'E'N'A'M'E</String>
<String>F'I'L'E'D'E'S'C'R'I'P'T'I'O'N</String>
<String>P'R'O'D'U'C'T'V'E'R'S'I'O'N</String>
<String>S'T'R'I'N'G'F'I'L'E'I'N'F'O</String>
<String>V'A'R'F'I'L'E'I'N'F'O'''''$</String>
<String>I'N'T'E'R'N'A'L'N'A'M'E</String>
<String>F'I'L'E'V'E'R'S'I'O'N</String>
<String>P'R'O'D'U'C'T'N'A'M'E</String>
<String>.'M'U'I</String>
This can be verified by output of pelook tool with version resource
displaying -v option (See appended 386/output/*-v.txt).
Later i found examples like xrwctmgt.dll.mui which does not contain the
InternalName variables. This can be verified by output of pelook tool with
version resource displaying -v option (See appended
386\versionMuiExt\more25\output\*-v.txt).
Then there exist some samples with version resource, but the filename is
empty like in DiagPackage.dll.mui or has no mui extension like
FontCacheService in FntCache.dll.mui. But these examples still have the
string MUI stored as UTF-16 inside binary. That is expressed inside global
string section of mui-386-version_string.trid.xml by line like:
<String>M'U'I</String>
This can be verified by output of pelook tool with version resource
displaying -v option (See appended 386/versionNoMuiExt/output/*-v.txt).
Then there exist some samples like igxpin.exe.mui that have no or a short
version section, but contain the string MUI as UTF-16 string inside the
file. So i run tridscan on these examples to generate definition
mui-386-string.trid.xml. This can be verified by output of pelook tool with
version resource displaying -v option (See appended
386/NoVersion/output/*-v.txt).
Then there exist a few (44) samples that does not contain the string MUI
inside the file. So i run tridscan on these examples to generate definition
mui-386-unspecific.trid.xml.
When running a patched file command on the examples, it was not able to
distinguish the Multilingual User Interface libraries (*.mui), from Resource
libraries ( *.rll) or Icons libraries (*.icl) (See appended
386/NoVersion/output/file.tmp).
So i do a counter check. I run trid also with definitions for RLL and ICL
samples and i also run trid on RLL and ICL samples with definitions for
MUI. Now some MUI like aadtb.dll.mui are identified first as RLL (see
appended 386\NoMUI-utf16\more2\output\trid-new.txt) and some RLL like
sqlsrv32.rll are identified as MUI by mui-386-version_string.trid.xml.xml.
So i tried to improve or change definitions. When looking in output of
patched file command i see the MUI samples seem to contain always one or two
sections. One section has the the name ".rsrc". That was expressed inside
global string section by line like:
<String>.RSRC</String>
When looking at 2 section samples often the other section has name like
".rdata" like in tipresx.dll.mui. But sometimes the second section name is
".reloc" like in InkWatson.exe.mui. This can be verified by output of pelook
tool with header info displaying -h option (See appended
386/more/output/*-h.txt). So for me this information seem not suitable as
additional test pattern.
So my conclusion is to use only definition mui-386.trid.xml. This recognized
with very high rate of about 93 percent MUI examples. It does this
reliable. That means not misidentification of RLL examples whereas the other
definitions mui-386-version_string.trid.xml, mui-386-string.trid.xml and
mui-386-unspecific.trid.xml has difficulties to do clear distinguishment. So
i recommend to do not use these definitions.
Maybe also a refinement of the rll.trid.xml should be done.
With the definition most of my MUI samples are now recognized (See
appended 386/output/trid-v-new.txt).
Some (99) samples are described by file command as "PE32+ executable (DLL)"
and "x86-64, for MS Windows" (See appended x64/output/file-5.39.txt)
According to Portable Executable documentation the COFF header starts with 4
byte signature "PE\0\0" and typically this signature is still near the
beginning. Afterwards comes 2 byte machine types in little endian
format. For Intel x64 this value is 0x8664. That gives in ASCII the Letter d
after 4 byte signature. That is expressed in trid definition
mui-x64.trid.xml by line like:
<String>PE''D</String>
Again we find samples with and without version resource (see
x64/output/*-v.txt), but at least all samples contain the UTF-16 MUI string.
That is expressed inside global string section by line like:
<String>M'U'I</String>
Luckily i found here no collision with RLL and ICL samples.
TrID definition, some examples and output are stored in archive mui.zip. I
hope that my XML files can be used in future version of triddefs.
With best wishes
Jörg Jenderek
