[File] [PATCH] of Magdir/cafebabe, mach, archive for Java byte code *.class, Mach-O universal binary *.dylib *.bundle *.o, Apple DiskCopy

Jörg Jenderek joerg.jen.der.ek at gmx.net
Sat Aug 29 18:27:06 UTC 2020


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

some days ago i handle some thousands compiled Java byte codes with
file name extension class.
When running file command version 5.39 on such examples and other
similar files with -k option i get an output like:

EnglishChunkFilter.class:
	[64-bit architecture=28672]
	[architecture=29961] [architecture=7209082]
	[64-bit architecture=458880] [architecture=8587776]
	compiled Java class data, version 52.0 (Java 1.8)
javaversion.class:
	[architecture=5376]
	[64-bit architecture=808] [architecture=7695714]
	[architecture=2644812] [64-bit architecture=2708993]
	compiled Java class data, version 45.3
Flags$StringJoiner.class:
	[64-bit architecture=7629925]
	[64-bit architecture=7631465] [architecture=6369132]
	[architecture=6386273] [64-bit architecture=5469298]
	compiled Java class data, version 51.0 (Java 1.7)
	Apple DiskCopy 4.2 image þº¾,
	1075809 bytes,
	0x76612f6c tag size, 0x63 encoding, 0x74 format
UNICODE.DAT:
	Apple DiskCopy 4.2 image inc Data File Version 4.0\032,
	67153669 bytes, 0x4f287f2e tag size,
	GCR CLV ssdd (400k), 0x0 format
	(Lepton 3.x), scale 55641-55897,
	spot sensor temperature 11213409064321024.000000,
	color scheme 17, minimum point enabled,
	calibration: offset 3.407858, slope 894661.625000
Disquette Installation 13.image:
	Apple DiskCopy 4.2 image Disquette Installation 13,
	1474560 bytes,
	MFM CAV dshd (1440k), 0x2 format
	(Lepton 2.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000,
	slope 0.000000
Microsoft Mail.image:
	Apple DiskCopy 4.2 image Microsoft Mail,
	819200 bytes,
	0x4b00 tag size, GCR CLV dsdd (800k), 0x22 format
Bzip2.bundle:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 bundle, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL>
	(Lepton 3.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000,
	slope 0.000000]
	[x86_64:Mach-O 64-bit x86_64 bundle, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL>]
	(Lepton 3.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000,
	slope 0.000000
AMDil_r700.dylib:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 bundle, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK>]
	[x86_64]
	(Lepton 3.x), scale 0-51013,
	spot sensor temperature 0.000000,
	color scheme 0,
	calibration: offset -8192.000000,
	slope -0.000000
libclang_rt.asan_watchos_dynamic.dylib:
	Mach-O universal binary with 4 architectures:
	[armv7:Mach-O armv7 dynamically linked shared library, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|
	NO_REEXPORTED_DYLIBS|APP_EXTENSION_SAFE>
	(Lepton 3.x), scale 762-497,
	spot sensor temperature
	-675171784372783770000000000000000000.000000,
	color scheme 0, minimum point enabled, maximum point enabled,
	calibration: offset 852479.187500, slope 0.000000
	(Lepton 2.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000]
	[armv7s:Mach-O armv7s dynamically linked shared library,
	flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|
	NO_REEXPORTED_DYLIBS|APP_EXTENSION_SAFE>
	(Lepton 2.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000]
	[armv7k] [arm64]
	(Lepton 3.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000
	(Lepton 2.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000
libsqlite3.dylib:
	Mach-O universal binary with 3 architectures:
	[i386:Mach-O i386 dynamically linked shared library, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|
	NO_REEXPORTED_DYLIBS|APP_EXTENSION_SAFE>]
	[x86_64] [x86_64_haswell subarchitecture=8]
	(Lepton 2.x), scale 8323-4608,
	spot sensor temperature -0.000000,
	unit celsius, color scheme 18,
	calibration: offset 914063900949478930000000000000.000000,
	slope -0.000000
gcrt1.o:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 object, flags:
	<|SUBSECTIONS_VIA_SYMBOLS>]
	[x86_64:Mach-O 64-bit x86_64 object, flags:
	|SUBSECTIONS_VIA_SYMBOLS>]
a2p5.16:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>]
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]
db_codegen:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>
	(Lepton 3.x), scale 9232-36165,
	spot sensor temperature 0.000000,
	color scheme 8,
	calibration: offset -0.000000, slope 1593.125488
	(Lepton 2.x), scale 59591-22030,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset -0.000000,
	slope -254063184552125390000000000000.000000]
	[x86_64]
file:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>
	(Lepton 3.x), scale 9353-21540,
	spot sensor temperature 0.000000,
	color scheme 8, minimum point enabled,
	calibration: offset 0.000000, slope 0.000000]
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]
perl:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|NO_HEAP_EXECUTION>
	(Lepton 2.x), scale 3108-51012,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset -9671403674613271900000000.000000,
	slope 0.000000]
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]
	(Lepton 3.x), scale 4352-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000
