Unlocking Android Devices with Brute-Force
Even non-DFIR people nowadays know that manually guessing an unknown passcode is the fastest way to permanentky 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. However, some solutions can target specific groups of chipset models. So, 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?
