Metadata, EXIF, and File-Structure Forensics

EXIF metadata lives in the APP1 segment of a JPEG file, positioned immediately after the SOI (Start of Image) marker. It is structured as a TIFF IFD (Image File Directory) tree, with each field identified by a two-byte tag number, a data type, and a value. The specification was originally developed by JEIDA (Japan Electronics Industry Development Association) in 1995 and has been maintained through subsequent versions; the current widely-implemented specification is EXIF 2.32 (2019).

The fields most frequently used in forensic analysis fall into three groups. First, device identification: Make (tag 0x010F), Model (0x0110), Software (0x0131), CameraSerialNumber (MakerNote-derived), and LensModel (0xA434). Second, temporal data: DateTimeOriginal (0x9003), DateTimeDigitized (0x9004), SubSecTimeOriginal (0x9291), and GPSTimeStamp (in the GPS IFD). Third, spatial data: GPSLatitude, GPSLongitude, GPSAltitude, and GPSImgDirection.

The three timestamp tags serve different purposes and often diverge in altered images. DateTimeOriginal records when the shutter fired according to the camera clock. DateTimeDigitized records when the image was scanned or digitised (identical to DateTimeOriginal for direct digital capture). DateTime records the last modification time and is updated by software that rewrites the file. An image with DateTimeOriginal in 2021 but DateTime in 2024 is consistent with post-processing. An image with DateTimeOriginal later than DateTime is inconsistent with normal capture and software workflows and requires explanation.

GPS metadata in EXIF lives in a separate IFD pointed to by tag 0x8825 in the main IFD. It stores latitude, longitude, altitude, GPS timestamp (UTC), the direction the camera was pointing (GPSImgDirection), and the fix source (GPS, cell network, or Wi-Fi triangulation, recorded in GPSMeasureMode and GPSProcessingMethod). These fields are independent of the camera's own clock, so a GPS timestamp inconsistent with DateTimeOriginal can indicate timezone manipulation or fabrication.

GPS data is among the most easily edited EXIF fields because many desktop tools offer GPS coordinate editing explicitly for privacy or travel-log purposes. A forensic examiner therefore treats GPS evidence as a starting point for corroboration, not a terminal conclusion. The relevant corroboration sources include cell-tower records for the device, the image content itself (buildings, street furniture, vegetation), meteorological records for the claimed date and location (cloud cover, sun angle), and timestamps in any accompanying video or audio recorded around the same time.

The Makernote stores data that does not fit the EXIF standard specification. Each manufacturer defines their own IFD structure inside this field, often undocumented and reverse-engineered by the forensic and photography communities. Canon Makernotes include the camera's internal serial number, the specific AF point used, the colour temperature measured by the AWB sensor, and the Picture Style setting. Nikon Makernotes include a firmware version string, the shooting mode dial position, and a VR (vibration reduction) status flag. Sony Makernotes include the scene recognition mode used by the camera's AI exposure system.

These fields are useful for two tasks. First, source verification: the Makernote of a file claimed to come from a Canon EOS 90D should contain Canon-format data consistent with that model's firmware. A Makernote in Nikon format, or a structurally malformed Makernote, is an immediate inconsistency. Second, internal consistency checking: the camera serial number implied by the Makernote can be compared across multiple images claimed to come from the same device.

Privacy-conscious users and malicious actors both strip metadata from image files. Tools like ExifTool, ImageMagick, and platform-side processing (Twitter, WhatsApp, most social platforms strip all EXIF on upload) can remove all EXIF and IPTC data. What stripping tools cannot do is alter the pixel-level forensic signatures written during capture. A stripped image is not a sanitised one: the PRNU fingerprint, CFA correlation, and JPEG quantisation table remain intact.

Partial stripping is forensically more informative than complete removal. Editing workflows that preserve some EXIF fields while rewriting others leave a metadata archaeology layer. A common pattern: Adobe Lightroom exports retain the CameraSerialNumber and LensMake fields from the original Makernote but rewrite DateTimeOriginal to the export time and add an XMP packet signed with a Lightroom history. If the claimed context is an unedited original, this history is contradicting that claim.

XMP history blocks provide a direct record of software operations performed on the file. Applications that write XMP include an xmpMM:History entry for each action taken on the file: open, save, export, and the software name and version. A file with an XMP history showing three separate Photoshop save operations is not an unedited original, whatever the EXIF DateTimeOriginal says.

• Timestamp conflicts: DateTimeOriginal earlier than the creation date of the claimed software version suggests fabricated capture times.
• GPS/clock inconsistency: GPS UTC timestamp and DateTimeOriginal displaced by an amount that is not a whole-hour timezone offset suggests manipulation rather than timezone correction.
• Software fingerprint mismatch: EXIF Software tag claiming direct camera output while XMP reveals a history of Photoshop operations is an internal contradiction.
• Absent Makernote: a JPEG with standard EXIF but no Makernote from a brand that always writes one (Canon, Nikon, Sony) suggests the file was re-saved by software that could not preserve the proprietary block.

An MP4 file is a hierarchy of typed units called boxes (or atoms in QuickTime terminology). Each box has a four-byte length, a four-byte type code, and a data payload. Boxes nest: the moov box contains trak boxes for each track, which contain mdia and minf boxes, which contain stbl (sample table) boxes that index every compressed frame.

The key boxes for forensic timeline analysis are:

• mvhd (Movie Header): stores creation time and modification time as seconds since 1904-01-01 (Macintosh epoch). These are set by the recording software; a modification time that predates the creation time is impossible under normal conditions.
• stts (Sample-to-Time): maps each sample to its duration in the timeline. Gaps or zero-duration entries can indicate deleted or replaced samples.
• stco / co64 (Chunk Offset): stores the byte offset of each media chunk within the file. If offsets have been rewritten while the media data has not, or vice versa, the file is internally inconsistent.
• udta / uuid: vendor-specific boxes that carry device model, firmware version, GPS, orientation, and software metadata. Their content is a device fingerprint independent of the video bitstream.

A comparison of the creation time in the mvhd box with the file system timestamps (ctime, mtime) and with the GPS timestamps embedded in the udta box can reveal whether the file has been moved, copied, or re-packaged since its original creation. File system timestamps are easily altered by setting the system clock, but aligning them convincingly with all three internal timestamp sources simultaneously is much harder.

WAV files use the RIFF (Resource Interchange File Format) chunk structure, originally developed by Microsoft and IBM. The file starts with a four-byte RIFF identifier, a four-byte total length, and a four-byte format identifier ('WAVE'). Inside the WAVE container, chunks are arranged as a flat or mildly nested sequence of typed records.

The mandatory fmt chunk (format chunk) defines the audio parameters: PCM or IEEE float, number of channels, sample rate, bit depth, and byte rate. The data chunk holds the actual PCM samples. Several optional chunks are forensically interesting:

• BEXT (Broadcast Wave Extension): defined in EBU Tech 3285. Contains a 256-character description, an originator reference (recorder model), a date and time string, and a 64-bit sample-accurate timestamp referenced to midnight. Common in professional recording equipment and broadcast systems. The originator reference is an encoder fingerprint.
• INFO: an RIFF list chunk containing named sub-fields (INAM for title, ICRD for creation date, ISFT for software, IENG for engineer). The ISFT field records the recording or editing software name and version.
• id3 or _PMX: some WAV files carry ID3v2 tags (normally associated with MP3) or XMP metadata in non-standard chunks. These carry editing history in the same form as image XMP, including application version and processing actions.