Tuesday, March 17, 2020

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 ( 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

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

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. 

  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.

Tuesday, March 3, 2020

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:
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:
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:

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.

Saturday, February 22, 2020

ALEAPP - Android Logs Events And Protobuf Parser

From the department of unimaginative names comes ALEAPP, the sister script to iLEAPP. For additional information on iLEAPP go here.

ALEAPP will aggregate all my previous Android parsing scripts as well as be the framework for future script development. Previous users of iLEAPP will recognize the same interface and workflow present in ALEAPP. The script can parse logical file systems, tar and zip extractions as well as providing reports in html and csv formats.

ALEAPP can be downloaded from:


GUI interface
This first release only parses events and accounts from the Wellbeing Android database. I can't thank enough Josh Hickman for sharing his research on the Wellbeing database and allowing me to use it to make the first ALEAPP artifacts. His research is a must read if you do Android digital forensics and can be found here:


The next artifact to be supported will be UsageStats events both in XML and protobuf formats. For details on this artifact go here and here. The standalone script that parses UsageStats can be found here. ALEAPP will absorb that functionality. Many thanks to Yogesh Khatri for his UsageStats research and coding.

The prerequisites for ALEAPP are:

  • Python 3.7.4 and above
  • pip install six
  • pip install PySimpleGUI
The next screenshots illustrate the Wellbeing artifacts output.

The Wellbeing Account report normalizes a protobuf file for account information. The data is shown in both parsed and unparsed formats.

Account data
The Wellbeing Events report has tons of useful data. Josh Hickman's post has all the details. Great investigative data source.

Add captionfdfd
A csv report example.

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

Saturday, February 15, 2020

Initial thoughts on Android 10 parsing

When Josh Hickman (@josh_hickman1) told me he was working on creating an Android 10 full file system image as part of his testing images series I was stoked. After suggesting some apps to test he diligently worked on it and made the image public for all to use. Go get it here. Before I continue I want to thank Josh for putting this work out and to express how useful it is to everybody. Thank you!

After running the image by two commercial digital forensic tools I noted a few things.
  • When parsing the image with commercial DFIR you will see 99% of what you expect to see. This is good and speaks to the maturity of Android as an operating system and the responsiveness of vendors in this space. Still, as expected, a new OS version will break artifact parsers third party apps and native files. It is our job to figure out where the known but now lost items are as well as finding new artifacts we weren't aware of. This is how toolmakers can focus effectively on what needs to be done, it is us doing the work and telling them what's important to us.  For example chat messages from Discord and TikTok seem to be missing even though they are there. In the case of TikTok the old database query to extract chats still works. SQL queries can be found here.
  • One example of a native OS file changing format is the UsageStats files. These keep track of application usage. It is similar to KnowledgeC database entries in iOS. For details see here. Traditionally these UsageStats files where XML formatted. With Android 10 they are now protobuf encoded.All credit goes to Yogesh Khatri since he did all the heavy research work on it. His blog post is required reading. It can be found here. Not only did he identify the change in format he also updated my old UsageStats XML parser to make it protobuf encoded capable. The script can be found here. These protobuf encoded files were not decoded by the digital forensic tools. As said before, this is not a bash on digital forensic tool developers. It is a call to action to the community to test, discover, and help focus our development efforts on the artifacts we need and deem to be relevant.
  • It is rare. Haven't seen it happen on a case yet but never assume you never will. Multiple user accounts on an Android device. Artifacts left behind by a second account seem to be missing or come out jumbled together after parsing. For example if the examiner looks at app data she might find that in one case a parsed report for a database might show data for both accounts while in another artifact the data available is from the currently active account only. It is important that we identify the presence of multiple user accounts on the device and take steps to validate our output accordingly. A quick check for multiple user accounts can be done by looking at the contents of the /data/user_de/ directory. If you see another folder other than folder 0 then you have multiple user account on the device.
Multiple user accounts. Usually account #2 is 10 but who knows why it went to 11.

As an example of how tool design might affect report output I will show how my own UsageStats parser script comingles in one report the data from the two Android user accounts on the device.

After extracting the UsageStats directory the script is run.

Notice it processed 11099 records from the files.
Next I separately processed the data from each user directory. To do so I processed the usagestats directory with either directory 0 or directory 11 present.

Directory 0 and directory 11.
Data processed from user directory 0:

Records processed number went down to 8796.
Now user directory 11:

Records processed number is 2303.
Even without looking at the contents of each report we can determine which account was used the most easily. This insight would have been lost if the data was shown all together in one report.

As examiners we own the data we are tasked with processing and it is our responsibility to verify that any inferences gathered from it are exact and backed up by the source. We are uniquely positioned to identify gaps in knowledge, to work in filling them up, and sharing that knowledge with others that can automate the process to the benefit of the greater community of practitioners. If you feel bored while working in this field you are definitely not paying attention. Your perspective is needed, your expertise is essential. Make it known. 

Saturday, January 11, 2020

Awesome Friends!

iLEAPP wouldn't be possible without the assist of some awesome friends. Heck, they go beyond awesome. They truly are....

I'm the doggo. :-)
From research, coding, and being innovators to listening and discussing all things #DFIR and beyond, the following folks are truly heroic. I owe them a debt of gratitude for all the help and support I've been given. The list is not complete and I will be adding more soon. This blog post will be a link in the main iLEAPP report webpage. Without further ado:

Sarah Edwards
Sarah Edwards

Researcher: iOS Jedi Council Master in KnowledgeC, Powerlog, and literal tons of other relevant databases and artifacts. No iLEAPP without her monumental work.
Coder: Apollo Framework. THE best pattern of life analysis tool anywhere for iOS devices. Period.
Twitter: https://twitter.com/iamevltwin
Blog: https://www.mac4n6.com/
Github: https://github.com/mac4n6

Jessica Hyde
Jessica Hyde

Researcher: UsageStats in Android, IoT Forensics, and the best and most energetic presenter in the multiverse. Her ideas, DFIR philosophy, and suggestions for improvement have been and will continue to be key in the field and to me personally. She is an educator extraordinaire.

Phill Moore
Phill Moore

Researcher: As the person responsible for This Week in 4n6 he needs no intro. Truly my Australian brother from another mother. His GSERPent parser opened my eyes to the importance of applied research that screams to be shared. This is something i've tried to emulate. Lucky enough to work on joint projects and steal find inspiration in his code. 
Coder: KnowledgeC Struct Metadata script now in iLEAPP.

Heather Mahalik
Heather Mahalik

Researcher: World class Grandmaster mobile forensics Sensei. Renowned investigator known for dragging a body across the floor for science she is always at the forefront of the newest iOS artifacts and related forensic techniques. Her work is also an integral part of iLEAPP. Fortunate enough to have been, and to continue being, her student. Osu!!
Twitter: https://twitter.com/HeatherMahalik
Web: https://smarterforensics.com/
Blog: https://smarterforensics.com/blog/

Mattia Epifani
Mattia Epifani

Researcher: iLEAPP leverages TONS of artifacts that come straight from Mattia's research. His blog posts are INDISPENSABLE reading for all things iOS. Hope to meet him in person in a not too distant future. It will be an honor.
Twitter: https://twitter.com/mattiaep
Blog: https://blog.digital-forensics.it/

Geraldine Blay

Researcher: Until not too long ago my DFIR padawan she has now graduated to full, all awards, master. Couldn't be more proud of her work and her tangible results. She is mom to Siri, the best electronic sniffing canine this side of the Mississippi. You both are the best.
Tester: Hope your patience dealing with by buggy beta code doesn't run out any time soon.
Twitter: https://twitter.com/i_am_the_gia
Blog: https://gforce4n6.blogspot.com/

Mike Williamson
Mike Williamson

Researcher: My Canadian brother from another mother. I hope to one day have 1/2 of your skills. Heck 1/4 and I'm set for life. Reverse engineer, mission focused, lucky I can call him friend.
Coder: Yes, yes, yes. I learn and say thanks.
Twitter: https://twitter.com/forensicmike1
Blog: https://forensicmike1.com/

Christopher Vance

Researcher: If you haven't taken a course with Chris you are missing out for real. I will never be able to repay him for letting me complement his deleted apps research that gained us a DFIR Summit 2019 speaking slot. His iOS notifications research has been applied in iLEAPP. I don't know of any other tool that applies it yet.
Twitter: https://twitter.com/cScottVance
Blog: https://blog.d204n6.com/


Tester: Thank you so much for debugging that unicode error! You are awesome and I have lots of respect for you and the essential work you support. I don't know how you do so much work day in and day out. Much appreciated.
Twitter: https://twitter.com/xbrookego

Jack Farley
Jack Farley
Researcher: Thank you so much for letting me use your connected devices code in iLEAPP. Wish I could code as concise and precise as you.
Coder: Best iTunes Backup Analyzer blog and script I've seen. If you want to understand how these backups work in detail and understandable English his blog IS a must read. Check it out.
Twitter: https://twitter.com/JackFarley248
Web: http://farleyforensics.com/

Shafik Punja
Shafik Punja
Tester: Thank you for making iLEAPP accessible without a magnifying glass. Testing is so important. Thank you for giving some of your time.
Twitter: https://twitter.com/qubytelogic

Researcher: The one and only Cheeky4n6Monkey has been around for quite awhile making the world easier for digital evidence examiners. His work is always a must read and his code is super useful.
Coder: I took a bunch of his code and implemented it in iLEAPP. Attribution as comments in code. Check the out the github. Highly recommended.
Twitter: https://twitter.com/Cheeky4n6Monkey

Edward Greybeard
Contributor: Mysterious, efficient, generous with his time and skills. That's all you need to know.
Github: https://github.com/edward-greybeard

Douglas Kein

Tester: Breaker of code extraordinaire, which is precisely what is needed. Your testing has made the code way more resilient and useful. Thank you so much!!! It helps a ton.

Thursday, January 9, 2020

iLEAPP latest updates for 01/09/2020

iLEAPP download: https://github.com/abrignoni/iLEAPP

The iOS Logs, Events, And Properties Parser has been updated by adding the following artifacts:
  • Photos.sqlite
    • Metadata about media files to include deletion timestamps.
    • Thanks to Heather Mahalik for the query.
  • Medialibrary.sqlite
    • Multimedia file list and metadata.
  • Accounts3.sqlite
    • System accounts.
  • Zliveusage & zliveprocess data.
  • Device screen auto lock history.
  • Unicode support for artifact reports.
    • Thanks to @xbrookego for testing and helping debug
  • Error handling for databases that lack tables.
  • Alternating report background row color for readability.
Any errors encountered during usage or request to support additional artifacts please report via Twitter @AlexisBrignoni and/or email 4n6[at]abrignoni[dot]com.

Sunday, January 5, 2020

iLEAPP latest updates for 01/05/2020

iLEAPP download: https://github.com/abrignoni/iLEAPP

The iOS Logs, Events, And Properties Parser has been updated by adding the following iOS 12 & 13 artifacts:

  • KnowledgeC
    • Application Usage
    • Application in Focus
    • Application Activity
    • Battery Level
    • Applications Installed
    • Device Locked
    • Plugged In
  • Call History
  • SMS
    • SMS Chat
    • SMS Read
    • SMS Delivered
  • Safari History
  • Query Predictions
  • Powerlog
    • Mobile Backups
    • WIFI Properties
    • Paired Device Configuration
  • Proper report URL pathing. The iLEAPP report can be copied/moved to any directory and the HTML reports work as expected.
  • Added a "temp" directory at the root of the report folder that contains a copy of the data sources used by the scripts. The temp folder is created on .tar and .zip processing reports only.
Any errors encountered during usage or request to support additional artifacts please report via Twitter @AlexisBrignoni and/or email 4n6[at]abrignoni[dot]com.