Learn · Multimedia forensics

TIFF & EXIF

EXIF is not a format of its own: it is a small TIFF file inside the JPEG's APP1 segment. Once you can read a TIFF directory by hand, every metadata tool becomes something you can check.

2 Image File Directories

An IFD is a 2-byte entry count, then 12-byte entries, then a 4-byte offset of the next IFD (0 = none). Every entry has the same shape:

tag (2) · type (2) · count (4) · value or offset (4) size = count × type size (BYTE/ASCII/UNDEFINED 1, SHORT 2, LONG 4, RATIONAL 8) size ≤ 4 → the value is stored inline in the last 4 bytes size > 4 → the last 4 bytes are an offset (from the TIFF header) to the value

Try this: IFD0 has 11 entries. Entry 0 is Make, type ASCII, count 7 ("Lumora" + NUL). Seven bytes do not fit into four, so the field holds the offset 0x92; add the TIFF header at 0xC and you reach file offset 0x9E. Orientation (one SHORT) is stored inline. The last two entries are not data but pointers to the Exif and GPS sub-IFDs, and the next-IFD offset at the end leads to IFD1.

The same directory in big-endian. The tags are identical; only the byte order of every number has flipped:

3 The Exif IFD: time, exposure, MakerNote

Three time-related fields deserve attention. Date/Time Original (0x9003) is the moment of capture according to the camera clock, which the user sets and which has no time zone. Offset Time Original (0x9011, here +02:00) adds the zone in newer cameras. Modify Date in IFD0 is also set at capture, but many editors overwrite it on save, so a Modify Date later than Date/Time Original is a hint that software touched the file.

The MakerNote (0x927C, type UNDEFINED) is a blob in a format each manufacturer defines for itself, often undocumented. It can hold extra settings, focus data or internal counters. Our sample starts with the vendor name and a small private IFD. Programs that rewrite EXIF without understanding it often move it and break offsets inside it; a MakerNote that no longer parses is itself a trace of editing.

4 GPS coordinates

Latitude and longitude are three RATIONALs each (8 bytes = numerator and denominator): degrees, minutes, seconds. The sign is not stored in the number: it comes from the separate Ref fields (N/S, E/W).

decimal = degrees + minutes / 60 + seconds / 3600 negative if Ref = S (latitude) or W (longitude)

Try this: the latitude is 40/1, 57/1, 5400/100: 40 + 57/60 + 54/3600 = 40.96500. The longitude Ref is W, so the longitude is negative: −5.66400. The decoded group at the end of the view shows the pair in the form map services expect. Now do the same for the big-endian camera (the answer is in the last group of the view):

GPS time is UTC. GPS Time Stamp and GPS Date Stamp come from the satellites, not from the camera clock. Comparing them with Date/Time Original shows the camera's clock offset; a GPS fix can also be stale (the last known position) if the receiver had no signal when the picture was taken.

5 IFD1 and the embedded thumbnail

IFD0's next-IFD pointer leads to IFD1. It describes a thumbnail: compression 6 (JPEG), then 0x0201 = offset and 0x0202 = length of a complete small JPEG stored inside the EXIF data.

Thumbnail offset 866 + TIFF header 0xC = file offset 0x36E, 3864 bytes long. It is a JPEG of its own, with SOI, tables, scan and EOI, 160 × 120 pixels:

The camera creates the thumbnail together with the main image. Software that edits the main image is supposed to regenerate it, but not all software does. The Tampering page shows what that looks like.

The same metadata as an exiftool-style listing

6 Try it yourself

Answer from the hex views above. Numbers can be typed in decimal or hex (0x…).

At which file offset is the Model string of the little-endian (Lumora) photo stored?

Entry 1 of IFD0 is Model. Its count is more than 4 bytes, so the last 4 bytes of the entry are an offset, counted from the TIFF header at 0xC.

Entry 1 (at 0x22): tag 10 01, type 02 00 (ASCII), count 05 00 00 00 = 5, offset 9A 00 00 00 = 0x9A.

File offset = 0xC + 0x9A = 0xA6. There you find 4C 58 2D 37 00 = "LX-7" + NUL.

In the big-endian (Corvane) photo, how many bytes does the Make value occupy, according to its IFD entry?

Entry 0 of IFD0, bytes 4–7 of the entry. In an MM file the most significant byte comes first.

Entry 0 at 0x16: 01 0F (Make) · 00 02 (ASCII) · 00 00 00 08 · 00 00 00 92.

Count = 0x00000008 = 8 bytes: "Corvane" (7 letters) + NUL. Read as little-endian, the same bytes would mean 134,217,728.

At which file offset does the Exif IFD of the Lumora photo begin?

IFD0 entry 9 (tag 0x8769) is a pointer. Its value is an offset from the TIFF header.

Entry 9 at 0x82: 69 87 · 04 00 (LONG) · 01 00 00 00 · D8 00 00 00. The value is 0xD8 = 216.

File offset = 0xC + 0xD8 = 0xE4 (228). The Exif IFD there begins with the entry count 0F 00 = 15.

The Lumora's GPS Time Stamp is UTC. By how many hours is the camera clock (Date/Time Original) ahead of UTC?

GPS Time Stamp is three RATIONALs: hours, minutes, seconds. Compare with the time part of Date/Time Original in the Exif IFD.

GPS Time Stamp at 0x2EC: 0C 00 00 00 01 00 00 00 = 12/1, then 3/1, 27/1 → 12:03:27 UTC.

Date/Time Original is "2026:05:16 14:03:27": 14 − 12 = 2 hours. That agrees with Offset Time Original +02:00, so the camera clock and the time zone field are consistent.

These are the 8-byte TIFF header of the Lumora photo, IFD0's entry count and the Make entry. Edit them and watch the decoded IFD0 below:

  • Change the byte order 49 49 to 4D 4D. The parser now reads the entry count 0B 00 as 0x0B00 = 2,816 and gives up. Converting a file between II and MM means rewriting every number in it.
  • Reset, then change the Make type at 0x18 from 02 00 (ASCII) to 03 00 (SHORT). Same count and offset, but now 7 × 2 = 14 bytes, read as numbers: the bytes of "Lumora" become 30028, 28525, …
  • Reset, then change the count at 0x1A from 07 to 04. Four bytes fit inline, so the parser reads the offset bytes 92 00 00 00 themselves as the text.