perl5.16:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>
	(Lepton 3.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000]
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>
	(Lepton 2.x), scale 25951-28789,
	spot sensor temperature
	1208812857586044400000000000000000.000000,
	color scheme 0, maximum point enabled,
	calibration: offset 71423472822524088000000000000000.000000,
	slope 293086112594234310000000000.000000]
	(Lepton 2.x), scale 0-0, spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000
perl5.18:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>
	(Lepton 3.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000]
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>
	(Lepton 2.x), scale 25951-28789,
	spot sensor temperature
	1208812857586044400000000000000000.000000,
	color scheme 0, maximum point enabled,
	calibration: offset 71423472822524088000000000000000.000000,
	slope 293086112594234310000000000.000000]
	(Lepton 2.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000
uuidgen:
	Mach-O universal binary with 2 architectures:
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>
	(Lepton 3.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000]
	[x86_64_haswell subarchitecture=8:Mach-O 64-bit
	x86_64_haswell subarchitecture=8 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]
	(Lepton 3.x), scale 0-0,
	spot sensor temperature 0.000000,
	unit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000
	(Lepton 2.x), scale 0-0,
	spot sensor temperature 0.000000,
	nit celsius, color scheme 0,
	calibration: offset 0.000000, slope 0.000000

With --extension option in most cases only ??? is displayed.

By Magdir/measure i get misidentifications starting with phrase
"(Lepton 2.x)" "(Lepton 3.x)". This nearly happens all the
time when running file command with -k option on a few dozens
samples. So this magic file gives too many false hits. So i propose
to deactivate or improve magic lines for DIY-Thermocam raw data files
.

Real Mach-O universal binaries like file or uuidgen found for example
on Mac OS X system are recognized by Magdir/cafebabe by starting line
 0	belong		0xcafebabe

To understand what is going on here, i looked in some Apple open
source header files fat.h and machine.h. That information is added by
reference lines like:
 # Reference:	opensource.apple.com/source/cctools/cctools-949.0.1/
 #		include/mach-o/fat.h
 #		include/mach/machine.h

According to fat.h at offset 4 the number of fat_arch structures (CPU
architectures) is stored as 4 byte unsigned integer variable nfat_arc
h.

In current header file machine.h the different CPU architectures are
listed. First CPU architecture is VAX (CPU_TYPE_VAX=1) and highest
CPU type is PowerPC (CPU_TYPE_POWERPC=18). So in worst or biggest
case a Mach-O universal apparently contains maximal 18 binaries and
for smallest case it contains only one binary.

That information is used as second and third test by magic lines like
:
 >4  belong >1
 >>4 belong <20	 Mach-O universal binary with %d architectures:
 !:mime application/x-mach-binary

Afterwards the 20 bytes sized fat_arch structures should inspected
and information is shown by calling subroutine mach-o. This should be
expressed on test level 3 ( three greater signs ) by lines like
 >>>4	ubelong		>1
 >>>>28	use		mach-o		\b
 >>>4	ubelong		>2
 >>>>48	use		mach-o		\b
Instead this inspection is done on wrong test level 2 ( two greater
signs) like
 >>4	belong		>1
 >>>28	use		mach-o		\b
 >>4	belong		>2
 >>>48	use		mach-o		\b
So every file starting with CAFEBABE magic and positive nfat_arch
value like all Java byte code classes is misidentified as Mach-O
binary. So i correct test level.

On Wikipedia is a page about Java class file. So i add this
information by comment line like
 # Reference:	http://en.wikipedia.org/wiki/Java_class_file

According to documentation compiled Java byte code starts also with
CAFEBABE magic. At offset 4 the minor version number is stored as 2
byte unsigned integer and at offset 6 the major version number is
stored as 2 byte unsigned integer. That information is shown by lines
like
 >>6	ubeshort	x	        version %d.
 >>4	ubeshort	x       	\b%d
For debugging purpose and comparison with Mach-O universal binary
reason that version can be also shown as hexadecimal by line like
 >>4	ubelong		x       	(0x%8.8x)
The oldest and lowest version is 43.0. So all Java versions are above
the "low" nfat_arch value (about 18) of Mach-O universal binaries.
This is used and expressed by lines like
 0	belong		0xcafebabe
 >4	ubelong		>30		compiled Java class data,
Afterward the mime type and now also file name extension is shown by
line like
 !:mime	application/x-java-applet
 #!:mime	application/java-byte-code
 !:ext	class
Some Software use the mime type application/java-byte-code, but when
looking at IANA site such mime type is not officially registered. So
i keep the old user defined one.

The Java version is also show in human readable form by lines likes
 >>4	belong		0x002e		(Java 1.2)
 ...
 >>4	belong		0x0034		(Java 1.8)
Now some newer Versions exist. So according to Wikipedia i show this
information by additional lines like:
 >>4	belong		0x0035		(Java SE 9)
 ...
 >>4	belong		0x003A		(Java SE 14)

For debugging and comparison reason also the non zero pool count and
the pool table can be shown by additional lines like:
 >>8	beshort		x	        \b, pool count 0x%x
 >>10	ubequad		x	        \b, pool 0x%16.16llx...

According to page about Mach-O file format different file name
extensions like dylib are used for Mach-O universal binaries. The
different file types are listed inside header file loader.h. This
information is added as comment line inside Magdir/mach by line like:
 # Reference:	opensource.apple.com/source/cctools/cctools-949.0.1/
 #              include/mach-o/loader.h
So inside sub routine mach-o-be after value 1=MH_OBJECT for
relocatable object files show file name extension by additional line
 !:ext	o/
I add an additional slash "/" at the end because without for
for Mach-O with 2 architectures oo is displayed by --extension option
.
In the same manner after value 6=MH_DYLIB for dynamically bound
shared library show file name extension by additional line like:
 !:ext	dylib/
After value 8=MH_BUNDLE for dynamically bound bundle file show file
name extensions by line like
 !:ext	bundle/dylib/
Must of my inspected samples have bundle name extension, but i
found also an bundle example like AMDil_r700.dylib.
The executables on UNIX like systems normally have no file
extension like perl, but i found exceptions like perl5.18 perl5.16.
So after value 2=MH_EXECUTE for demand paged executables show such
file name extensions by line like:
 !:ext	16/18/
According to header file there seems to exist about a dozen of
different file types. Highest value is 0xb by constant MH_KEXT_BUNDLE
for x86_64 kexts. At the moment only for 4 different file types
(MH_OBJECT=0x1, MH_EXECUTE=0x2, MH_DYLIB=0x6 and MH_BUNDLE=0x8) are
described with extensions.

Some files like Flags$StringJoiner.class, UNICODE.DAT and
windows7en.mbr are misidentified as Apple DiskCopy 4.2 image
by Magdir/archive by lines starting with lines like:
 0x52	ubeshort	0x0100
 >0x40	ubelong		>409599	Apple DiskCopy 4.2 image
 >>00	pstring/B	x	%s
 >>0x40	ubelong		x	\b, %u bytes

After testing for "weak" 2 byte magic 0x0100 at offset 0x52 as second
test checking for disk image size equal or above 400k was done and
displaying of information starts. Unfortunately these 2 tests are not
unique enough. So more test lines must be added.

As first step i put displaying lines in a subroutine starting with
lines like
 0	name		dc42-floppy
 >00	pstring/B	x	Apple DiskCopy 4.2 image %s
 >0x40	ubelong		x	\b, %u bytes
 #>0x40	ubelong		x	(0x%8.8x)

On web site about DiskCopy 4.2 format specification the biggest
mentioned floppy image size is 1440 KiB. So i test also for disk
image size equal or below this value by additional third test line
like:
 >>0x40	ubelong		<1474561
By this test misidentified samples like windows7en.mbr and
UNICODE.DAT are skipped.

Unfortunately this is still not sufficient. According to
documentation in this size range only 4 specific floppy sizes are
mentioned. That are 400k (hexadecimal 00064000h), 720k (000b4000h),
800k (000c8000h) and 1440k (00168000). So 14 lower and 13 upper
bits are always zero for these 4 sizes. So as fourth test check for
these bits by lines like:
 >>>0x40	ubelong&0xffE03fFF	0
 >>>>0		use	dc42-floppy
Now also misidentified Java file Flags$StringJoiner.class with
value 00106A61h is skipped.

After applying the above mentioned modifications by patches
file-5.39-cafebabe.diff, file-5.39-mach.diff,
file-5.39-archive-dc42.diff then misidentification vanish and i get
without Magdir/measure an output like:

EnglishChunkFilter.class:
	compiled Java class data, version 52.0 (Java 1.8)
javaversion.class:
	compiled Java class data, version 45.3
Flags$StringJoiner.class:
	compiled Java class data, version 51.0 (Java 1.7)
UNICODE.DAT:
	data
Disquette Installation 13.image:
	Apple DiskCopy 4.2 image Disquette Installation 13,
	1474560 bytes,
	MFM CAV dshd (1440k), 0x2 format
Microsoft Mail.image:
	Apple DiskCopy 4.2 image Microsoft Mail,
	819200 bytes, 0x4b00 tag size,
	GCR CLV dsdd (800k), 0x22 format
Bzip2.bundle:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 bundle, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL>]
	[x86_64:Mach-O 64-bit x86_64 bundle, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL>]
