Shiftphone 8 nach Root Fehler bei native key attestation

[Oliver500]

Hallo zusammen. Ich habe mein Shiftphone 8 nach der hier im Forum vorliegenden Anleitung gerootet und habe dann auf Basis diverses anderer Quellen verschiedene Magisk-Module installiert und eingerichtet. Um zu testen, in wieweit eine key attestation (noch) möglich ist, habe ich die App Key Attestation 1.8.4 verwendet. Hintergrund war, dass auch der Google Play Store zeigt, dass das Gerät nicht zertifiziert ist. Ich war zuerst davon ausgegangen, dass dies Folge des Rootens wäre, und das Root nicht in vollem Umfang verborgen werden kann, was aus meiner Sicht auch Sinn ergeben würde. Aber: Beim Ausführen der Key Attestation App bekomme ich einen Fehler "Unable to attest", und nicht etwa "MEETS_DEVICE_INTEGRITY=false" oder Ähnliches. Ich habe hier mal einen Screenshot angehängt. Für mich sieht das so aus, als ob schon die Prüfung an sich nicht durchgeführt werden kann, statt mit einem negativen Ergebnis abzuschließen. Das Logcat liefert hierzu auch einen Fehler "HARDWARE_TYPE_UNAVAILABLE". Ich wollte eigentlich nun doch nochmal prüfen, ob der Fehler auch dann auftritt, wenn das Gerät nicht gerootet ist, und habe dazu das ShiftOS 6.8 auf beiden Slots per OTA installiert und das Root per Magisk nicht nachgezogen, sodass jetzt beide Slots wieder alles aus dem Stock-OS haben, inklusive boot (und somit kein Root mehr funktioniert). Ich will nun aber doch nicht den Bootloader wieder schließen, nur um zu Testen, ob das Problem auch dann noch besteht, da ich a) nicht wieder ganz von vorn anfangen will (Werksreset) und b) ich an dieser Stelle ein GANZ klein wenig nervös werde. Mit geöffnetem Bootloader ist das Ergebnis der Key Attestation App immer noch genauso, allerdings frage ich mich, ob das wirklich daran liegt, oder ob es auf dem Gerät irgendein anderes Problem gibt. Ist das Problem Folge des Rootens (was ich eigentlich wieder entfernt habe), oder des offenen Bootloaders oder gibt es ein Problem mit dem Gerät selbst? Hat hierzu jemand eine Idee?

 

[@Lhotze]

Du kennst Key Attestation aus einer Vielzahl an Gründen verlieren. Offener Bootloader, Root, User-Debug-Keys, da gibt es einfach eine Vielzahl an Sachen drumherum und eines davon reicht meist aus um alles auf no integrity zu setzen.

Und es gibt auch mittlerweile nicht mehr das Rezept, wie du das irgendwie gelöst bekommst. Das ist eine einzige Rennerei und ich betreibe Root gefühlt, seit ich Android habe. Und mein Gerät ist meistens auch nur auf Device Integrity und das reicht oft aus.
Aber da ich bisher nie in der Lage war, meine eigene Device-ID auszulesen, bin ich auch immer auf geleakte Keyboxen angewiesen, weswegen ich gefühlt jeden Monat eine neue suchen darf und die Integrität dazwischen verliere.

Wenn es dir auf die Integrität ankommt, geh zurück auf Stock, lass den Bootloader zu, kein Root. Wenn es dir auf Root ankommt und du Integrity brauchst, überleg dir wirklich gut, welche Module du benutzt, weil du auch oft Module nutzen kannst, die sich grundsätzlich widersprechen und das Gegenteilige bewirken. Und da Google da auch regelmäßig nachpatcht, was die Erkennung angeht, gibt es nicht das Rezept A, sondern man ist ständig am Ende nur am Probieren.

Greetz

 

[Oliver500]

Du kennst Key Attestation aus einer Vielzahl an Gründen verlieren. Offener Bootloader, Root, User-Debug-Keys, da gibt es einfach eine Vielzahl an Sachen drumherum und eines davon reicht meist aus um alles auf no integrity zu setzen.

