[File] Magdir for aria control file *.aria2
Jörg Jenderek
joerg.jen.der.ek at gmx.net
Wed Dec 22 22:02:00 UTC 2021
-----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-----
-------------- next part --------------
#------------------------------------------------------------------------------
# URL: https://de.wikipedia.org/wiki/Aria_(Software)
# Reference: https://github.com/aria2/aria2/blob/master/doc/manual-src/en/technical-notes.rst
# From: Joerg Jenderek
# Note: only version 1 suited
# check for valid version one
0 beshort 0x0001
# skip most uncompressed DEGAS med-res bitmap *.PI2 and GEM bitmap (v1) *.IMG
# by test for valid infoHashCheck extension
>2 ubelong&0xffFFffFE 0x00000000
# skip DEGAS med-res bitmap DIAGRAM1.PI2 by test for valid length of download
>>(6.L+14) ubequad >0
>>>0 use aria
0 name aria
# version; (0x0000) or (0x0001); for 0 all multi-byte are in host byte order. For 1 big endian
>0 beshort x aria2 control file, version %u
#!:mime application/octet-stream
!:mime application/x-aria
!:ext aria2
# EXTension; if EXT[3]&1 == 1 checks whether saved InfoHash and current downloading the same; infoHashCheck extension
>2 ubelong !0 \b, infoHashCheck %#x
# info hash length like: 0 14h
>6 ubelong !0 \b, %#x bytes info hash
# info hash; BitTorrent InfoHash
>>10 ubequad x %#16.16llx...
# piece length; the length of the piece like: 400h 100000h
>(6.L+10) ubelong x \b, piece length 0x%x
# total length; the total length of the download
>(6.L+14) ubequad x \b, total length %llu
#>(6.L+14) ubequad x \b, total length %#llx
# upload length; the uploaded length of download like: 0 400h
>(6.L+22) ubequad !0 \b, upload length %#llx
# bitfield length; the length of bitfield like: 4 6 Ah 10h 13h 167h
>(6.L+30) ubelong x \b, %#x bytes bitfield
# bitfield; bitfield which represents current download progress
>(6.L+34) ubequad !0 %#llx...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aria.txt.sig
Type: application/octet-stream
Size: 941 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20211222/39865f05/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aria-trid-v.txt.gz
Type: application/x-gzip
Size: 1420 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20211222/39865f05/attachment.bin>
More information about the File
mailing list