Skrivanje korenskega dostopa v Magisku bo kmalu postalo veliko težje zaradi nedavne spremembe v SafetyNet, ki prinaša atestiranje strojne opreme.
V marcu je nekaj uporabnikov z nameščenim Magiskom opazil da njihove naprave niso opravile atestiranja SafetyNet. Ta novica je vznemirila skupnost na XDA, ker pomeni, da številne ključne bančne/finančne aplikacije in priljubljene igre, kot sta Pokémon Go in Fate/Grand Order, nočejo delovati na zakoreninjenih napravah. Nekaj časa se je zdelo, kot da so bile poostrene omejitve v SafetyNetu umaknjene, da bi se v zadnjih nekaj tednih znova uvedle za peščico uporabnikov. Vendar je Google v začetku maja tiho potrdil, da preizkušajo strojno podprto potrdilo za odzivov SafetyNet, zaradi česar Magisk ni mogel skriti statusa odklepanja zagonskega nalagalnika nazaj v marec. Če bo ta sprememba široko uvedena, bo to pomenilo, da bodo morali uporabniki izbirati med dostopom do root/ROM-ov po meri/jeder itd. ali njihove najljubše bančne aplikacije in igre. Ena največjih privlačnosti Androida za napredne uporabnike bi lahko kmalu izginila.
Če povzamemo ta niz dogodkov, bi morali najprej govoriti o SafetyNetu samem. SafetyNet je niz API-jev v storitvah Google Play. SafetyNet Attestation API je eden od teh API-jev in ga lahko pokličejo aplikacije tretjih oseb, da preverijo, ali je bilo programsko okolje naprave kakor koli spremenjeno. API preverja različne stvari, kot so znaki binarnih datotek superuporabnika, stanje odklepanja zagonskega nalagalnika in drugo. Ko napravo rootate z Magiskom, »[ustvari] izolirano 'varno okolje' za postopek zaznavanja [SafetyNet] in gre skozi Googlov API, da ustvari zakonit Rezultat SafetyNet, ki ne odraža dejanskega stanja naprave,« navaja starejši priznani razvijalec XDA topjohnwu. To uporabniku omogoča rootanje telefona, hkrati pa zagotavlja, da API vedno vrne "false" za vsa preverjanja odklepanja zagonskega nalagalnika. Ta metoda za izogibanje zaznavanju odklepanja zagonskega nalagalnika SafetyNet je Magisku uspevala zadnjih nekaj let, vendar je to samo zato, ker je Google odlašal s preverjanjem celovitosti zagonske slike s strojno opremo atestiranje. Marca se je zdelo, da je Google končno začel uporabljati atestiranje strojne opreme v SafetyNetu za preverjanje zagonske slike, vendar od Googla nikoli nismo prejeli uradne izjave, ki bi potrdila spremembo, in le nekaj uporabnikov je bilo prizadeti. Kot je opazil višji član XDA Displaxvendar je Google 5. maja 2020 potrdil, da odgovori SafetyNet Attestation API iz nekaterih naprav zdaj vključujejo preverjanja, podprta s strojno opremo.
V Googlovi skupini za »odjemalce API-ja SafetyNet« je Google podrobno predstavil novo funkcijo za API za potrdila: evalvationType. Odgovor spletnega podpisa JSON (JWS) iz nekaterih naprav bo imel polje z imenom "evaluationType", ki "bo razvijalcem zagotovilo vpogled v vrste signalov/meritev, ki so prispevale k vsakemu posameznemu odzivu API-ja za potrdilo SafetyNet." Eden od podprtih žetonov v tem polju je »HARDWARE_BACKED«, kar označuje, da je API »[uporabil] razpoložljive strojno podprte varnostne funkcije oddaljene naprave (npr. strojno podprto potrdilo ključev), da bi vplivali na [njegovo] oceno." Google pravi, da "trenutno ocenjujejo in prilagajajo merila primernosti za naprave, kjer se bomo zanašali na strojno podprto opremo. varnostne funkcije." To pomeni, da v nekaterih napravah storitve Google Play zdaj uporabljajo potrdilo, podprto s strojno opremo, da zaznajo, da programska oprema naprave ni bila posegali v. Google te spremembe ni uradno dokumentiral razen objave v Googlovi skupini, zato lahko nekateri razvijalci, ki uporabljajo SafetyNet ne zavedajo te spremembe (in zato še ne preverjajo polja »HARDWARE_BACKED« v odgovorih JWS.) Vendar za tiste aplikacije, ki preverjajo to polje, zdaj pred njimi ne morete skriti korenskega dostopa, pod pogojem, da je vaša naprava del preizkusa, ki ga Google teče.
Po mnenju topjohnwuja strojno podprto atestiranje pomeni, da storitve Google Play zdaj »[pošljejo] nespremenjeno potrdilo shrambe ključev strežnikom SafetyNet, [preverijo] njegovo legitimnost in [preverja] podatke razširitve potrdila, da izve, ali ima vaša naprava [ima] omogočen preverjen zagon (stanje zagonskega nalagalnika).« Ker zasebni ključi, iz katerih izhajajo potrdila shrambe ključev so podprti z izoliranim varnim okoljem telefona, zato bi njihovo pridobivanje pomenilo premagovanje varnosti zaupanja vrednega izvajalskega okolja (TEE) telefona ali namenske varnosti strojne opreme modul (HSM). Če bi nekomu nekako uspelo razkriti zasebni ključ, bi ključi bi bili hitro preklicani ko je Google izvedel. Google ponuja več sto tisoč dolarjev nagrad za vse kritične varnostne ranljivosti, ki vplivajo na TEE v telefonih Pixel, kar samo dokazuje, da je neverjetno malo verjetno, da bo to potencialna pot za obhod zaznavanja odklepanja zagonskega nalagalnika vseeno.
Drug možen način, na katerega bi lahko Magisk še naprej ponarejal stanje odklepanja zagonskega nalagalnika, je spreminjanje kode na strani odjemalca SafetyNet, da vedno uporablja vrednotenje BASIC. Kot topjohnwu ugotavlja, vendar bi to zahtevalo vbrizgavanje kode po meri v storitve Google Play prek povezovalnega okvira, kot je Xposed Framework. To ni le težko narediti, ker so storitve Google Play zelo zakrite, ampak je tudi nemogoče skriti, saj bo "nekatera analiza pomnilniškega prostora razkrila manipulacijo kode zelo preprosto." Poleg tega bi to delovalo le, če Googlovi strežniki še naprej sprejemajo ocene BASIC in če vrednotenja HARDWARE_BACKED niso uveljavljena v napravah, ki podpirajo njim. (Odzivi SafetyNet "[prihajajo] iz Googlovih strežnikov in so podpisani z Googlovim zasebnim ključem," pravi topjohnwu, tako da dejanskih odgovorov ni mogoče ponarediti.)
Od Androida 7 Nougat je Google zahteval, da imajo vse naprave izolirano varno okolje, kar pomeni, da bo ta sprememba v tem, kako SafetyNet preverja odklepanje zagonskega nalagalnika, vplivala na večino naprav, ki niso na voljo tam. Ker starejše naprave brez izoliranega varnega okolja očitno ne morejo izvesti strojno podprtega atestiranja, bo Magisk še vedno lahko skril korenski dostop do teh naprav. Če pa bo ta sprememba razširjena, se bodo morali vsi ostali težko odločiti med korenskim dostopom in bančnimi aplikacijami.
Na žalost obstaja verjetno veliko aplikacij, ki uporabljajo preverjanje SafetyNet, čeprav tega dejansko ne potrebujejo. En primer, ki ga je navedel topjohnwu, je uradna aplikacija McDonald's, ki se na videz noče zagnati na napravi z odklenjenim zagonskim nalagalnikom. Na Twitterju topjohnwu aplikacije, ki prekomerno uporabljajo API, označuje za ustvarjanje sovražnega okolja za napredne uporabnike. XDA priznani razvijalec Quinny899 se pridruži z anekdoto o tem, kako je njegova ekipa razmišljala o uporabi SafetyNet za preverjanje varnostnega stanja naprave. Na koncu so se odločili, da se tega ne bodo lotili, saj aplikacija njegove ekipe šifrira vse občutljive podatke, s katerimi dela. Trdi, da se SafetyNet ne bi smel uporabljati namesto ustrezne varnosti in praks ravnanja s podatki, zlasti če upoštevamo možnost izkoriščanja superuporabnika.
Za več informacij o tem, kako nova sprememba SafetyNet vpliva na Magisk, si oglejte topjohnwu's odlična pogosta vprašanja na Twitterju. Če želite samo preveriti, ali je vaša naprava del Googlovega novega testa SafetyNet, potem lahko sledite ta vodnik avtor XDA Senior Member Displax ali prenesite najnovejšo izdajo programa Magisk Manager.
Ta članek je bil posodobljen 30. junija 2020 ob 10.46 EST, da bi popravil, da Google izplačuje nagrade samo za ranljivosti TEE, ki jih najdemo v telefonih Pixel. Poleg tega so bile dodane podrobnosti o najnovejši izdaji programa Magisk Manager, ki zdaj prikazuje polje evalvationType v vgrajenem pregledovalniku SafetyNet.