Erstellen und Flashen eines gesicherten AOSP-Builds mit verifiziertem Boot und separatem Sperrbildschirm-Passwort für das Nexus 5X

Haftungsausschluss und Lizenz

Alle Daten und Informationen, die in diesem Tutorial bereitgestellt werden, dienen nur zu Informationszwecken. Der Autor gibt keine Zusicherungen hinsichtlich der Genauigkeit, Vollständigkeit, Aktualität, Eignung oder Gültigkeit von Informationen in diesem Tutorial und haftet nicht für Fehler, Auslassungen oder Verzögerungen in diesen Informationen oder für Verluste, Verletzungen oder Schäden, die aus deren Anzeige oder Nutzung resultieren. Alle Informationen werden ohne Gewähr bereitgestellt.

In keinem Fall haftet der Autor oder howtoforge für Verluste oder Schäden, einschließlich, aber nicht beschränkt auf indirekte oder Folgeschäden, oder für Verluste oder Schäden, die aus Datenverlust oder Gewinnen resultieren, die aus der Nutzung dieses Tutorials entstehen.

Sofern nicht anders angegeben, ist der Inhalt dieser Seite unter der Creative Commons Attribution 3.0 Lizenz lizenziert, und Codebeispiele sind unter der Apache 2.0 Lizenz lizenziert.

Motivation

Das Nexus 5X und 6P waren die ersten Geräte, die verifiziertes Boot basierend auf benutzereigenen (und nicht vom Anbieter durchgesetzten) Signaturschlüsseln unterstützten. Vor seiner “Implosion” [1] bot CopperheadOS (eine sicherheitsverbesserte AOSP-Variante) gute Dokumentationen und Skripte zum Erstellen und Flashen einer sicheren AOSP-Version [2]. Das Projekt hat jedoch in den letzten Monaten keine Updates mehr bereitgestellt, sodass die meisten ehemaligen Benutzer nach tragfähigen Alternativen suchen.

Mein Eindruck ist, dass viele Benutzer zustimmen, dass das Ausführen einer selbstgebauten AOSP-ROM eine viel bessere Alternative zu anderen Optionen wie dem Wechsel zu z.B. LineageOS ist. Es gibt eine Reihe guter Gründe dafür:

AOSP ist reines Stock und hat nur wenige möglicherweise unerwünschte Funktionen
AOSP kann als “user” anstelle von “userdebug” Build-Variante erstellt werden und ist daher voraussichtlich sicherer (ich habe versucht, Benutzer-Bauten von LineageOS zu kompilieren, aber sie scheinen aufgrund der invasiven Änderungen, die LineageOS an den AOSP-Quellen vorgenommen hat, defekt zu sein)
Sobald die Quellen abgerufen sind, kann AOSP einfach gebaut werden. Im Gegensatz zu LineageOS beginnt es nicht, zusätzliche Quellen während des Builds herunterzuladen.

Da das Nexus 5X als gut unterstütztes Entwicklergerät gilt, erwartete ich, dass der Prozess des Erstellens von AOSP einfach und gut dokumentiert ist. Es stellt sich jedoch heraus, dass es eine Reihe von Vorbehalten gibt:

Das Einfügen der Vendor-Binärdateien gemäß der offiziellen Dokumentation führt zu unvollständigen Builds, die nicht für inkrementelle Updates verwendet werden können, ohne jedes Mal zu entsperren und zu löschen (die Vendor-Partition, Radio-ROM usw. sind nicht im Build enthalten)
Die offizielle Dokumentation beschreibt nicht, wie man den verifizierten Build auf eine direkt anwendbare Weise verwendet. Es gibt bessere Dokumentationen in den CopperheadOS-Dokumenten [05], aber die Anweisungen basieren auf veralteten Skripten, die nicht für AOSP anwendbar sind.
Es gibt keine Dokumentation, wie man eine “schwache” PIN als Passphrase, aber ein starkes Passwort als Festplattenverschlüsselungsschlüssel verwendet (im Gegensatz zu neueren Pixel-Geräten basiert das Nexus 5X auf dem älteren FDE-Ansatz). Die Methoden, die für LineageOS-Geräte funktionieren, sind nicht anwendbar, da sie davon ausgehen, dass das Gerät gerootet ist, was bei regulären AOSP-Benutzer-Bauten nicht der Fall ist.