Wie immer danke dir für deine Informationen! Das versteh ich auch, ich habe mich nur gewundert, dass scheinbar überhaupt keine Integritätsprüfung durchgeführt werden konnte, selbst dann nicht (mehr), als boot wieder mit der Stock-Version versehen wurde. Ich wollte es nun aber doch nochmal genauer wissen, und habe den Schritt gewagt, und den Bootloader wieder geschlossen (Werksreset kam, System funktioniert noch Und schon geht's mir wieder besser. ) Nun, nach erneutem Stock ohne Root direkt mal die beiden Apps "Key Attestation" und "Play Integrity API Checker" installiert und getestet - und tatsächlich, alle Integrities vorhanden und auch die Key Attestation funktioniert. Kann es denn sein, dass allein aufgrund der Tatsache, dass der Bootloader geöffnet wird, die Key Attestation mit einem "HARDWARE_TYPE_UNAVAILABLE" bzw. einem Fehler -10003 abbricht, und erst gar nicht prüfen kann? Oder kann eine Veränderung irgendwo im System immernoch vorhanden sein, auch wenn ich boot wieder durch Stock-boot ersetze, und damit Root entferne?

 

[amartinz]

Also wenn wir Zertifizierungstests machen und das Gerät entsperrt lassen, schlagen jegliche Attestation Tests fehl, der Bootloader kann garnicht mehr auf gewisse Bereiche zugreifen.

 

[Oliver500]

Also wenn wir Zertifizierungstests machen und das Gerät entsperrt lassen, schlagen jegliche Attestation Tests fehl, der Bootloader kann garnicht mehr auf gewisse Bereiche zugreifen.

Das ist interessant. Ich habe jetzt gerade den Bootloader wieder geöffnet und direkt wieder die Tests mit den beiden Apps (nach derer erneuten Installation) durchgeführt (ohne zu rooten oder sonst irgendwas zu verändern). Ich komme wieder direkt zu dem Fehler aus meinem ersten Post, und es wird keine Integritätsstufe bestanden. Heißt das denn, dass es nach dem Öffnen des Bootloaders überhaupt keine Möglichkeit gibt, zumindest eine Basic Integrity zu bekommen, weil diese gar nicht erst geprüft werden kann? Also auch nicht mittels entsprechender Module über Magisk, da die Technik "dahinter" nicht mehr funktioniert?

 

[@Lhotze]

Das Setup aus den Modulen
- HMA-OSS Zygisk
- PlayIntegrity Fix (Inject)
- TEESimulator RS (+Tricky Add-on zur leichteren Verwaltung
- NeoZygisk

und einer Keybox.xml die die Integritätsprüfung besteht hat sich bei mir in der Vergangenheit bewährt um (mindestens Device Integrity, mehr ist eigentlich nicht notwendig, manchmal auch Full) zu erreichen.
Für den Bootloader ist hier insbesondere TEESimulator (oder alternativ Tricky-Store) zuständig.
Bei Magisk bietet sich bei einer Verwendung einer anderen Zygisk-Variante als NeoZygisk noch das nicht quelloffene Shamiko oder Zygisk Assistant an.

Wer APatch nutzt sollte auch noch das ein oder andere KPM (NoHello, Selinux Access Filter) und NoHello direkt berücksichtigen.

Zu SusFS / KernelPatch kann ich noch keine validen Aussagen machen, da bin ich erst seit ein paar Tagen am Testen.
Magisk habe ich (nach dem abwerben von John Wu zu Google und dem rausnehmen der Hide Sektion) den Rücken gekehrt und bin zu APatch gewechselt, da hier die Hiding-Mechanismen in meinem Augen besser implementiert sind als es die Community dann bei Magisk über Module selbst in die Hand genommen hat.

Ne Anleitung kann ich dir nicht geben, da das nach Anwendungsfall und App unterschiedlich ist.
Beispielsweise funktioniert bei mir auf LineageOS derzeit "Mobiles bezahlen" nach Update nicht mehr, was in der Vergangenheit eigentlich nur auf Root, Selinux und offenen Bootloader geprüft hat (und nicht auf Integrity) während alle anderen Integrity abhängigen Apps ohne Probleme durchrennen (ausgenommen Disney, das läuft aber über den Browser).

Du solltest dir bei so einem Setup einfach bewusst sein, dass du beispielsweise eines Morgens aufstehst, Google was geändert hat und du den Handy plötzlich nicht mehr als Bankkarte nutzen kannst (oder was bei Versicherung einreichen etc...) bis du wieder einige Zeit investiert hast um den Fehler zu erkennen und zu umgehen.
Scheinbar will ich es (und es ist so eine Art Hobby geworden, das alle 1,5 Monate anzugehen), aber bei mir ist das auch nicht wild, wenn mal was ausfällt, da ich prinzipiell damit rechnen .

Greetz

 

[Oliver500]

Bei Magisk bietet sich bei einer Verwendung einer anderen Zygisk-Variante als NeoZygisk noch das nicht quelloffene Shamiko oder Zygisk Assistant an.

Ich hatte es mit Magisk, dem Integrierten Zygisk, und den Modulen Zygisk Assistant, Play Integrity Fix (inject), Tricky Store und Tricky Store Assistant versucht. Aber deine Beschreibung verstehe ich so, dass es nach dem Öffnen des Bootloaders erstmal egal ist, ob Key Attestation mit diesem Fehler abbricht, und die Prüfung durch die richtige Konfiguration wieder funktionsfähig gemacht werden kann. Und wenn ich keine keybox.xml verwende, müsste aber doch zumindest eine Basic Integrity erreichbar sein, oder?

Du solltest dir bei so einem Setup einfach bewusst sein, dass du beispielsweise eines Morgens aufstehst, Google was geändert hat und du den Handy plötzlich nicht mehr als Bankkarte nutzen kannst (oder was bei Versicherung einreichen etc...) bis du wieder einige Zeit investiert hast um den Fehler zu erkennen und zu umgehen.
Scheinbar will ich es (und es ist so eine Art Hobby geworden, das alle 1,5 Monate anzugehen), aber bei mir ist das auch nicht wild, wenn mal was ausfällt, da ich prinzipiell damit rechnen .

Ja, das versteh ich absolut. Man sollte sich also nicht drauf verlassen, aber nice to have ist auch ganz nett. Ich hätte es auch notfalls eben ohne Integrity und mit Root weiter verwendet. Vielleicht muss ich das auch noch, wenn ich es nich schaffe, es entsprechend zu konfigurieren. Vielen Dank auf jeden Fall (mal wieder) für deine (erneute) Hilfe hier im Forum.

 

[@Lhotze]

Aber deine Beschreibung verstehe ich so, dass es nach dem Öffnen des Bootloaders erstmal egal ist, ob Key Attestation mit diesem Fehler abbricht, und die Prüfung durch die richtige Konfiguration wieder funktionsfähig gemacht werden kann.

Ja genau. Dein Gerät springt dann zwischen "No Integrity", "Basis Integrity", "Device Integrity" und "Strong Identity", je nach Zustand des Schlüssels, welche Anforderungen dieser erfüllt und ob Google ihn zurückgezogen hat oder nicht.

Eine App kann den Bootloader dadurch auch als Geschlossen erkennen und gleichzeitig feststellen, dass keine Integrität vorliegt.

Bei entsperrten Bootloader und Root wirst du regelmäßig auf "No Integrity" landen.

Durch den richtigen Keystore (das macht dann Tricky Store / TEESimulator) in Verbindung mit passenden Geräte Props (dafür PIF).
Kannst du dann meist auf Basis oder Device. Strong ist stark schlüsselabhängig.

Du kannst diese Kette jederzeit durch einen Wechsel der entsprechenden Dateien neu anstoßen und könntest so heute ein nicht integeres Gerät und morgen ein integeres haben. Das geht aus dem fließenden System raus, wobei es Apps gibt, die erkennen, wenn du nicht integer bist und dann auch nicht mehr starten, wenn du wieder Integrity hast. Das muss man dann neu einrichten. Andere stört das nicht und wieder andere brauchen nur für die Ersteinrichtung den Integrity-Check und danach nicht mehr.

Und wenn ich keine keybox.xml verwende, müsste aber doch zumindest eine Basic Integrity erreichbar sein, oder?

Nur weil du eine Keybox hast, ist das kein Garant, dass du Integrität erreichst. Da hängt auch viel damit zusammen, ob die Apps den Root-Zugriff erkennen oder der Key noch gültig ist.
Viele Apps fragen einfach nur den Integrity Check von den Google Play Services ab. Es gibt aber auch noch ein paar, die ein paar extra Tests mitbringen.

Greetz