In the age of file-based encryption, complete file system extractions are the gold standard for analyzing mobile devices.

App and system data, logs, media, and ideally the keychain allow for a comprehensive analysis of an Android smartphone (we will exclude multi-user scenarios from this discussion for now).

But what if, despite known login credentials, no file system backup is currently available for a recent device? Android/iOS developers and forensic software providers have long been engaged in a cat-and-mouse game. It often takes some time before a “FFS” is made available for a new model.

Many commercial tools offer an “advanced logical backup” for these cases - that is, a collection of the data that the device voluntarily discloses. This backup is usually far less comprehensive and contains, for example, only a fraction of the available app data. Nevertheless, depending on the objectives of the investigation, this type of extraction can also be justified. Incidentally, I have named my own modification of an extended logical backup for UFADE and ALEX PRFS (“Partially Restored File System”).

Beyond the scope of actually available files (as copies from the device file system), Android offers several built-in tools that allow relevant information to be retrieved from the system without the source files being directly accessible. The Bash tool Android Triage by Mattia Epifani automates some of these queries and provides a dialog-based interface for the command line. This script also served as the inspiration for some of the features I integrated into ALEX.

For example, a PRFS backup of an Android device (in the default configuration) includes not only files accessible to the user (the “Dump” folder) but also live-queried content (the “Extra” folder), which cannot be found in the file system in this form. Currently, the following ADB commands are used:

| Command | Path in Backup | |

Over Christmas, a family member asked me for a little help with data migration between two iPhones.
This also involved transferring chats from the Threema application from one device to the other.
Although this was not possible as desired (without setting up the second device again), a new iLEAPP parser at least made the chats readable.

Threema

The paid app can be purchased from the App Store (Adam ID 578665578).

Threema is essentially a chat application with E2E encryption and a focus on data protection and privacy. The app's code is even open source: Github. Developed in Switzerland, Threema is mainly used in German-speaking countries. The Swiss army and administration rely on Threema, as do various German politicians. But the application is also considered an (data protection) secure alternative to WhatsApp internationally. Recently, the app was featured in the Darcy Jenson case. Three Australian citizens are alleged to have received instructions from a “Mr. Big” via Threema to murder Australian Zivan Radmanovic on the Indonesian island of Bali.

The fact that no phone number or email address is required for registration contributes to the anonymity of using Threema.

So far, I have only looked at the iOS version. An analysis of the Android version may follow later.

Data backup

Conveniently, the Threema database is not only included in an FFS backup, but also in an iTunes backup (and thus in a UFADE PRFS backup). User data is located (as is often the case with iOS applications) in the “Shared” directory:

/private/var/mobile/Containers/Shared/AppGroup/{uuid}

Outsourced media files are located in the hidden subfolder: .ThreemaData_SUPPORT/_EXTERNAL_DATA/

Special thanks go to my colleague Bruno Fischer, who provided me with several innocuous data sets to test my parser and create this documentation.

Sources

User data is almost exclusively stored in the database: ThreemaData.sqlite. Thankfully, almost everything here (compared to PotatoChat) is readable in plain text and logically structured.

The following tables are particularly interesting:

| Table | Content | |

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!

I was recently made aware of an iOS chat application called “Potato Chat,” for which no tool offered processing at the time (the app is now supported by several commercial providers).

In any case, my interest was piqued, and I installed the app on my iPhone 7 Plus test device, as I was able to jailbreak it and thus create a full file system backup without commercial tools.

Bruno Fischer, who is also a contributor to LEAPPs, helped me create test data. He will work on the Android version of the app and provide an ALEAPP parser in due course.

Through online research, I discovered that investigations into this app had already been conducted. DFIR examiner Forrest Cook (Whee30) has already addressed the app in two blog posts:

forrestcook.net - Potato Chat
forrestcook.net - Potato Chat 2, starchy boogaloo 🥔💬

He also provides his own Python scripts for processing binary blobs on Github:

Whee30 - App Parsers - Potato

