Bypassing Bootloader Checks on Snapdragon 8 Elite via ABL Patching

Anyone who has rooted recent Android smartphones over the past couple of years knows this pain. The moment you unlock the bootloader, banking apps go on strike, and Play Integrity checks happily report a compromised system. Usually people resort to modules like TrickyStore or keystore patches, but chipset manufacturers and Google keep tightening the screws.

Recently I came across an interesting project called gbl_root_canoe by developer superturtlee. The repository has been archived since the author brought the patching logic to a stable state and locked in the final release. The project offers an unconventional low-level approach to solving the problem for Snapdragon 8 Gen 5 and 8 Elite chips.

What this tool does

Essentially, gbl_root_canoe is an EDK2-based workspace for modifying EFI applications inside Qualcomm ABL (Android Bootloader) images.

The author's core idea is to exploit a vulnerability in GBL (Generic Bootloader Loader). The stock ABL loads a custom superfastboot BDS directly from raw partition efisp. This BDS then scans a compatible partition with ext4 or fat32 filesystem, finds a prepared boot entry list, and transfers control to the modified ABL.

As a result, the device boots with a fake locked bootloader state (Fake Locked Bootloader). To the operating system and hardware checks, the device appears as if its bootloader is completely sealed, while in reality you retain full access to modifications.

What the solution consists of

The entire mechanism relies on a combination of several components:

• BDS.efi — a custom bootloader (superfastboot BDS) that is flashed directly to partition efisp.
• boot.efi (called ABL.efi in the PC version) — a patched ABL binary with fake lock status. It resides in directory efisp/ on partition persist.
• BOOTENTRIES — a text configuration file with a list of paths for passing the boot chain.
• LinuxLoader.efi (ABL_original.efi) — the original unmodified ABL, preserved for analysis and rollback.

This separation allows avoiding direct modifications to system partitions with each edit, isolating the bypass logic in service partitions efisp and persist.

How it works from a technical perspective

The project architecture is tied to cross-compiling C code for UEFI and building low-level utilities extractfv and patch_abl.

If building the toolkit from source yourself, you will need a Linux host with the standard set of utilities: Clang or GCC, LLD, Python 3, MinGW-w64, and Android NDK. The build script supports multiple targets:

# Сборка тулкита для Linux
make target_toolkit_linux

# Сборка тулкита под Windows (через MinGW-w64)
make target_toolkit_windows

# Сборка модуля для KernelSU / Magisk / APatch через Android NDK
make target_magisk_module

# Сборка автономного набора утилит для запуска прямо на Android (arm64)
make target_toolkit_android

To build root manager modules, you don't even need the original boot image dump abl.img of your smartphone. The patcher cross-compiles for Android architecture and assembles into a zip archive ready for installation via KernelSU, Magisk, or APatch.

Installation quirks and pitfalls

Working with low-level bootloader partitions is risky business, so the author embedded an interactive installation scenario directly into the module script.

When flashing the archive for the first time via Magisk or KernelSU, control is handled through physical volume buttons:

1. Volume Up (primary installation): The script extracts .abl from the current slot, patches it into boot.efi, places files boot.efi, LinuxLoader.efi, and BOOTENTRIES into path /mnt/vendor/persist/efisp/, then flashes BDS.efi to partition efisp.
2. After this, you must reboot into Recovery and perform a full Format Data.
3. After the system boots, the module is installed again, but this time you select Volume Down to apply patches for maintaining functionality through future OTA updates.

If you prefer doing everything manually from a computer, the toolkit allows unpacking the stock abl.img, running it through scripts build.sh or build.bat, and getting a patched ABL.efi.

By the way, if the log patch_log.txt shows a warning that the GBL patch could not be applied, the vendor has already closed this vulnerability in your current firmware version. In that case, you will need to roll back partition abl to an earlier build where the bug still exists.

Manually flashing BDS.efi is done via a standard block write:

dd if=BDS.efi of=/dev/block/by-name/efisp bs=4M

Working with Superfastboot

When OEM Unlocking is activated, during device power-on when the warning screen appears, you can hold the volume down button. The device will drop into Superfastboot mode (that very BDS).

From there, familiar fastboot commands are available, but with extended capabilities:

# Временный запуск любого EFI-файла без прошивки
fastboot boot custom.efi

# Блокировка загрузчика со сбросом данных
fastboot flashing lock

# Разблокировка загрузчика без вайпа данных
fastboot flashing unlock

Here you need to be careful with encryption keys. If the TEE status becomes desynchronized, the secure chip will refuse to release the decryption key for user data, and the Data partition will remain inaccessible.

Who will benefit from this project

The gbl_root_canoe project is unlikely to suit beginners who just want to install a couple of tweaks on their phone. This is a tool for advanced enthusiasts, custom ROM maintainers, and those deeply familiar with Snapdragon boot architecture and Android partition structure.

If you have a Snapdragon 8 Gen 5 or 8 Elite device and are tired of fighting unlocked bootloader detection at the OS level, this repository provides a ready-made and technically elegant way to bypass the problem at the early EFI initialization stage. The source code is open under GPL v3 license, so you can freely fork and adapt the code for your own custom scenarios.