Udvikleren af Magisk har opdaget, at Google muligvis er begyndt at bruge hardwaretjek for at afgøre, om en enhed er blevet låst op med bootloader.
XDA anerkendt udvikler topjohnwu's "Magisk"-projekt er i det væsentlige blevet synonymt med "rod" i Android-fællesskabet. En af hovedårsagerne til, at det er så populært, er, at det kan skjule det faktum, at brugeren har ændret deres enhed. Dog kan Google slå ned på Magisks evne til at skjule oplåsningsstatus for bootloader fra applikationer.
For at roote din telefon skal du normalt låse opstartsindlæseren op, som giver dig mulighed for at flashe modificerede opstartsbilleder. Dette er nødvendigt, fordi Magisk ændrer opstartsbilledet for at forfalske opstartsindlæserens status og/eller kontrol af Verified Boot-status. Googles SafetyNet Attestation API, som er en del af Google Play Services, bruges til at fortælle en app, om den kører på en manipuleret enhed; hvis SafetyNet API registrerer, at bootloaderen er blevet låst op, vil den returnere en fejlstatus for "Basic Integrity"-kontrollen. Enheder, der fejler denne kontrol, kan derefter låses ude fra apps, der bruger SafetyNet API til at bestemme enhedens integritet; sådanne apps inkluderer typisk bankapps, betalingsapps (som Google Pay) og mange onlinespil (som Pokémon Go). Men fordi SafetyNet API hidtil kun har brugt softwaretjek til at afgøre, om der er blevet manipuleret med enheden, kan Magisk blot forfalske bootloader og/eller Verified Boot-status, da den er installeret på et lavere niveau og med højere privilegier end Google Play Services og andre brugerområder applikationer. Som topjohnwu forklarer, MagiskHide "[skaber] et isoleret 'sikkert miljø' til detektionsprocessen, og det går gennem Googles API for at skabe en
For nylig har brugere dog bemærket, at deres bootloader-ulåste enheder fejler SafetyNets grundlæggende integritetstjek, selvom de brugte Magisk til at lappe opstartsbilledet. Ifølge topjohnwu skyldes det, at Google muligvis har implementeret nøgleattestering på hardwareniveau for at bekræfte, at opstartsbilledet ikke er blevet manipuleret. Dette betyder specifikt, at Google Play Services "[sender] et umodificeret nøglelagercertifikat til SafetyNet-servere, bekræfter dets legitimitet og kontrollerer certifikatudvidelsesdata for at vide, om din enhed [har] bekræftet start aktiveret (bootloader-status)." Det betyder, at den muligvis ikke længere er muligt at skjule det faktum, at bootloaderen er blevet låst op, hvilket vil resultere i, at applikationer som Google Pay og Pokémon Go ikke fungerer normalt.
Som topjohnwu bemærkede, kommer denne ændring af måden, hvorpå SafetyNet kontrollerer oplåsningsstatus for bootloaderen, gennem en server-sideopdatering til SafetyNet API indeholdt i Google Play Services. Det er dog ikke alle brugere, der fejler disse opdaterede SafetyNet-tjek, så den nye nøgleattestering på hardwareniveau er muligvis ikke håndhævet bredt endnu.
Vi har set topjohnwu overvinde tekniske forhindringer gang på gang. Google udruller ofte nye checks i SafetyNet, som topjohnwu derefter opdager og omgår i Magisk. Hver ny version af Android bringer ændringer til partitionsstrukturen eller boot-billedet, hvilket kræver, at topjohnwu studerer ændringerne og derefter implementerer en ny patch-metode. Men selv topjohnwu kan have svært ved at finde en bypass denne gang.
Det er fordi løsningen denne gang ville involvere hacking af Trusted Execution Environment (TEE) firmwaren på enheder for at hente den private nøgle. Dette er dog utroligt svært at gøre, da det kræver at finde en sårbarhed i firmware, der er designet til at være utrolig sikker. Faktisk tilbyder mange virksomheder betalinger i hundredtusindvis af dollars, hvis en sådan sårbarhed skulle blive fundet. Google betaler f.eks. $250.000 for sårbarheder ved fjernudførelse af kode i Pixels Trusted Execution Environment, og op til $1.000.000 for sårbarheder i Titan M sikkerhedschip. Selv hvis en privat nøgle på en eller anden måde skulle blive lækket, er det usandsynligt, at det ville være til stor nytte, da Google kan tilbagekalde nøglen eksternt så det kan ikke bruges til at verificere enheders integritet.
Når først nøgleattestering på hardwareniveau er håndhævet bredt for SafetyNet, vil de fleste enheder med ulåste bootloadere, der kører Android 8.0 Oreo eller nyere, ikke bestå SafetyNets grundlæggende integritetskontrol. Dette skyldes, at alle enheder, der er lanceret med Android 8.0 Oreo eller nyere, skal have et hardwarenøglelager implementeret i en TEE. Visse enheder har i dag endda dedikerede hardwaresikkerhedsmoduler (HSM'er), der gør udnyttelsen endnu sværere ved at flytte TEE'en væk fra hovedprocessoren; Titan M i Pixel 4 og Samsungs nye sikkerhedschip i Galaxy S20 er eksempler på dette.
Topjohnwu forklarer også at andre potentielle løsninger enten er umulige eller meget udfordrende. Brug af Xposed Framework til at ændre SafetyNet Attestation API i Google Play Services vil sandsynligvis ikke fungere, da "korrekte SafetyNet-tjek vil bekræfte resultater på en ekstern server, ikke på [den] enhed, som kan manipuleres af kodeinjektionsrammer." Desuden er Google Play Services meget sløret, hvilket gør oprettelsen af et sådant Xposed-modul utroligt udfordrende i den første placere. Spoofing af et SafetyNet-testresultat vil heller ikke være muligt, da SafetyNet-svarene "kommer fra Googles servere og er signeret med Googles private nøgle."
Google har haft muligheden for at skærpe SafetyNet-tjek ved hjælp af hardware-understøttet nøgleattestering i flere år nu. Det faktum, at de afholdt sig fra at gøre det i 3 år, har givet brugerne mulighed for at nyde root- og Magisk-moduler uden at ofre muligheden for at bruge bankapps. Det ser dog ud til, at Magisks evne til effektivt at skjule bootloaderens oplåsningsstatus snart er ved at være slut. Det er en ændring, som vi har forventet i årevis, men vi er kede af at se den endelig træde i kraft. Vi håber, at Google opdaterer SafetyNet Attestation API for at returnere, om statuskontrollen bruges hardwarebaseret attestation, da dette ville give app-udviklere mulighed for at beslutte, om de vil blokere alle brugere, der har låst op bootloader.
Tak til Daniel Micay (@Daniel Micay) for hans input i denne sag!