AMDil_r700.dylib:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 bundle, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK>]
	[x86_64]
libclang_rt.asan_watchos_dynamic.dylib:
	Mach-O universal binary with 4 architectures:
	[armv7:Mach-O armv7 dynamically linked shared library,
	flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|
	NO_REEXPORTED_DYLIBS|APP_EXTENSION_SAFE>]
	[armv7s:Mach-O armv7s dynamically linked shared library,
	flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|
	NO_REEXPORTED_DYLIBS|APP_EXTENSION_SAFE>]
	[armv7k] [arm64]
libsqlite3.dylib:
	Mach-O universal binary with 3 architectures:
	[i386:Mach-O i386 dynamically linked shared library, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|NO_REEXPORTED_DYLIBS|
	APP_EXTENSION_SAFE>]
	[x86_64] [x86_64_haswell subarchitecture=8]
gcrt1.o:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 object, flags:<|SUBSECTIONS_VIA_SYMBOLS>]
	[x86_64:Mach-O 64-bit x86_64 object, flags:
	<|SUBSECTIONS_VIA_SYMBOLS>]
a2p5.16:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>]
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]
db_codegen:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>]
	[x86_64]
file:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>]
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]
perl:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|NO_HEAP_EXECUTION>]
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]
perl5.16:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>]
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]
perl5.18:
	Mach-O universal binary with 2 architectures:
	[i386:Mach-O i386 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|NO_HEAP_EXECUTION>]
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]
uuidgen:
	Mach-O universal binary with 2 architectures:
	[x86_64:Mach-O 64-bit x86_64 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]
	[x86_64_haswell subarchitecture=8:Mach-O 64-bit
	x86_64_haswell subarchitecture=8 executable, flags:
	<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]

