Things that were, and things that are, and things that yet may be - ALEX is now available!

Is there really a need for another tool that wraps ADB commands in a graphical user interface?

With Magnet Acquire, Avilla Forensics, android_triage, Arsenic, and several other representatives, there are already free tools that allow ADB extractions from Android devices.

Nevertheless, I decided to create my own tool. Developing UFADE as part of my master's thesis took quite a bit of time, but it was also a lot of fun. Since I planned to give my Android tool a similar range of functions and a very similar graphical user interface, I was able to reuse some parts of the code directly with minor adjustments. The result was to be an open source tool that runs on Windows, Linux, and macOS and can be used in virtually the same way as UFADE — I present: ALEX.

The Android Logical Extractor can be obtained free of charge via GitHub and is intended as a supplement to commercial applications.

Everything is still in a very early stage and there will probably be some bugs. I definitely need help from the DFIR community here, whether through testing with a wide range of test devices or through contributions to the code.

In due course, documentation for ALEX will of course also be available on this website. Hopefully, a few more features will have been added by then.

Here is just a brief overview of the current features:

Most features are available for Android and WearOS devices (including FireOS and other Android derivatives).

Reporting Options

... as with UFADE, offer the option of outputting the displayed device information together with a list of installed apps in text or PDF format. In addition to the bundle name and version, the installation source is also displayed. This makes it immediately apparent whether an app was obtained from the Play Store or another installer. For Ubuntu Touch devices, installed apps and their respective versions are also displayed.

Acquisition Options (Android, WearOS, FireOS)

Pull “sdcard”

... allows the extraction of the user's internal memory regardless of whether USB-MTP has been enabled or not. The name of this function may be somewhat confusing. Under “/sdcard,” there is usually a softlink to the freely accessible user data, even if the directory was actually mounted under “/storage/emulated/0.” This backup mainly contains media.

ADB Backup

Although backup via ADB is becoming less and less important, some information, such as stored Wi-Fi passwords, may also be included in the extraction of newer devices. ALEX offers the option to modify the backup options via checkboxes. If “shared” is enabled, user data from “sdcard” is also backed up. This can be advantageous when analyzing with forensic tools, as the individual files are not temporarily stored in the file system and thus no modification of the timestamps occurs.

Logical+ (UFED Style)

This form of backup attempts to replicate the essential components of the advanced logical extraction of the UFED4PC software. It includes:

• the “sdcard” directory (in a zip archive)
• an ADB backup - without sdcard (in the same zip archive)
• a Report.xml with the live queried content: calls, contacts, SMS, calendar (in the same zip archive)
• an “InstalledAppsList.txt” with a list of all applications
• a ufd file for smooth import into Cellebrite Physical Analyzer ©

UFED4PC © uses an agent (i.e., an APK to be installed) for logical extraction. ALEX, on the other hand, attempts to reconstruct the information by querying the content providers.
This can be advantageous if it is not possible to install the agent on the device. However, data extraction via an agent allows more direct access to the information to be queried.

The following image shows a Logical+ backup that was read in using the Physical Analyzer:

Partially Reconstructed Filesystem Backup

Just like with UFADE, I am trying to reconstruct the filesystem as closely as possible to how it actually exists on the device. Currently, this includes:

• the sdcard directory
• “system” directories for which the shell user has permission
• Apps of the “system” user and the “/data/system” directory on devices that are vulnerable to CVE-2024-31317 (some Android 9-11 devices)
• Reconstructed databases and files (calendar2.db, calllog.db, contacts2.db, mmssms.db, and packages.list)
• A “device_info_alex.json” file with extracted device information

These options can be selected individually. Please note that the reconstructed databases are not identical in content to the files that would be available in a full file system extraction. The databases are reconstructed using content provider queries and thus originate from an API that outputs the contents of the actual databases. Reconstruction in Sqlite format serves to improve compatibility with various analysis tools that expect these files. Incidentally, Magnet Acquire also follows this approach.

In the future, an ADB backup will also be created here and integrated into the backup according to the original file paths.

The following image shows a PRFS backup that was imported via ALEAPP:
(The parser for “device_info_alex.json” has already been adopted by the ALEAPP team and will be included in the next release.)

Acquisition Options (Ubuntu Touch, AsteroidOS)

The extraction options offered differ for the alternative operating systems Ubuntu Touch (smartphones, tablets) and AsteroidOS (smartwatches).

Pull “Home”

In classic Linux systems, user data is mainly located in the “Home” directory. Therefore, the home directory is extracted instead of “sdcard” for these devices.

Physical Acquisition

Both Ubuntu Touch and AsteroidOS allow you to log in as the “root” user. This user has access to the block devices and can therefore initiate a bit-by-bit copy of the data storage. With Ubuntu Touch, the “sudo” password is required for this type of backup. This is usually the device's lock code. By default, the memory of these systems is unencrypted.

I am currently not aware of any other software that offers extraction options for Ubuntu Touch.

Logging Options

These options are available for Android, WearOS, and FireOS.
More information about the individual logging systems (and other artifacts) can be found on Mattia Epifani's blog.

Advanced Options

Take Screenshots

As the name suggests, this option allows you to capture the current screen content of the device as a screenshot. In addition to the actual image in PNG format, a text file containing the hash (Sha256) of the PNG is created. A PDF is also generated, which outputs some device information in addition to the screenshot.

The procedure for creating the screenshot also depends on the connected system. On current Android systems, the image is output directly via ADB. Older systems (e.g., Android 6) require the creation of a temporary image file on the device. The situation is similar with AsteroidOS. Ubuntu Touch currently poses the greatest difficulties in terms of screenshots - on older systems, the framebuffer can be accessed to output content from apps (not the entire screen). I will invest a little time here to create reliable screenshots without installing additional software. Until then, screenshots can also be taken on the device using the buttons loud and quiet.

Chat Capture

The screenshot function has been expanded to include the option of automatically capturing entire chats. Between individual captures, swipe movements are simulated, which are performed from the center upwards or downwards, depending on the selected capture direction. This shifts the current view by half the screen content. Other starting points could be selected to allow larger jumps (i.e., an entire screen content). However, the approach of swiping from the center worked most reliably in the apps tested so far. This feature is currently available for Android, WearOS, and FireOS.

Query Content Providers

For this feature, I drew heavily on Mattia Epifani's android_triage.
His script already lists numerous queries. I only added a few more. I also moved the queries to a JSON file. This allows you to experiment with new queries as you wish without having to make changes to ALEX's code.

Users can also choose whether the information should be output in text format (as returned by the console) or as JSON.

Some examples of possible content:

• SMS
• MMS
• Call log
• Contact list
• Calendar entries
• Device settings
• Media information (with timestamps)

ALEX is currently attempting to establish a connection with the first device in the “devices” list. This allows a connection to be established via WiFi, after which ALEX can be used for extraction. I think it will also be possible in the future to establish a WiFi connection directly via the ALEX interface.

There are definitely enough ideas for new features. Nevertheless, I am always happy to receive suggestions and success stories!