How to Analyze Unparsed Data in Cellebrite Physical Analyzer
Many examiners have asked: “How do I know what Cellebrite Physical Analyzer (PA) isn’t parsing in regard to applications?” This is a great question and we decided to film it and share it with you.
PA has built-in features to aid in alerting an examiner to unparsed application data that may be hiding behind the scenes. The App Genie is a research tool built to search for application databases that may contain relevant artifacts, such as contacts, communications, and more.
The Fuzzy Model plug-in is an additional tool that carves for databases containing communications, user information, locations, and more. These two capabilities make it easier to identify what is parsed and what is left for manual examination.
In this video, we dive right into the Application Insights, which is a great place to launch the App Genie. We’ll look at how to identify what PA parsed and what it didn’t. We’ll then launch the App Genie and examine the results.
The same is then run for the Fuzzy Model plug-in. The video will review getting started, running each tool, and ultimately, examining the findings. We realize that applications can be overwhelming. Our goal is to help you manage the investigation by providing solutions that allow you to dig deeper.
There are a few ways to look for data that is not parsed out by the tool. One of those is the “Database View.” If you click on “Databases” in the “Extraction Summary,” PA will open up a list of all the databases that were discovered or recovered during data collection from the device.
We can turn off “Decoded by Cellebrite” and it will only leave blanks available because if it has already been decoded, we may not be as interested in that database right now.
We can then sort by row or by database size. More rows of data mean more data to look at. In theory, the bigger the database is the more data that will be available for examination. From there it’s just a matter of learning what kind of data is stored in some of these databases and taking the time to look at each database to see what is stored.
For example, the “onion browser” has not yet been decoded. It has a cache.db (“db” stands for “database”).
If we click on it we can look through the tables. Everything in a database is stored in tables consisting of columns and rows; similar to an Excel spreadsheet. Each table has a name and if we look at something like “cfurl_cache_receiver_data,” we can click on that and see there’s some data in there.
If we go down to “cfurl_cache_response,” we see that there are also some websites in there. If we scroll down, we start to get a little bit of information about the websites that may have been visited using that onion browser.
Simple steps like working through the databases, looking at each database, and seeing what data might be available there that is stored that you can pull out manually, can really help you get to the bottom of what you might be missing.