Hello trid users,
Some weeks ago i handled some software packages made by InstallShield. In
some (uh! only 3) cases are files with name setup.ibt.
When running TrID command on such IBT examples these samples are described
as "Unknown!" (See appended output/trid-v-old.txt).
For comparison reason i also run file command on such samples. Here these
are described as "InstallShield archive" with "MS Compress archive data,
SZDD variant". (See appended output/file-5.43.txt).
So i run tridscan on examples to create ibt.trid.xml. Characteristic is
described inside global strings section by line like:
<String>2'SZDD</String>
I explain later why this becomes to line like :
<String>'SZDD</String>
When looking inside IBT examples i saw SZDD string and got the thought that
these InstallShield archives are just containing SZDD compressed files. So
with the help of hexl-mode of emacs and dd tools i split IBT examples in
parts with BIN file name extension. And not surprisingly some are
identified by file command as "MS Compress archive data, SZDD variant" and
are described as "Microsoft SZDD compressed (Haruhiko Okumura's LZSS)" by
szdd.trid.xml. But this could be happen luckily. On mentioned site download
links for tools are listed. So i verified information partly by decoding
tool deark and 7-zip package tool (See appended 7z-l-bin.txt.gz) by command
lines like:
deark -l -m lzss_oku -d2 setup-1-41.bin
7z l -tMsLZ -slt *.bin
So i know the SZDD starting parts are really compressed archives. So i
choose there mentioned reference URL also here by line like:
<RefURL>
http://fileformats.archiveteam.org/wiki/MS-DOS_installation_compression </RefURL>
Unfortunately from Install shield there exist no file format
specification. I was lucky that on flexera.com the existence of setup.ibt is
mentioned as part of InstallShield Redistributable Files. See
https://community.flexera.com/t5/InstallShield-Knowledge-Base/InstallShield-Redistributable-Files/ta-p/5647
Now i look at bytes before SZDD magic. This part contain 4 nil terminated
text strings. The first is apparently the name of compressed archive member
(like: setup.dl_ _setup7int.dl_ _setup2k.dl_ _igdi.dl_ cabinet.dl_). So this
is shown by file command as first file name. Apparently this is the
modified original name where last character is replaced by underscore.
Afterwards apparently comes the name of uncompressed original file (like:
setup.dll _Setup.dll IGdi.dll CABINET.DLL). So this information is shown by
file command as name inside parentheses.
In my examples the first combination was always setup.dl_ (setup.dll). This
is expressed inside front block by XML construct like:
<Bytes>73657475702E646C5F0073657475702E646C6C00</Bytes>
<ASCII> s e t u p . d l _ . s e t u p . d l l</ASCII>
<Pos>0</Pos>
This is also expressed inside global strings section by line like:
<String>SETUP.DL_'SETUP.DLL</String>
But i do not know if this always true. After the first SZDD part comes the
next IBT part, which use again structure found for first IBT part. So we
found more library names. These are expressed inside Global Strings section
by lines like:
<String>CABINET.DL_'CABINET.DLL'1.0.601.0'40</String>
<String>IGDI.DL_'IGDI.DLL</String>
<String>.DL_'_SETUP.DLL</String>
The third string is point separated digits (like 9.0.0.333 9.1.0.429
11.50.0.42618 1.0.601.0). Probably this is a kind of version. So this
information is shown by file command after version phrase. Assuming that
there exist also other version numbers. So the above line becomes like:
<String>CABINET.DL_'CABINET.DLL'</String>
Because only a few samples are used to generate definition i get an average
of version numbers, That was expressed by XML construct like
<Bytes>302E</Bytes>
<ASCII> 0</ASCII>
<Pos>24</Pos>
I assume that there exist also other version number strings. SO i delete
that pattern.
Then there exist many short patterns like:
<Pattern>
<Bytes>00</Bytes>
<Pos>50</Pos>
</Pattern>
<Pattern>
<Bytes>7424</Bytes>
<ASCII> t $</ASCII>
<Pos>1027</Pos>
</Pattern>
Because i know this part SZDD compressed part these pattern i just created
by lucky circumstance ( or too few examples). So i delete these patterns.
In global string are short patterns like:
<String>B}R}B}</String>
<String>C0%H1P</String>
<String>J-Z-J-</String>
<String>L$8+N{</String>
<String>QRUPW</String>
<String>QRYAF</String>
I assume that these are generate by lucky circum stance (too few examples)
So i delete such patterns.
Because the IBT archive contains Windows Dynamic Link Libraries (*.DLL) i
get inside global string section still some lines which are characteristic
for DLL. So i keep such lines like:
<String>PE''L</String>
<String>THIS</String>
<String>HIS PROG</String>
<String>IN DOS M</String>
<String>M CANNOT</String>
<String>SHELLEX</String>
<String>.RDATA</String>
<String>.DEBU</String>
<String>.RSRC</String>
<String>.TEXT</String>
<String>GETDLL</String>
As fourth part comes a number string (like 168048 169333 181842). When
counting this number from SZDD magic you jump to next archive text block. So
apparently this is the SZDD member length. So this information is shown by
file command before "bytes" phrase.
Instead of generic mime type application/octet-stream i show the user
defined one also shown by file command (See appended
output/file-i-5.43.txt).
With the new trid definition now my IBT examples are identified (see
appended output/trid-v-new.txt). TrID definition and output are stored in
archive ibt_trid.zip. I hope that my XML file can be used in future version
of triddefs.
With best wishes
Jörg Jenderek
