[File] [PATCH] Fix broken BMP detection since 5.38

Huki gk7huki at gmail.com
Sat Feb 29 14:53:23 UTC 2020


Here is a test bitmap file that is broken in v5.38:
http://rv12.revoltzone.net/downloads/file-5.38-test.bmp.gz

The file was saved in GIMP 2.10 with "Don't write colorspace 
information" checked.

The output:

$ file test.bmp
test.bmp: data


The expected result (I've used my patched magic.mgc):

$ file -m magic.mgc test.bmp
test.bmp: PC bitmap, Windows 3.x format, 1024 x 1024 x 24, image size 3145728, resolution 11811 x 11811 px/m, cbSize 3145782, bits offset 54


The problem is caused by this line which doesn't behave as expected when 
the file size is too big:

# jump 4 bytes before end of file/header to skip fmt-116-signature-id-118.dib
>>(2.l-4)	ulong	x		PC bitmap, Windows 3.x format


The line was recently added to the "Windows 3.x format" branch, hence 
the bug only affects this format. It is possible that there is an 
internal limitation that breaks things when (2.l-4) value is too big. 
There is also the edge case when 2.l = 0 (so it tries seeking to -4 from 
start of file?). In any case, seeking to the end of a large file sounds 
inefficient and best avoided IMO.

Incidentally, I tested the "fmt-116-signature-id-118.dib" file 
(https://github.com/openpreserve/nanite/blob/master/nanite-core/src/test/resources/skeleton-suite/fmt/fmt-116-signature-id-118.dib). 
It's a file with bitmap header alone and no further data.

With file 5.38:

$ file fmt-116-signature-id-118.dib
fmt-116-signature-id-118.dib: dBase III DBT, version number 0, next free block index 19778


With my patch to remove the (2.l-4) jump:

$ file -m magic.mgc fmt-116-signature-id-118.dib
fmt-116-signature-id-118.dib: PC bitmap, Windows 3.x format, 0 x 0 x 1, cbSize 0, bits offset 0


So it appears to be better without the jump in this case too.


Regards,
Huki

------------------------------------------------------------------------
*From:* Christos Zoulas <christos at zoulas.com>
*Sent:* Fri, 28 Feb 2020 19:45:50 -0500
*To:* Huki <gk7huki at gmail.com>, Jörg Jenderek <joerg.jen.der.ek at gmx.net>
*Cc:* file mailinglist <file at astron.com>
*Subject:* Re: [File] [PATCH] Fix broken BMP detection since 5.38

Hi Huki,

Can you supply a bmp file that is broken? Jörg Jenderek made the latest 
changes and I want to make sure that we understand what's going on 
before making more changes.

Best,

christos

> On Feb 27, 2020, at 10:08 PM, Huki <gk7huki at gmail.com 
> <mailto:gk7huki at gmail.com>> wrote:
>
> Hi,
>
> Any news regarding the fix for broken bitmaps? I noticed my email was 
> filtered because of too big attachments. If it helps, I'm reposting my 
> patch in plain text.
>
>
> diff --git a/magic/Magdir/images b/magic/Magdir/images
> index 931df682..3cde072c 100644
> --- a/magic/Magdir/images
> +++ b/magic/Magdir/images
> @@ -613,7 +613,7 @@
>   0	leshort		40
>   # skip bad samples like GAME by looking for valid number of color planes
>   >12	uleshort	1		Device independent bitmap graphic
> -!:mime	image/bmp
> +!:mime	image/x-ms-bmp
>   !:apple	????BMPp
>   !:ext	dib
>   >>4	lelong		x		\b, %d x
> @@ -639,7 +639,7 @@
>   >>18	leshort		x		\b, %d x
>   >>20	leshort		x		%d
>   >14	leshort		64		PC bitmap, OS/2 2.x format
> -!:mime	image/bmp
> +!:mime	image/x-ms-bmp
>   !:apple	????BMPp
>   !:ext	bmp
>   # image width and height fields are unsigned integers for OS/2
> @@ -660,7 +660,7 @@
>   #>>(10.l) ubequad		!0	\b, bits 0x%16.16llx
>   # BITMAPV2INFOHEADER	adds RGB bit masks
>   >14	leshort		52		PC bitmap, Adobe Photoshop
> -!:mime	image/bmp
> +!:mime	image/x-ms-bmp
>   !:apple	????BMPp
>   !:ext	bmp
>   >>18	lelong		x		\b, %d x
> @@ -668,54 +668,52 @@
>   >>28	leshort		x		%d
>   # BITMAPV3INFOHEADER	adds alpha channel bit mask
>   >14	leshort		56		PC bitmap, Adobe Photoshop with alpha channel mask
> -!:mime	image/bmp
> +!:mime	image/x-ms-bmp
>   !:apple	????BMPp
>   !:ext	bmp
>   >>18	lelong		x		\b, %d x
>   >>22	lelong		x		%d x
>   >>28	leshort		x		%d
> ->14	leshort		40
> -# jump 4 bytes before end of file/header to skip fmt-116-signature-id-118.dib
> ->>(2.l-4)	ulong	x		PC bitmap, Windows 3.x format
> -!:mime	image/bmp
> +>14	leshort		40		PC bitmap, Windows 3.x format
> +!:mime	image/x-ms-bmp
>   !:apple	????BMPp
> ->>>18	lelong		x		\b, %d x
> ->>>22	lelong		x		%d
> +>>18	lelong		x		\b, %d x
> +>>22	lelong		x		%d
>   # 320 x 400		https://en.wikipedia.org/wiki/LOGO.SYS
> ->>>18	ulequad		=0x0000019000000140	x
> +>>18	ulequad		=0x0000019000000140	x
>   !:ext	bmp/sys
> ->>>18	ulequad		!0x0000019000000140
> +>>18	ulequad		!0x0000019000000140
>   # compression method 2~RLE 4-bit/pixel implies also extension rle
> ->>>>30	ulelong		2		x
> +>>>30	ulelong		2		x
>   !:ext	bmp/rle
> ->>>>30	default		x		x
> +>>>30	default		x		x
>   !:ext	bmp
>   # number of bits per pixel (color depth); found 1 2 4 8 16 24 32
> ->>>28	leshort		x		%d
> +>>28	leshort		x		%d
>   # x, y coordinates of the hotspot; there is no hotspot in bitmaps, so values 0
> -#>>>6	uleshort	>0		\b, hotspot %ux
> -#>>>>8	uleshort	x		\b%u
> +#>>6	uleshort	>0		\b, hotspot %ux
> +#>>>8	uleshort	x		\b%u
>   # number of color planes (must be 1), except badplanes.bmp for testing
> -#>>>26	uleshort	>1		\b, %u color planes
> +#>>26	uleshort	>1		\b, %u color planes
>   # compression method: 0~no 1~RLE 8-bit/pixel 2~RLE 4-bit/pixel 3~Huffman 1D 6~RGBA bit field masks
> -#>>>30	ulelong		3		\b, Huffman 1D compression
> ->>>30	ulelong		>0		\b, %u compression
> +#>>30	ulelong		3		\b, Huffman 1D compression
> +>>30	ulelong		>0		\b, %u compression
>   # image size is the size of raw bitmap; a dummy 0 can be given for BI_RGB bitmaps
> ->>>34	ulelong		>0		\b, image size %u
> +>>34	ulelong		>0		\b, image size %u
>   # horizontal and vertical resolution of the image (pixel per metre, signed integer)
> ->>>38	lelong		>0		\b, resolution %d x
> ->>>>42	lelong		x		%d px/m
> +>>38	lelong		>0		\b, resolution %d x
> +>>>42	lelong		x		%d px/m
>   # number of colors in palette 16 256, or 0 to default to 2**n
> -#>>>46	ulelong		>0		\b, %u colors
> +#>>46	ulelong		>0		\b, %u colors
>   # number of important colors used, or 0 when every color is important
> ->>>50	ulelong		>0		\b, %u important colors
> +>>50	ulelong		>0		\b, %u important colors
>   # cbSize; often size of file
> ->>>2	ulelong		x		\b, cbSize %u
> -#>>>2	ulelong		x		\b, cbSize 0x%x
> +>>2	ulelong		x		\b, cbSize %u
> +#>>2	ulelong		x		\b, cbSize 0x%x
>   # offBits; offset to bitmap data like 36h 76h BEh 236h 406h 436h 4E6h
> ->>>10	ulelong			x	\b, bits offset %u
> -#>>>10	ulelong			x	\b, bits offset 0x%x
> -#>>>(10.l) ubequad		!0	\b, bits 0x%16.16llxd
> +>>10	ulelong			x	\b, bits offset %u
> +#>>10	ulelong			x	\b, bits offset 0x%x
> +#>>(10.l) ubequad		!0	\b, bits 0x%16.16llxd
>   >14	leshort		124		PC bitmap, Windows 98/2000 and newer format
>   !:mime	image/x-ms-bmp
>   >>18	lelong		x		\b, %d x
>
>
> ------------------------------------------------------------------------
> *From:* Huki <gk7huki at gmail.com>
> *Sent:* Sun, 2 Feb 2020 04:22:49 +0530
> *To:* file <file at astron.com>
> *Subject:* [File] [PATCH] Fix broken BMP detection since 5.38
>
>
> Since updating to File 5.38, bitmap images with header size 40 (Windows
> 3.x format) aren't detected under certain conditions. It seems to happen
> when the file size is > 1MB (eg, a 1024 x 1024 RGB image).
>
> $ file test.bmp
> test.bmp: data
>
> I traced down the issue to this recently added line:
>
> # jump 4 bytes before end of file/header to skip
> fmt-116-signature-id-118.dib
>   >>(2.l-4)    ulong    x        PC bitmap, Windows 3.x format
>
> It's a bit weird and I don't see any reason to do this. I removed this
> (and adjusted the lines below) and the detection is working again.
>
> $ file -m magic.mgc test.bmp
> test.bmp: PC bitmap, Windows 3.x format, 1024 x 1024 x 24, image size
> 3145728, resolution 11811 x 11811 px/m, cbSize 3145782, bits offset 54
>
> Also, I changed the mimetype to consistently use image/x-ms-bmp as
> opposed to image/bmp in some places.
> I've attached the patch and the test bitmap file.
>
> Regards,
> Huki
>
>
>
> -- 
> File mailing list
> File at astron.com <mailto:File at astron.com>
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>




More information about the File mailing list