Author Topic: updated ocx.trid.xml.xml for Windows ActiveX control *.ocx  (Read 1563 times)

jenderek

  • Sr. Member
  • ****
  • Posts: 375
updated ocx.trid.xml.xml for Windows ActiveX control *.ocx
« on: December 01, 2020, 11:17:03 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 OCX
file name extension are Windows ActiveX controls.

All 64-bit examples are not described by ocx.trid.xml.xml as "Windows
ActiveX control". Instead these are described only generic 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 64-bit examples as "PE32+ executable (DLL)"
and "x86-64, for MS Windows" (see appended output/file-5.39.txt). It also
displays correct file name extension ocx for such special DLL (see appended
output/file-extension-5.39.txt).

So i run tridscan on 6 undetected samples and i update a trid definition
file ocx.trid.xml.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 also the following one 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.

Then i still found one 32-bit example like SysWOW64/msdxm.ocx that is not
recognized (see appended SysWOW64/output/trid-v-old.txt). So i run tridscan
on that undetected sample and i update the trid definition file
ocx.trid.xml.xml. now in global string section 1 line vanished. That is:
   String>T'Y'P'E</String>

Because such OCX 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>

I find on the web no good site about OCX file format. So i choose a site on
Microsoft Server about How to register an ActiveX control (.ocx). That is
expressed now by reference URL line like:
 <RefURL>
 https://support.microsoft.com/en-us/office/
 how-to-register-an-activex-control-ocx-manually-27ea0fc7-7629-1a38-1f5b-1e57c2c22437
 </RefURL>

Then i find 4 other OCX files, that are not recognized by trid (see appended
wine/output/trid-v-new.txt), but recognized by file command as 32-bit DLL
(See wine/output/file-5.39.txt). These samples are found inside WINE
directories and are too different from "normal" OCX samples. For example in
the DOS stub it contains the phrase "WINE PLACEHOLDER DLL" instead of normal
"This program cannot be run in DOS mode".

So i run tridscan on these 4 samples and i generate trid definition file
ocx-wine.trid.xml. I find no file format explanation, but i assume that such
OCX files are still ActiveX control libraries, but suited for WINE instead
of Windows. This is expressed by line like:
   <FileType>Wine ActiveX control </FileType>

Unfortunately i find no web page about that file format. So i choose man
page of WINE software. That is expressed by reference URL line like:
   <RefURL>https://www.winehq.org/</RefURL>

When looking in updated trid definition i do not know which phrases are
unique enough to distinguish OCX 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 2 definitions the unspecific described OCX files are now described
more precisely (see appended output/trid-v-new.txt
wine/output/trid-v-new.txt). TrID definition, some examples and output are
stored in archive ocx.zip. I hope that my 2 XML files 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 ocx.trid.xml.xml for Windows ActiveX control *.ocx
« Reply #1 on: December 01, 2020, 11:31:18 PM »
Thanks!