Dieses Tutorial zielt darauf ab, detaillierte Anweisungen zu geben, wie man diese Vorbehalte löst, AOSP für das Nexus 5X mit verifiziertem Boot zu erstellen und zu flashen und separate Sperrbildschirm-/Verschlüsselungsgeheimnisse zu verwenden. Es sollte auch für das Nexus 6P mit kleinen Änderungen gelten, aber ich konnte es nicht testen, da ich kein Nexus 6P zur Hand hatte.

Abgesehen von einer kleinen Skriptsammlung (die erforderlich ist, um die Vendor-Blobs ordnungsgemäß aus den von Google bereitgestellten Binärdateien zu extrahieren) und seiner Abhängigkeit “oatdump” (die als Binärdatei von einem öffentlichen Share heruntergeladen wird) verwenden die Anweisungen keine “inoffiziellen” (im Sinne von “nicht von Google bereitgestellten”) Drittanbieter-Ressourcen.

Seien Sie sich der folgenden Freiheitsprobleme bewusst:

Der AOSP-Quellbaum enthält eine Reihe von vorgefertigten Binärdateien (z.B. Toolchain, Linux-Kernel, …). Während diese Binärdateien aus dem Quellcode neu erstellt werden könnten, sind die erforderlichen Schritte in diesem Tutorial nicht abgedeckt.
Der Quellcode für die Vendor-Blobs, die für die Verwendung vieler Hardwarekomponenten des Nexus 5X erforderlich sind, ist nicht öffentlich verfügbar!
Das Tool “android-prepare-vendor”, das verwendet wird, um die proprietären Vendor-Dateien zu extrahieren, verwendet selbst vorgefertigte Binärdateien (einige sogar extern gehostet).

Anforderungen und Annahmen

Das Tutorial geht davon aus, dass Sie die folgenden Voraussetzungen haben (andere Versionen/Distributionen könnten ebenfalls funktionieren, erfordern jedoch möglicherweise andere oder zusätzliche Pakete):

ein Nexus 5X mit einem entsperrten Bootloader (das Entsperren wird in diesem Tutorial nicht behandelt)
(virtuelle) Maschine, die Debian9 in der x86_64-Variante ausführt, die ausschließlich für unseren Zweck verwendet wird (wir gehen davon aus, dass Sie sudo verwenden; wenn nicht, passen Sie die Befehle an)
mindestens 5 GB RAM (mehr ist besser)
ca. 200 MB Speicherplatz
schnelle Internetverbindung (wir müssen etwa 30 GB Daten herunterladen)

Abhängigkeiten installieren

Zuerst installieren Sie die Abhängigkeiten wie in den LineageOS-Bauanweisungen [3] beschrieben (AOSP-Bauanweisungen bieten diese Liste nicht):

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

Jetzt installieren Sie zusätzliche Abhängigkeiten:

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

Richten Sie dann einen Bin-Pfad in Ihrem Home-Verzeichnis ein (in Debian 9 wird dieser Pfad automatisch im Bash-Profil konfiguriert):

mkdir -p ~/bin

Installieren Sie den Repo-Befehl:

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

Überprüfen Sie die Prüfziffer der Repo-Binärdatei. Sie sollte e147f0392686c40cfd7d5e6f332c6ee74c4eab4d24e2694b3b0a0c037bf51dc5 für die aktuelle Version 1.23 sein. Für spätere Versionen überprüfen Sie die AOSP-Bauanweisungsseite [4]. Verwenden Sie den folgenden Befehl, um die Prüfziffer zu berechnen:

