Construire et flasher une version AOSP sécurisée avec démarrage vérifié et mot de passe de verrouillage d'écran séparé pour le Nexus 5X

Avertissement et Licence

Toutes les données et informations fournies dans ce tutoriel sont à des fins d’information uniquement. L’auteur ne fait aucune déclaration quant à l’exactitude, l’exhaustivité, l’actualité, la pertinence ou la validité de toute information dans ce tutoriel et ne sera pas responsable des erreurs, omissions ou retards dans cette information ou de toute perte, blessure ou dommage résultant de son affichage ou de son utilisation. Toutes les informations sont fournies en l’état.

En aucun cas, l’auteur ou howtoforge ne sera responsable de toute perte ou dommage, y compris, sans limitation, la perte ou le dommage indirect ou consécutif, ou toute perte ou dommage de quelque nature que ce soit résultant de la perte de données ou de bénéfices découlant de, ou en relation avec, l’utilisation de ce tutoriel.

Sauf indication contraire, le contenu de cette page est sous licence Creative Commons Attribution 3.0, et les exemples de code sont sous licence Apache 2.0.

Motivation

Le Nexus 5X et 6P étaient les premiers appareils à prendre en charge le démarrage vérifié basé sur des clés de signature fournies par l’utilisateur (et non imposées par le fournisseur). Avant son “implosion” [1], CopperheadOS (une variante AOSP améliorée en matière de sécurité) fournissait une bonne documentation et des scripts pour construire et flasher une version AOSP sécurisée [2]. Cependant, le projet a cessé de fournir des mises à jour ces derniers mois, donc la plupart des anciens utilisateurs recherchent des alternatives viables.

Mon impression est que de nombreux utilisateurs s’accordent à dire qu’exécuter un ROM AOSP auto-construit est une bien meilleure alternative à d’autres options telles que le passage à par exemple LineageOS. Il y a plusieurs bonnes raisons à cela :

AOSP est un stock pur et n’a que peu de fonctionnalités potentiellement indésirables
AOSP peut être construit en tant que variante de construction “user” au lieu de “userdebug” et, donc, est censé être plus sécurisé (j’ai essayé de compiler des versions utilisateur de LineageOS, mais elles semblent être cassées en raison des changements invasifs que LineageOS a apportés aux sources AOSP)
Une fois les sources récupérées, AOSP peut être simplement construit. Contrairement à LineageOS, il ne commence pas à télécharger des sources supplémentaires pendant la construction.

Puisque le Nexus 5X est considéré comme un appareil de développement bien pris en charge, je m’attendais à ce que le processus de construction d’AOSP soit facile et bien documenté. Cependant, il s’avère qu’il y a un certain nombre de mises en garde :

inclure les binaires du fournisseur en suivant la documentation officielle entraîne des constructions incomplètes qui ne peuvent pas être utilisées pour des mises à jour incrémentielles sans déverrouiller et effacer à chaque fois (la partition fournisseur, le ROM radio, etc. ne sont pas inclus dans la construction)
la documentation officielle ne décrit pas comment utiliser une construction vérifiée d’une manière directement applicable. Il y a une meilleure documentation dans les docs de CopperheadOS [05], mais les instructions reposent sur des scripts obsolètes qui ne sont pas applicables pour AOSP.
il n’y a pas de documentation sur la façon d’utiliser un PIN “faible” comme phrase de passe mais un mot de passe fort comme clé de chiffrement de disque (contrairement aux nouveaux appareils Pixel, le Nexus 5X est basé sur l’approche FDE plus ancienne). Les méthodes qui fonctionnent pour les appareils LineageOS ne sont pas applicables car elles supposent que l’appareil est rooté, ce qui n’est pas le cas pour les constructions utilisateur AOSP régulières.

Ce tutoriel vise à fournir des instructions détaillées sur la façon de résoudre ces mises en garde, en construisant et en flashant AOSP pour le Nexus 5X avec démarrage vérifié et en utilisant des secrets de verrouillage d’écran/chiffrement séparés. Cela devrait également s’appliquer au Nexus 6P avec de petits changements, mais je n’ai pas pu le tester car je n’avais pas de Nexus 6P à portée de main.

