Razvijalec Magiska je odkril, da je Google morda začel uporabljati preverjanje strojne opreme, da ugotovi, ali je bil zagonski nalagalnik naprave odklenjen.
XDA priznani razvijalec topjohnwuProjekt "Magisk" je v bistvu postal sinonim za "root" v skupnosti Android. Eden glavnih razlogov, zakaj je tako priljubljen, je ta, da lahko skrije dejstvo, da je uporabnik spremenil svojo napravo. Vendar pa Google morda zatira zmožnost Magiska, da skrije stanje odklepanja zagonskega nalagalnika pred aplikacijami.
Če želite izkoreniniti svoj telefon, morate običajno odkleniti zagonski nalagalnik, ki vam omogoča flashanje spremenjenih zagonskih slik. To je potrebno, ker Magisk spremeni zagonsko sliko, da ponaredi stanje zagonskega nalagalnika in/ali preverjanja stanja preverjenega zagona. Googlov API za potrjevanje SafetyNet, ki je del storitev Google Play, se uporablja za sporočanje aplikaciji, ali se izvaja v napravi, v kateri je bilo spremenjeno; če API SafetyNet zazna, da je bil zagonski nalagalnik odklenjen, vrne stanje napake za preverjanje »Osnovne celovitosti«. Naprave, ki ne opravijo tega preverjanja, se lahko nato zaklenejo iz aplikacij, ki uporabljajo API SafetyNet za ugotavljanje celovitosti naprave; takšne aplikacije običajno vključujejo bančne aplikacije, plačilne aplikacije (kot je Google Pay) in številne spletne igre (kot je Pokémon Go). Ker pa je SafetyNet API doslej uporabljal samo preverjanja programske opreme, da bi ugotovil, ali je bila naprava spremenjena, lahko Magisk preprosto ponaredi zagonski nalagalnik in/ali stanje preverjenega zagona, ker je nameščen na nižji ravni in z višjimi privilegiji kot storitve Google Play in drug uporabniški prostor aplikacije. Kot pojasnjuje topjohnwu, MagiskHide "[ustvari] izolirano" varno okolje "za postopek odkrivanja in gre skozi Googlov API, da ustvari
Pred kratkim pa so uporabniki opazili, da njihove naprave, odklenjene z zagonskim nalagalnikom, ne opravijo osnovnega preverjanja integritete SafetyNet, čeprav so uporabili Magisk za popravek zagonske slike. Po mnenju topjohnwuja je to zato, ker je Google morda implementiral potrditev ključa na ravni strojne opreme, da preveri, ali zagonska slika ni bila spremenjena. Natančneje, to pomeni, da storitve Google Play »[pošljejo] nespremenjeno potrdilo shrambe ključev strežnikom SafetyNet, preverijo njegovo legitimnost in preverijo podatke o razširitvi potrdila, če želite izvedeti, ali je vaša naprava [ima] preverjen zagon omogočen (stanje zagonskega nalagalnika).« To pomeni, da morda ni več mogoče skriti dejstvo, da je bil zagonski nalagalnik odklenjen, zaradi česar aplikacije, kot sta Google Pay in Pokémon Go, ne bodo delovale običajno.
Kot je omenil topjohnwu, ta sprememba načina, kako SafetyNet preverja stanje odklepanja zagonskega nalagalnika, prihaja s posodobitvijo na strani strežnika API-ja SafetyNet v storitvah Google Play. Vendar pa ni vsak uporabnik neuspešen pri teh posodobljenih preverjanjih SafetyNet, zato novo potrjevanje ključev na ravni strojne opreme morda še ni široko uveljavljeno.
Videli smo, kako topjohnwu vedno znova premaguje tehnične ovire. Google pogosto uvaja nova preverjanja v SafetyNet, ki jih topjohnwu nato odkrije in obide v Magisku. Vsaka nova različica Androida spremeni strukturo particije ali zagonsko sliko, kar zahteva, da topjohnwu preuči spremembe in nato izvede novo metodo popravkov. Vendar se bo morda celo topjohnwu tokrat trudil najti obvod.
To je zato, ker bi tokratna rešitev vključevala vdor v vdelano programsko opremo Trusted Execution Environment (TEE) naprav, da bi pridobili zasebni ključ. Vendar je to izjemno težko narediti, saj zahteva iskanje ranljivosti v vdelani programski opremi, ki je zasnovana tako, da je neverjetno varna. Pravzaprav mnoga podjetja ponujajo plačila v več sto tisoč dolarjih, če bi se odkrila taka ranljivost. Google na primer plača 250.000 $ za ranljivosti pri oddaljenem izvajanju kode v Pixelovem Trusted Execution Environment in do 1.000.000 $ za ranljivosti v Titan M varnostni čip. Tudi če bi zasebni ključ nekako pricurljal, je malo verjetno, da bi bil zelo uporaben, saj Google lahko na daljavo prekliče ključ zato ga ni mogoče uporabiti za preverjanje celovitosti naprav.
Ko bo za SafetyNet široko uveljavljeno potrjevanje ključev na ravni strojne opreme, večina naprav z odklenjenimi zagonskimi nalagalniki s sistemom Android 8.0 Oreo ali novejšim ne bo prestala osnovnega preverjanja integritete SafetyNet. To je zato, ker morajo vse naprave, ki so bile izdane s sistemom Android 8.0 Oreo ali novejšim, imeti shrambo ključev strojne opreme implementirano v TEE. Nekatere naprave imajo dandanes celo namenske varnostne module strojne opreme (HSM), ki dodatno otežijo izkoriščanje s premikanjem TEE stran od glavnega procesorja; Titan M v Pixel 4 in Samsungov novi varnostni čip v Galaxy S20 so primeri tega.
Topjohnwu tudi pojasnjuje da so druge možne rešitve bodisi nemogoče bodisi zelo zahtevne. Uporaba ogrodja Xposed Framework za spreminjanje API-ja za potrjevanje SafetyNet v storitvah Google Play verjetno ne bo delovala, saj bodo "ustrezna preverjanja SafetyNet preverila rezultate na oddaljenem strežniku, ne na [the] naprava, ki jo je mogoče manipulirati z okviri za vbrizgavanje kode." Poleg tega so storitve Google Play zelo zakrite, zaradi česar je ustvarjanje takšnega modula Xposed v prvem trenutku izjemno zahtevno. mesto. Tudi ponarejanje rezultatov testa SafetyNet ne bo mogoče, saj odgovori SafetyNet "prihajajo iz Googlovih strežnikov in so podpisani z Googlovim zasebnim ključem."
Google že nekaj let lahko okrepi preverjanja SafetyNet s strojno podprtim potrjevanjem ključev. Dejstvo, da so se tega vzdržali 3 leta, je uporabnikom omogočilo, da uživajo v modulih root in Magisk, ne da bi žrtvovali možnost uporabe bančnih aplikacij. Vendar se zdi, da se bo zmožnost Magiska, da učinkovito skrije stanje odklepanja zagonskega nalagalnika, kmalu končala. To je sprememba, ki smo jo pričakovali leta, vendar smo žalostni, ko vidimo, da je končno začela veljati. Upamo, da bo Google posodobil API za potrdilo SafetyNet, da bo pokazal, ali je preverjanje stanja uporabljalo strojno opremo potrdilo, saj bi to razvijalcem aplikacij omogočilo, da se odločijo, ali želijo blokirati vse uporabnike, ki so odklenili zagonski nalagalnik.
Hvala Danielu Micayu (@DanielMicay) za njegov prispevek v zvezi s to zadevo!