1 What the file says: Make, Model, serial, MakerNote
The obvious source information sits in the EXIF fields covered on the TIFF & EXIF page:
- Make (
0x010F) and Model (0x0110) in IFD0 name the device type. They narrow things down to a model, never to one device. - Body Serial Number (
0xA431) in the Exif IFD, if the firmware writes it, names one specific camera body. Many cameras and most phones do not write it at all; some write it only in the MakerNote. - Software (
0x0131): the firmware version from a camera, or the program that saved the file last. - The MakerNote (
0x927C): vendor-specific data. Its format (signature, byte order, internal offsets) is itself characteristic of a manufacturer, and some vendors store internal counters there.
Try this: find the body serial and the MakerNote in this big-endian Exif IFD. The MakerNote is 40 bytes and begins with the vendor name, then its own byte-order mark. Note that every one of these fields is plain ASCII or a blob at an offset: rewriting them takes one command in any EXIF editor, and the file shows no trace of that unless something else contradicts the new value.
2 How the pixels were encoded: quantisation fingerprints
The quantisation tables are chosen by whatever wrote the JPEG. Camera firmwares usually have their own tables, often several, chosen per quality setting or even per image. Software libraries mostly use the scaled standard tables. Changing the tables means re-compressing the image, which a simple EXIF edit does not do, so the tables are harder to fake than a text field.
The two (fictional) cameras on these pages, first the Lumora LX-7 and then the Corvane C-200:
Their estimated qualities are close (≈ 87 and ≈ 85), but the tables are clearly different entry by entry, and neither is a scaled IJG table. A single "quality" number is not a fingerprint; the full table set is.
Now the Lumora photo after it was opened and saved again by an image library (Pillow, quality 75):
Both tables are exact IJG tables for quality 75. Yet the library copied the EXIF block unchanged, so the metadata still says the camera wrote it:
Make "Lumora", Software "LX-7 Firmware 1.04", but tables the LX-7 never uses and a JFIF APP0 segment before the EXIF that the camera does not write. The file was re-encoded by software after it left the camera. That alone is not suspicious (resizing for e-mail does the same), but the file is not a camera original.
3 The sensor itself: PRNU
No two image sensors are identical. Each pixel converts light with a slightly different efficiency, fixed at manufacture. This photo-response non-uniformity (PRNU) adds a faint, constant multiplicative pattern to every picture the sensor takes: a fingerprint of the individual device, not of the model.
To use it you need the device, or a set of pictures known to come from it (ideally flat, bright scenes such as sky or a white wall), to estimate the fingerprint. A questioned image is then tested against it.
- Strength: it identifies a single sensor and survives moderate JPEG compression and EXIF stripping, because it lives in the pixels.
- Weaknesses: cropping, resizing, rotation and digital stabilisation misalign the pattern; heavy compression and strong denoising (common in phone pipelines) weaken it; it needs reference material and careful thresholds. Results are statistical and must be reported with error rates.
PRNU needs many full-size images and real sensor noise, so it is not demonstrated with the synthetic samples here; the concept is what matters for planning an examination.
4 Limits and anti-forensics
- EXIF is trivially editable. Make, Model, serial, dates and GPS can be changed, added or removed with free tools in seconds. A plausible value is not a verified value.
- Platforms strip it. Messengers and social networks usually remove EXIF and re-compress the image with their own tables. A picture downloaded from such a platform tells you about the platform, not the camera.
- Absence is not proof. Missing EXIF, a missing serial or an empty GPS IFD has many innocent causes (settings, apps, export dialogs). It does not show that someone removed the data on purpose.
- Look for agreement between independent sources: EXIF fields, quantisation tables, thumbnail, file system timestamps, the device's own records, sensor noise. One source can lie; several unrelated ones lying consistently is much less likely.
5 Try it yourself
Answer from the hex views above. Numbers can be typed in decimal or hex (0x…).
What is the first (DC) entry of the Corvane C-200's luminance table? (The Lumora LX-7 uses 4.)
The table starts right after the precision/id byte 00 that follows the DQT length.
The DQT at 0x1003: FF DB · 00 43 · 00 (8-bit, table 0), then 02 04 04 06 06 06 09 09.
The DC divisor is 2, against 4 in the Lumora table. The estimated qualities (≈ 85 and ≈ 87) are close, the entries are not.
The re-saved photo's luminance table is an exact IJG table. For which quality?
The view compares the table with every scaled IJG table; look at the last row of the table group. The first entries are 08 06 06 07.
The standard luminance table starts 16 11 12 14 in zigzag order. Quality 75 gives scale = 200 − 2 × 75 = 50, so 16 → ⌊(16 × 50 + 50) / 100⌋ = 8, 11 → 6, 12 → 6, 14 → 7.
The file has 08 06 06 07 …: quality 75, every entry exact. No camera table in these pages matches it.
In the re-saved photo, at which file offset does the TIFF header (II) start? In the camera original it is at 0xC.
The IFD0 view of the re-saved file says where IFD0 is in the file and which TIFF offset that is.
IFD0 is at file offset 0x26 and at TIFF offset 0x8, so the header is at 0x26 − 8 = 0x1E.
The difference 0x1E − 0xC = 18 bytes is exactly the inserted JFIF APP0 segment: marker FF E0 + length 00 10 (16). Because EXIF offsets count from the TIFF header, the copied EXIF block still parses.
A questioned JPEG has quantisation tables identical to the Corvane C-200 tables above. What does that support?
Tables are set by firmware or software. Which devices share the same firmware?
Every C-200 at that setting writes the same tables (luminance starting 02 04 04 06), so a match is consistent with the model, not with one unit. It says nothing about the EXIF fields, which can be rewritten without touching the tables.
Telling individual bodies apart needs sensor noise (PRNU), not tables.
These 48 bytes of the re-saved photo hold the Make, Model and Software strings that IFD0 points to (from file
offset 0xB0). Edit them and watch the decoded IFD0 below:
- Change the model
4C 58 2D 37("LX-7") to4C 58 2D 39("LX-9"). - The Software string ends with
31 2E 30 34("1.04"). Make it32 2E 31 30("2.10"). - Nothing else in the file had to change: no checksum, no length, no second copy. The quantisation tables still say "IJG quality 75". Which of the two is easier to fake, and which one would you trust?