Programer Magiska otkrio je da je Google možda počeo koristiti provjere hardvera kako bi utvrdio je li na uređaju otključan bootloader.
XDA priznati programer topjohnwuProjekt "Magisk" u biti je postao sinonim za "root" u Android zajednici. Jedan od glavnih razloga zašto je tako popularan je taj što može sakriti činjenicu da je korisnik modificirao svoj uređaj. Međutim, Google možda ruši mogućnost Magiska da sakrije status otključavanja bootloadera od aplikacija.
Kako biste rootali svoj telefon, obično trebate otključati bootloader, koji vam omogućuje flash modificirane slike za pokretanje. Ovo je potrebno jer Magisk mijenja sliku za pokretanje kako bi lažirao status pokretačkog programa i/ili provjere statusa provjerenog pokretanja. Googleov SafetyNet Attestation API, koji je dio Google Play usluga, koristi se da se aplikaciji kaže radi li na neovlaštenom uređaju; ako SafetyNet API otkrije da je bootloader otključan, tada će vratiti status greške za provjeru "Basic Integrity". Uređaji koji ne prođu ovu provjeru tada se mogu zaključati iz aplikacija koje koriste SafetyNet API za utvrđivanje integriteta uređaja; takve aplikacije obično uključuju aplikacije za bankarstvo, aplikacije za plaćanje (kao što je Google Pay) i mnoge online igre (kao što je Pokémon Go). Međutim, budući da je SafetyNet API do sada koristio samo provjere softvera kako bi utvrdio je li uređaj petljano, Magisk može jednostavno lažirati bootloader i/ili Verified Boot status jer je instaliran na nižoj razini i s višim privilegijama od Google Play usluga i drugog korisničkog prostora aplikacije. Kao što topjohnwu objašnjava, MagiskHide "[stvara] izolirano 'sigurno okruženje' za proces otkrivanja, a ono prolazi kroz Googleov API za stvaranje
zakonit SafetyNet rezultat koji ne odražava stvarno stanje uređaja."Međutim, nedavno su korisnici primijetili da njihovi uređaji s otključanim bootloaderom ne prolaze SafetyNetovu osnovnu provjeru integriteta iako su koristili Magisk za krpanje slike za pokretanje. Prema topjohnwuu, to je zato što je Google možda implementirao ovjeru ključa na razini hardvera kako bi potvrdio da slika za pokretanje nije dirana. Konkretno, to znači da usluge Google Play "[šalju] neizmijenjeni certifikat pohrane ključeva poslužiteljima SafetyNet, provjeravaju njegovu legitimnost i provjeravaju podatke o proširenju certifikata kako biste znali je li vaš uređaj [ima] potvrđeno omogućeno pokretanje (status pokretača)." To znači da možda više nije moguće sakriti činjenicu da je bootloader otključan, što će rezultirati prekidom rada aplikacija kao što su Google Pay i Pokémon Go normalno, redovno.
Kao što je topjohnwu primijetio, ova promjena u načinu na koji SafetyNet provjerava status otključavanja bootloadera dolazi kroz ažuriranje na strani poslužitelja SafetyNet API-ja sadržanog u Google Play uslugama. Međutim, ne prolazi svaki korisnik ove ažurirane SafetyNet provjere, tako da nova potvrda ključa na razini hardvera možda još nije u širokoj primjeni.
Vidjeli smo kako topjohnwu uvijek iznova svladava tehničke prepreke. Google često uvodi nove provjere u SafetyNetu koje topjohnwu zatim otkriva i zaobilazi u Magisku. Svaka nova verzija Androida donosi promjene u strukturi particije ili slici za pokretanje, zahtijevajući da topjohnwu prouči promjene i zatim implementira novu metodu krpanja. Međutim, čak bi se i topjohnwu ovaj put mogao pomučiti da pronađe zaobilaznicu.
To je zato što bi zaobilazno rješenje ovog puta uključivalo hakiranje firmvera Trusted Execution Environment (TEE) uređaja kako bi se dohvatio privatni ključ. Međutim, to je nevjerojatno teško učiniti jer zahtijeva pronalaženje ranjivosti u firmveru koji je dizajniran da bude nevjerojatno siguran. Zapravo, mnoge tvrtke nude plaćanja u stotinama tisuća dolara ako se pronađe takva ranjivost. Google, na primjer, plaća 250.000 dolara za ranjivosti daljinskog izvršavanja koda u Pixelovom okruženju pouzdanog izvršavanja, i do 1.000.000 dolara za ranjivosti u Titan M sigurnosni čip. Čak i kad bi privatni ključ nekako procurio, malo je vjerojatno da bi bio od velike koristi jer Google može daljinski opozvati ključ tako da se ne može koristiti za provjeru integriteta uređaja.
Nakon što se za SafetyNet široko provede atestiranje ključeva na razini hardvera, većina uređaja s otključanim programima za podizanje sustava koji koriste Android 8.0 Oreo ili noviji neće uspjeti proći osnovnu provjeru integriteta SafetyNeta. To je zato što svi uređaji koji su pokrenuti s Androidom 8.0 Oreo ili novijim moraju imati hardversko spremište ključeva implementirano u TEE. Određeni uređaji danas čak imaju namjenske hardverske sigurnosne module (HSM) koji dodatno otežavaju iskorištavanje pomicanjem TEE od glavnog procesora; Titan M u Pixelu 4 i Samsungov novi sigurnosni čip u Galaxy S20 su primjeri za to.
Topjohnwu također objašnjava da su druga potencijalna rješenja ili nemoguća ili vrlo zahtjevna. Korištenje Xposed Frameworka za izmjenu SafetyNet Attestation API-ja u Google Play uslugama vjerojatno neće raditi jer će "odgovarajuće SafetyNet provjere potvrditi rezultate na udaljenom poslužitelju, a ne na [the] uređaj kojim se može manipulirati okvirima za ubacivanje koda." Nadalje, Google Play usluge su jako zamagljene, što stvaranje takvog Xposed modula čini nevjerojatnim izazovom u prvom mjesto. Ni lažiranje rezultata SafetyNet testa neće biti moguće jer odgovori SafetyNeta "dolaze s Googleovih poslužitelja i potpisani su Googleovim privatnim ključem."
Google već nekoliko godina ima mogućnost ojačati SafetyNet provjere pomoću hardverski podržane atestacije ključeva. Činjenica da su se suzdržavali od toga 3 godine omogućila je korisnicima da uživaju u root i Magisk modulima bez žrtvovanja mogućnosti korištenja bankarskih aplikacija. Međutim, čini se da Magiskovoj sposobnosti da učinkovito sakrije status otključavanja bootloadera uskoro dolazi kraj. To je promjena koju smo očekivali godinama, ali smo tužni što je konačno stupila na snagu. Nadamo se da će Google ažurirati SafetyNet Attestation API kako bi pokazao je li provjera statusa korištena na temelju hardvera atest jer bi to omogućilo programerima aplikacija da odluče žele li blokirati sve korisnike koji su otključali bootloader.
Hvala Danielu Micayu (@DanielMicay) za njegov doprinos u vezi s ovim pitanjem!