[File] [PATCH] Magdir/images, mcrypt for NetCDF Data Format, mcrypt encrypted *.NC
Christos Zoulas
christos at zoulas.com
Tue Feb 8 21:04:52 UTC 2022
Applied, thanks. Sorry for the delay.
christos
> On Feb 1, 2022, at 6:20 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> some days ago i handled some NetCDF Data samples with file name
> extension NC.
>
> When running file command version 5.41 on such examples and related
> files i get an output like:
>
> 19981111_0045.nc: NetCDF Data Format data
> HRDL_iop12-example.nc: NetCDF Data Format data
> README.txt.nc: mcrypt 2.5 encrypted data,
> algorithm: rijndael-128,
> keysize: 32 bytes, mode: cbc,
> bad_cdf5_begin.nc: data
> dmake.nc: ASCII text, with CR line terminators
> fmt-282-signature-id-298.nc: NetCDF Data Format data
> fmt-283-signature-id-299.nc: NetCDF Data Format data (64-bit offset)
> rhum.2003.nc: NetCDF Data Format data
> test_echam_spectral.nc: NetCDF Data Format data
> tst_small_64bit.nc: NetCDF Data Format data (64-bit offset)
>
> Furthermore with -i option only generic application/octet-stream or
> text/plain is shown. With option --extension only 3 byte sequence ???
> is shown.
>
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). Most examples are
> described as "NetCDF Network Common Data Form" with mime type
> application/netcdf by netcdf.trid.xml. The example README.txt.nc is
> described as "mcrypt encrypted (v2.5)" with application/octet-stream
> by nc-mcrypt.trid.xml (See appended nc-trid-v.txt.gz).
> Luckily TrID tool displays correct file name extension NC for
> inspected samples. This list with -v option the related URL pointing
> to used file information.
>
> For comparison reason i also run the file format identification
> utility DROID ( See https://sourceforge.net/projects/droid/). This
> identifies most as "netCDF-3 Classic" by PUID fmt/282. Example
> tst_small_64bit.nc is described as "netCDF-3 64-bit" by PUID fmt/283.
> As mime type here application/netcdf and application/x-netcdf is
> shown. (See appended DROID-nc.csv.gz)
>
> That informations are expressed by comment lines inside Magdir/images
> like:
>
> # URL: https://en.wikipedia.org/wiki/NetCDF
> # http://fileformats.archiveteam.org/wiki/NetCDF
> # Ref.: http://mark0.net/download/triddefs_xml.7z
> # defs/n/netcdf.trid.xml
> # https://www.loc.gov/preservation/digital/formats/
> # fdd/fdd000330.shtml
>
> The description happen by lines like:
> 0 string CDF\001 NetCDF Data Format data
> 0 string CDF\002 NetCDF Data Format data (64-bit offset)
>
> This now becomes like:
> 0 string CDF\001
>> 3 leshort >0 NetCDF Data Format data
> !:mime application/x-netcdf
> !:ext nc
> 0 string CDF\002
>> 3 leshort >0 NetCDF Data Format data (64-bit offset)
> !:mime application/x-netcdf
> !:ext nc
>
> The DROID signatures contain just the 4 magic bytes. So the
> 2 examples fmt-282-signature-id-298.nc and
> fmt-283-signature-id-299.nc are identified as NetCDF, but in
> reality these examples contain no data. To skip these examples i
> test also for bytes afterwards by second line. Some sites us the
> mime type application/netcdf, but i found no such official
> registered type.
> So i apply the user defined one. According to www.file-extensions.org
> cdf was used as file name extension, but in 1994 changed to NC to
> avoid a clash with other file formats using also THE CDF file name
> extension. I my self found no example with CDF extension. So i
> display only the NC extension.
>
> That informations are expressed by comment lines inside Magdir/mcrypt
> like:
>
> # URL: https://en.wikipedia.org/wiki/Mcrypt
> # http://fileformats.archiveteam.org/wiki/MCrypt
> # Reference: http://mark0.net/download/triddefs_xml.7z
> # defs/n/nc-mcrypt.trid.xml
>
>
> The description happen by lines like:
> 0 string \0m\3 mcrypt 2.5 encrypted data,
> This now becomes like:
> 0 string \0m\3 mcrypt 2.5 encrypted data,
> !:mime application/x-crypt-nc
> !:ext nc
> Instead of generic mime type application/octet-stream i display a
> user defined one.
>
> After applying the above mentioned modifications by patches
> file-5.41-mcrypt-nc.diff and file-5.41-images-nc.diff
> then all my inspected examples are now described as before, but
> some misidentification vanish. This now looks like:
>
> 19981111_0045.nc: NetCDF Data Format data
> HRDL_iop12-example.nc: NetCDF Data Format data
> README.txt.nc: mcrypt 2.5 encrypted data,
> algorithm: rijndael-128,
> keysize: 32 bytes, mode: cbc,
> bad_cdf5_begin.nc: data
> dmake.nc: ASCII text, with CR line terminators
> fmt-282-signature-id-298.nc: data
> fmt-283-signature-id-299.nc: data
> rhum.2003.nc: NetCDF Data Format data
> test_echam_spectral.nc: NetCDF Data Format data
> tst_small_64bit.nc: NetCDF Data Format data (64-bit offset)
>
>
> I hope my diff files can be applied in future version of file
> utility. Newer versions are based on the Hierarchical Data Format
> version 5. So these must be handled in a future session.
>
> With best wishes
> Jörg Jenderek
> - --
> Jörg Jenderek
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYfnAVgAKCRCv8rHJQhrU
> 1l73AJoDWuY2YzoVyZ/L+irKEJXqq37XHQCgg1TLp65Sx21fcr3tBMifo7Ak9mQ=
> =LR55
> -----END PGP SIGNATURE-----
> <Nachrichtenteil als Anhang.DEFANGED-53186><file-5_41-mcrypt-nc_diff.DEFANGED-53187><file-5_41-mcrypt-nc_diff_sig.DEFANGED-53188><nc-trid-v.txt.gz><nc-DROID.csv.gz><file-5_41-images-nc_diff.DEFANGED-53189><file-5_41-images-nc_diff_sig.DEFANGED-53190>--
> 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/20220208/264e37ed/attachment.asc>
More information about the File
mailing list