Androidqf : (Android Quick Forensics) Helps Quickly Gathering Forensic Evidence From Android Devices, In Order To Identify Potential Traces Of Compromise

Androidqf (Android Quick Forensics) is a portable tool to simplify the acquisition of relevant forensic data from Android devices. It is the successor of Snoopdroid, re-written in Go and leveraging official adb binaries.

androidqf is intended to provide a simple and portable cross-platform utility to quickly acquire data from Android devices. It is similar in functionality to mvt-android. However, contrary to MVT, androidqf is designed to be easily run by non-tech savvy users as well.

Build

Executable binaries for Linux, Windows and Mac should be available in the latest release. In case you have issues running the binary you might want to build it by yourself.

In order to build androidqf you will need Go 1.15+ installed. You will also need to install make. When ready you can clone the repository and run any of the following commands, for your platform of choice:

make linux
make darwin
make windows

These commands will generate binaries in a build/ folder.

How To Use

Before launching androidqf you need to have the target Android device connected to your computer via USB, and you will need to have enabled USB debugging. Please refer to the official documentation on how to do this, but also be mindful that Android phones from different manufacturers might require different navigation steps than the defaults.

Once USB debugging is enabled, you can proceed launching androidqf. It will first attempt to connect to the device over the USB bridge, which should result in the Android phone to prompt you to manually authorize the host keys. Make sure to authorize them, ideally permanently so that the prompt wouldn’t appear again.

Now androidqf should be executing and creating an acquisition folder at the same path you have placed your androidqf binary. At some point in the execution, androidqf will prompt you some choices: these prompts will pause the acquisition until you provide a selection, so pay attention.

The following data can be extracted:

1. A list of all packages installed and related distribution files.
2. (Optional) Copy of all installed APKs or of only those not marked as system apps.
3. The output of the dumpsys shell command, providing diagnostic information about the device.
4. The output of the getprop shell command, providing build information and configuration parameters.
5. The output of the ps shell command, providing a list of all running processes.
6. (Optional) A backup of SMS and MMS messages.

Encryption & Potential Threats

Carrying the androidqf acquisitions on an unencrypted drive might expose yourself, and even more so those you acquired data from, to significant risk. For example, you might be stopped at a problematic border and your androidqf drive could be seized. The raw data might not only expose the purpose of your trip, but it will also likely contain very sensitive data (for example list of applications installed, or even SMS messages).

Ideally you should have the drive fully encrypted, but that might not always be possible. You could also consider placing androidqf inside a VeraCrypt container and carry with it a copy of VeraCrypt to mount it. However, VeraCrypt containers are typically protected only by a password, which you might be forced to provide.

Alternatively, androidqf allows to encrypt each acquisition with a provided age public key. Preferably, this public key belongs to a keypair for which the end-user does not possess, or at least carry, the private key. In this way, the end-user would not be able to decrypt the acquired data even under duress.

If you place a file called key.txt in the same folder as the androidqf executable, androidqf will automatically attempt to compress and encrypt each acquisition and delete the original unencrypted copies.

Once you have retrieved an encrypted acquisition file, you can decrypt it with age like so:

$ age –decrypt -i ~/path/to/privatekey.txt -o .zip .zip.age

Bear in mind, it is always possible that at least some portion of the unencrypted data could be recovered through advanced forensics techniques – although we’re working to mitigate that.