I hope my 3 patches 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+v8rHJQhrU1gUCX0qd3AAKCRCv8rHJQhrU
1mKKAKCgqunmlSKblo1L/qxS2yK3LBV9FwCfepLjn7IyLFC7DdZAqtdKioTdDW0=
=FMR+
-----END PGP SIGNATURE-----
-------------- next part --------------
--- file-5.39/magic/Magdir/archive.old	2020-06-15 00:01:01 +0000
+++ file-5.39/magic/Magdir/archive	2020-08-28 17:09:32 +0000
@@ -453,30 +453,45 @@
 # URL:		https://wiki.68kmla.org/DiskCopy_4.2_format_specification
 # reference:	http://nulib.com/library/FTN.e00005.htm
 0x52	ubeshort	0x0100
-# test for disk size equal or above 400k
->0x40	ubelong		>409599	Apple DiskCopy 4.2 image
+# test for disk image size equal or above 400k
+>0x40	ubelong		>409599
+# test also for disk image size equal or below 1440k to skip
+# windows7en.mbr UNICODE.DAT
+>>0x40	ubelong		<1474561
+# To skip Flags$StringJoiner.class with size 00106A61h test also for only 4 disk image sizes
+# 00064000 for  400k GCR disks
+# 000c8000 for  800k GCR disks
+# 000b4000 for  720k MFM disks
+# 00168000 for 1440k MFM disks
+>>>0x40	ubelong&0xffE03fFF	0
+>>>>0	use	dc42-floppy
+#	display information of Apple DiskCopy 4.2 floppy image
+0	name		dc42-floppy
+# image pascal name padded with NULs like Microsoft Mail
+>00	pstring/B	x	Apple DiskCopy 4.2 image %s
 #!:mime	application/octet-stream
