Monday, May 10, 2021

CLEAPP it! - ChromeOS Logs Events And Protobuf Parser

Short version:

Process data extractions from Chromebooks using the ChromeOS Logs Events And Protobuf Parser (CLEAPP.) 

CLEAPP is made in Python 3 and can be downloaded here:
https://github.com/markmckinnon/cLeapp


 

Long version:

Until not too long ago extracting data for forensic analysis from Chromebooks seemed impossible. Thanks Daniel Dickerman's workflow we can extract data provided you have a username and password for the device.

Check out the peer-reviewed process here:
https://dfir.pubpub.org/pub/inkjsqrh/release/1

Thanks to Magnet Forensics the process has been automated and now its implementation is available as a free software tool called the Magnet Chromebook Acquisition Assistant. 

You can do it!!

To get the free tool go here:

https://www.magnetforensics.com/resources/magnet-chromebook-acquisition-assistant/

Now what?

So now you have an awesome extraction from the device. You will receive a file named extracted.tgz.

extracted.tgz

What do you do with it? How can you dig into the contents? Use CLEAPP for it. You can get CLEAPP here: https://github.com/markmckinnon/cLeapp

Two step process:

  1. Extract the tgz file.
  2. Select the extracted data location with CLEAPP and press process. 
Simple!!! 

This project is Mark McKinnon's brainchild and it is based on the Android Logs Events And Protobuf Parser community project. ALEAPP can be found here:
https://github.com/abrignoni/ALEAPP

Currently CLEAPP parses 38 artifact categories. The project wouldn't be what it is without the contributions from Alex Caithness and Ryan Benson. Thank you so much!

Thank you gentlepeople <3

Installation

If you are familiar with how iLEAPP of ALEAPP works then you already know how to use CLEAPP. These projects are done in python. If you are not familiar with how to run python scripts just follow the steps in the following video.


You can also use the provided executables contained in the release version for CLEAPP. Those can be found here:
https://github.com/markmckinnon/cLeapp/releases/tag/v1.0

Using CLEAPP

Run the cleappGUI.py script for the graphical user interface version. It will look like this:

Click around and done

Notice the list of modules on the left. You can parse all or select individual modules. CLEAPP is pretty fast so for most purposes running with all modules enabled is recommended.

Here is a short list of some modules it supports:
  • Chromebook device details
  • Chromebook device logs
  • Chromium Browsers
  • Instagram Threads
  • Chromium LevelDB data stores (Thanks Alex Caithness & Ryan Benson)
  • Microsoft RDP
  • Real VNC
  • Google Docs
  • and tons more...

After CLEAPP finishes processing the output will be in the following formats:
  • HTML report
  • Tab separated values text files for every artifact
  • KML files for artifacts that have geolocation data points
  • SQLite timeline file for artifacts that have timestamps
  • SQlite contacts file for artifacts that have contacts information
The HTML report contains the categories and artifacts on the left of the report.

HTML report

The Device Details tab will have information on the Chromebook like serial number, current operatin system version, and more.

Device Details

One of the interesting facts about Chromebooks is that they can run Android apps. As time permits I plan to merge all ALEAPP artifacts for use in CLEAPP and make sure that both projects support Android artifacts. 

Since this is a community project we will be more than happy to have additional collaborators. 

Get ready for this, Mark has provided Autopsy integration for CLEAPP right out the bat. Check it out here:
https://medium.com/@markmckinnon_80619/cleapp-autopsy-plugin-59ba312beccc


Any questions or any comments I can be reached on twitter @AlexisBrignoni and email 4n6[at]abrignoni[dot]com.

-Brigs

Thursday, April 15, 2021

Android version without the build.props file

 Short version

Use one of the following files to determine the Android version of a digital forensic extraction that is lacking the \system\build.prop file:

  • \data\system\usagestats\0\version
  • \data\system_ce\0\usagestats\version

Long version

