Trust but verify: Formats, timestamps, and validation

One of the most important aspects of digital forensics is the need to validate tool output. Sadly it is also one of the most overlooked by practitioners. The reason for this is obvious, NO TOOL IS PERFECT. No matter the vendor, no matter how gifted the developer is. No tool is perfect. Heck, nothing is (except the wife of course.) But when perfection, or as close as we can get to, is the goal then we have to test.

One of the easiest ways to conduct a quick sanity check validation is by comparing the output of one tool to the output of another. But what happens when you only have the output of one tool and nothing else? When the extraction is only parsed by the tool set that created it?

You actually do.

For some years now Cellebrite has been using the disk archiver format (http://dar.linux.free.fr/) to collect full file system data from target devices. This format is known as DAR. It goes without saying that UFED4PC and Physical Analyzer (PA) are THE industry leading tools with incredible technology behind it. Anyone that has used their products can attest that they are one step away from magic (and that step I contend is above not below.) Any comments on the tool are done in the context of full praise and illustrate the great work they do as developers, technicians, and experts. Folks that have a zeal for truth and clarity in the service of justice.

Today a new version of PA (7.31.0.222) came out. It addresses a bug on the way creation times where being presented after processing a DAR file with previous PA versions. For full disclosure it is well documented that I am not a big fan of the format, or any other obscure format for that matter.

Then again I am all for progress and advancement if something is better, faster,  and/or more modern. Still with the new there comes risks. I remember back in the day when Microsoft re-did the whole network stack for Windows Vista from scratch and some old network vulnerabilities resurfaced. The point of this analogy is that new implementations will always require extra work and vigilance due to their newness. Both in implementation and application.

The new release addresses many things but mainly, in my opinion, the following:

• PA was not parsing the creation date from the DAR file.
• There was some issue with access and modified dates.

Below are a couple of screenshots from the release.

Birth - Creation time

Access and modified

Per the release notes older versions of PA were not presenting the changed category of timestamps as well as giving erroneous dates for the creation category. We infer this from the fact that only the change, modify and access timestamps where supported by DAR as seen above. 

This confused me. If DAR itself only supports 3 types of timestamps, how can just reprocessing, and not re-extracting, fix the problem? I will assume that the release meant to say that DAR extractions do contain all timestamps but that older versions of PA were ignoring the change times and putting a wrong timestamp under the creation label.

Here is how that looks when we compare the new PA version with the previous one. The following is a screenshot of some image metadata parsed from a DAR by PA 7.28.0.203.

As explained in the release there are only 3 timestamps visible. These are created, accessed and modified. There is no changed timestamp. Let's now look at the same image from the same DAR extraction as parsed with PA 7.31.0.222.

Notice how there is now a 4th timestamp, changed. Even more interesting is to note the difference in creation times between PA versions. The following seems to be the issue in the old PA output:

• The changed time is the modified time.
• The creation time is the accessed time.

In this particular case the difference between the creation and access times is 17 days. It goes without saying how critical the misplacement of this information can be when dealing with geolocation data or any file type that is tied to user generated activity. From when an image was taken to the time it was last accessed, timestamps can be the determining factor between freedom or incarceration. Just on a timestamp! If your case depended on a key creation timestamp you need to go back, as the release notes, and reprocess that case again. 

Conclusions:

1. I love Cellebrite. The previous is not a dig at them, their technology, and much less their people. They came out with a fix and release notes about it as one expects from industry leading vendors when the inevitable bug surfaces. They aren't the first, wont be the last, and that is ok. I appreciate and value the cutting edge work they do and how the push the industry forward with newer, better, and faster things.
2. Trust but verify. This is hard when presented with somewhat of a black box scenario. In this case the only way to test that I could see was to get a test phone, create known data, generate a DAR extraction, jailbreak the device, SSH into the device, and compare timestamps between the device and the tool. Not an easy nor quick task for most users. How can this be approached as a community exercise, since no one person can do this alone, is something we should all think about and share ideas for.
3. Vendors should not move to a new technology without providing some backward compatibility to more established formats. It could be temporary acting as a bridge to newer ones. For example E01s are still supported even when newer formats, like AFF4, are now around. If the new format is needed because there is no other way to do the thing then the way it was implemented should be shared with the community. For an example see Blackbag (a Cellebrite company) and how they provided the specs to their APFS implementations. Incredible work.

If anything else I hope the previous motivates you to read all release notes that have to do with the tools you depend on for work. As en examiner you need to understand what the tool does, what new things it does, and what things it has failed on and how they were fixed. Own your data. Own your tools. Research, test and validate. And whatever you find, make it known.

As always, I can be reached on twitter @AlexisBrignoni and email 4n6[at]abrignoni[dot]com.

So you have a DAR file...

With UFED support of Checkm8 for iOS extractions Cellebrite uses the DAR (Disk Archiver) format as their archiving file type of choice. It works great and captures the necessary data but it is not easy to work with nor does it have widespread third party support.

Cellebrite? Yes!!! - DAR? ok...

That being said the nice folks at Cellebrite promised additional image support in the not too distant future.

If you speaketh they will listenth

In the meantime you might want to validate the Cellebrite tool output or run a third party tool to generate a particular visualization. What to do?

The solution is pretty easy. First get the DAR binaries for your favorite platform. For this example we will use Windows. The files can be found here:

https://sourceforge.net/projects/dar/files/dar/2.6.8/

Get that (ironic) Windows ZIP

When the files are extracted add dar.exe to your Windows Path so you can access the executable from any command line window. For help on how to do that go here:

https://www.howtogeek.com/118594/how-to-edit-your-system-path-for-easy-command-line-access/

After that is done go to your UFED Checkm8 extraction and identify the file/s that end in .dar.

In my case I decided to move the FullFileSystem.1.dar to the same directory as the dar.exe program to make my extraction command as short as possible. To extract make sure to be in the directory that will hold all the extracted files coming from the dar file, the destination directory. From there run dar.exe with the -x argument and the location of the dar archive. Since I placed it in the same directory as the dar.exe the path is as short as it can be.

Notice how the executable seems to notice the #1 in the filename assuming there are more parts to the dar file. When that warning shows up just press enter and let it move forward. After a little bit you will see files and directory locations fly by the command prompt as everything is being unarchived. When done you should see the following:

Success!!!

As seen in the image with the command line execution, the data is now in the extracted directory. Now you can point third party tools that can traverse directories (Apollo, iLEAPP, KAPE, etc...) and get the needed validations and/or visualizations.

For testing I pointed iLEAPP to the extracted files directory.

Notice the Extraction location and Extraction type entries. The scripts were able to parse all the data with no issues.

As examiners we will be well served to live in the spirit of the survivalist mentality. To always improvise, adapt, and overcome (while documenting of course.) Find a way to get the data, make the correct interpretations, fulfill the mission.

As always remember to validate all findings and be aware I can be reached on twitter @AlexisBrignoni and via email 4n6[at]abrignoni[dot]com.