À l’exception d’une petite collection de scripts (nécessaires pour extraire correctement les blobs du fournisseur à partir des binaires fournis par Google) et de sa dépendance “oatdump” (qui est téléchargée sous forme binaire à partir d’un partage public), les instructions n’utilisent aucune ressource tierce “non officielle” (dans le sens “non fournie par Google”).

Soyez conscient des problèmes de liberté suivants :

L’arbre source AOSP contient un certain nombre de binaires précompilés (par exemple, toolchain, noyau Linux, …). Bien que ces binaires puissent être reconstruits à partir de la source, les étapes nécessaires ne sont pas couvertes dans ce tutoriel.
Le code source pour les blobs du fournisseur nécessaires à l’utilisation de nombreux composants matériels du Nexus 5X n’est pas disponible publiquement !
L’outil “android-prepare-vendor” utilisé pour extraire les fichiers propriétaires du fournisseur utilise lui-même des binaires précompilés (certains même hébergés en externe).

Exigences et hypothèses

Le tutoriel suppose que vous avez les prérequis suivants (d’autres versions/distributions peuvent également fonctionner mais pourraient nécessiter d’autres paquets ou des paquets supplémentaires) :

un Nexus 5X avec un bootloader déverrouillé (le déverrouillage n’est pas couvert dans ce tutoriel)
machine (virtuelle) exécutant Debian9 dans la variante x86_64, utilisée exclusivement à notre fin (nous supposons que vous utilisez sudo, sinon, adaptez les commandes)
au moins 5 Go de RAM (plus c’est mieux)
environ 200 Mo d’espace disque
connexion Internet rapide (nous devons télécharger environ 30 Go de données)

Installation des dépendances

Tout d’abord, installez les dépendances comme décrit dans les instructions de construction de LineageOS [3] (les instructions de construction AOSP ne fournissent pas cette liste) :

sudo apt install bc bison build-essential ccache curl flex g++-multilib gcc-multilib git gnupg gperf imagemagick lib32ncurses5-dev lib32readline-dev lib32z1-dev liblz4-tool libncurses5-dev libsdl1.2-dev libssl-dev libwxgtk3.0-dev libxml2 libxml2-utils lzop pngcrush rsync schedtool squashfs-tools xsltproc zip zlib1g-dev

Maintenant, installez des dépendances supplémentaires :

sudo apt install cmake zip unzip openjdk-8-jdk-headless

Ensuite, configurez un chemin bin dans votre répertoire personnel (dans Debian 9, ce chemin est automatiquement configuré dans le profil bash) :

mkdir -p ~/bin

Installez la commande repo :

curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo  
chmod a+x ~/bin/repo

Vérifiez le checksum binaire de repo. Il devrait être e147f0392686c40cfd7d5e6f332c6ee74c4eab4d24e2694b3b0a0c037bf51dc5 pour la version actuelle 1.23. pour les versions ultérieures, vérifiez la page des instructions de construction AOSP [4]. Utilisez la commande suivante pour calculer le checksum :

sha256sum ~/bin/repo

Ensuite, fournissez une identité git en exécutant les commandes suivantes (vous pouvez laisser les données d’exemple si vous préférez rester anonyme) :

git config --global user.email "[email protected]"

git config --global user.name "Votre Nom"

Malheureusement, le paquet brotli (nécessaire pour empaqueter les constructions) dans Debian 9 est trop ancien, donc nous devons construire la version actuelle nous-mêmes. Tout d’abord, obtenez le code source et changez dans son répertoire :

git clone https://github.com/google/brotli.git

Exécutez la construction (remplacez -j15 par le nombre de vos threads CPU) :

cd ~/brotli

./configure-cmake

make -j15

Enfin, copiez le binaire résultant dans notre chemin bin :

cp brotli ~/bin/

Enfin, déconnectez-vous et reconnectez-vous pour que votre profil bash soit relu.

