GhostLock pour Humane AI Pin

GhostLock pour Humane AI Pin est une preuve de concept open-source de root limitée au démarrage, pour une version exacte du firmware de vente au détail. Elle exploite CVE-2026-43499, un use-after-free de rtmutex Linux, depuis un shell ADB autorisé ordinaire.

Le lanceur est délibérément restreint. Il vérifie l'empreinte complète du firmware, la version du noyau, le slot, l'UID du shell et l'état SELinux avant de préparer quoi que ce soit. Une incohérence arrête 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 dont vous pouvez assumer la récupération. Le root disparaît au redémarrage.

Cible testée

Le slot _a, le firmware développeur, les versions de firmware proches et les autres produits Qualcomm atoll sont rejetés. Voir 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 userspace.

Avant de commencer

Vous avez besoin de :

• un Pin vous appartenant déjà autorisé pour ADB ;
• une connexion USB de données 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 bugreport, 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

Exécution

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 SELinux, la batterie, la source d'alimentation et la révision du NDK.

run effectue une tentative gardée. Il vous demande de saisir ROOT YOUR_SERIAL, compile depuis les sources, vérifie le hachage de la charge utile après l'avoir poussée, capture un bugreport du démarrage en cours pour dériver le KASLR, supprime ce bugreport brut par défaut, et lance l'exploit seulement après un second prévol complet.

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 permissif sur le même démarrage.

Ce que le PoC modifie

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

1. remplace les pointeurs de credentials du processus d'exploit par init_cred ;
2. désactive le mode enforcing de SELinux et recharge la politique actuelle ;
3. écrit un petit client de commandes dans /data/local/tmp/su ;
4. 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 pas de service réseau et ne téléverse pas de 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 lanceur autorise une tentative par démarrage du noyau. S'il signale un échec, un timeout, 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 check à nouveau.

Si ADB répond encore :

adb -s YOUR_SERIAL reboot

Si le Pin est complètement bloqué et qu'ADB ne répond pas, débranchez toute alimentation externe. Le matériel de vente au détail testé n'a pas de redémarrage forcé fiable accessible à l'utilisateur, donc la récupération peut 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 préparés peuvent rester inertes sous /data/local/tmp ; un shell propre peut les supprimer :

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'

Lisez SAFETY.md avant d'utiliser le PoC et TROUBLESHOOTING.md avant de réessayer 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 noyau et de la télémétrie d'exploit. Ne joignez jamais ce répertoire ni un bugreport Android brut à un problème.

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

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

Examinez le JSON avant de le partager. Le rédacteur omet les numéros de série, les identifiants de démarrage, les chemins hôtes, la sortie brute des commandes et les adresses noyau. Voir PRIVACY.md.

Compilation et tests

Compilez la charge utile Android :

./ghostlock build

Exécutez tous les tests hôtes et deux compilations indépendantes :

./scripts/verify-release.sh

La charge utile est écrite dans :

source/build/humane-aipin-45.20/bin/preload.so

Les produits de compilation sont ignorés par Git. Les ressources de version doivent être vérifiées par rapport aux sommes de contrôle jointes à la version GitHub correspondante.

Fonctionnement

L'exploit utilise le rt_mutex_waiter résidant sur la pile et pendant du CVE pour router une mise à jour contrôlée d'arbre rouge-noir. KernelSnitch divulgue d'abord une adresse mm_struct via le timing du futex-hash. Une barrière perf-event de même PFN prouve ensuite que la page slab d'ordre 3 libérée a été récupérée par des données contrôlées de socket-buffer avant que le déclencheur de corruption puisse se poursuivre. Une base KASLR liée au démarrage est dérivée d'au moins deux ancres WARN concordantes du démarrage en cours. La route lecture/écriture résultante résout la tâche actuelle et effectue le changement de credentials limité au démarrage.

Le profil cible ne contient que les offsets et symboles consommés par cette route. L'image noyau et la table complète des symboles ne sont pas distribuées. TECHNICAL.md décrit les étapes et les barrières fail-closed.

État du projet

Il s'agit d'une version de recherche expérimentale pour un appareil grand public non pris en charge. Ce n'est pas un outil de root Android général et il n'est pas affilié à Humane, HP ou CosmOS.

Le code est sous licence Apache-2.0. L'implémentation part du travail Apache-2.0 CyberMeowfia de NebuSec ; le portage AI Pin et l'outillage de version sont documentés dans PROVENANCE.md et THIRD_PARTY_NOTICES.md.

Veuillez lire SECURITY.md avant de signaler une vulnérabilité ou un problème d'utilisation abusive.