How to unpack Android firmware: a step-by-step guide

Particular attention should be paid to the Sparse IMG format. This is a special format used to Android ave space when writing empty file system blocks. Direct mounting or unpacking of such a file is impossible without first converting it to a raw format. Ignoring this nuance will result in you receiving a file with garbage instead of structured data.

⚠️ Attention: Never try to edit files inside the firmware image without creating a full backup copy of the original file. Even one changed byte sequence in the partition header can make the device unable to boot.

There is also the concept of a “super image” (super.img), introduced in new versions of Android with dynamic partitions. This file combines the system, product and vendor sections into a single container. Working with it requires special utilities that can extract logical partitions from the physical container before further processing.

Preparing the working environment and necessary software

To successfully unpack the firmware, you will need a computer running an operating system with command line support. Although some operations are possible in the Windows GUI, most professional tools are designed for or require terminal emulation. Setting up the correct environment will eliminate many compatibility errors and problems with file access rights. Linux or require terminal emulation. Setting up the right environment will eliminate a lot of compatibility errors and file permissions issues.

The basic set of tools includes utilities for working with archives, image converters and file system mounting tools. In the Windows environment, a popular solution is to use WSL (Windows Subsystem for Linux), which allows you to run native Linux utilities without the need to install a second OS on a virtual machine. This greatly simplifies the work with tools such as simg2img and imgextractor.

You must also make sure that the ADB and Fastboot drivers are installed on your computer if you plan to interact with the device directly. However, for purely programmatic unpacking of files already downloaded to a PC, these drivers are not required. It is enough to have a Python interpreter to work with a number of modern unpacking scripts.

• 🛠️ Python 3.x —needed to work with modern unpacking scripts, such as payload_dumper or lpunpack.
• 💻 7-Zip or WinRAR —basic archivers for extracting initial ZIP or TAR containers.
• 🐧 WSL or Linux virtual machine —the recommended environment for executing image conversion commands.
• 📂 Text Editor (Notepad++, VS Code) —for viewing and editing configuration files inside the unpacked firmware.

It is important to keep track of the versions of the software you are using. Utilities written several years ago may not correctly handle new compression formats used in recent versions Android 13 or 14. Always check tool developer repositories for updates that support the latest encryption and packaging algorithms.

Unpacking standard ZIP and TAR archives

The simplest scenario is working with official updates distributed in the form of ZIP archives. Such files can often be found on manufacturers' websites or in the recovery mode of the device. The first step is always to check the contents of the archive using any convenient archive manager. If inside you see the usual folder structure with .apk or .xml files, then the process can be considered complete.

However, most often there are other archives or images inside the ZIP archive. For example, the file system.new.dat.br indicates the use of the Brotli compression algorithm, which requires a specific approach for decompression. In this case, standard WinRar will not help, and you will have to use specialized Python scripts. The command to unpack such a file usually looks like running a script indicating the path to the archive.

For TAR files, which are often found in Samsung firmware, the process is similar. You extract the contents of the TAR archive, resulting in a set of .lz4 or .img.lz4 files. Next comes the decompression stage of the LZ4 algorithm, after which you get clean partition images. This two-step process (TAR -> LZ4 -> IMG) is standard for many vendors.

After receiving raw images (.img), you move on to the next difficulty level. If the file is a multiple of the filesystem block size (usually 4096 bytes) and is not a Sparse image, you can attempt to mount it directly. Otherwise, conversion is required.

⚠️ Attention: When unpacking Samsung firmware, remember that the files inside the TAR archive may have checksums. Changing the content without recalculating the hashes will result in a verification error when trying to write back to the device.

Converting and working with Sparse IMG images

Sparse IMG is an optimized image format that does not take up disk space for empty blocks. An attempt to open such a file through a regular archiver or mount it as a regular disk will result in an error or display of incorrect data. To work with it, you need to convert it to a Raw IMG (raw image), which contains a complete copy of the data, including zero blocks.