Most automated tools that parse Android full file system extractions depend on the /system/build.prop file to determine the Android version among other device identifiers. Due to how variable are Android implementations as well as data extracting software a build.prop file might not be available. Is there a way to determine the Android version of an extraction by only looking at the userdata directory? The answer is yes. This was useful to me since some of my digital forensics tooling for Android extractions would benefit from programmatically identifying the Android version when a build.props file is not available.

by: https://gs.statcounter.com/android-version-market-share/mobile-tablet/worldwide

Usagestats

One of the ways Android devices keep track of application activity is by registering events in the usagestats directory. Depending on the Android version these can be kept in XML or protobuf format. These can be found in the following locations depending on your Android version:

  • \data\system\usagestats\0\
  • \data\system_ce\0\usagestats\

For a quick explanation on usagestats and their applicability see here: https://abrignoni.blogspot.com/2019/02/android-usagestats-xml-parser.html

To parse usagestats data you can use ALEAPP (Android Logs Events And Protobuf Parser) here: https://github.com/abrignoni/ALEAPP

 The usagestats folder contains a plain text file called version. It is usually composed of two lines. The first one being a number and the second one a series of alphanumeric values separated by semicolons. 

Usagestats/version file from a Samsung SM-G960U

The filename clearly indicated that the content had to be versioning related. Since the build.props file is well understood and documented I made a comparison between the too to try and determine the provenance of the version's file content if possible.

Notice in the following image the side by side comparison and color coding of similar values of files extracted from a Samsung device.


From the version file's second line we can determine the following:

  •  First items = Version release = Android version
  • Second item = Codename = Fingerprint
  • Third item = Incremental build version
  • Fourth item = CRC = Country Specific Code
Thanks to Kevin Pagano (@KevinPagano3) for identifying that the fourth value is a CRC and for leading me a list that matched codes with values. These CRC values seem to be Samsung specific.

 https://www.androidsage.com/2017/07/12/list-of-samsung-galaxy-country-specific-product-code-csc-and-country-region/

It is of note that Pixel devices have less values within the version file. There is no CRC and no final value. Still the Android version was the same as the one located in the build.props file. This was true across all sample extractions I was able to check.

Version file from a Pixel phone

What about the number on the first line? Through the process of testing the values on the second line a pattern appeared for the number in the first line. It is as follows:

  • 3 = Android 8, 9
  • 4 = Android 10
  • 5 = Android 11 

Jessica Hyde (@B1N2H3X) suggested I take into consideration how the file would look, if anything, after an operating system upgrade. Great point! Thanks to Josh Hickman (@josh_hickman1) that was really easy to do. He has well documented test Android images for community use and testing. By looking at the values within the version file on his Android 10 extraction and then the values on the upgraded Android 11 image I was able to determine that an update would produce an additional file in the directory where version resides called migrated.

The migrated file.

The migrated file contains the number in the first line of the version file previous to the upgrade. After the upgrade the version file contains the numbers that are consistent with the current version. The next image is the value contained within the migrated file in the Android 10 extraction.

Migrated file with a value of 4

Now compare it with the values within the version file in the same Android 11 extraction.

Version file with a value of 5

This behaviour was also confirmed by Carlos Eduardo (@GalloDu) with his own upgraded device data.

Confirmation of migrated & version relationship

Based on this behaviour it follows that the presence of a migrated file indicates a major operating system upgrade. By comparing the contents of the migrated and version files the analys can determine from and to what version the device was upgraded to.

Pending work

For this analysis I only had access to Samsung and Pixel files. It would be of use if migrated and version files from other vendors (LG, OnePlus, etc...) are shared to see how they might defer and/or what additional data they might provide if any.

Implementation 

I have made a parser for the version file within ALEAPP. The script will identify and use Android version number contained in either the build.props or version file for reporting and artifact purposes. To quickly view the data press the device details tab at ALEAPP's report home page.

Device details tab with Android version data

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

-Brigs