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 rll file name extension are Microsoft Resource Libraries.
14 of 114 inspected samples are described correctly by rll.trid.xml as
"Microsoft Resource Library". But 100 not described by that definition.
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/output/file-5.39.txt) An
patched file command is able to determine some RLL partly as "Icons or
Resource Library" if number of sections is 1 (See appended
386/output/file.tmp)
So i run tridscan recursive on undetected samples and i update the trid
definition file rll.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>
Many examples like sqlsrv32.rll are part of Microsoft SQL server package. So
current definition seems to be based on such samples. So the samples contain
the UTF-16 string SQL. That was expressed inside global string section by
line like:
<String>S'Q'L</String>
So for examples like 0409.rll and 0804.rll (part of GPSMapEdit program
version 2.1.78.10 from
http://www.geopainting.com/) this of course is not
true and the above line vanish.
Often the samples contain in resource sections variables like CompanyName,
ProductName ProductVersion, FileVersion, InternalName and
OriginalFilename. These are stored as UTF-16 strings. These values can be
shown by pelook.exe tool with -v option to display version resource (see
appended output/*-v.txt). This was expressed inside global string sections
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>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>C'O'M'P'A'N'Y'N'A'M'E'''''M'I'C'R'O'S'O'F'T' 'C'O'R'P'O'R'A'T'I'O'N</String>
<String>P'R'O'D'U'C'T'N'A'M'E'''''M'I'C'R'O'S'O'F'T</String>
<String>P'R'O'D'U'C'T'V'E'R'S'I'O'N</String>
<String>F'I'L'E'V'E'R'S'I'O'N</String>
Apparently this variables are optional. In mapedit samples these things are
missing (see appended 0409-v.txt 0804-v.txt). So the above string lines
vanish.
When building such libraries with Microsoft tools these contain near the
beginning MS "Rich" Header. This contains information about used compiler
types and versions. These values can be shown by pelook.exe tool with -rh
option to display decoded fields of this header (see appended
output/*-rh.txt). When examining more examples this header becomes more
different. As a result in front block section the following XML construct
vanish like:
<Pattern>
<Bytes>52696368</Bytes>
<ASCII> R i c h</ASCII>
<Pos>160</Pos>
</Pattern>
That the header still exist at other offset becomes visible that the keyword
Rich still exist near the beginning. That is still expressed inside global
strings sections by line like:
<String>RICH</String>
Some patterns mainly containing nils vanish or become shorter like:
<Pattern>
<Bytes>0000000000000000E000</Bytes>
<Pos>196</Pos>
</Pattern>
<Pattern>
<Bytes>210B01</Bytes>
<ASCII> !</ASCII>
<Pos>207</Pos>
</Pattern>
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 was expressed inside front block section by
line like:
<Pattern>
<Bytes>00000000000000000000000000000000504500004C01</Bytes>
<ASCII> . . . . . . . . . . . . . . . . P E . . L</ASCII>
<Pos>168</Pos>
</Pattern>
and in global string section by line:
<String>PE''L</String>
When examining more examples that structure appears at other offsets. So in
front block the concerning part vanish. And in global string sections the
corresponding line still exists.
So i also mention this fact in the remark line. That is now expressed by
line like:
<Rem>Intel 80386 variant</Rem>
With the updated definition such RLL samples are now recognized (See
appended output/trid-v-new.txt).
The file command identifies some examples especially found in System32 and
"Program Files" sub directory on 64-bit Windows systems as "PE32+ executable
(DLL)" and "x86-64, for MS Windows" (See appended x64/output/file-5.39.txt)
So i run tridscan on such examples to generate rll-x64.trid.xml for 64-bit
RLL samples. 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
wformat. For Intel x64 this value is 0x8664. That gives in ASCII the Letter
d after 4 byte signature. That is expressed in trid definition by line like:
<String>PE''D</String>
So i also mention this fact in the remark line. That is now expressed by
line like:
<Rem>Intel x64 variant</Rem>
With the second definition all my x64 RLL samples are now recognized (See
appended x64/output/trid-v-new.txt)
Unfortunately all my x64 rll examples are related to SQL server. So in
global string section there still exist a line like:
<String>S'Q'L</String>
When inspecting more such RLL samples this line should vanish.
Unfortunately i found no web page with file format specification. At least
on some pages the relationship to Windows DLL is mentioned. That is now
expressed by reference line like:
<RefURL>
https://fileinfo.com/extension/rll</RefURL>
Because the RLL file format is extended from DOS MZ executable, the file
command use mime type "application/x-dosexec" (see appended
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>
TrID definition, some examples and output are stored in archive rll.zip. I
hope that my 2 XML files can be used in future version of triddefs.
With best wishes
Jörg Jenderek
