Dear friends, welcome to this week’s video evidence pitfall post! We often hear about the importance of metadata as a way to reveal more than pixels alone would. While it’s certainly true that metadata can give us lots of useful info, they must be looked at carefully and prudently, as they hide several pitfalls. Keep reading to discover some!
Issue: Metadata May Seem (or Be) Misleading!
As part of a drug-dealing investigation, you’re provided a video submitted by a citizen, who captured it with their smartphone (you can download it from this link).
The video is brought to you on a USB drive by a colleague. Using Amped FIVE‘s Copy and Verify tool, you copy it on your workstation checking that hashes match, and then create a working copy of it. The first question you want to address is: is the integrity of the video file preserved?
So you load the video in Amped FIVE, open the Advanced File Info and take a look at the Exiftool tab. A load of information appears, and you’re suddenly puzzled by something.
The File Creation Date/Time reads April 29th, 2021, but the File Modification Date/Time reads September 26th, 2019. How could a file be modified before being created? Does this already mean integrity is broken? Then you scroll down and find more information about time…
The Media Create Date and Media Modify Date both suggest September 26th, 2019 as the creation date. What does all of this mean?
Explanation: Metadata Come in Many Flavors
When talking about image and video metadata, there’s an important first distinction that must be made: the one between Filesystem metadata and Embedded metadata.
Filesystem Metadata are not part of the file. They are created and maintained by the operating system somewhere else on the hosting device. As far as Windows is concerned, among the others, there’s a Create date, a Modify date, and an Access date maintained for each file. Whenever a program accesses the file (even for simply reading part of it), the Access date (should) get updated. Whenever a program writes something into the file, the Modify date gets changed (even if the file did not actually change). The Create date, as suggested by the name, tells when that file was created on the filesystem.
Now, when your colleague brought the file to you, you copied it from the USB drive and pasted it on your workstation. Since you’re creating a new copy, the filesystem sets the copy date as the Create date, while of course, the source file’s Create date remains unaltered. However, since the file is just being copied, the filesystem does not update the Modify date — and this explains how you can easily have a Create date that is later than the Modify date!
Embedded Metadata are a different story: they are written inside the file and travel with it. They are normally written when the image/video is created and possibly updated by processing software when the file is manipulated in any way. They won’t be affected by copy-paste operations, since they are part of the file payload. Unfortunately, however, it is very easy to delete or modify them for an attacker! In Windows, some embedded metadata can be just changed or erased from the File Properties panel!
You can add or change virtually all embedded metadata using dedicated software, such as Exiftool, or working with a Hex editor.
Until now, we’ve looked at a standard video file. When dealing with proprietary video files, however, even more problems arise. For example, if a proprietary container hosts a standard video stream and a proprietary audio stream, it may easily happen that your analysis software will only be able to detect the standard video stream and not the audio stream! You may thus believe the recording has no audio, while actually there’s audio and the proprietary player could play it! The same happens with timestamps: if they’re written in a non-standard way, you will almost certainly lose them if you don’t use specialized software.
The metadata in the below file is reporting one single video stream (Video ID 0)
However, as we saw in the last ‘Video Evidence Pitfalls’ post (about Multiplexing), this single stream could really be multiple streams. Is it 1 video or 8? And take a look at that frame rate — is it really 50 fps? (Spoiler — no it’s not!)
As it was explained in a dedicated blog post (What is the frame rate?), in a single file you may find even 3 or 4 conflicting information about the frame rate at which the video should be played (some info in the container metadata, some in the video stream’s metadata, some in the audio’s, etc.). For example, we’ve been recently dealing with a video claiming a 50 fps playback speed. Since there were timestamps printed over frames, we could find that actually, the frame rate oscillated between 42 to 59 fps, depending on which part of the video you concentrated on.
Solution: Don’t Trust Too Much Metadata… nor Yourself!
Although in this post we could only cover the tip of the iceberg, it should be pretty clear that metadata are a mine of information but also a minefield. This is especially true when dealing with proprietary file metadata, which will not be parsed by most file analysis software. A very good starting point for examining the available information in your file is Amped FIVE’s Advanced File Info, going through the various tabs it offers. The ffprobe tab will display lots of technical data about the container and the included streams, but it’s also harder to read for a non-expert.
If you’re dealing with recovering a license plate from a video, probably you don’t have to worry too much about metadata. But when the date and time of events matter (e.g., car incident analysis), you’d better ask yourself: am I confident in dealing with this stuff? If the answer is “perhaps no”, then call an analyst with experience and get some help.