Obtention des blobs du fournisseur

Il y a plusieurs problèmes avec l’utilisation des blobs du fournisseur à partir des paquets de pilotes binaires fournis par Google (voir [5]). Pour les résoudre, nous utilisons l’ensemble de scripts externes “android-prepare-vendor” par “anestisb” qui extrait les blobs du fournisseur à partir des images d’usine à la place.

Tout d’abord, clonez le dépôt :

git clone https://github.com/anestisb/android-prepare-vendor.git

En utilisant le site de Google [6], découvrez le dernier tag de build pour votre Nexus 5X (actuellement c’est OPM6.171019.030.K1).

Changez de répertoire, créez un répertoire de sortie et exécutez le script (nous exécutons le script en tant que root en raison de problèmes avec fuse dans Debian 9) :

cd android-prepare-vendor

mkdir bullhead-blobs

sudo ./execute-all.sh -k -d bullhead -a bullhead -b OPM6.171019.030.K1 -o bullhead-blobs

Téléchargement des sources AOSP

Remarque : Les étapes suivantes manquent d’instructions pour vérifier la source téléchargée.

Tout d’abord, créez un répertoire où les sources seront stockées :

mkdir -p ~/aosp

Sachant le tag de build actuel pour le Nexus 5X, découvrez quel est le tag Android correspondant en utilisant l’aperçu disponible à [6]. Ensuite, vérifiez le manifeste Android pour la branche correspondante (dans cet exemple, nous utilisons android-8.1.0_r46) :

cd ~/aosp

repo init -u https://android.googlesource.com/platform/manifest -b android-8.1.0_r46

comme d’habitude dans XML pour commenter des dépôts. Je recommande d’exclure/remplacer les suivants :

- le QuickSearchBox est de toute façon principalement cassé dans AOSP
- remplacez ceci par un dépôt contenant un arbre de périphérique corrigé où les deux cœurs CPU défectueux sont désactivés. Cela entraîne une pénalité de performance d’environ 30 %. Pourtant, recommandé, même si vous avez un Nexus 5X qui n’est pas affecté par le bootloop, car il est probable qu’il le sera à l’avenir.
- il existe de meilleures alternatives à l’application calendrier AOSP par défaut que vous pouvez installer plus tard (comme Etar)
- Silence.im est une meilleure alternative pour l’application de messagerie AOSP
- OpenCamera est une meilleure alternative pour l’appareil photo par défaut

Maintenant, récupérez tous les dépôts (cela peut prendre beaucoup de temps, principalement en fonction de votre connexion Internet) :

repo sync

Enfin, copiez les blobs du fournisseur générés précédemment en tant que root (c’est requis, sinon qmus et d’autres blobs seront manquants et provoqueront un échec de compilation ultérieur) dans le répertoire vendor de votre arbre AOSP (remplacez le numéro de build d’usine par le numéro actuel) :

sudo cp -av ~/android-prepare-vendor/bullhead-blobs/bullhead/opm6.171019.030.k1/vendor .

sudo cp -av ~/android-prepare-vendor/bullhead-blobs/bullhead/opm6.171019.030.k1/vendor_overlay .

Faites de votre utilisateur le propriétaire des répertoires du fournisseur (sinon, la construction échouera plus tard). Remplacez yourusername par votre nom d’utilisateur réel :

sudo chown -R yourusername:yourusername ~/aosp/vendor

sudo chown -R yourusername:yourusername ~/aosp/vendor_overlay

Génération des clés

Définissez les variables de construction :

source build/envsetup.sh

Construisez l’outil nécessaire pour générer la clé de vérification :

make generate_verity_key

Créez un répertoire pour stocker vos clés (les docs de CopperheadOS [2] recommandent d’utiliser une clé séparée pour chaque appareil, dans ce cas bullhead) :

mkdir -p keys/bullhead

Maintenant, il est temps de générer les clés (ne définissez pas de mots de passe sur vos clés) :

cd keys/bullhead

../../development/tools/make_key releasekey '/C=DE/ST=Hometown/L=XX/O=yournamehere/OU=yournamehere/CN=yournamehere/[email protected]'