sha256sum ~/bin/repo

Geben Sie als Nächstes eine Git-Identität an, indem Sie die folgenden Befehle ausführen (Sie können die Beispieldaten belassen, wenn Sie anonym bleiben möchten):

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

git config --global user.name "Ihr Name"

Leider ist das Brotli-Paket (das zum Packen der Builds erforderlich ist) in Debian 9 zu alt, sodass wir die aktuelle Version selbst erstellen müssen. Zuerst den Quellcode abrufen und in sein Verzeichnis wechseln:

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

Führen Sie den Build aus (ersetzen Sie -j15 durch die Anzahl Ihrer CPU-Threads):

cd ~/brotli

./configure-cmake

make -j15

Kopieren Sie schließlich die resultierende Binärdatei in unseren Bin-Pfad:

cp brotli ~/bin/

Melden Sie sich schließlich ab und wieder an, damit Ihr Bash-Profil erneut gelesen wird.

Abrufen der Vendor-Blobs

Es gibt mehrere Probleme bei der Verwendung der Vendor-Blobs aus den von Google bereitgestellten Binärtreiberpaketen (siehe [5]). Um diese zu lösen, verwenden wir das Set externer Skripte “android-prepare-vendor” von “anestisb”, das die Vendor-Blobs aus den Fabrikbildern extrahiert.

Zuerst klonen Sie das Repository:

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

Verwenden Sie die Google-Website [6], um das neueste Build-Tag für Ihr Nexus 5X herauszufinden (derzeit ist es OPM6.171019.030.K1).

Wechseln Sie in das Repository, erstellen Sie ein Ausgabeverzeichnis und führen Sie das Skript aus (wir führen das Skript als Root aus, da es in Debian 9 Probleme mit Fuse gibt):

cd android-prepare-vendor

mkdir bullhead-blobs

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

Herunterladen der AOSP-Quellen

Hinweis: Die folgenden Schritte enthalten keine Anweisungen zur Überprüfung der heruntergeladenen Quelle.

Zuerst erstellen Sie ein Verzeichnis, in dem die Quellen gespeichert werden:

mkdir -p ~/aosp

Wenn Sie das aktuelle Build-Tag für das Nexus 5X kennen, finden Sie heraus, welches das entsprechende Android-Tag ist, indem Sie die Übersicht auf [6] verwenden. Dann, checkout das Android-Manifest für den entsprechenden Branch (in diesem Beispiel verwenden wir android-8.1.0_r46):

cd ~/aosp

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

wie gewohnt in XML, um Repositories auszukommentieren. Ich empfehle, die folgenden auszuschließen/zu ersetzen:

- die QuickSearchBox ist in AOSP sowieso größtenteils defekt
- ersetzen Sie dies durch ein Repository, das einen gepatchten Gerätetree enthält, bei dem die beiden fehlerhaften CPU-Kerne deaktiviert sind. Dies hat eine Leistungseinbuße von ~30%. Dennoch empfohlen, auch wenn Sie ein Nexus 5X haben, das nicht von der Bootschleife betroffen ist, da es wahrscheinlich ist, dass es in Zukunft betroffen sein wird.
- es gibt bessere Alternativen zum Standard-AOSP-Kalender, die Sie später installieren können (wie Etar)
- Silence.im ist eine bessere Alternative zur AOSP-Messaging-App
- OpenCamera ist eine bessere Alternative zur Standardkamera

Jetzt holen Sie sich alle Repositories (kann lange dauern, hauptsächlich abhängig von Ihrer Internetverbindung):

repo sync

Kopieren Sie schließlich die zuvor generierten Vendor-Blobs als Root (dies ist erforderlich, oder qmus und andere Blobs fehlen und verursachen später einen Kompilierungsfehler) in das Vendor-Verzeichnis Ihres AOSP-Baums (ersetzen Sie die Fabrik-Build-Nummer durch die aktuelle):

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 .

