Hello trid users,
some days ago handled some omni.ja files which are part of Firefox and
Thunderbird installation.
Now i take a look at cross-platform installer modules or addons with file
name extension XPI for such Mozilla products.
When i run TrID on examples all are described correctly generic as "ZIP
compressed archive" by ark-zip.trid.xml. Older versions like
noscript_security_suite-2.9-sm+fx+fn.xpi are also described as "Mozilla
Firefox browser extension" by moz-fb-xpi.trid.xml but for newer examples
like noscript_security_suite-11.2-an+fx.xpi there is no such description
(see appended output/trid-v-old.txt).
For comparison reason i also run the file utility (version 5.40). This
describes this examples with keep-going option as "Zip archive data" (see
appended output/file-k-5.40.txt).
According to documentation XPI packages contain a JavaScript install script
(install.js) or a RDF file (install.rdf). This specific criteria is
expressed inside global strings section of moz-fb-xpi.trid.xml by XML
construct like:
<String>INSTALL.</String>
When we look in listing output of archives we see that newer packages does
not contain such an installer file any more. Instead these examples all
contain a manifest.json file (see appended output/7z-l.txt).
That is mentioned in up-to-date documentation about XPI like on
Wikipedia. So this is mentioned by line like:
<RefURL>
https://en.wikipedia.org/wiki/XPInstall</RefURL>
So this changed package layout is expressed in new tridscan generated
definition moz-fb-xpi-v45.trid.xml by XML construct like:
<String>MANIFEST.JSON</String>
This new package format is used in newer XPI versions since Firefox version
45.
The first pattern is characteristic for central directory file head of ZIP
packages. That looks like:
<Bytes>504B0304</Bytes>
<ASCII> P K</ASCII>
<Pos>0</Pos>
At offset 8 the general purpose bit flag is stored as 2 byte little endian
integer. Here i found that upper byte was always nil. That means bits 8 til
15 are zero. That means no language encoding, enhanced compression and
alternate streams. That is expressed by second XML construct like:
<Bytes>00</Bytes>
<Pos>9</Pos>
At offset 20 the compressed size is stored as 4 byte little endian
integer. I expect that all values are possible. So the following XML
construct was triggered by lucky circumstances and should be removed:
<Bytes>00</Bytes>
<Pos>21</Pos>
At offset 24 the uncompressed size is stored as 4 byte little endian
integer. I expect that all values are possible. So the following XML
constructs were triggered by lucky circumstances and should be removed:
<Bytes>00</Bytes>
<Pos>25</Pos>
<Bytes>00</Bytes>
<Pos>27</Pos>
At offset 28 the Extra field length is stored as 2 byte little endian
integer variable m. In my examples value was lower 256. That means upper
byte is nil. That is expressed by XML construct like:
<Bytes>00</Bytes>
<Pos>29</Pos>
Instead of mime type application/zip for valid ZIP the XPI packages get
there own type. That is expressed by line like:
<Mime>application/x-xpinstall</Mime>
With my trid definition now also new XPI examples are now recognized (see
appended output/trid-v.txt). TrID definition, some examples and output are
stored in archive xpi.zip. I hope that the XML file can be used in future
version of triddefs.
But things are become worse. Some Mozilla add ons ( with XPI extension)
seems to also use the optimized ZIP layout variant of OMNI.JA and identification as
"Java Archive" by java-jar.trid.xml still comes first.
With best wishes
Jörg Jenderek
