Hello trid users,
some days ago just for interest i inspect efi executables starting with MZ
magic. Afterwards i look for other MZ-executables. Such samples with ACM
file name extension are Windows Audio Compression Manager driver.
A few like sample SysWOW64_8/l3codec.acm are identified by acm.trid.xml as
Windows Audio Compression Manager driver. Other 32-bit examples are only
described by dll.trid.xml as "Win32 Dynamic Link Library (generic)" (see
appended SysWOW64_8/output/trid-v-old.txt). The undetected 64-bit samples
are described by exe-win64.trid.xml as "Win64 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 the 32-bit examples as "PE32 executable (DLL)"
and "Intel 80386, for MS Windows" (see appended
SysWOW64_8/output/file-5.39.txt). The recognized 32-bit example l3codeca.acm
is characterized as console variant, whereas the undetected 32-bit examples
are described as GUI variant. It also displays correct file name extension
acm for such special DLL (see appended
SysWOW64_8/output/file-extension-5.39.txt).
Instead of generic Microsoft web site i use Microsoft overview site about
Audio Compression Manager (ACM). That is expressed now by reference URL line
like:
<RefURL>
https://docs.microsoft.com/en-us/windows/win32/multimedia/audio-compression-manager </RefURL>
Because such ACM 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), but the Wikipedia page about Portable Executable
mention another mime type. That is expressed by line like:
<Mime>application/vnd.microsoft.portable-executable</Mime>
So i run tridscan on undetected samples and i update a trid definition file
acm.trid.xml. All my samples 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>
After updating trid definition with 5 32-bit samples in global strings section
now some lines vanish like:
<String>KERNEL32.DLL</String>
<String>USER32.DLL</String>
<String>WINMM.DLL</String>
<String>STRING</String>
or are shortened like:
<String>2.DLL</String>
Not surprisingly because the GUI variants depend on other libraries like
api-ms-win-core-processthreads-l1-1-2.dll instead of KERNEL32.DLL.
After running tridscan on 64-bit examples (These are identified by file
command as" PE32+ executable" and "x86-64, for MS Windows") now also the
following string line totally disappeared:
<String>PE''L</String>
Surprisingly i did not expect this behavior. 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. For Intel/AMD x64 CPU type this values is
0x8664. Then we get letter d after 4 byte signature. So the above line after
running tridscan on 64 bit examples should be become like:
<String>PE''</String>
Surprisingly that line now completely vanished. Maybe now the magic pattern
has become too short. So i manually insert that line in string section.
When running tridscan on 4 more undetected examples in global string section
more lines get shorter like:
<String>2.DLL</String>
<String>GETDRIVERMODULEHANDLE</String>
This then becomes like:
<String>.DLL</String>
<String>MODULEHANDLE</String>
When looking in updated trid definition i do not know which phrases are
unique enough to distinguish ACM samples from other DLL. So maybe this is a
behavior also found for the Windows screen savers. So maybe it is advisable
to generate different TrID definition for 32 and 64 bit Windows systems.
With the updated definition the unspecific described ACM files are now
described more precisely (see appended output/trid-v-new.txt). TrID
definition and output are stored in archive acm.zip. I hope that my XML file
can be used in future version of triddefs.
With best wishes
Jörg Jenderek
