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 CPL file name extension are Windows Control Panel Items.
255 of my inspected samples ( maybe containing duplicates) are described
correctly by cpl-win.trid.xml as "Windows Control Panel Item (generic)".
But 268 are not described by cpl-win.trid.xml. Such examples are only
described by dll.trid.xml as "Win32 Dynamic Link Library" (See appended
output/trid-v-old.txt).
So i run tridscan recursive on undetected samples and i update a trid
definition file cpl-win.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 block like:
<Bytes>4D5A</Bytes>
<ASCII> M Z</ASCII>
<Pos>0</Pos>
Now some patterns in global strings section vanish like:
<String>A'L'L</String>
<String>ABLE</String>
<String>ADLIBRARY</String>
<String>APPL</String>
<String>C'O'N</String>
<String>C'O'R</String>
<String>CALL</String>
<String>ECOUNT</String>
<String>ESSI</String>
<String>ETIME</String>
<String>ETUN</String>
<String>FILET</String>
<String>GETCURRENTP</String>
<String>GETCURRENTTHREADID</String>
<String>GETSYSTEM</String>
<String>I'N'D</String>
<String>INFO</String>
<String>O'P'E</String>
<String>P'O'R</String>
<String>PERFORMANCE</String>
<String>QUER</String>
<String>R'E'S</String>
<String>RDATA</String>
<String>RENTPRO</String>
<String>T'I'N'G</String>
<String>TERMINATEPROCESS</String>
<String>TPROCESS</String>
<String>TURE</String>
<String>UNHANDLEDEXCEPTIONFILTER</String>
<String>UNTER</String>
<String>WIND</String>
Many CPL samples have code in DOS stub with message string "This program
cannot be run in DOS mode.", but some CPL have completely other message
strings like WINE CPL with strings like "Wine placeholder DLL". So the
following line also vanish:
<String>CANNOT</String>
The Microsoft tools produce a so called undocumented "Rich" part at the
beginning. That was expressed by line like:
<String>RICH</String>
Some tools do not produce such part. So the above line vanish.
Many tools especially the Microsoft programs produce code section with name
".text" and data section with name ".data". That was expressed by lines
like:
<String>.DATA</String>
<String>.TEXT</String>
Some compiler suites like from Borland instead use the names "TEXT" and
"DATA". So the 2 above lines now become like:
<String>DATA</String>
<String>TEXT</String>
When looking in old and updated cpl-win.trid.xml i see no phrase, that seems
to be characteristic for CPL samples.
So for reverse test purpose i run trid with the old and updated definition
variant on 39431 MZ samples with EXE file name extension. 3088 are
misidentified as CPL by old variant and 15492 samples are misidentified by
updated variant. So that definition file is not well suited to distinguish
clearly CPL samples from EXE samples.
For comparison reasons i also run other identifying tools on such examples.
The file command identifies some examples especially found in SysWOW64 sub
directory inside Windows directory as "PE32 executable (DLL)" and "Intel
80386, for MS Windows" (See appended SysWOW64_7/output/file-5.39.txt). So i
run tridscan on such examples to generate cpl-win-32.trid.xml for 32-bit CPL
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
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>
The file command identifies some examples especially found in System32 sub
directory inside 64-bit Windows directory 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 cpl-win-64.trid.xml for 64-bit CPL
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
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 by line like:
<String>PE''D</String>
I found also examples belonging to Windows 3.1 and 95. The file command
identifies such examples as "executable, NE for MS Windows 3.x (DLL or
font)" (See appended NE_/output/file-5.39.txt). So i run tridscan on such
examples to generate cpl-win-16.trid.xml for such CPL samples.
I also found some old Windows NT 3.1 CPL variants. The file command
identifies such examples as "PE32+ executable (DLL)" and "MIPS R4000" (See
appended MIPS/output/file-5.39.txt). So i run tridscan on such examples to
generate cpl-win-mips.trid.xml for such CPL 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
format. For MIPS little endian this value is 0x0166 and for MIPS16 with FPU
this value is 0x0466. That gives in ASCII the Letter f after 4 byte
signature. That is expressed in trid definition by line like:
<String>$'''''''PE''F</String>
I also found one example of imdisk.cpl, that is identified by the file
command as "PE32+ executable (DLL)" and "Intel Itanium, for MS Windows" (See
appended Itanium/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 the Intel Itanium processor
family this value is 0x0200. That would be expressed in trid definition by
line like:
<String>PE''''</String>
Unfortunately now also no clear distinguish between CPL and EXE samples is
still possible. When running trid with bit variants, 6897 EXE samples are
misidentified as "Windows Control Panel Item (32-bit)" and 385 samples are
misidentified as "Windows Control Panel Item (64-bit)".
So i look for other methods. Many CPL samples export a function with name
CPlApplet. (This can be shown by -e option (dump exports directory table) of
pelook tool). So i run tridscan on such samples to generate
cpl-win-applet.trid.xml. Now a characteristic line is found in global string
section. That is expressed by line like:
<String>CPLAPPLET</String>
Now 351 examples are identified by cpl-win-applet.trid.xml.
The samples that are not detected by this definition, contain in most cases
a resource section (.rsrc) with OriginalFilename. That is something like
APPWIZ.CPL, hdwwiz.cpl or sysdm.cpl stored as UTF16 string. This can be
shown for example by -v option (display version resource) of pelook tool. So
the stored name extension is ".cpl". So when i run tridscan to generate
cpl-win-extension-utf16.trid.xml. These characteristic phrases as UTF-16
strings are expressed in side global string section by lines like:
<String>O'R'I'G'I'N'A'L'F'I'L'E'N'A'M'E</String>
<String>.'C'P'L</String>
With this second definition now more 74 CPL samples are now described (See
for example appended extension/output/trid-v-new.txt)
Unfortunately still a few CPL samples like bthprops.cpl and irprops.cpl are
not recognized. These are part of the WINE project. Some of the included CPL
do not export function CPlApplet ( See bthprops-pelook.txt and
irprops-pelook.txt in cpl_wine-6.0/ascii/output). Also some Reactos
ncpa.cpl falls in that category ( see ncpa-pelook.txt in
reactos04.3/ascii/output and reactos04.13/ascii/output).
So i run tridscan on such samples to generate
cpl-win-extension.trid.xml. But somewhere in the binary the filename with
.cpl extension is stored as ASCII string. That characteristic is expressed
inside global string section by line like:
<String>.CPL</String>
For comparison reasons i also run other identifying tools on such examples.
The file command identifies some examples as "PE32 executable (DLL)" and
"Intel 80386, for MS Windows" (See appended file-5.39.txt in
reactos04.3/ascii/output and reactos04.13/ascii/output). 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>
When the WINE CPL samples contain a resource section, then these samples are
recognized by cpl-win-extension.trid.xml (See appended
cpl_wine-6.0/output/trid-v-new.txt).
Just for interest i generate by tridscan cpl-wine.trid.xml from such
examples. In the end i get in global string section characteristic lines for
WINE examples. That looks like:
<String>PE''L</String>
<String>WINE</String>
But as far as i can see i get no characteristics for CPL. So probably also
WINE executables and other libraries are identified by that definition. So
that XML file is not really suitable for precise detection.
Unfortunately also some versions of conhost.exe, control.exe, explorer.exe
and Ray Hinchliffe SIV exectables like SIV64X.exe are misidentified as CPL
by cpl-win-applet.trid.xml because these examples contain also the string
CPlApplet somewhere inside the binary. So i mention these exceptions inside
the remark line. (See appended exe_cpl/output/trid-v-new.txt). Later i
found 3 more similar executables like msmsgs.exe, sethc.exe and UBUSB.exe
(See appended exe_cpl_/output/trid-v-new.txt).
Unfortunately also some versions of executables are misidentified as CPL by
cpl-win-extension.trid.xml because these examples contain also the string
.cpl inside the binary. As expected 2 main programs like control.exe and
explorer.exe call control panels programs. But also other Microsoft
executables like irftp.exe, Journal.exe, mblctr.exe, MuiUnattend.exe and
SndVol.exe seems to call or refer control panel tools. And for Microsoft
Imaging Devices Control Panel the stored name is ImagingDevices.exe and not
ImagingDevices.cpl. (See appended exe_cpl/output/trid-v-new.txt). So i
mention theses exceptions inside the remark line. Later i found 4 more
executables like AcroRd32.exe, FlashPlayerApp.exe, Setup.exe and UBUSB.exe
calling or referring other control panels. (See appended
exe_cpl_/output/trid-v-new.txt).
With the 3 new definition variants most CPL samples are now recognized with
higher reliability (See appended output/trid-v-new.txt).
TrID definition, some examples and output are stored in archive cpl.zip. I
hope that my 3 XML files cpl-win-applet.trid.xml, cpl-win-extension.trid.xml
and cpl-win-extension-utf16.trid.xml can be used in future version of triddefs.
With best wishes
Jörg Jenderek