../../development/tools/make_key platform '/C=DE/ST=Hometown/L=XX/O=yournamehere/OU=yournamehere/CN=yournamehere/[email protected]'

../../development/tools/make_key shared '/C=DE/ST=Hometown/L=XX/O=yournamehere/OU=yournamehere/CN=yournamehere/[email protected]'

../../development/tools/make_key media '/C=DE/ST=Hometown/L=XX/O=yournameher /OU=yournamehere/CN=yournamehere/[email protected]'

../../development/tools/make_key verity '/C=DE/ST=Hometown/L=XX/O=yournamehere/OU=yournamehere/CN=yournamehere/[email protected]'

cd ~/aosp

Convertissez la clé de vérification au format requis par AOSP :

out/host/linux-x86/bin/generate_verity_key -convert keys/bullhead/verity.x509.pem keys/bullhead/verity_key

Compilation

Assurez-vous que vos variables de construction sont définies :

cd ~/aosp

source build/envsetup.sh

Créez une configuration lunch pour l’appareil bullhead (remplacez user par userdebug si vous souhaitez une configuration userdebug à la place) :

lunch aosp_bullhead-user

Désactivez Jack (il provoque souvent des problèmes de compilation et a été déprécié dans Android 9 de toute façon) :

export ANDROID_COMPILE_WITH_JACK=false

Compilez le package de fichiers cibles (remplacez -j15 par le nombre de vos threads CPU) :

make target-files-package -j15

Emballage et signature

Créez un répertoire pour stocker les fichiers de sortie (en dehors du répertoire de construction habituel nommé out) :

mkdir dist

Exécutez la cible dist (remplacez -j15 par le nombre de vos threads CPU) :

make dist -j15

Créez un package de fichiers cibles signés, remplaçant les clés de test par vos clés (remplacez yourusername par votre nom d’utilisateur réel sur le système) :

build/tools/releasetools/sign_target_files_apks -o -d keys/bullhead --replace_verity_public_key keys/bullhead/verity_key.pub --replace_verity_private_key keys/bullhead/verity --replace_verity_keyid keys/bullhead/verity.x509.pem out/dist/aosp_bullhead-target_files-eng.yourusername.zip dist/signed-target-files.zip

Créez un package OTA signé :

build/tools/releasetools/ota_from_target_files -k keys/bullhead/releasekey dist/signed-target-files.zip dist/signed-ota-update.zip

Flashage

Démarrez votre appareil Nexus 5X en mode bootloader (maintenez le volume vers le bas, puis appuyez sur l’alimentation).

Connectez votre appareil via USB à votre machine (et rendez-le disponible pour la VM au cas où vous construisez dans une VM). Vous pouvez également copier le contenu du répertoire dist sur une autre machine et flasher à partir de là, mais nous supposons que vous flashez en utilisant les binaires fastboot/adb construits à partir des sources AOSP (si vous flashez de l’extérieur, assurez-vous que votre binaire fastboot est récent).

Décompressez les images de signed-target-files.zip :

cd ~/aosp/dist

unzip `signed-target-files.zip IMAGES/*  
`

Maintenant, flashez toutes les images :

../out/host/linux-x86/bin/fastboot flash boot boot.img

../out/host/linux-x86/bin/fastboot flash recovery recovery.img

../out/host/linux-x86/bin/fastboot flash vendor vendor.img

../out/host/linux-x86/bin/fastboot flash system system.img

Sélectionnez “reboot system” en utilisant les boutons physiques de votre appareil et assurez-vous que votre nouveau système fonctionne.

Enfin, redémarrez dans le bootloader, et re-verrouillez-le (cela effacera toutes les données) :

out/host/linux-x86/bin/fastboot flash oem locking

C’est tout !

Définir des secrets de démarrage/verrouillage d’écran séparés

Définir un mot de passe de démarrage/verrouillage d’écran séparé peut être fait avec une petite astuce :