+!:mime	application/x-dc42-floppy-image
 !:apple	dCpydImg
 !:ext	image/dc42
-# image pascal name padded with NULs like Microsoft Mail
->>00	pstring/B	x	%s
 # data size in bytes like 409600
->>0x40	ubelong		x	\b, %u bytes
+>0x40	ubelong		x	\b, %u bytes
+# for debugging purpose size in hexadecimal
+#>0x40	ubelong		x	(0x%8.8x)
 # tag size in bytes
->>0x44	ubelong		>0	\b, 0x%x tag size
+>0x44	ubelong		>0	\b, 0x%x tag size
 # data checksum
-#>>0x48	ubelong		x	\b, 0x%x checksum
+#>0x48	ubelong		x	\b, 0x%x checksum
 # tag checksum
-#>>0x4c	ubelong		x	\b, 0x%x tag checksum
+#>0x4c	ubelong		x	\b, 0x%x tag checksum
 # disk encoding
->>0x50	ubyte		0	\b, GCR CLV ssdd (400k)
->>0x50	ubyte		1	\b, GCR CLV dsdd (800k)
->>0x50	ubyte		2	\b, MFM CAV dsdd (720k)
->>0x50	ubyte		3	\b, MFM CAV dshd (1440k)
->>0x50	ubyte		>3	\b, 0x%x encoding
+>0x50	ubyte		0	\b, GCR CLV ssdd (400k)
+>0x50	ubyte		1	\b, GCR CLV dsdd (800k)
+>0x50	ubyte		2	\b, MFM CAV dsdd (720k)
+>0x50	ubyte		3	\b, MFM CAV dshd (1440k)
+>0x50	ubyte		>3	\b, 0x%x encoding
 # format byte
->>0x51	ubyte		x	\b, 0x%x format
-#>>0x54	ubequad		x	\b, data 0x%16.16llx
+>0x51	ubyte		x	\b, 0x%x format
+#>0x54	ubequad		x	\b, data 0x%16.16llx
 # ESP, could this conflict with Easy Software Products' (e.g.ESP ghostscript) documentation?
 0	string	ESP ESP archive data
 # ZPack
-------------- next part --------------
--- file-5.39/magic/Magdir/mach.old	2020-05-31 10:34:40 +0000
+++ file-5.39/magic/Magdir/mach	2020-08-29 00:30:45 +0000
@@ -13,2 +13,5 @@
 
+# Reference:	https://opensource.apple.com/source/cctools/cctools-949.0.1/
+#               include/mach-o/loader.h
+# display CPU type as string like: i386 x86_64 ... armv7 armv7k ...
 0	name	mach-o-cpu
@@ -200,3 +203,9 @@
 >12	belong		1		object
+# GRR: Does not work for Mach-O with 2 architectures; instead display oo
+#!:ext	o
+!:ext	o/
 >12	belong		2		executable
+# the executables normally have no file extension like perl,
+# but exceptions like perl5.18 perl5.16
+!:ext	16/18/
 >12	belong		3		fixed virtual memory shared library
@@ -205,4 +214,9 @@
 >12	belong		6		dynamically linked shared library
+# GRR: Does not work for Mach-O with 2 architectures; instead display dylibdylib
+#!:ext	dylib
+!:ext	dylib/
 >12	belong		7		dynamic linker
 >12	belong		8		bundle
+# normally name extesion bundle; but exceptions like: AMDil_r700.dylib 
+!:ext	bundle/dylib/
 >12	belong		9		dynamically linked shared library stub
