Unlocking Android Devices with Brute-Force
Table of Contents
Even non-DFIR people nowadays know that manually guessing an unknown passcode is the fastest way to permanently lose access to a device—and its data. Device manufacturers and software developers have done an impressive job protecting user data. And even if there are no login attempt limits, doing Android pin brute-force by hand with thousands and millions of possible combinations? Clearly not an option.
So, how to unlock an Android device for forensic purposes? Find a vulnerability that lets you break into the system, bypass restrictions (at least, part of them), and launch an automated brute-force attack.
Easier said than done.
Android devices are incredibly diverse. While they share common security features, there is no one-size-fits-all approach. The available solutions target specific groups of chipset models, that is why each Android password brute-force method in Belkasoft X comes with its own workflow—depending on whether you are dealing with a MediaTek, Kirin, or Unisoc-based device.
Android lock screen brute-force in a nutshell
Most Android devices that end up in forensic labs nowadays have user data encrypted. The encryption keys used to secure it are derived in the Trusted Execution Environment (TEE) after the device is booted and the user supplies their passcode. They are based on device-specific keys and the keys derived from the user’s lock screen passcode.
Forensic brute-force attacks leverage chipset-specific vulnerabilities, exploiting weaknesses in the boot process like insecure boot ROMs or debug modes. In particular, Belkasoft X can interrupt the secure boot chain, obtain code execution at a low level, and extract the keys needed to brute-force the passcode from TEE. It runs the brute-force attack offline—avoiding Android’s normal throttling (delays or attempt limits). The passcode guessing speed depends on the complexity of the key derivation function and on the computing capacity of the digital forensic workstation.
This process does not interact with user data dumped from the device, that is why it is unlikely to alter information or cause data loss.
Unisoc brute-force specifics
Unisoc’s low-cost processors (formerly Spreadtrum) are found in many budget Android devices. Some of these SoC models include vulnerabilities that allow code execution in the BootROM simply via USB when the device is booted into Spreadtrum Download Mode (SPD). Belkasoft X exploits them to run its own code at the earliest boot stages, dump encryption key material, and brute-force the passcode offline. BootROM flaws are not patchable via software update (they are in read-only memory), so affected SoCs remain vulnerable.
This brute-force method is part of the Spreadtum acquisition workflow, and it is easy and relatively fast to run. You just need to install a couple of drivers, put the Unicoc device into the SPD mode, and begin the process.
MediaTek (MTK) brute-force specifics
MediaTek SoCs power a variety of Android devices (especially mid-range phones by Xiaomi, Vivo, Oppo, and the like). Many of these devices lack a dedicated secure element and rely solely on the TEE for protection—and critically, MTK’s BootROM has known vulnerabilities that open the door to brute-force attacks. In particular, it allows uploading and executing unsigned code before secure boot enforcement.
Belkasoft X provides an acquisition workflow that can break into the booting process of devices based on a number of MTK chipsets. Just like with Unisoc-based devices, it downloads the physical device image and encryption key material to run the brute-force process offline.
To successfully perform MTK brute-force, you will need to install drivers for low-level communication with MTK and then put the device into BootROM mode (or Preloader mode, for some devices). The whole process requires a few more prerequisite steps and more attention than the Unisoc brute-force one, but it is still relatively easy to run, and it works quite fast.
Kirin brute-force specifics
HiSilicon Kirin chipsets, used primarily in Huawei and Honor devices, present a slightly different scenario. Huawei's flagship phones often had robust security (including their own TEE implementations and, in newer models, integrated secure elements for payments). Unlike MTK or Unisoc, there have not been as many public BootROM exploits disclosed for Kirin. Instead, DFIR tools use Huawei’s device-specific engineering modes and bootloader vulnerabilities.
To brute-force a Kirin-based device, you must place it into USB Download mode (also referred to as COM Port mode), which enables USB communication with the device and thus access to the components required for brute-force attacks. Activating this mode requires some manual effort: you will need to disassemble the device, locate the test point, and short it using fine-tipped tweezers.
Belkasoft X currently supports brute-force and data acquisition for devices running on Kirin 970 and 980 chipsets. The process runs offline, which makes it quite fast and safe. The acquisition workflow varies depending on whether the device has received certain security patches. Some models may not connect via USB, others may require a Harmony TCP cable to initiate USB communication, and certain others will still connect directly via USB-C. Belkasoft X will notify you on what to do.
Final thoughts: Do not give up on locked evidence!
Almost any device has hardware or software vulnerabilities. Cheaper and older ones, often used as burner phones, usually have more loopholes for brute-force and acquisition, while top-range Android devices are usually built like Fort Knox (pun intended).
Exploits are not easy to find and take time to research and implement; that is why many brute-force methods only target older models of phones and tablets. But you should not give up on locked evidence anyway!
Picture this: you receive a locked phone from a non-cooperative suspect. It is a new model, fully updated, and tough to crack. But then, during the search, another device turns up—an older phone that the suspect abandoned years ago. It is locked, too, but this time, your DFIR tool (presumably, Belkasoft X) supports it. Here is the thing: people often use the same passcodes for years, sometimes decades. There is a strong chance the passcode used on the old device is the same as on the new one.
Persistence, creativity, and the right tools can turn a dead end into a breakthrough. Check device models supported by Belkasoft X: https://belkasoft.com/brute. Maybe one of them has been gathering dust on a shelf in your evidence storage?
Frequently Asked Questions
What is the Mobile Passcode Brute-Force module in Belkasoft X?
It is a module for automated unlocking of mobile devices by brute-forcing the screen lock. It leverages low-level vulnerabilities in the boot chain and TEE to obtain key material and perform offline brute-force, bypassing Android’s attempt limits and delays.
How does Android screen lock brute-force work in general?
Android uses encryption where data keys derive within TEE from a combination of device-unique secrets and the user’s screen lock. By exploiting chipset-specific vulnerabilities early in the boot process, Belkasoft X obtains key material and performs offline password guessing without touching user data.
What is specific about the Unisoc (Spreadtrum) approach?
Certain Unisoc SoCs have BootROM vulnerabilities enabling code execution via Spreadtrum Download Mode (SPD). Belkasoft X uses this to extract key material and run offline brute-force. Since BootROM lives in ROM, such flaws cannot be patched with OS updates.
Typically, this involves driver installation, entering SPD mode, and following the Belkasoft X workflow.
What is specific about the MediaTek (MTK) approach?
On some MTK chipsets, BootROM allows loading/exec of unsigned code before secure boot enforcement. Belkasoft X interrupts the boot chain, extracts images and key material, and runs offline brute-force of the screen lock.
It usually requires MTK low-level drivers and booting into BootROM/Preloader mode; setup is a bit more involved than Unisoc but remains reproducible and efficient.
Are Kirin-based devices supported?
Yes. Belkasoft X provides brute-force and extraction scenarios for a range of Kirin models (e.g., 970/980). This enables obtaining a physical image, keystore, and decryption keys for FBE, facilitating data analysis after code recovery.
Is this safe for user data? Any risk of data loss?
The brute-force process runs offline on extracted key material and does not operate on live user data, minimizing alteration or loss. Always follow DFIR best practices: power/network isolation, shielding, state preservation, and documentation.
What affects the speed of password guessing?
Speed depends on the KDF complexity for the specific stack/chipset and the performance of the examiner’s workstation (CPU/GPU), as well as the length and type of the screen lock (PIN/password/pattern).
Do Android attempt limits or delays interfere with the module?
No. The module runs offline outside Android’s standard mechanisms, so attempt limits and delays do not apply. Low-level access steps are performed first (vary by chipset), then the guesswork happens on the workstation.
Which drivers or modes are required to begin?
For Unisoc, SPD drivers and Spreadtrum Download Mode; for MTK, VCOM/Preloader drivers and BootROM/Preloader mode. Kirin devices have their own guided steps in the Belkasoft X wizard. All steps are launched from Belkasoft X acquisition workflows.
Can I get a decrypted file system image directly?
Yes, for supported scenarios Belkasoft X can extract decryption keys and produce a decrypted file system copy for devices using FBE/FDE (relevant for certain MTK, Kirin, and Unisoc models), accelerating artifact analysis.
Does the module work alongside other Belkasoft X acquisition methods?
Yes. Brute-force is part of a complete toolkit: from logical (ADB, agent-based, MTP/PTP) and APK-downgrade app extractions to chipset-specific physical acquisitions. Start with minimally intrusive methods, escalate when needed.
Where can I find the list of supported chipsets and devices?
Refer to Belkasoft X materials and specifications for up‑to‑date chipset/device coverage (MTK, Kirin, Unisoc, etc.). Check product documentation and “What’s new” prior to acquisition to confirm current support and limitations.