Utvikleren av Magisk har oppdaget at Google kan ha begynt å bruke maskinvaresjekker for å finne ut om en enhet har blitt låst opp med bootloader.
XDA anerkjent utvikler topjohnwusitt «Magisk»-prosjekt har i hovedsak blitt synonymt med «root» i Android-fellesskapet. En av hovedgrunnene til at det er så populært, er fordi det kan skjule det faktum at brukeren har endret enheten sin. Imidlertid kan Google slå ned på Magisks evne til å skjule opplåsingsstatusen for oppstartslasteren fra applikasjoner.
For å roote telefonen din, må du vanligvis låse opp bootloaderen, som lar deg flashe modifiserte oppstartsbilder. Dette er nødvendig fordi Magisk endrer oppstartsbildet for å forfalske oppstartslasterstatus og/eller verifisert oppstartsstatuskontroll. Googles SafetyNet Attestation API, som er en del av Google Play Services, brukes til å fortelle en app om den kjører på en manipulert enhet; hvis SafetyNet API oppdager at bootloaderen har blitt låst opp, vil den returnere en feilstatus for "Basic Integrity"-sjekken. Enheter som mislykkes i denne kontrollen, kan deretter låses ute fra apper som bruker SafetyNet API for å fastslå enhetens integritet; slike apper inkluderer vanligvis bankapper, betalingsapper (som Google Pay) og mange nettspill (som Pokémon Go). Men fordi SafetyNet API så langt bare har brukt programvaresjekker for å avgjøre om enheten har blitt tuklet med, kan Magisk ganske enkelt forfalske bootloader og/eller Verified Boot-status siden den er installert på et lavere nivå og med høyere rettigheter enn Google Play Services og andre brukerområder applikasjoner. Som topjohnwu forklarer, MagiskHide "[oppretter] et isolert "trygt miljø" for deteksjonsprosessen, og det går gjennom Googles API for å lage en
Nylig har imidlertid brukere lagt merke til at deres oppstartslaster-ulåste enheter mislykkes i SafetyNets grunnleggende integritetssjekk, selv om de brukte Magisk til å lappe oppstartsbildet. I følge topjohnwu skyldes dette at Google kan ha implementert nøkkelattestering på maskinvarenivå for å bekrefte at oppstartsbildet ikke har blitt tuklet med. Dette betyr spesifikt at Google Play Services «[sender] et umodifisert nøkkellagersertifikat til SafetyNet-servere, bekrefter legitimiteten og kontrollerer sertifikatutvidelsesdata for å vite om enheten din [har] bekreftet oppstart aktivert (oppstartslasterstatus)." Dette betyr at den kanskje ikke lenger er mulig å skjule det faktum at bootloaderen har blitt låst opp, noe som vil føre til at applikasjoner som Google Pay og Pokémon Go ikke fungerer normalt.
Som topjohnwu bemerket, kommer denne endringen i måten SafetyNet sjekker opplåsingsstatusen for oppstartslasteren gjennom en oppdatering på serversiden til SafetyNet API i Google Play Services. Det er imidlertid ikke alle brukere som mislykkes i disse oppdaterte SafetyNet-kontrollene, så den nye nøkkelattesten på maskinvarenivå er kanskje ikke håndhevet i stor grad ennå.
Vi har sett topjohnwu overvinne tekniske hindringer gang på gang. Google ruller ofte ut nye sjekker i SafetyNet som topjohnwu deretter oppdager og omgår i Magisk. Hver ny versjon av Android bringer endringer i partisjonsstrukturen eller oppstartsbildet, noe som krever at topjohnwu studerer endringene og deretter implementerer en ny oppdateringsmetode. Imidlertid kan selv topjohnwu slite med å finne en omkjøringsvei denne gangen.
Det er fordi løsningen denne gangen ville innebære hacking av Trusted Execution Environment (TEE)-fastvaren til enheter for å hente den private nøkkelen. Dette er imidlertid utrolig vanskelig å gjøre, da det krever å finne en sårbarhet i fastvaren som er designet for å være utrolig sikker. Faktisk tilbyr mange selskaper betalinger i hundretusenvis av dollar hvis en slik sårbarhet skulle bli funnet. Google betaler for eksempel $250 000 for sikkerhetsproblemer med ekstern kjøring av kode i Pixels Trusted Execution Environment, og opptil $1 000 000 for sårbarheter i Titan M sikkerhetsbrikke. Selv om en privat nøkkel på en eller annen måte skulle lekke, er det usannsynlig at den vil være til stor nytte siden Google kan trekke tilbake nøkkelen eksternt så den kan ikke brukes til å bekrefte integriteten til enheter.
Når nøkkelattestering på maskinvarenivå er håndhevet bredt for SafetyNet, vil de fleste enheter med ulåste oppstartslastere som kjører Android 8.0 Oreo eller høyere, ikke bestå SafetyNets grunnleggende integritetssjekk. Dette er fordi alle enheter som lanseres med Android 8.0 Oreo eller høyere, må ha en maskinvarenøkkellager implementert i en TEE. Enkelte enheter i dag har til og med dedikerte maskinvaresikkerhetsmoduler (HSM) som gjør utnyttelse enda vanskeligere ved å flytte TEE bort fra hovedprosessoren; Titan M i Pixel 4 og Samsungs nye sikkerhetsbrikke i Galaxy S20 er eksempler på dette.
Topjohnwu forklarer også at andre potensielle løsninger er enten umulige eller svært utfordrende. Å bruke Xposed Framework til å endre SafetyNet Attestation API i Google Play Services vil sannsynligvis ikke fungere siden "riktige SafetyNet-kontroller vil bekrefte resultatene på en ekstern server, ikke på [den] enhet som kan manipuleres av rammeverk for kodeinjeksjon." Videre er Google Play Services svært uklare, noe som gjør opprettelsen av en slik Xposed-modul utrolig utfordrende i den første plass. Forfalskning av et SafetyNet-testresultat vil heller ikke være mulig siden SafetyNet-svarene "kommer fra Google-servere og er signert med Googles private nøkkel."
Google har hatt muligheten til å skjerpe SafetyNet-sjekker ved å bruke maskinvarestøttet nøkkelattestering i flere år nå. Det faktum at de avsto fra å gjøre det i 3 år har gjort det mulig for brukere å nyte root- og Magisk-moduler uten å ofre muligheten til å bruke bankapper. Det ser imidlertid ut til at Magisks evne til effektivt å skjule opplåsingsstatusen til oppstartslasteren snart nærmer seg slutten. Det er en endring vi har forventet i årevis, men vi er triste å se at den endelig trer i kraft. Vi håper at Google oppdaterer SafetyNet Attestation API for å returnere om statussjekken er maskinvarebasert attestering, da dette vil tillate apputviklere å bestemme om de vil blokkere alle brukere som har låst opp bootloader.
Takk til Daniel Micay (@Daniel Micay) for hans innspill i denne saken!