<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body smarttemplateinserted="true">
<div id="smartTemplate4-template">Hi, Any update on this?<br>
<br>
Thanks,<br>
Huki<br>
<br>
<hr style="width:100%; height:1px; border:0; color:#B5C4DF;
background-color:#B5C4DF">
<span>
<b>From:</b> Huki <a class="moz-txt-link-rfc2396E" href="mailto:gk7huki@gmail.com"><gk7huki@gmail.com></a><br>
<b>Sent:</b> Sat, 29 Feb 2020 20:23:23 +0530<br>
<b>To:</b> Christos Zoulas <a class="moz-txt-link-rfc2396E" href="mailto:christos@zoulas.com"><christos@zoulas.com></a>, Jörg
Jenderek <a class="moz-txt-link-rfc2396E" href="mailto:joerg.jen.der.ek@gmx.net"><joerg.jen.der.ek@gmx.net></a><br>
<b>Cc:</b> file mailinglist <a class="moz-txt-link-rfc2396E" href="mailto:file@astron.com"><file@astron.com></a><br>
<b>Subject:</b> Re: [File] [PATCH] Fix broken BMP detection
since 5.38
</span>
<br>
<br>
</div>
<div class="replaced-blockquote"
cite="mid:b6a95e21-5781-870d-9161-1f653eb0ca73@gmail.com"
type="cite">
<pre class="moz-quote-pre" wrap="">Here is a test bitmap file that is broken in v5.38:
<a class="moz-txt-link-freetext" href="http://rv12.revoltzone.net/downloads/file-5.38-test.bmp.gz">http://rv12.revoltzone.net/downloads/file-5.38-test.bmp.gz</a>
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
(<a class="moz-txt-link-freetext" href="https://github.com/openpreserve/nanite/blob/master/nanite-core/src/test/resources/skeleton-suite/fmt/fmt-116-signature-id-118.dib">https://github.com/openpreserve/nanite/blob/master/nanite-core/src/test/resources/skeleton-suite/fmt/fmt-116-signature-id-118.dib</a>).
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 <a class="moz-txt-link-rfc2396E" href="mailto:christos@zoulas.com"><christos@zoulas.com></a>
*Sent:* Fri, 28 Feb 2020 19:45:50 -0500
*To:* Huki <a class="moz-txt-link-rfc2396E" href="mailto:gk7huki@gmail.com"><gk7huki@gmail.com></a>, Jörg Jenderek <a class="moz-txt-link-rfc2396E" href="mailto:joerg.jen.der.ek@gmx.net"><joerg.jen.der.ek@gmx.net></a>
*Cc:* file mailinglist <a class="moz-txt-link-rfc2396E" href="mailto:file@astron.com"><file@astron.com></a>
*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 <a class="moz-txt-link-rfc2396E" href="mailto:gk7huki@gmail.com"><gk7huki@gmail.com
></a> <a class="moz-txt-link-rfc2396E" href="mailto:gk7huki@gmail.com"><mailto:gk7huki@gmail.com></a>> 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 <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/LOGO.SYS">https://en.wikipedia.org/wiki/LOGO.SYS</a>
> ->>>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 <a class="moz-txt-link-rfc2396E" href="mailto:gk7huki@gmail.com"><gk7huki@gmail.com></a>
> *Sent:* Sun, 2 Feb 2020 04:22:49 +0530
> *To:* file <a class="moz-txt-link-rfc2396E" href="mailto:file@astron.com"><file@astron.com></a>
> *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
> <a class="moz-txt-link-abbreviated" href="mailto:File@astron.com">File@astron.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:File@astron.com"><mailto:File@astron.com></a>
> <a class="moz-txt-link-freetext" href="https://mailman.astron.com/mailman/listinfo/file">https://mailman.astron.com/mailman/listinfo/file</a>
> <sanitizer.log>
</pre>
</div>
<br>
</body>
</html>