-------------- next part --------------
--- file-5.39/magic/Magdir/cafebabe.old	2020-05-31 10:34:40 +0000
+++ file-5.39/magic/Magdir/cafebabe	2020-08-29 00:24:46 +0000
@@ -17,8 +17,16 @@
 ### JAVA START ###
+# Reference:	http://en.wikipedia.org/wiki/Java_class_file
+# Update:	Joerg Jenderek
 0	belong		0xcafebabe
->4	belong		>30		compiled Java class data,
+>4	ubelong		>30		compiled Java class data,
 !:mime	application/x-java-applet
->>6	beshort		x	        version %d.
->>4	beshort		x       	\b%d
+#!:mime	application/java-byte-code
+!:ext	class
+>>6	ubeshort	x	        version %d.
+>>4	ubeshort	x       	\b%d
+# for debugging purpose version as hexidecimal to compare with Mach-O universal binary
+#>>4	ubelong		x       	(0x%8.8x)
 # Which is which?
+# https://docs.oracle.com/javase/specs/jvms/se6/html/ClassFile.doc.html
+#>>4	belong		0x002b		(Java 0.?)
 #>>4	belong		0x032d		(Java 1.0)
@@ -32,2 +40,12 @@
 >>4	belong		0x0034		(Java 1.8)
+>>4	belong		0x0035		(Java SE 9)
+>>4	belong		0x0036		(Java SE 10)
+>>4	belong		0x0037		(Java SE 11)
+>>4	belong		0x0038		(Java SE 12)
+>>4	belong		0x0039		(Java SE 13)
+>>4	belong		0x003A		(Java SE 14)
+# pool count unequal zero
+#>>8	beshort		x	        \b, pool count 0x%x
+# pool table
+#>>10	ubequad		x	        \b, pool 0x%16.16llx...
 
@@ -46,5 +64,12 @@
 ### MACH-O START ###
+# URL:		https://en.wikipedia.org/wiki/Mach-O
 
 0	name		mach-o		\b [
+# for debugging purpose CPU type as hexidecimal
+#>0	ubequad		x		CPU=%16.16llx 
+# display CPU type as string like: i386 x86_64 ... armv7 armv7k ...
 >0	use		mach-o-cpu	\b
+# for debugging purpose print offset to 1st mach_header like:
+# 1000h 4000h seldom 2d000h 88000h 5b000h 10e000 h
+#>8	ubelong		x		at 0x%x offset
 >(8.L)	indirect	x		\b:
@@ -52,2 +77,5 @@
 
+# Reference:	https://opensource.apple.com/source/cctools/cctools-949.0.1/
+#		include/mach-o/fat.h
+#		include/mach/machine.h
 0	belong		0xcafebabe
@@ -56,16 +84,17 @@
 >>8	use		mach-o		\b
->4	belong		>1
->>4	belong		<20		Mach-O universal binary with %d architectures:
+# nfat_arch; number of CPU architectures; highest is 18 for CPU_TYPE_POWERPC in 2020
+>4	ubelong		>1
+>>4	ubelong		<20		Mach-O universal binary with %d architectures:
 !:mime application/x-mach-binary
 >>>8	use		mach-o		\b
->>4	belong		>1
->>>28	use		mach-o		\b
->>4	belong		>2
->>>48	use		mach-o		\b
->>4	belong		>3
->>>68	use		mach-o		\b
->>4	belong		>4
->>>88	use		mach-o		\b
->>4	belong		>5
->>>108	use		mach-o		\b
+>>>4	ubelong		>1
+>>>>28	use		mach-o		\b
+>>>4	ubelong		>2
+>>>>48	use		mach-o		\b
+>>>4	ubelong		>3
+>>>>68	use		mach-o		\b
+>>>4	ubelong		>4
+>>>>88	use		mach-o		\b
+>>>4	ubelong		>5
+>>>>108	use		mach-o		\b
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.39-archive-dc42.diff.sig
Type: application/octet-stream
Size: 95 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20200829/9f607eb7/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.39-mach.diff.sig
Type: application/octet-stream
Size: 95 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20200829/9f607eb7/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.39-cafebabe.diff.sig
Type: application/octet-stream
Size: 95 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20200829/9f607eb7/attachment-0005.obj>


More information about the File mailing list