Sakrivanje root pristupa u Magisku uskoro će postati puno teže zahvaljujući nedavnoj promjeni u SafetyNetu koja donosi atestiranje hardvera.
U ožujku je nekoliko korisnika imalo instaliran Magisk primijetio da njihovi uređaji nisu prošli SafetyNet atest. Ova je vijest uznemirila zajednicu na XDA jer znači da su mnoge ključne bankarske/financijske aplikacije i popularne igre poput Pokémon Go i Fate/Grand Order odbijale raditi na rootanim uređajima. Neko se vrijeme činilo da su pooštrena ograničenja u SafetyNetu povučena, da bi se u posljednjih nekoliko tjedana ponovno pokrenula za nekolicinu korisnika. Međutim, Google je tiho potvrdio početkom svibnja da testira hardverski potkrijepljenu ovjeru za SafetyNet odgovori, zbog čega Magisk nije mogao sakriti status otključavanja bootloadera u Ožujak. Ako se ova promjena široko proširi, to će značiti da će korisnici morati birati između pristupa root-u/prilagođenim ROM-ovima/jezgri/itd. ili njihove omiljene bankarske aplikacije i igre. Jedna od najvećih privlačnosti Androida za napredne korisnike uskoro bi mogla nestati.
Da rezimiramo ovaj niz događaja, prvo bismo trebali govoriti o samom SafetyNetu. SafetyNet je skup API-ja u Google Play uslugama. SafetyNet Attestation API jedan je od tih API-ja i mogu ga pozvati aplikacije trećih strana kako bi provjerile je li softversko okruženje uređaja na bilo koji način petljano. API provjerava razne stvari kao što su znakovi binarnih datoteka superkorisnika, status otključavanja bootloadera i više. Kada rootate uređaj s Magiskom, on “[stvara] izolirano 'sigurno okruženje' za proces otkrivanja [SafetyNet], i prolazi kroz Googleov API za stvaranje zakonit SafetyNet rezultat koji ne odražava stvarni status uređaja," prema XDA Senior Recognised Developer topjohnwu. To omogućuje korisniku da root-uje svoj telefon, a istovremeno osigurava da API uvijek vraća "false" za sve provjere otključavanja bootloadera. Ova metoda zaobilaženja otkrivanja otključavanja pokretačkog programa SafetyNet radila je za Magisk zadnjih nekoliko godina, ali to je samo zato što je Google odugovlačio s provjerom integriteta slike za pokretanje pomoću hardvera ovjeravanje. U ožujku se činilo da je Google konačno počeo koristiti atestiranje hardvera u SafetyNetu kako bi potvrdio boot image, ali nikada nismo dobili službenu izjavu od Googlea koja potvrđuje promjenu i samo je nekoliko korisnika pogođeni. Kao što je primijetio stariji član XDA Displax, međutim, Google je 5. svibnja 2020. potvrdio da SafetyNet Attestation API odgovori s nekih uređaja sada uključuju hardverske provjere.
Na Google grupi za "SafetyNet API klijente," Google je detaljno opisao novu značajku za Attestation API: evaluationType. Odgovor JSON web potpisa (JWS) s nekih uređaja imat će polje pod nazivom "evaluationType" koje će "programerima pružiti uvid u vrste signala/mjerenja koji su pridonijeli svakom pojedinačnom odgovoru API-ja za potvrdu SafetyNet." Jedan od podržanih tokena u ovom polju je "HARDWARE_BACKED" što označava da je API "[koristio] dostupne sigurnosne značajke hardverski podržane na udaljenom uređaju (npr. hardverski podržano ovjeravanje ključa) kako bismo utjecali [na njegovu] procjenu." Google kaže da oni "trenutačno procjenjuju i prilagođavaju kriterije prihvatljivosti za uređaje na kojima ćemo se oslanjati na hardverski sigurnosne značajke." To znači da na nekim uređajima usluge Google Play sada koriste hardverski potpomognutu ovjeru kako bi otkrile da softver uređaja nije petljati s. Google nije službeno dokumentirao ovu promjenu osim objave u Google grupi, tako da neki programeri koji koriste SafetyNet mogu nisu svjesni ove promjene (i stoga još ne provjeravaju polje "HARDWARE_BACKED" u JWS odgovorima.) Međutim, za one aplikacije koje provjeravaju ovo polje, sada ne postoji način da sakrijete root pristup od njih, pod uvjetom da je vaš uređaj dio testa koji Google trčanje.
Prema topjohnwu, hardverski potpomognuta atestacija znači da Google Play usluge sada “[šalju] neizmijenjeni certifikat pohrane ključeva SafetyNet poslužiteljima, [provjeravaju] njegovu legitimnost i [provjerava] podatke proširenja certifikata kako bi saznao je li vaš uređaj [ima] omogućeno potvrđeno pokretanje (status pokretača)." Budući da privatni ključevi iz kojih su izvedeni certifikati spremišta ključeva podržani izoliranim sigurnim okruženjem telefona, njihovo dohvaćanje uključivalo bi narušavanje sigurnosti okruženja pouzdanog izvršavanja telefona (TEE) ili namjenske hardverske sigurnosti modul (HSM). Ako bi se nekako uspjelo otkriti privatni ključ, ključevi bi brzo bili opozvani nakon što je Google otkrio. Google nudi stotine tisuća dolara u nagradama za sve kritične sigurnosne propuste koji utječu na TEE u Pixel telefonima, što samo pokazuje da je nevjerojatno vjerojatno da će ovo biti potencijalni put za zaobilaženje otkrivanja otključavanja bootloadera svejedno
Drugi potencijalni način na koji bi Magisk mogao nastaviti lažirati status otključavanja bootloadera je modificiranje SafetyNet-ovog koda na strani klijenta da uvijek koristi BASIC procjenu. Kao topjohnwu bilješke, međutim, to bi zahtijevalo ubacivanje prilagođenog koda u usluge Google Play putem okvira za spajanje kao što je Xposed Framework. Ovo ne samo da je teško učiniti jer su usluge Google Play jako zamagljene, nego je također nemoguće sakriti jer će "neka analiza memorijskog prostora otkriti vrlo manipulaciju kodom lako." Nadalje, ovo bi također funkcioniralo samo ako Googleovi poslužitelji nastave prihvaćati BASIC procjene i ako se HARDWARE_BACKED procjene ne provode na uređajima koji podržavaju ih. (SafetyNet odgovori "[dolaze] s Googleovih poslužitelja i potpisani su Googleovim privatnim ključem", prema topjohnwu, tako da se stvarni odgovori ne mogu lažirati.)
Od Androida 7 Nougat, Google zahtijeva da svi uređaji imaju izolirano sigurno okruženje, što znači da će ova promjena načina na koji SafetyNet provjerava otključavanje bootloadera utjecati na većinu uređaja koji nisu dostupni tamo. Budući da stariji uređaji bez izoliranog sigurnog okruženja očito ne mogu izvesti hardverski potpomognuto ovjeravanje, Magisk će i dalje moći sakriti root pristup na tim uređajima. Ali ako se ova promjena široko proširi, svi ostali će morati napraviti težak izbor između root pristupa i bankovnih aplikacija.
Nažalost, vjerojatno postoji mnogo aplikacija koje koriste SafetyNet provjere kada im to zapravo nije potrebno. Jedan primjer koji navodi topjohnwu je službena McDonald'sova aplikacija, koja se naizgled odbija pokrenuti na uređaju s otključanim bootloaderom. Na Twitteru topjohnwu proziva aplikacije koje pretjerano koriste API da stvaraju neprijateljsko okruženje za napredne korisnike. XDA priznati programer Quinny899 pridružuje se anegdotom o tome kako je njegov tim razmišljao o korištenju SafetyNeta za provjeru sigurnosnog statusa uređaja. Naposljetku su odlučili da neće proći kroz to jer aplikacija njegovog tima šifrira sve osjetljive podatke s kojima radi. SafetyNet, tvrdi on, ne bi se trebao koristiti umjesto odgovarajuće prakse sigurnosti i rukovanja podacima, osobito kada se uzme u obzir mogućnost superuser exploita.
Za više informacija o tome kako nova SafetyNet promjena utječe na Magisk, pogledajte topjohnwu's odličan FAQ na Twitteru. Ako samo želite provjeriti je li vaš uređaj dio Googleovog novog SafetyNet testa, onda ga možete pratiti ovaj vodič od strane XDA Senior Member Displax ili preuzmite najnovije izdanje Magisk Managera.
Ovaj je članak ažuriran u 10:46 EST 30. lipnja 2020. kako bi se ispravilo da Google isplaćuje nagrade samo za TEE ranjivosti pronađene u Pixel telefonima. Nadalje, dodani su detalji u vezi s najnovijim izdanjem Magisk Managera koje sada prikazuje polje EvaluationType u ugrađenom SafetyNet alatu za provjeru.