His work helped me immensely in understanding the references created by the app, and when preparing group chats, I was able to use parts of his code with slight adjustments for interpreting blobs.

More on that later.

Potato Chat

On iOS, the app can be conveniently downloaded from the App Store (Adam ID 1204726898). The Android version is not available in the Play Store – here, the APK file must be downloaded from the developer's website and installed manually.

The main features of the app include:

• User-to-user chats
• “Secret chats” that are not synchronized with the web service
• Group chats
• Calls (within chats)

In addition, other features are offered, but these are not the focus of the current investigation:

• Sending and requesting payments
• Installation and use of additional apps and games via an internal app store

Data acquisition

I first collected some app information directly from the device. This allowed me to trace the bundle ID “org.potatochat.PotatoEnterprise” via the UFADE report. It was also apparent that the “Documents” directory was not shared with the user.

More detailed information could be obtained directly via Pymobiledevice3:

python3 pymobiledevice3 apps query org.potatochat.PotatoEnterprise

Output (abridged):

"CFBundleDisplayName": "Potato",
"CFBundleShortVersionString": "2.47.207050",
"CFBundleURLName": "org.telegram.TelegramHD",
"Container": "/private/var/mobile/Containers/Data/Application/C701A36E-63F1-4F6C-B579-59EB3AB2B9D2"
"GroupContainers": 
{"group..ph.potatochat.Potato": "/private/var/mobile/Containers/Shared/AppGroup/7CF11843-0DC7-461A-84C2-7F33310EAEB0",
"group.org.potatochat.PotatoEnterprise": "/private/var/mobile/Containers/Shared/AppGroup/D2734A7E-41BD-4DDD-801E-C5623C27A927"
},

The practical aspect of this approach is that the relevant app directories are output directly, eliminating the need to search the backup for the appropriate app GUID. I plan to provide this information via a UFADE app report in the future.

The actual user data was found in the directory: /private/var/mobile/Containers/Shared/AppGroup/D2734A7E-41BD-4DDD-801E-C5623C27A927.

All data considered by the created parser is located here in the Documents subdirectory. This is only included in a complete file system image. There is also a Caches directory, which apparently contains pairs of image data and an associated thumbnail. These files were also found in a PRFS backup. The relationship between the images and the app will also be discussed later.

Locations

In Forrest Cook's blog articles, the naming of files and their storage locations has already been discussed extensively.
Therefore, here is just a summarized overview of the locations within the Documents directory:

| Artifact | Location | |

Since there is some interest in the community for instructions on how to build my “UFADE Touch” acquisition system, I am providing a short construction report and tips for initial setup here.

Components

I aimed to build a system as affordably as possible.
My first version of a portable backup device is therefore not based on the current Raspberry Pi 5 but instead on the cheaper fourth-generation model with 4GB of RAM. I also considered that the 4B has lower power consumption than the Pi 5.

A touchscreen was essential so that backups could be performed without a mouse and keyboard during everyday use. I specifically wanted a display with an DSI interface to keep the four USB ports of the Raspberry Pi free for data sources and destination drives. Most inexpensive displays only offer HDMI and USB connections.

The cheapest display that met my criteria was available from a large international online retailer.
The product name: "7inch Capacitive Touch IPS Display for Raspberry Pi, with Protection Case, 1024×600, DSI Interface".

Advantages in my view:

• 7 inches is pleasantly compact
• The low resolution of 1024x600 (saves resources)
• DSI connection for display and touch
• Case included
• Power passthrough for fan

To ensure longevity and stable performance, I opted for active cooling. I chose the "GeeekPi Ultra Thin ICE Tower Cooler". Besides being relatively quiet for its size, it offers a lot of surface area due to its slim fin design.

The operating system is installed on a 64GB SanDisk UHS-1 microSD card. That’s more than enough for a lean system and some essential tools. Backups are intended to be stored on external drives anyway.

Component summary (German retail prices as of July 2025):

| Component | Price | |