[File] BUG, suggestion for offset beyond EndOfFile or FILE_BYTES_MAX limit

Jörg Jenderek joerg.jen.der.ek at gmx.net
Sun Nov 11 02:27:10 UTC 2018


I run the new file command version 5.34 with option -m
Magdir/filesystems on some hard disk images and Master Boot Record
files (*.mbr). I got some surprising output like:

sd16mb.bin: DOS/MBR boot sector
	; partition 1 : ID=0xe, active, start-CHS (0x0,1,1)
	, end-CHS(0x0,254,63)
	, startsector 63, 28665 sectors
	; partition 2 : ID=0xea, start-CHS (0x0,254,63)
	, end-CHS (0x0,254,63)
	, startsector 28728, 63 sectors
sd16mb.mbr: DOS/MBR boot sector

The master boot record files (*.mbr) just contains the first 512 bytes
of hard disk whereas the other files contain more following bytes or
the whole disk content. For mbr files no partition info is printed
compared with other files. This should not happen because displayed
partition information is stored in first sector.

The first information is shown by line:
 0x1FE          leshort         0xAA55         	DOS/MBR boot sector

After some additional test lines the information about partition table
is displayed by line like:
 >>>>>>>>>>>446	use		partition-table

After some testing i find the line that is the source of error
 >>>514		string		!HdrS

This is needed to distinguish MBR from "Linux kernel x86 boot
executable" identified by lines in Magdir/linux like:
 514	string		HdrS		Linux kernel
 >510	leshort		0xAA55		x86 boot executable

For non mbr examples with file size bigger than 518 at offset 514
there exist 4 bytes and critical test line succeed and code flow
continuous as expected. For mbr examples at this offset there exist no
bytes that can be read and critical line display no message and
following magic lines are never executed.

I think this must be considered as a BUG!
The file command maybe should print a warning on standard error.

As a human i would expect that reading from non existing places maybe
gives as result nulls.
Another solution would be to introduce a new new magic type like EOB
that test for end of buffer conditions. At the moment i see no easy
solution to distinguish MBR examples from whole disk images using
different file name extensions and mime types.  With suggested new type
this can be easily done like:

 # only 512 bytes implies MBR alone
 >>>512	EOB
 !:mime	application/octet-stream
 !:ext	mbr
 # more than 512 bytes means MBR with following which implies whole disk
 >>>512	!EOB
 !:mime	application/x-raw-disk-image
 !:ext	img/raw-disk-image

The annoying end of buffer condition also occur for other cases. I
tried to write magic lines for VHDX disk images. The inspected position
of log entry is printed by line like:

 >>0x10048	ulequad		x		\b, LogOffset 0x%llx

The next magic line looking for Log Entry Signature "loge" does not
succeed with standard option:
 >>(0x10048.q)	string		loge		Log Entry FOUND

If i raise the standard FILE_BYTES_MAX limit value 100000h inside
src/file.h magic line works as expected.

I hope my suggestions can be applied in future version of file

With best wishes
Jörg Jenderek
Jörg Jenderek

More information about the File mailing list