Machen Sie Ihren Benutzer zum Besitzer der Vendor-Verzeichnisse (oder der Build schlägt später fehl). Ersetzen Sie yourusername durch Ihren tatsächlichen Benutzernamen:

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

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

Generieren von Schlüsseln

Setzen Sie die Build-Variablen:

source build/envsetup.sh

Bauen Sie das Tool, das zum Generieren des Verity-Schlüssels benötigt wird:

make generate_verity_key

Erstellen Sie ein Verzeichnis zum Speichern Ihrer Schlüssel (CopperheadOS-Dokumente [2] empfehlen, für jedes Gerät einen separaten Schlüssel zu verwenden, in diesem Fall bullhead):

mkdir -p keys/bullhead

Jetzt ist es Zeit, die Schlüssel zu generieren (setzen Sie keine Passwörter auf Ihre Schlüssel):

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

Konvertieren Sie den Verity-Schlüssel in das von AOSP benötigte Format:

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

Kompilieren

Stellen Sie sicher, dass Ihre Build-Variablen gesetzt sind:

cd ~/aosp

source build/envsetup.sh

Erstellen Sie eine Benutzer-Lunchkonfiguration für das Bullhead-Gerät (ersetzen Sie user durch userdebug, wenn Sie stattdessen eine userdebug-Konfiguration wünschen):

lunch aosp_bullhead-user

Deaktivieren Sie Jack (es verursacht oft Kompilierungsprobleme und wurde in Android 9 ohnehin eingestellt):

export ANDROID_COMPILE_WITH_JACK=false

Kompilieren Sie das target-files-package (ersetzen Sie -j15 durch die Anzahl Ihrer CPU-Threads):

make target-files-package -j15

Verpacken und Signieren

Erstellen Sie ein Verzeichnis zum Speichern der Ausgabedateien (außerhalb des üblichen Build-Verzeichnisses namens out):

mkdir dist

Führen Sie das dist-Ziel aus (ersetzen Sie -j15 durch die Anzahl Ihrer CPU-Threads):

make dist -j15

Erstellen Sie ein signiertes target-files-Paket, indem Sie die Standard-Testschlüssel durch Ihre Schlüssel ersetzen (ersetzen Sie yourusername durch Ihren tatsächlichen Benutzernamen im System):

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

Erstellen Sie ein signiertes OTA-Paket:

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

Flashen

Starten Sie Ihr Nexus 5X-Gerät im Bootloader (halten Sie die Lautstärketaste nach unten gedrückt und drücken Sie dann die Einschalttaste).

Verbinden Sie Ihr Gerät über USB mit Ihrem Computer (und machen Sie es verfügbar für die VM, falls Sie in einer VM bauen). Sie können auch die Inhalte aus dem dist-Verzeichnis auf einen anderen Computer kopieren und von dort flashen, aber wir gehen davon aus, dass Sie mit den fastboot/adb-Binärdateien, die aus AOSP-Quellen erstellt wurden, flashen (wenn Sie von außerhalb flashen, stellen Sie sicher, dass Ihre fastboot-Binärdatei aktuell ist).

Entpacken Sie die Bilder aus der signed-target-files.zip:

cd ~/aosp/dist

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

Jetzt flashen Sie alle Bilder:

../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

Wählen Sie “System neu starten” mit den physischen Tasten Ihres Geräts und stellen Sie sicher, dass Ihr neues System funktioniert.

Starten Sie schließlich zurück in den Bootloader und sperren Sie ihn erneut (alle Daten werden gelöscht):

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

Das war’s!

Festlegen separater Boot-/Sperrbildschirm-Geheimnisse

Das Festlegen eines separaten Boot-/Sperrbildschirm-Passworts kann mit einem kleinen Trick erfolgen:

