>_ DevTrendsfr

Langue

Accueil

Langages

Sections

Frontend Backend Mobile DevOps AI / ML GameDev Blockchain Embarqué Sécurité
C

Contourner les vérifications du bootloader sur Snapdragon 8 Elite via le patching ABL

Quiconque a rooté un smartphone Android récent au cours des dernières années connaît cette galère. Le moment où vous déverrouillez le bootloader, les applications bancaires font la grève, et les vérifications Play Integrity se font un plaisir de signaler un système compromis. D'habitude, les gens ont recours à des modules comme TrickyStore ou des patches keystore, mais les fabricants de chipsets et Google ne cessent de resserrer les vis.

Récemment, je suis tombé sur un projet intéressant appelé gbl_root_canoe par le développeur superturtlee. Le dépôt a été archivé depuis que l'auteur a stabilisé la logique de patching et verrouillé la version finale. Le projet propose une approche peu conventionnelle de bas niveau pour résoudre le problème sur les chips Snapdragon 8 Gen 5 et 8 Elite.

Ce que fait cet outil

Fondamentalement, gbl_root_canoe est un espace de travail basé sur EDK2 pour modifier les applications EFI dans les images Qualcomm ABL (Android Bootloader).

L'idée centrale de l'auteur est d'exploiter une vulnérabilité dans GBL (Generic Bootloader Loader). Le ABL standard charge un BDS superfastboot personnalisé directement depuis la partition brute efisp. Ce BDS scanne ensuite une partition compatible avec un système de fichiers ext4 ou fat32, trouve une liste d'entrées de boot préparée, et transfère le contrôle au ABL modifié.

En résultat, l'appareil démarre avec un état de bootloader faussement verrouillé (Fake Locked Bootloader). Pour le système d'exploitation et les vérifications matérielles, l'appareil apparaît comme si son bootloader était complètement scellé, alors qu'en réalité vous conservez un accès complet aux modifications.

De quoi se compose la solution

L'ensemble du mécanisme repose sur une combinaison de plusieurs composants :

  • BDS.efi — un bootloader personnalisé (superfastboot BDS) qui est flashé directement sur la partition efisp.
  • boot.efi (appelé ABL.efi dans la version PC) — un binaire ABL patché avec un statut de verrouillage falsifié. Il réside dans le répertoire efisp/ sur la partition persist.
  • BOOTENTRIES — un fichier de configuration texte avec une liste de chemins pour la chaîne de boot.
  • LinuxLoader.efi (ABL_original.efi) — le ABL original non modifié, conservé pour l'analyse et la restauration.

Cette séparation permet d'éviter les modifications directes des partitions système à chaque édition, en isolant la logique de contournement dans les partitions de service efisp et persist.

Comment cela fonctionne d'un point de vue technique

L'architecture du projet est liée à la compilation croisée de code C pour UEFI et à la construction d'utilitaires de bas niveau extractfv et patch_abl.

Si vous compilez la boîte à outils vous-même depuis les sources, vous aurez besoin d'un hôte Linux avec l'ensemble standard d'utilitaires : Clang ou GCC, LLD, Python 3, MinGW-w64 et Android NDK. Le script de build prend en charge plusieurs cibles :

# Сборка тулкита для 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

Pour construire les modules root manager, vous n'avez même pas besoin du dump de l'image de boot originale abl.img de votre smartphone. Le patcher compile de manière croisée pour l'architecture Android et assemble dans une archive zip prête pour l'installation via KernelSU, Magisk ou APatch.

Pièges et particularités de l'installation

Travailler avec des partitions bootloader de bas niveau est risqué, c'est pourquoi l'auteur a intégré un scénario d'installation interactif directement dans le script du module.

Lors du flash de l'archive pour la première fois via Magisk ou KernelSU, le contrôle s'effectue via les boutons physiques du volume :

  1. Volume Haut (installation principale) : Le script extrait .abl du slot actuel, le patche en boot.efi, place les fichiers boot.efi, LinuxLoader.efi et BOOTENTRIES dans le chemin /mnt/vendor/persist/efisp/, puis flash BDS.efi sur la partition efisp.
  2. Après cela, vous devez redémarrer en Recovery et effectuer un Format Data complet.
  3. Une fois le système démarré, le module est installé à nouveau, mais cette fois vous sélectionnez Volume Bas pour appliquer les patches permettant de maintenir la fonctionnalité lors des futures mises à jour OTA.

Si vous préférez tout faire manuellement depuis un ordinateur, la boîte à outils permet de décompresser le abl.img original, de le traiter via les scripts build.sh ou build.bat, et d'obtenir un ABL.efi patché.

Au fait, si le log patch_log.txt affiche un avertissement indiquant que le patch GBL n'a pas pu être appliqué, le fournisseur a déjà comblé cette vulnérabilité dans votre version actuelle du firmware. Dans ce cas, vous devrez revenir à une version antérieure de la partition abl où le bug existe encore.

Le flash manuel de BDS.efi se fait via une écriture standard par blocs :

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

Travailler avec Superfastboot

Lorsque le déverrouillage OEM est activé, lors de la mise sous tension de l'appareil lorsque l'écran d'avertissement apparaît, vous pouvez maintenir le bouton volume bas. L'appareil passera en mode Superfastboot (ce BDS susmentionné).

De là, les commandes fastboot familières sont disponibles, mais avec des capacités étendues :

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

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

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

Ici, vous devez faire attention aux clés de chiffrement. Si le statut TEE se désynchronise, la puce sécurisée refusera de libérer la clé de déchiffrement pour les données utilisateur, et la partition Data restera inaccessible.

À qui ce projet sera utile

Le projet gbl_root_canoe ne conviendra probablement pas aux débutants qui veulent simplement installer quelques tweaks sur leur téléphone. C'est un outil pour les passionnés avancés, les mainteneurs de ROM personnalisées et ceux qui connaissent bien l'architecture de boot Snapdragon et la structure des partitions Android.

Si vous avez un appareil Snapdragon 8 Gen 5 ou 8 Elite et que vous en avez marre de lutter contre la détection de bootloader déverrouillé au niveau de l'OS, ce dépôt fournit un moyen prêt à l'emploi et techniquement élégant de contourner le problème au stade précoce de l'initialisation EFI. Le code source est ouvert sous licence GPL v3, vous pouvez donc librement forker et adapter le code pour vos propres scénarios personnalisés.

Projets similaires