înapoi în martie, câțiva utilizatori cu Magisk instalat observat că dispozitivele lor au fost lipsa de atestare SafetyNet. Această știre a fost îngrijorătoare pentru comunitatea de la XDA, deoarece înseamnă că multe aplicații bancare/financiare cruciale și jocuri populare precum Pok Oktimon Go și Fate/Grand Order refuzau să ruleze pe dispozitive înrădăcinate. De ceva timp, se părea că restricțiile strânse din SafetyNet au fost retrase, doar pentru a se lansa din nou pentru o mână de utilizatori în ultimele săptămâni. Cu toate acestea, Google a confirmat în liniște la începutul lunii mai că testează atestarea susținută de hardware pentru răspunsurile SafetyNet, ceea ce a făcut ca Magisk să nu poată ascunde starea de deblocare a bootloader-ului în martie. Dacă această modificare se derulează pe scară largă, va însemna că utilizatorii vor trebui să aleagă între a avea acces la root/ROM-uri personalizate/kernel/etc. sau aplicațiile și jocurile lor bancare preferate. Unul dintre cele mai mari apeluri ale Android pentru utilizatorii de energie ar putea dispărea în curând.
pentru a recapitula această serie de evenimente, ar trebui să vorbim mai întâi despre SafetyNet în sine. SafetyNet este un set de API-uri în serviciile Google Play. API-ul de atestare SafetyNet este unul dintre aceste API-uri și poate fi apelat de aplicații terțe pentru a verifica dacă mediul software al dispozitivului a fost modificat în vreun fel. API verifică diverse lucruri, cum ar fi semne ale binarelor superuser, starea de deblocare a încărcătorului de boot și multe altele. Când rădăcină un dispozitiv cu Magisk, ” un „mediu sigur” izolat pentru procesul de detectare, și trece prin API Google pentru a crea un rezultat SafetyNet legit care nu reflectă starea reală a dispozitivului,” per XDA Senior recunoscut dezvoltator topjohnwu. Acest lucru permite utilizatorului să rădăcină telefonul lor asigurându-se în același timp că API-ul returnează întotdeauna „false” pentru orice controale de deblocare bootloader. Această metodă de ocolire a detectării deblocării bootloader-ului SafetyNet a funcționat pentru Magisk în ultimii ani, dar asta doar pentru că Google a reținut verificarea integrității imaginii de boot folosind atestarea hardware. În martie, se părea că Google a început în cele din urmă să folosească atestarea hardware în SafetyNet pentru a verifica imaginea de pornire, dar nu am primit niciodată o declarație oficială de la Google care să confirme schimbarea și doar câțiva utilizatori au fost afectați. Cu toate acestea, după cum a fost observat de membrul Senior XDA Displax, Google a confirmat pe 5 mai 2020 că răspunsurile API de atestare SafetyNet de la unele dispozitive includ Acum verificări susținute de hardware.
în grupul Google pentru „clienții API SafetyNet”, Google a detaliat o nouă caracteristică pentru API-ul de atestare: evaluationType. Răspunsul JSON Web Signature (JWS) de la unele dispozitive va avea un câmp numit „evaluationType” care „va oferi dezvoltatorilor o perspectivă asupra tipurilor de semnale/măsurători care au contribuit la fiecare răspuns API individual SafetyNet Attestation.”Unul dintre jetoanele acceptate în acest domeniu este „HARDWARE_BACKED”, care indică faptul că API-ul ” caracteristicile de securitate disponibile susținute de hardware ale dispozitivului la distanță (de exemplu, atestarea cheii susținute de hardware) pentru a influența evaluarea.”Google spune că” evaluează și ajustează în prezent criteriile de eligibilitate pentru dispozitivele în care ne vom baza pe funcții de securitate susținute de hardware.”Ceea ce înseamnă acest lucru este că, pe unele dispozitive, serviciile Google Play utilizează acum atestarea susținută de hardware pentru a detecta că software-ul dispozitivului nu a fost modificat. Google nu a documentat Oficial această modificare în afara anunțului din grupul Google, astfel încât este posibil ca unii dezvoltatori care utilizează SafetyNet să nu fie conștienți de această modificare (și, prin urmare, nu verifică încă câmpul „HARDWARE_BACKED” în răspunsurile JWS.) Cu toate acestea, pentru acele aplicații care verifică acest câmp, acum nu există nicio modalitate de a ascunde accesul root de la acestea, cu condiția ca dispozitivul dvs. să facă parte din testul pe care îl rulează Google.
potrivit topjohnwu, atestarea susținută de hardware înseamnă că Google Play Services acum” un certificat keystore nemodificat la serverele SafetyNet, legitimitatea și datele de extensie a certificatului pentru a ști dacă dispozitivul dvs. a verificat boot-ul activat (starea bootloader-ului).”Deoarece cheile private din care sunt derivate certificatele de chei sunt susținute de mediul securizat izolat al telefonului, recuperarea acestora ar implica înfrângerea securității mediului de execuție de încredere al telefonului (TEE) sau a modulului de securitate hardware dedicat (HSM). Dacă cineva ar putea cumva să scurgă o cheie privată, cheile ar fi revocate rapid odată ce Google ar afla. Google oferă sute de mii de dolari în recompense pentru orice vulnerabilități critice de securitate care afectează TEE-ul în telefoanele Pixel, ceea ce arată că este incredibil de puțin probabil ca aceasta să fie o potențială cale de a ocoli detectarea deblocării bootloader-ului oricum.
un alt mod potențial prin care Magisk ar putea continua să falsifice starea de deblocare a bootloader-ului este prin modificarea Codului SafetyNet din partea clientului pentru a utiliza întotdeauna evaluarea de bază. După cum notează topjohnwu, acest lucru ar necesita injectarea de cod personalizat în serviciile Google Play printr-un cadru de prindere precum Cadrul Xposed. Acest lucru nu este doar dificil de făcut, deoarece Serviciile Google Play sunt foarte confuze, dar este, de asemenea, imposibil de ascuns, deoarece „unele analize ale spațiului de memorie vor dezvălui foarte ușor manipularea codului.”În plus, acest lucru ar funcționa numai dacă serverele Google continuă să accepte evaluări de bază și dacă evaluările HARDWARE_BACKED nu sunt aplicate pe dispozitivele care le acceptă. (Răspunsurile SafetyNet” de pe serverele Google și sunt semnate cu cheia privată Google”, potrivit topjohnwu, astfel încât răspunsurile reale nu pot fi falsificate.)
de la Android 7 Nougat, Google a cerut ca toate dispozitivele să aibă un mediu securizat izolat, ceea ce înseamnă că această modificare a modului în care SafetyNet verifică deblocarea bootloader-ului va afecta majoritatea dispozitivelor care sunt acolo. Deoarece dispozitivele mai vechi fără un mediu securizat izolat, evident, nu pot efectua atestarea susținută de hardware, Magisk va putea în continuare să ascundă accesul root pe aceste dispozitive. Dar dacă această schimbare se desfășoară pe scară largă, toți ceilalți vor trebui să facă o alegere dificilă între accesul root și aplicațiile bancare.
din păcate, există probabil o mulțime de aplicații care utilizează verificări SafetyNet atunci când nu au nevoie de fapt. Un exemplu citat de topjohnwu este aplicația oficială McDonald ‘ s, care aparent refuză să ruleze pe un dispozitiv deblocat de bootloader. Pe Twitter, topjohnwu solicită aplicații care utilizează în exces API-ul ca creând un mediu ostil pentru utilizatorii de putere. Dezvoltatorul recunoscut XDA Quinny899 se alătură cu o anecdotă despre modul în care echipa sa a luat în considerare utilizarea SafetyNet pentru a verifica starea de securitate a dispozitivului. În cele din urmă au decis să nu treacă prin ea, deoarece aplicația echipei sale criptează toate datele sensibile cu care funcționează. SafetyNet, susține el, nu ar trebui să fie utilizat în locul unor practici adecvate de securitate și manipulare a datelor, în special atunci când se ia în considerare posibilitatea exploatărilor superuser.
susțin @AndroidDev să restricționeze evaluarea SafetyNet susținută de hardware la aplicații sensibile la securitate „reale”. Dezvoltatorii ar trebui să treacă printr-un proces de aplicare pentru a califica acest nivel de acces API. Este ridicol ca McDonalds să refuze să ruleze pe un dispozitiv deblocat de bootloader.
— John Wu (@topjohnwu) iunie 29, 2020
pentru mai multe informații despre modul în care noua schimbare SafetyNet afectează Magisk, consultați Întrebările frecvente excelente ale topjohnwu pe Twitter. Dacă doriți doar să verificați dacă dispozitivul dvs. face parte din noul test SafetyNet Google, atunci puteți urma acest ghid de XDA Senior Member Displax sau puteți descărca cea mai recentă versiune Magisk Manager.
actualizat Magisk Manager pentru a reflecta câmpul evaluationType în verificările SafetyNet, astfel încât oamenii să poată începe să numere ultimele zile de glorie
pic.twitter.com/x61tGjM7IK
— John Wu (@topjohnwu) iunie 30, 2020
acest articol a fost actualizat la 10:46 AM EST pe 30 iunie 2020, pentru a corecta faptul că Google plătește doar recompense pentru vulnerabilitățile TEE găsite în telefoanele Pixel. În plus, au fost adăugate detalii cu privire la cea mai recentă versiune Magisk Manager, care arată acum câmpul evaluationType din verificatorul SafetyNet încorporat.
- despre autor
- citiți acest următor
- Google formează Android Ready se Alliance pentru a conduce adoptarea cheilor digitale ale mașinii și a permiselor de conducere
- Fairphone 2 din 2015 primește acum actualizarea oficială la Android 9 Pie
- Motorola Moto G50 are un cip de buget 5G și un preț scăzut
- ASUS lansează noi actualizări pentru ROG Phone 5, ROG Phone 3 și ROG Phone II cu corecții de securitate și remedieri de erori
despre autor
Mishaal Rahman
sunt redactorul-șef al XDA. Pe lângă știrile de ultimă oră de pe sistemul de operare Android și dispozitivele mobile, gestionez tot conținutul editorial și recenzii de pe Portal. Sfaturi / anchete media: [email protected].
citiți acest următor
-
Google formează Android Ready se Alliance pentru a conduce adoptarea cheilor digitale ale mașinii și a permiselor de conducere
-
Fairphone 2 din 2015 primește acum actualizarea oficială la Android 9 Pie
-
Motorola Moto G50 are un cip de buget 5G și un preț scăzut
-
ASUS lansează noi actualizări pentru ROG Phone 5, ROG Phone 3 și ROG Phone II cu corecții de securitate și remedieri de erori
