[File] Magdir for aria control file *.aria2

Fri Dec 24 18:09:08 UTC 2021

Committed thanks!

Happy Holidays,

christos

> On Dec 22, 2021, at 5:02 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> some times ago i send patches for Atari DEGAS bitmap.
> 
> Unfortunately the weak starting sequence 0x0001 of medium resolution
> bitmap *.PI2 also occur in aria control files.
> Now i inspect such control files with file name extension aria2,
> which are produced by download tool client aria2c during work progres
> s.
> 
> When running running file command version 5.41 on such control files
> and related files i get an output like:
> 
> 8GadgetPackSetup.msi:        Composite Document File V2 Document,
> 			     Little Endian, Os: Windows, Version 6.2,
> 			     MSI Installer, Code page: 1252,
> 			     Title: Installation Database,
> 			     Subject: 8GadgetPack,
> 			     Author: 8GadgetPack.net,
> 8GadgetPackSetup.msi.aria2:  data
> DIAGRAM1.PI2:                dBase III DBT, version number 0,
> 			     next free block index 256,
> 			     1st item "\377\377"
> GAMEOVR4.IMG:                GEM XIMG Image data 256 x 176,
> 			     4 planes, 372 x 372 pixelsize
> ST_TOOLS.PI2:                data
> gnucash-4.8.setup.exe:       PE32 executable (GUI) Intel 80386,
> 			     for MS Windows
> gnucash-4.8.setup.exe.aria2: data
> load-nonBt-v0001.aria2:      data
> load-v0001.aria2:            data
> medres.pi2:                  data
> 
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). All aria control
> files are misidentified as "DEGAS med-res bitmap" with PI2 file name
> extension by bitmap-pi2-degas.trid.xml, because of same weak 2 byte
> starting pattern (See appended aria-trid-v.txt.gz).
> 
> Luckily on German Wikipedia was a page about Aria software. On
> referenced software page on GitHub is a document with technical notes
> (especially the aria2 control file format). That is expressed inside
> Magdir aria.txt by comment lines likes:
> # URL: 		https://de.wikipedia.org/wiki/Aria_(Software)
> # Reference:	https://github.com/aria2/aria2/
> #		blob/master/doc/manual-src/en/technical-notes.rst
> 
> Unfortunately there exist no strong significant magic pattern (only 2
> bytes) for such control files. So i put displaying part inside sub
> routine aria which starts like:
> 0	name		aria
>> 0	beshort		x	aria2 control file, version %u
> !:mime	application/x-aria
> !:ext	aria2
> 
> The first 2 bytes determinate the version. It should be either
> version 0 (0x0000) or version 1 (0x0001). In version 1, all
> multi-byte integers are saved in network byte order (big endian). In
> version 0, all multi-byte integers are saved in host byte order. I
> handle only version 1 variant, because i found no older version 0
> examples. Instead of generic mime type application/octet-stream i
> show a user defined one and display used filename extension aria2.
> 
> Afterwards 4 EXTENSION bytes are stored. Here i found only value 0 or
> 1. According to specification aria2 checks whether the saved Info Has
> h
> and current downloading one are the same ( called "infoHashCheck"
> extension) if EXT[3]&1 == 1.
> So show non zero value by line like:
>> 2		ubelong		!0	\b, infoHashCheck %#x
> 
> Afterwards show info hash information if available (like in example
> load-v0001.aria2) by lines like
>> 6		ubelong		!0	\b, %x bytes info hash
>>> 10		ubequad		x	%#16.16llx...
> Afterwards show other length information by lines like:
>> (6.L+10)	ubelong		x	\b, piece length 0x%x
>> (6.L+14)	ubequad		x	\b, total length %llu
>> (6.L+22)	ubequad		!0	\b, upload length %#llx
> 
> With these information i was able to identify such control files by
> lines like:
> 0		beshort			0x0001
>> 2		ubelong&0xffFFffFE	0x00000000
>>> (6.L+14)	ubequad			>0
>>>> 0		use     		aria
> 
> The first test line checks for valid version number of one variant.
> This test is also true for DEGAS PI2 bitmaps and GEM IMG bitmaps. By
> second test for valid infoHashCheck extension probably all DEGAS PI2
> bitmaps are skipped. Interpreting EXT value as DEGAS colour palette
> entry would mean a bitmap with black (0000) in first entry and also
> black again in second entry or "nearly black with little blue" (0001)
> in second entry. But PI2 images have only 4 colors. So you maybe find
> on black entry but typically the second entry is another contrast
> colour like white (0777 or 0FFFF). Finally i found one such
> unlikely example DIAGRAM1.PI2 with 2 black colour entries at
> beginning of palette. Also GEM IMG graphics are skipped by second
> test, because there at offset 2 the header size is stored which is
> significantly higher than 0 or 1. By third test i check for valid
> total download length (At the moment greater than zero).  By this
> test line DIAGRAM1.PI2 is skipped because there value at possible
> offset gives invalid length 0.
> 
> After applying the above mentioned modifications by aria.txt then
> former diff for DEGAS images then all my aria control files are
> correctly identified and are different from Atari Degas bitmaps and
> GEM IMG graphics. This now looks like:
> 
> 8GadgetPackSetup.msi:        Composite Document File V2 Document,
> 			     Little Endian, Os: Windows, Version 6.2,
> 			     MSI Installer, Code page: 1252,
> 			     Title: Installation Database,
> 			     Subject: 8GadgetPack,
> 			     Author: 8GadgetPack.net,
> 8GadgetPackSetup.msi.aria2:  aria2 control file, version 1,
> 			     piece length 0x100000,
> 			     total length 27517992,
> 			     0x4 bytes bitfield 0x1...
> DIAGRAM1.PI2:                Atari DEGAS Elite bitmap 640 x 200 x 4,
> 			     color palette 0000 0000 0777 0777 0000
> GAMEOVR4.IMG:                GEM XIMG Image data 256 x 176,
> 			     4 planes, 372 x 372 pixelsize
> ST_TOOLS.PI2:                Atari DEGAS Elite bitmap 640 x 200 x 4,
> 			     color palette 0fff 0f00 00f0 0000 0fff
> gnucash-4.8.setup.exe:       PE32 executable (GUI) Intel 80386,
> 			     for MS Windows
> gnucash-4.8.setup.exe.aria2: aria2 control file, version 1,
> 			     piece length 0x100000,
> 			     total length 153249768,
> 			     0x13 bytes bitfield
> load-nonBt-v0001.aria2:      aria2 control file, version 1,
> 			     piece length 0x400,
> 			     total length 81920,
> 			     0xa bytes bitfield 0xffffffffffffffff...
> load-v0001.aria2:            aria2 control file, version 1,
> 			     infoHashCheck 0x1,
> 			     0x14 bytes
> 			     info hash 0x1122334455667788...,
> 			     piece length 0x400,
> 			     total length 81920,
> 			     upload length 0x400,
> 			     0xa bytes bitfield 0xffffffffffffffff...
> medres.pi2:                  Atari DEGAS Elite bitmap 640 x 200 x 4,
> 			     color palette 0777 0700 0070 0000 0007
> 
> I hope my aria template for Magdir can be applied in future version
> of file utility.
> 
> With best wishes
> Jörg Jenderek
> - --
> Jörg Jenderek
> 
> 
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYcOgWAAKCRCv8rHJQhrU
> 1nmhAKCX/RoBtNY516Dz8WiKgzs8S1QUZgCdEgKx/8GXEJI62nLf3wrpScVLUTQ=
> =cJOs
> -----END PGP SIGNATURE-----
> <aria.txt><aria_txt_sig.DEFANGED-856><aria-trid-v.txt.gz>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20211224/1e09dbf6/attachment.asc>