[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
Hello,
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
utility.
With best wishes
Jörg Jenderek
--
Jörg Jenderek
More information about the File
mailing list