Magisk kann möglicherweise die Freigabe des Bootloaders vor Anwendungen nicht mehr verbergen
Das "Magisk"-Projekt des von XDA anerkannten Entwicklers topjohnwu ist in der Android-Community im Wesentlichen zum Synonym für "root" geworden. Einer der Hauptgründe, warum es so beliebt ist, ist, dass es die Tatsache verbergen kann, dass der Benutzer sein Gerät modifiziert hat. Allerdings geht Google möglicherweise hart gegen die Fähigkeit von Magisk vor, den Bootloader-Freigabestatus vor Anwendungen zu verbergen.
Um Ihr Telefon als Root zu verwenden, müssen Sie normalerweise den Bootloader entsperren, der es Ihnen ermöglicht, modifizierte Boot-Bilder zu flashen. Dies ist erforderlich, weil Magisk das Boot-Image so modifiziert, dass der Bootloader-Status gefälscht und/oder der verifizierte Boot-Status überprüft wird. Die SafetyNet Attestation API von Google, die Teil der Google Play Services ist, wird verwendet, um einer Anwendung mitzuteilen, ob sie auf einem manipulierten Gerät läuft; wenn die SafetyNet API erkennt, dass der Bootloader entsperrt wurde, gibt sie einen Fehlerstatus für die "Grundlegende Integritätsprüfung" zurück. Geräte, die diese Prüfung nicht bestehen, können dann von Anwendungen gesperrt werden, die die SafetyNet-API zur Bestimmung der Geräteintegrität verwenden; zu solchen Anwendungen gehören typischerweise Bankanwendungen, Zahlungsanwendungen (wie Google Pay) und viele Online-Spiele (wie Pokémon Go). Da die SafetyNet-API bisher jedoch nur Software-Prüfungen verwendet hat, um festzustellen, ob das Gerät manipuliert wurde, kann Magisk den Bootloader und/oder den verifizierten Boot-Status einfach fälschen, da es auf einer niedrigeren Ebene und mit höheren Privilegien installiert ist als Google Play Services und andere Userspace-Anwendungen. Wie topjohnwu erklärt, schafft MagiskHide "[eine] isolierte 'sichere Umgebung' für den Erkennungsprozess, und es geht durch die API von Google, um ein echtes SafetyNet-Ergebnis zu erzeugen, das nicht den tatsächlichen Status des Geräts widerspiegelt.
Kürzlich haben Anwender jedoch bemerkt, dass ihre mit dem Bootloader entsperrten Geräte die grundlegende Integritätsprüfung von SafetyNet nicht bestehen, obwohl sie Magisk zum Patchen des Boot-Images verwendet haben. Laut topjohnwu liegt dies daran, dass Google möglicherweise eine Schlüsselbescheinigung auf Hardware-Ebene implementiert hat, um zu überprüfen, dass das Boot-Image nicht manipuliert wurde. Konkret bedeutet dies, dass Google Play Services "[sendet] ein unmodifiziertes Keystore-Zertifikat an SafetyNet-Server, überprüft seine Legitimität und überprüft die Zertifikatserweiterungsdaten, um zu wissen, ob Ihr Gerät die Boot-Freigabe (Bootloader-Status) verifiziert hat". Das bedeutet, dass es möglicherweise nicht mehr möglich ist, die Tatsache zu verbergen, dass der Bootloader freigeschaltet wurde, was dazu führt, dass Anwendungen wie Google Pay und Pokémon Go nicht mehr normal funktionieren.
Wie topjohnwu bemerkte, erfolgt diese Änderung der Art und Weise, wie SafetyNet den Status der Bootloader-Freischaltung überprüft, durch ein serverseitiges Update der SafetyNet-API, die in Google Play Services enthalten ist. Allerdings fallen nicht alle Nutzer bei diesen aktualisierten SafetyNet-Prüfungen durch, so dass die neue Schlüsselbescheinigung auf Hardware-Ebene möglicherweise noch nicht allgemein durchgesetzt werden kann.
Wir haben gesehen, wie topjohnwu immer wieder technische Hürden überwunden hat. Google führt häufig neue Prüfungen im SafetyNet ein, die topjohnwu dann in Magisk entdeckt und umgeht. Jede neue Version von Android bringt Änderungen der Partitionsstruktur oder des Boot-Images mit sich, so dass topjohnwu die Änderungen untersuchen und dann eine neue Patching-Methode implementieren muss. Aber selbst topjohnwu kann es diesmal schwer haben, eine Umgehung zu finden.
Das liegt daran, dass die Umgehung dieses Mal das Hacken der Firmware der vertrauenswürdigen Ausführungsumgebung (TEE) von Geräten beinhalten würde, um den privaten Schlüssel abzurufen. Dies ist jedoch unglaublich schwierig, da man dazu eine Schwachstelle in der Firmware finden muss, die unglaublich sicher sein soll. Tatsächlich bieten viele Unternehmen Zahlungen in Höhe von Hunderttausenden von Dollar an, wenn eine solche Schwachstelle gefunden wird. Google zahlt beispielsweise 250.000 Dollar für Schwachstellen in der vertrauenswürdigen Ausführungsumgebung von Pixel und bis zu 1.000.000 Dollar für Schwachstellen im Sicherheits-Chip Titan M. Selbst wenn ein privater Schlüssel irgendwie durchsickern sollte, ist es unwahrscheinlich, dass er von großem Nutzen wäre, da Google den Schlüssel aus der Ferne widerrufen kann, so dass er nicht zur Überprüfung der Integrität von Geräten verwendet werden kann.
Sobald die Schlüsselbescheinigung auf Hardware-Ebene für SafetyNet weitgehend durchgesetzt ist, werden die meisten Geräte mit entsperrten Bootloadern, auf denen Android 8.0 Oreo oder höher läuft, die grundlegende Integritätsprüfung von SafetyNet nicht bestehen. Dies liegt daran, dass alle Geräte, die mit Android 8.0 Oreo oder höher gestartet wurden, einen in einem TEE implementierten Hardware-Schlüsselspeicher haben müssen. Bestimmte Geräte verfügen heutzutage sogar über dedizierte Hardware-Sicherheitsmodule (HSMs), die die Nutzung noch schwieriger machen, indem sie das TEE vom Hauptprozessor entfernen; der Titan M im Pixel 4 und der neue Sicherheitschip von Samsung im Galaxy S20 sind Beispiele dafür.
Topjohnwu erklärt auch, dass andere mögliche Umgehungsmöglichkeiten entweder unmöglich oder sehr schwierig sind. Die Verwendung des Xposed Framework zur Modifizierung der SafetyNet Attestation API in Google Play Services wird wahrscheinlich nicht funktionieren, da "ordnungsgemäße SafetyNet-Prüfungen die Ergebnisse auf einem entfernten Server verifizieren, nicht auf [dem] Gerät, das durch Code-Injection-Frames manipuliert werden kann".
Google ist seit mehreren Jahren in der Lage, SafetyNet-Prüfungen mit Hilfe von hardwaregestützten Schlüsselbescheinigungen zu verhärten. Die Tatsache, dass sie drei Jahre lang davon Abstand genommen haben, hat es den Nutzern ermöglicht, Root- und Magisk-Module zu nutzen, ohne die Möglichkeit der Nutzung von Banking-Anwendungen zu opfern. Es scheint jedoch, dass die Fähigkeit von Magisk, den Bootloader-Freigabestatus effektiv zu verbergen, bald zu Ende geht. Das ist eine Änderung, die wir seit Jahren erwartet haben, aber wir sind traurig, dass sie endlich in Kraft tritt. Wir hoffen, dass Google die SafetyNet Attestation API aktualisiert und zurückgibt, ob bei der Statusprüfung eine hardwarebasierte Bestätigung verwendet wurde, da dies den App-Entwicklern die Entscheidung ermöglichen würde, ob sie alle Nutzer, die den Bootloader freigeschaltet haben, blockieren möchten.
Übersetzt mit DeepL Übersetzer (kostenlose Version)
Quelle: Magisk may no longer be able to hide bootloader unlocking from apps
... paßt... weitermachen 
