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 ICL file name extension are Icons Library.
Many are described correctly by icl.trid.xml as "Icons Library". But 18
examples like ANIMATAI.ICL and SIMPSONI.ICL are only described by
exe-generic.trid.xml as "Generic Win/DOS Executable" (See appended
NE_/output/trid-v-old.txt).
For comparison reasons i also run other identifying tools on such examples.
The file command identifies these examples as "MS-DOS executable" (See
appended output/file-5.39.txt).
So i run tridscan on these 18 undetected samples and i update a trid
definition file icl.trid.xml. All my samples still start with typical
Windows executable phrase that is also found in other trid definitions
exe-win*.trid.xml. That is expressed by XML pattern blocks like:
<Bytes>4D5A</Bytes>
<ASCII> M Z</ASCII>
<Pos>0</Pos>
Now some short null pattern vanish like:
<Pattern>
<Bytes>000000</Bytes>
<Pos>61</Pos>
</Pattern>
<Pattern>
<Bytes>0000000000</Bytes>
<Pos>133</Pos>
</Pattern>
Unfortunately the new executables signature (NE) now appears at different
offsets. So in front block section the following pattern now vanished:
<Pattern>
<Bytes>4E45000000000000000000000000000000000000000
<ASCII> N E</ASCII>
<Pos>128</Pos>
</Pattern>
Also no other characteristic string is found in all such ICL samples.
At offset 0x3C the offset of the new exe header is stored as 4 byte value.
That field is often called e_lfanew. For most examples this value is 0x80,
but for 2 examples like ANIMATAI.ICL and ANIMATBD.ICL that value is 0x40. So
i mention this fact in a remark line like:
<Rem>
At offset 0x3C offset to the new exe header is 0x40 or often 0x80
</Rem>
So some long pattern become shorter or are splitted in shorter parts. That
were patterns like:
<Pattern>
<Bytes>000000000000000000000000000000000000000000000000000000000000000000000080
<Pos>25</Pos>
</Pattern>
<Pattern>
<Bytes>00000000000000000000000000000200000000000000</Bytes>
<Pos>168</Pos>
</Pattern>
Because such ICL file format is extended from DOS MZ executable, the file
command use mime type "application/x-dosexec" (see appended
NE_/output/file-i-5.39.txt). But the MZ format is only used as container for
images and is not executable. So i choose a more suitable user defined mime
type. That is expressed by line like:
<Mime>image/x-ms-icl</Mime>
Some information about that file format can be found on file formats archive
team web site. That is now expressed by reference line like:
<RefURL>
http://fileformats.archiveteam.org/wiki/Icon_library</RefURL>
There i also found links to ICL examples, that i inspected. Furthermore there
software like RealWorld Icon Editor is mentioned. By this software i was
able to visualize the icons inside the ICL samples.
On the web site is also mentioned that ICL can be based on the portable
executable (PE) format instead of NE. So i look for such variants. I found a
few examples like PENetwork.icl and i was able to create such samples like
fdosfish.icl and iconlib-empty.icl by RealWorld Icon Editor. When i run trid
on these examples these are only recognized by exe-win.trid.xml as "Win32
Executable (generic)" (See appended output/trid-v-old.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 output/file-5.39.txt).
And many software like XnView and IrfanView claim to open ICL files, can
only open the 32-bit variant ( also known as PE format).
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 should be expressed in trid definition by line
like:
<String>PE''L</String>
So i run tridscan on these 6 samples and i generate trid definition
icl-32.trid.xml. All my samples still start with typical Windows executable
phrase that is also found in other trid definitions exe-win*.trid.xml. That
is expressed by XML pattern blocks like:
<Pattern>
<Bytes>4D5A90000300000004000000FFFF0000B80000000000000040
<ASCII> M Z . . . . . . . . . . . . . . . . . . . . . . @</ASCII>
<Pos>0</Pos>
</Pattern>
Unfortunately in global string section only few unspecific string lines
appear. One is triggered by DOS stub header, that is found in many Windows
executables. But that can be replaced by other DOS code. That line is:
<String>THIS PROGRAM CANNOT BE RUN IN DOS MODE.</String>
One line is triggered by the undocumented Microsoft "Rich" Header, that also
appear in many Windows executables. That is expressed by following line:
<String>RICH</String>
In contrast to real executables with .data and .text sections these ICL
samples contains only 1 PE section. And that is the resource section with
the icons. That is expressed by line like:
<String>.RSRC</String>
For that reason i keep all patterns in front block section, even when these
are very short or null patterns.
With the 2 definitions now more 16-bit icon libraries (NE) are now described (See
appended NE_/output/trid-v-new.txt) and also the 32-bit (PE) icon libraries
are now recognized (See appended output/trid-v-new.txt).
TrID definition, some examples and output are stored in archive icl.zip. I
hope that my 2 XML files can be used in future version of triddefs.
With best wishes
Jörg Jenderek