The main tool for this task is the utility simg2img, which is part of the Android SDK Build Tools. The conversion process is performed via the command line. You need to specify the input file (sparse) and the output file name (raw). The command is executed quickly, but the resulting file can be several times larger than the original one, since it is filled with real zeros.

simg2img system_sparse.img system_raw.img

After successful conversion, you receive a file that you can work with using standard tools. However, if the image is encrypted (which is often the case with a partition userdata), you will only be able to see the file system header, but not the files themselves. Decryption requires keys that are unique to each device and are generated based on hardware identifiers, making the process extremely difficult for the average user.

In some cases, the image may be split into several parts (system_sparse.img.0, system_sparse.img.1, etc.). In such a situation, you first need to merge these parts into one file using the command cat in Linux or specialized utilities in Windows, and only then apply the conversion. simg2img.

Extracting data from files system.new.dat and payload.bin

Modern firmware, especially for Google Pixel devices and many Chinese brands, use the A/B (Seamless Updates) update mechanism. In such firmware, the data is packed into a file payload.bin, which contains the delta (difference) between the old and new versions of the system, or a full image compressed in a specific way. Direct unpacking of this file is impossible without using payload_dumper.

The utility payload_dumper is written in Python and allows you to extract individual partition images (system, boot, vendor) from a binary container. The process requires a file payload_properties.txtthat sometimes comes with the firmware, as it contains metadata about versions and hashes. Without this file, some versions of dumpers may fail to work.

Another common format is system.new.dat (sometimes paired with system.transfer.list). This format was used in OTA updates prior to the introduction of Project Treble. The .dat file contains compressed data, and the .list file contains instructions on how this data should be written to disk (which blocks to erase, which to move). To extract files from such a pair, use a script dat2img or similar tools in Python.

After extracting the image from payload.bin or dat-file, you get an .img file again. Often this file is still a Sparse image, so the cycle of "Extract -> Convert to Raw -> Mount" is repeated. This is a multi-step process that requires care at every step.

• 📦 payload.bin — a container for A/B updates, requires payload_dumper.
• 📝 system.transfer.list — a block map for recovery from a .dat file.
• 🔑 meta-data — a file with information about the sizes and types of partitions inside the payload.
• 🔄 A/B Partition — a diagram partitions where the data can be located in slot _a or _b.

⚠️ Attention: The structure of payload.bin files and the compression formats inside them change with each new major Android update. A script that worked for Android 10 may not work for Android 14. Always look for a more recently released version of the tool.

Mounting images and analyzing the file system

The final stage of unpacking is gaining access to the files inside the image. Once you have received the Raw IMG, you need to mount it into the operating system as a virtual disk. In Linux, this is done easily through the command mount indicating the file system type (usually ext4 or erofs). On Windows, you will need third-party drivers, such as Ext2Fsd or WSL2 functionality.

Modern devices are increasingly switching to the file system EROFS (Enhanced Read-Only File System) for the system partition. This system is read-only and provides better performance and compression. It is difficult to mount EROFS using standard Linux tools; it often requires compiling special kernel modules or using a utility fsck.erofs to extract files without mounting.

After mounting, you get access to the directories /system/app, /system/framework and others. Here you can extract APK files, .so libraries and configuration XML. Be careful: changing the permissions (chmod) or ownership of files inside a mounted image may prevent the system from reading those files after booting.

You can use the utility imgextractorto extract the entire contents of an image without mounting it. It recursively goes through the image and pulls out all the files into a regular folder on your computer. This is a safe method, since it does not require superuser rights to mount block devices and does not risk damaging the file system structure if unmounted incorrectly.

python3 imgextractor.py system_raw.img output_folder

Analysis of extracted files allows you to understand which applications are system, which libraries are used to operate the hardware, and how the network is configured. This is an indispensable tool for custom firmware developers and security researchers.