Hello dear friends, welcome to this week’s tip! Today we’re dedicating some room to metadata analysis with Amped Authenticate. In particular, we’ll deal with two cases where metadata were altered to change the acquisition date, but… the forger was not clever enough, and we’ll catch him! Curious? Keep reading!
We dedicated several posts on our blog to metadata analysis, and both in the blog and in our training we always emphasize two facts:
- metadata are a great resource, as they add lots of information to what’s simply shown in pixels;
- at the same time, they should not be blindly trusted because they can easily be altered, sometimes right from Windows’ “File Property” panel!
However, the fact that metadata can be altered doesn’t imply that villains are safe. Making a fully consistent manipulation of metadata is less trivial than it seems, especially if the analyst is equipped with Amped Authenticate!
We’ve shown in our blog posts that you can use the sun position and the weather to cross-check dates, and you can also compare GPS and device-clock time info to spot inconsistencies. We’ve also seen that you can effectively use Amped Authenticate’s JPEG Quantization Tables database to cross-check Make and Model metadata.
But today, we’re feeling geeky! Let’s take a look at two more ways to cross-check the sequential order of images.
Let’s use a sample case. A suspect provides these two pictures to prove that yes, he had been both in Tomar (Portugal) and Sevilla (Spain) in late July 2014 but, contrary to what the prosecutor says, he was first in Sevilla and then in Tomar. The suspect claims this is proved by the pictures’ names and metadata, both suggesting that the Sevilla image is precedent to the Tomar image. Below we show the pictures and the relevant metadata (click on pictures to enlarge them).
Well, pictures are indeed taken from the same camera model (using PRNU Identification, we could also check that it was the very same exemplar). Moreover, filenames and metadata actually suggest that the Sevilla picture (on the left) was taken two days before the Tomar picture.
But scrolling down the list of metadata, we notice something strange…
Ha! What’s that? The ShutterCount metadata is used by many digital cameras to store the number of shots taken, much like the odometer in your car. Every time you take a shot, the counter increases by one. It’s in the [MakerNote] category, which means it’s not something “universally standard,” it’s instead a manufacturer choice. Unfortunately for our suspect, the Nikon D50 camera uses it. And it’s telling us that the picture on the left was taken AFTER the picture on the right. Not only: 15464 – 14964 = 500. So that camera has taken other 499 images between these two, and we may kindly suggest the prosecutor to ask the suspect to provide these pictures.
“Okay”, you may think, “but the forger was not very smart in the example above”! He could have looked and realized that there was this ShutterCount metadata, the name is actually self-explicatory. Well, true… but, you know, people get arrested based on fingerprints, when everyone knows that gloves would be enough to rule them out! It’s just hard to keep everything into account, even the things you know.
Now let’s look at another case. We have a witness who claims to have reached a square with her bicycle right before two people met, and that she saw the full meeting happen. The witness provides the two pictures below, saying that she captured first the one on the left, upon arrival, and then the one on the right, a few minutes later, when the meeting began.
As in the previous case, the filename and datetime metadata are indicated as proof of truth. Upon inspection, datetime metadata actually seem to suggest that the bicycle picture is antecedent to the meeting picture by a couple of minutes.
But you already know we’ll find something strange, don’t you? So we keep scrolling the metadata and… aha!
One more cool MakerNotes metadata! This RunTimeValue was introduced by Apple devices some time ago: it tells the amount of time that has passed since the last boot of the telephone (standby time is not counted for). You can find some more details here and here. By looking at those huge numbers we already understand that something’s not right: the value of the bicycle image is larger than the other, while we would expect the opposite. Translating that value into seconds requires you to divide the RunTimeValue by the RunTimeScale. However, in the Composite metadata, you will find the translations already done for you by ExifTool and faithfully reported by Amped Authenticate (to answer a quite common question: yes, this is the meaning of Composite metadata, they are information derived from other metadata in the image, just like in this case, and they are not written in the image).
And so, we discovered that the bicycle image had been actually shot (at least) 17 seconds LATER than the meeting picture!
This week’s takeaway is: never give up! Scroll through all those metadata, you may end up discovering valuable information or, at least, learn some new things!
That’s all for today! We hope you’ve found this issue of the Video Evidence Pitfalls series interesting and useful! Stay tuned and don’t miss the next ones. You can also follow us on LinkedIn, YouTube, Twitter, and Facebook: we’ll post a link to every new Tip Tuesday so you won’t miss any!