variant moz-fb-xpi-v45.trid.xml for newer Mozilla Firefox browser extension

[jenderek]

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

[Mark0]

Thanks for the update, but it really seems that this kind of files bears too little distinctions from plain ZIP files.