Author Topic: updated ax.trid.xml for DirectShow filter *.ax  (Read 1474 times)

jenderek

  • Sr. Member
  • ****
  • Posts: 375
updated ax.trid.xml for DirectShow filter *.ax
« on: November 25, 2020, 08:49:21 PM »
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 AX file
name extension are DirectShow filter. Many are not identified by ax.trid.xml
as DirectShow filter *.ax. These samples are only described by dll.trid.xml
as "Win32 Dynamic Link Library (generic)" or by exe-generic.trid.xml as
"Generic Win/DOS Executable" (see appended output/trid-v.txt).

For comparison reasons i also run other identifying tools on such
examples. The file command identifies most inspected examples as "PE32+
executable (DLL)" for Microsoft Windows (see appended
output/file-5.39.txt). It also displays correct file name extension ax for
such special DLL (see appended output/file-extension-5.39.txt).

A little bit of information is found on Wikipedia. That is expressed now by
reference URL line like:
   <RefURL>https://en.wikipedia.org/wiki/DirectShow</RefURL>

Unfortunately there is not written about the AX file format and how to
handle it. After searching on the net, there it is written that ax files are
Windows dynamic link libraries (DLL) and how these get installed in the
system. So i mention this by a remark line like:
   <Rem>Installed by `regsvr32 example.ax`</Rem>

Because such AX 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 these samples and i update a trid definition file
ax.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>4D5A9000
   <ASCII> M Z . .
   <Pos>0</Pos>
In global strings section now some lines vanish or are shortened like:
   <String>INTERLOCKEDINCREMENT</String>
   <String>INTERLOCKEDDECREMENT</String>
   <String>KERNEL32.DLL</String>
I am no expert for DLL files, but probably such strings are in some example
too far from the beginning.

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 looking in updated trid definition i see no unique phrase, that is
characteristic for DirectShow filters. 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 AX files are now
described more precisely (see appended output/trid-new-v.txt). TrID
definition and output are stored in archive ax.zip. I hope that my XML file
can be used in future version of triddefs.

With best wishes
Jörg Jenderek

Mark0

  • Administrator
  • Hero Member
  • *****
  • Posts: 2743
    • Mark0's Home Page
Re: updated ax.trid.xml for DirectShow filter *.ax
« Reply #1 on: November 26, 2020, 12:44:22 PM »
Thanks for the new def.
I think that this kind of files, like other executable-like, definitely need a revamp, with a clear distinction from 32 and 64bit, if it's even possible.