[File] BigTIFF: Indirect offset, 64-bit value not supported?

[David Konerding]

Hi,
I am trying to write a rule to extract more info from BigTIFF.  Currently,
TIFF files extract directory entries and output metadata, while BigTIFF
only reports the file type and endian.

Working from this page, http://bigtiff.org/ I am trying to read the offset
to the first directory entry; in TIFF, this is a short (16-bit), while in
BigTIFF, it's a quad (64-bit) to support files with very large offsets.

As such, I am trying to write this continuation:
>>>(8.Q) use \^bigtiff_ifd
Which IIUC is saying "starting at file offset 8, read a bequad (64 bit) and
then recursively call the named magic bigtiff_ifd (which is slightly
different from tiff_ifd).

When I try this on my test file (a big-endian BigTIFF), I get this debug
error:
10: >>>> 8(bequad,&0), use,='^bigtiff_ifd',""]
lhs/off overflow 28956860354 0

If I understand the code in do_ops correctly (
https://github.com/file/file/blob/master/src/softmagic.c#L1465)
the values for lhs and off are compared to UINT_MAX and INT_MIN, and a
failure is reported if the value is too large.
On my 64-bit system, UINT_MAX seems to be based on 32-bit integer, which
causes the overflow error when compared against a 64-bit value.

Before I proceed, wanted a sanity check here: are 64-bit offsets larger
than 2**32 considered invalid by file?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.astron.com/pipermail/file/attachments/20240326/a9b5dc42/attachment.htm>