Déverrouillez le bootloader (efface toutes les données)
compilez et flashez une version userdebug (voir ci-dessus)
verrouillez le bootloader
définissez un PIN/mot de passe de verrouillage d’écran en utilisant l’interface utilisateur Android. Assurez-vous de choisir le bon car vous ne pourrez pas le changer à nouveau sans effacer vos données une fois que vous passez à la version utilisateur.
connectez-vous à l’appareil via adb
en tant que root, exécutez la commande suivante : vdc cryptfs changepw password your-new-password
redémarrez, et assurez-vous que cela fonctionne
compilez une version utilisateur régulière (ne déverrouillez pas le bootloader !)
flashez la version utilisateur

Remarque : Sans étapes supplémentaires, la récupération ne permet pas de flasher des versions plus anciennes. Ainsi, vous devez flasher une version utilisateur qui est plus récente que votre version userdebug !

Gestion des mises à jour

Si vous souhaitez passer à une nouvelle version AOSP, vous devez d’abord découvrir le nouveau numéro de version.

Ensuite, effacez l’ancien manifeste (faites une sauvegarde, au cas où vous auriez apporté des modifications que vous souhaitez refaire sur la version mise à jour) :

cd ~/aosp

rm -rf .repo/manifests.git

rm -rf .repo/manifest.xml

De plus, effacez les blobs du fournisseur (alors obsolètes) et le dépôt prepare-vendor :

rm -rf ~/android-prepare-vendor

rm -rf vendor

rm -rf vendor_overlay

De plus, nettoyez l’arbre de construction et les artefacts de construction :

rm -rf out

rm -rf dist

Ensuite, refaites UNIQUEMENT les étapes suivantes :

Obtention des blobs du fournisseur
Téléchargement des sources AOSP (cela sera beaucoup plus rapide, car seules les modifications seront récupérées)
Compilation
Emballage et signature

En théorie, vous devriez être en mesure de sideloader des mises à jour en tant que nouveaux packages OTA depuis la récupération sans effacer (puisqu’ils seront signés avec les mêmes - vos - clés). En pratique, cela ne fonctionne pas encore (voir la section suivante). Là, vous devrez également procéder comme suit :

Sauvegardez toutes vos données
Déverrouillez le bootloader (vos données seront effacées)
Flashez les images mises à jour et re-verrouillez votre bootloader comme décrit dans la section “Flashage”

WIP : Mises à jour OTA signées

Cette section est WIP, les instructions décrites ne fonctionnent pas encore !

En théorie, il devrait être possible de créer et de flasher des mises à jour OTA signées depuis la récupération. Cependant, toutes mes tentatives de le faire ont abouti à une erreur “Échec de la vérification de la signature”. Puisque cela fonctionne lorsque j’utilise directement les fichiers du fournisseur fournis par Google au lieu d’utiliser android-prepare-vendor, je suppose que cela est lié aux fichiers du fournisseur ou à d’autres fichiers (comme les images de bootloader ou de radio) qui ne sont pas correctement signés.

Créez le package OTA signé comme suit :

build/tools/releasetools/ota_from_target_files -k keys/bullhead/releasekey dist/signed-target-files.zip dist/signed-ota-update.zip

Redémarrez en mode récupération en utilisant les boutons physiques de votre appareil.

Dans la récupération, vous verrez un petit symbole android. Maintenez le bouton d’alimentation enfoncé et appuyez sur le volume haut pour accéder au menu de récupération.

Maintenant, sélectionnez “mettre à jour depuis adb” en utilisant les boutons physiques de votre appareil.

Sideload votre package OTA signé :

out/host/linux-x86/bin/adb sideload dist/`signed-ota-update.zip`

Références

[1] https://www.reddit.com/r/CopperheadOS/comments/8qdnn3/goodbye/

[2] https://copperhead.co/android/docs/building

[3] https://wiki.lineageos.org/devices/bullhead/build

[4] https://source.android.com/setup/build/downloading

[5] https://github.com/anestisb/android-prepare-vendor

[6] https://source.android.com/setup/start/build-numbers.html#source-code-tags-and-builds