Å skjule root-tilgang i Magisk er i ferd med å bli mye vanskeligere å gjøre takket være en nylig endring i SafetyNet som gir maskinvareattestering.
Tilbake i mars installerte noen få brukere med Magisk la merke til at enhetene deres sviktet SafetyNet-attest. Denne nyheten var urovekkende for samfunnet på XDA fordi det betyr at mange viktige bank-/finansapper og populære spill som Pokémon Go og Fate/Grand Order nektet å kjøre på rotfestede enheter. En stund virket det som om de skjerpede restriksjonene i SafetyNet ble trukket tilbake, for så å rulle ut igjen for en håndfull brukere de siste ukene. Imidlertid bekreftet Google stille i begynnelsen av mai at de tester maskinvarestøttet attestasjon for SafetyNet-svar, som er det som gjorde at Magisk ikke klarte å skjule opplåsingsstatusen for oppstartslasteren igjen Mars. Hvis denne endringen får stor utstrekning, vil det bety at brukerne må velge mellom å ha tilgang til root/egendefinerte ROM-er/kjerner/etc. eller deres foretrukne bankapper og spill. En av Androids største appeller for avanserte brukere kan snart være borte.
For å oppsummere denne serien av hendelser, bør vi først snakke om selve SafetyNet. SafetyNet er et sett med APIer i Google Play Services. SafetyNet Attestation API er en av disse APIene, og den kan kalles opp av tredjepartsapplikasjoner for å sjekke om programvaremiljøet til enheten har blitt tuklet med på noen måte. API-en ser etter forskjellige ting som tegn på binærfiler for superbrukere, opplåsingsstatus for oppstartslasteren og mer. Når du rooter en enhet med Magisk, "[oppretter] den et isolert "trygt miljø" for [SafetyNet]-deteksjonsprosessen, og den går gjennom Googles API for å lage en legitim SafetyNet-resultat som ikke gjenspeiler den virkelige statusen til enheten, sier XDA Senior Recognized Developer topjohnwu. Dette lar brukeren roote telefonen sin samtidig som den sikrer at API-en alltid returnerer "false" for eventuelle opplåsingskontroller for oppstartslaster. Denne metoden for å omgå SafetyNets opplåsingsdeteksjon for bootloader har fungert for Magisk de siste par år, men det er bare fordi Google har ventet på å verifisere integriteten til oppstartsbildet ved hjelp av maskinvare attestasjon. I mars virket det som om Google endelig begynte å bruke maskinvareattesting i SafetyNet for å bekrefte oppstartsbilde, men vi fikk aldri en offisiell uttalelse fra Google som bekreftet endringen, og det var bare noen få brukere berørt. Som oppdaget av XDA Senior Member DisplaxGoogle bekreftet imidlertid 5. mai 2020 at SafetyNet Attestation API-svar fra enkelte enheter nå inkluderer maskinvarestøttede kontroller.
På Google-gruppen for «SafetyNet API-klienter» beskrev Google en ny funksjon for Attestation API: evaluationType. JSON Web Signature (JWS)-svaret fra noen enheter vil ha et felt kalt "evaluationType" som "vil gi utviklere innsikt inn i typene signaler/målinger som har bidratt til hvert enkelt SafetyNet Attestation API-svar." Et av de støttede tokenene i dette feltet er "HARDWARE_BACKED" som indikerer at API-en "[brukte] de tilgjengelige maskinvarestøttede sikkerhetsfunksjonene til den eksterne enheten (f.eks. maskinvarestøttet nøkkelattest) for å påvirke evalueringen." Google sier at de "for øyeblikket evaluerer og justerer kvalifikasjonskriteriene for enheter der vi vil stole på maskinvarestøttet sikkerhetsfunksjoner." Hva dette betyr er at på enkelte enheter bruker Google Play Services nå maskinvarestøttet attestering for å oppdage at enhetens programvare ikke har blitt tuklet med. Google har ikke offisielt dokumentert denne endringen utenom kunngjøringen i Google-gruppen, så enkelte utviklere som bruker SafetyNet kan ikke være klar over denne endringen (og derfor ikke ser etter "HARDWARE_BACKED"-feltet i JWS-svar ennå.) Men for de appene som ser etter dette feltet, er det nå ingen måte å skjule root-tilgang for dem, forutsatt at enheten din er en del av testen som Google er løping.
I følge topjohnwu betyr maskinvarestøttet attestasjon at Google Play Services nå «[sender] et umodifisert nøkkellagersertifikat til SafetyNet-servere, [verifiserer] dets legitimitet, og [sjekker] sertifikatutvidelsesdata for å vite om enheten din [har] bekreftet oppstart aktivert (oppstartslasterstatus)." Siden de private nøklene som nøkkellagersertifikatene er avledet fra er støttet av telefonens isolerte sikre miljø, vil å hente dem innebære å beseire sikkerheten til telefonens Trusted Execution Environment (TEE) eller dedikert maskinvaresikkerhet modul (HSM). Hvis man på en eller annen måte var i stand til å lekke en privat nøkkel, nøkler ville raskt bli tilbakekalt når Google fant ut det. Google tilbyr hundretusenvis av dollar i belønninger for alle kritiske sikkerhetssårbarheter som påvirker TEE i Pixel-telefoner, som bare viser at det er utrolig usannsynlig at dette er en potensiell mulighet for å omgå opplåsingsdeteksjon av oppstartslaster uansett.
En annen mulig måte Magisk kan fortsette å forfalske opplåsingsstatusen for oppstartslasteren på, er ved å modifisere SafetyNets klientsidekode for alltid å bruke BASIC-evalueringen. Som topjohnwu notater, men dette vil kreve å injisere tilpasset kode i Google Play Services via et hooking-rammeverk som Xposed Framework. Dette er ikke bare vanskelig å gjøre fordi Google Play Services er svært tilslørt, men det er også umulig å skjule siden "noen minneplassanalyse vil avsløre kodemanipulasjon veldig enkelt." Videre vil dette også bare fungere hvis Googles servere fortsetter å godta BASIC-evalueringer og hvis HARDWARE_BACKED-evalueringer ikke håndheves på enheter som støtter dem. (SafetyNet-svar "[kommer] fra Google-servere og er signert med Googles private nøkkel," ifølge topjohnwu, så de faktiske svarene kan ikke forfalskes.)
Siden Android 7 Nougat har Google krevd at alle enheter har et isolert sikkert miljø, Det betyr at denne endringen i hvordan SafetyNet verifiserer opplåsing av oppstartslaster, vil påvirke de fleste enheter som er ute der. Siden eldre enheter uten et isolert sikkert miljø åpenbart ikke kan utføre maskinvarestøttet attestasjon, vil Magisk fortsatt kunne skjule rottilgang på disse enhetene. Men hvis denne endringen ruller ut bredt, vil alle andre måtte ta et vanskelig valg mellom root-tilgang og bankapper.
Dessverre er det sannsynligvis mange apper der ute som bruker SafetyNet-sjekker når de faktisk ikke trenger det. Et eksempel sitert av topjohnwu er den offisielle McDonald's-appen, som tilsynelatende nekter å kjøre på en oppstartslaster ulåst enhet. På Twitter kaller topjohnwu apper som overbruker API-en for å skape et fiendtlig miljø for superbrukere. XDA anerkjent utvikler Quinny899 slutter seg til en anekdote om hvordan teamet hans vurderte å bruke SafetyNet for å sjekke enhetens sikkerhetsstatus. De bestemte seg til slutt for å ikke gå gjennom det siden teamets app krypterer alle sensitive data den fungerer med. SafetyNet, hevder han, bør ikke brukes i stedet for riktig sikkerhet og datahåndteringspraksis, spesielt når man vurderer mulighet for superbrukerutnyttelse.
For mer informasjon om hvordan den nye SafetyNet-endringen påvirker Magisk, sjekk ut topjohnwu's utmerket FAQ på Twitter. Hvis du bare vil sjekke om enheten din er en del av Googles nye SafetyNet-test, så kan du følge med denne veiledningen av XDA Senior Member Displax eller last ned den nyeste Magisk Manager-utgivelsen.
Denne artikkelen ble oppdatert kl. 10:46 EST den 30. juni 2020 for å korrigere at Google bare utbetaler belønninger for TEE-sårbarheter funnet i Pixel-telefoner. Videre ble det lagt til detaljer om den siste Magisk Manager-utgivelsen som nå viser evaluationType-feltet i den innebygde SafetyNet-sjekkeren.