Entsperren Sie den Bootloader (löscht alle Daten)
kompilieren und flashen Sie einen userdebug-Build (siehe oben)
sperren Sie den Bootloader
setzen Sie eine Sperrbildschirm-PIN/-Passwort über die Android-Oberfläche. Stellen Sie sicher, dass Sie die richtige auswählen, da Sie sie nicht mehr ändern können, ohne Ihre Daten zu löschen, sobald Sie zum Benutzer-Build wechseln.
verbinden Sie sich über adb mit dem Gerät
führen Sie als Root den folgenden Befehl aus: vdc cryptfs changepw password your-new-password
starten Sie neu und stellen Sie sicher, dass es funktioniert
kompilieren Sie einen regulären Benutzer-Build (entsperren Sie den Bootloader nicht!)
flashen Sie den Benutzer-Build

Hinweis: Ohne zusätzliche Schritte erlaubt die Wiederherstellung nicht, ältere Builds zu flashen. Daher müssen Sie einen Benutzer-Build flashen, der neuer ist als Ihr userdebug-Build!

Umgang mit Updates

Wenn Sie auf eine neuere AOSP-Version aktualisieren möchten, müssen Sie zuerst die neue Versionsnummer herausfinden.

Dann löschen Sie das alte Manifest (machen Sie eine Sicherung, falls Sie Änderungen vorgenommen haben, die Sie auf dem aktualisierten wiederholen möchten):

cd ~/aosp

rm -rf .repo/manifests.git

rm -rf .repo/manifest.xml

Löschen Sie auch die (dann veralteten) Vendor-Blobs und das prepare-vendor-Repository:

rm -rf ~/android-prepare-vendor

rm -rf vendor

rm -rf vendor_overlay

Löschen Sie auch den Build-Baum und die Build-Artefakte:

rm -rf out

rm -rf dist

Führen Sie dann NUR die folgenden Schritte erneut aus:

Abrufen der Vendor-Blobs
Herunterladen der AOSP-Quellen (dies wird viel schneller sein, da nur die Änderungen abgerufen werden)
Kompilieren
Verpacken und Signieren

Theoretisch sollten Sie in der Lage sein, Updates als neue OTA-Pakete aus der Wiederherstellung zu sideloaden, ohne zu löschen (da sie mit denselben - Ihren - Schlüsseln signiert werden). In der Praxis funktioniert es jedoch noch nicht (siehe den nächsten Abschnitt). Dort müssen Sie auch wie folgt vorgehen:

Sichern Sie alle Ihre Daten
Entsperren Sie den Bootloader (Ihre Daten werden gelöscht)
Flashen Sie die aktualisierten Bilder und sperren Sie Ihren Bootloader erneut, wie im Abschnitt “Flashen” beschrieben.

WIP: Signierte OTA-Updates

Dieser Abschnitt ist WIP, die beschriebenen Anweisungen funktionieren noch nicht!

Theoretisch sollte es möglich sein, signierte OTA-Updates aus der Wiederherstellung zu erstellen und zu flashen. Alle meine Versuche, dies zu tun, führten jedoch zu einem Fehler “Signaturüberprüfung fehlgeschlagen”. Da dies funktioniert, wenn die von Google bereitgestellten Vendor-Dateien direkt verwendet werden, anstatt android-prepare-vendor zu verwenden, gehe ich davon aus, dass es mit den Vendor-Dateien oder anderen Dateien (wie den Bootloader- oder Radio-Bildern) zu tun hat, die nicht ordnungsgemäß signiert sind.

Erstellen Sie das signierte OTA-Paket wie folgt:

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

Starten Sie mit den physischen Tasten Ihres Geräts in die Wiederherstellung.

In der Wiederherstellung sehen Sie ein kleines Android-Symbol. Halten Sie die Einschalttaste gedrückt und drücken Sie die Lauter-Taste, um ins Wiederherstellungsmenü zu gelangen.

Wählen Sie jetzt “Update von adb” mit den physischen Tasten Ihres Geräts.

Sideloaden Sie Ihr signiertes OTA-Paket:

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

Referenzen

[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