GhostLock pour Humane AI Pin

GhostLock pour Humane AI Pin est une preuve de concept open source de root limitée au démarrage, destinée à une version exacte du firmware commercial. Elle exploite CVE-2026-43499, une utilisation après libération (use-after-free) de rtmutex dans Linux, depuis un shell ADB autorisé ordinaire.

Le lanceur est délibérément restrictif. Il vérifie l'empreinte complète du firmware, la version du noyau, le slot, l'UID du shell et l'état de SELinux avant de préparer quoi que ce soit. Une incohérence interrompt l'exécution.

[!WARNING] Il s'agit d'un exploit noyau. Il peut provoquer une panique, un redémarrage ou un blocage complet du Pin. Un blocage complet peut nécessiter de débrancher l'appareil et d'attendre que la batterie se décharge. Utilisez-le uniquement sur un Pin que vous possédez et que vous pouvez vous permettre de récupérer. Le root disparaît au redémarrage.

Cible testée

Propriété	Valeur acceptée
Appareil	Humane AI Pin, unité commerciale
Firmware	`qti/atoll/atoll:12/SKQ1.230401.001/101.000470.45.20:user/release-keys`
Android	12
Noyau	`4.14.190-perf`, compilé le `Mon Nov 4 18:37:23 PST 2024`
Slot	`_b` uniquement
Architecture du noyau	`aarch64`
ABI Android	`arm64-v8a`
ID de profil	`humane-aipin-45.20-nov4`
Projet de build	`humane-aipin-45.20`
SHA-256 de l'image du noyau	`d4f4e0deb20871fce207f1f095ba1934162081c2f10afaccbb2e6a1e938719fb`
Rejeu de la version candidate	En attente du rejeu final sur démarrage propre

Le slot _a, les firmwares développeur, les versions de firmware proches et les autres produits Qualcomm atoll sont rejetés. Voir les détails de compatibilité. Une empreinte Android correspondante ne suffit pas à contourner cette vérification : les slots A/B peuvent contenir des images de démarrage et des dispositions de noyau différentes sous la même identité de build de l'espace utilisateur.

La compatibilité est définie par un manifeste versionné sous profiles/. Le lanceur hôte, le runner, le précontrôle natif généré, la géométrie de l'allocateur, les symboles minimaux et la charge utile compilée sont liés à ce même manifeste. L'ajout d'un slot à un manifeste nécessite toujours un rejeu physique sur démarrage propre de l'image de noyau exacte du profil.

Avant de commencer

Vous avez besoin de :

un Pin vous appartenant déjà autorisé pour ADB ;
une connexion de données USB stable et une alimentation externe ;
adb, Python 3.10 ou plus récent, make et un compilateur C ;
Android NDK 28.2.13676358 (r28c) pour compiler la charge utile.

Ce dépôt ne contient pas de clé privée ADB, d'image de firmware, d'image de démarrage, de rapport de bug, de journal d'appareil ni de charge utile précompilée.

Installez le NDK épinglé avec les outils en ligne de commande d'Android :

sdkmanager "ndk;28.2.13676358"

Confirmez qu'ADB voit déjà le Pin comme device :

$ adb devices
List of devices attached
YOUR_SERIAL    device

Lancer l'outil

Clonez le dépôt, puis utilisez le même numéro de série explicite pour chaque commande :

git clone https://github.com/TheAndersMadsen/humane-aipin-ghostlock.git
cd humane-aipin-ghostlock

./ghostlock check --serial YOUR_SERIAL
./ghostlock run --serial YOUR_SERIAL
./ghostlock verify --serial YOUR_SERIAL

check est en lecture seule. Il affiche le firmware détecté, le noyau, le slot, la frontière du shell, l'état de SELinux, la batterie, la source d'alimentation, la révision du NDK et l'état des outils de compilation. Sa sortie de diagnostic masque le numéro de série de l'appareil par défaut.

run effectue une tentative unique et contrôlée. Il vous demande de saisir ROOT YOUR_SERIAL, compile depuis les sources, vérifie le hash de la charge utile après l'avoir poussée, capture un rapport de bug du démarrage en cours pour dériver le KASLR, supprime ce rapport de bug brut par défaut, et ne lance l'exploit qu'après un second précontrôle complet. Le lanceur exige au moins 20 % de batterie et une alimentation externe par défaut, puis l'exécuteur revérifie les deux immédiatement avant de consommer l'unique tentative du démarrage. --min-battery 0 désactive les deux conditions d'alimentation et n'est destiné qu'aux cas où une alimentation stable a été confirmée indépendamment.

verify demande indépendamment au broker root limité au démarrage d'exécuter id et getenforce.

Une vérification réussie ressemble à ceci :

uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
SELinux: Permissive
Boot epoch: <redacted>; uptime: <redacted>s

Le contexte SELinux exact dépend du noyau et du firmware. La condition d'acceptation est UID/GID 0 via le broker avec SELinux en mode permissif sur le même démarrage.

Ce que le PoC modifie

Pour le démarrage en cours, la charge utile :

remplace les pointeurs de credentials du processus d'exploit par init_cred ;
désactive le mode enforcing de SELinux et recharge la politique actuelle ;
écrit un petit client de commandes dans /data/local/tmp/su ;
démarre un broker à socket Unix qui n'accepte que les pairs UID 0 authentifiés par le noyau ou UID 2000 du shell Android.

Il n'écrit pas de partition, ne déverrouille pas le bootloader, n'installe pas de module, ne modifie pas le verified boot, ne crée pas de persistance au redémarrage, ne contacte aucun service réseau et ne téléverse aucune télémétrie.

Exécutez une commande root depuis un autre shell ADB avec :

adb -s YOUR_SERIAL shell '/data/local/tmp/su -c id'

Échec et récupération

Le runner autorise une seule tentative par démarrage du noyau. S'il signale un échec, un délai d'attente dépassé, une déconnexion, un état incertain, une panique ou un redémarrage, ne réessayez pas sur ce démarrage. Redémarrez d'abord et exécutez à nouveau check.

Si ADB répond encore :

adb -s YOUR_SERIAL reboot

Si le Pin est bloqué en position haute et qu'ADB ne répond pas, déconnectez toute alimentation externe. Le matériel de détail testé ne dispose d'aucun redémarrage forcé fiable accessible à l'utilisateur, la récupération peut donc nécessiter d'attendre que la batterie se décharge avant de rebrancher l'alimentation.

Après un redémarrage normal, le root a disparu. Les fichiers déposés peuvent rester inertes sous /data/local/tmp ; un shell propre peut les supprimer, y compris les revendications de tentative atomique spécifiques au démarrage :

adb -s YOUR_SERIAL shell 'rm -f /data/local/tmp/ghostlock-aipin.so /data/local/tmp/su /data/local/tmp/.ghostlock-su.sock /data/local/tmp/.ghostlock-aipin-attempt'
adb -s YOUR_SERIAL shell 'rm -rf /data/local/tmp/.ghostlock-aipin-attempt.*.lock'

Lisez SAFETY.md avant d'utiliser le PoC et TROUBLESHOOTING.md avant de relancer une exécution échouée.

Journaux privés et rapports de problèmes

Les enregistrements d'exécution sont écrits dans un répertoire temporaire en mode 0700. Ils contiennent un numéro de série d'appareil, une identité de démarrage, des adresses du noyau et la télémétrie de l'exploit. Ne joignez jamais ce répertoire ni un rapport de bug Android brut à un problème.

Créez plutôt un rapport réduit :

./ghostlock report /private/tmp/ghostlock-aipin-TIMESTAMP --output ghostlock-report.json

Populaires

humane-aipin-ghostlock