O privire asupra complicațiilor de la rădăcina și Verity Marshmallow

Pe măsură ce praful se așează pe Lansarea Android 6.0, utilizatorii Nexus din belșug fac scufundări pentru OTA și Imagini de fabricăși ne pregătim pentru cea mai recentă iterație a sistemului de operare Android.

În timp ce, din exterior, Android 6.0 pare (cel puțin vizual) remarcabil de similar cu Android 5.0 și 5.1 (versiunile Lollipop), există o serie de modificări semnificative pe interior. Unul dintre ei poate avea ramificații pentru ROM-ul personalizat și comunitățile rădăcină. În primul rând, un mic fundal. Dacă nu sunteți interesat de acest lucru, săriți în jos la „De ce este acest lucru important”.

O caracteristică numită Verity

Problema (este o problemă dacă vă plac dispozitivele de root și modificarea) provine din ceva ce am subliniat cu mult timp în urmă, când a lovit AOSP pentru prima dată - introducerea dm-verity la Android. Verity este o caracteristică de securitate, găsită inițial în ChromeOS, concepută pentru a oferi dispozitive de calcul sigure și de încredere, împiedicând software-ul rău intenționat să modifice un dispozitiv. Înapoi în Android 4.4, Google a anunțat Verity pentru Android și apoi totul a rămas liniștit. În timp ce au fost unele

cercetare în utilizarea verity, în cea mai mare parte, lucrurile au fost liniștite. Până acum, adică.

Cu Android 6.0, Google a început să-și îmbunătățească jocul în ceea ce privește securitatea dispozitivelor. Una dintre cerințele fundamentale pentru aceasta este prevenirea modificării software-ului de pe un dispozitiv fără știrea unui utilizator - în timp ce mulți aici la XDA luați root de la sine înțeles, imaginați-vă că dispozitivul unui utilizator este rootat fără știrea sau acordul acestuia, iar accesul root fiind folosit pentru a-și fura date. Din acest motiv, Google a început să implementeze verificarea partiției de sistem pe unele dispozitive. De asemenea, și-au actualizat recent pagini de suport pentru a acoperi asta.

Ce înseamnă acest lucru pentru utilizatorii înrădăcinați?

Cu adevărul în loc, orice modificări aduse partiției de sistem vor fi detectate la pornire sau acces. Te vei confrunta apoi cu una dintre erorile văzute mai sus. Unele vă permit să continuați, iar altele doresc să vă protejeze prin oprirea pornirii dispozitivului. Există trei stări disponibile. Unul este afișat atunci când bootloader-ul este deblocat, indicând că ați putea fi în pericol până când reblocați bootloader-ul. Acesta este cazul, deoarece o imagine a nucleului modificată poate ocoli veritatea, deoarece discul ram al nucleului conține cheile folosite pentru a verifica starea unui sistem.

Lucrurile par destul de nedistractive pentru utilizatorii care aspiră la root pe dispozitive blocate.

Următoarea stare este afișată (probabil) când Verity este dezactivată sau oprită, sau nu poate fi verificată din cauza modificărilor aduse discului ram. Nu pot fi sigur, din cauza lipsei unui Nexus 5X sau 6P de investigat, dar suspiciunea mea (bazată în jurul mesajelor) este că, dacă încărcați un alt ROM, care apoi își plasează propriul nucleu pe dispozitiv, pagina „sistem de operare diferit” va apărea.

Starea finală este avertismentul roșu care indică că dispozitivul este corupt. Bănuiesc că acest lucru înseamnă că imaginea conține adevăr, dar verificarea a eșuat din cauza modificării imaginii sistemului. Din nou, nu putem fi siguri fără hardware în mână, dar acea eroare pare să fie cea pe care o veți vedea dacă un dispozitiv stoc a fost modificat de un software rău intenționat.

De ce este acest lucru important?

Pe Android M (6.0), root necesită în prezent modificări la imaginea kernelului, în plus față de sistemul de fișiere. Aceasta înseamnă că, chiar dacă ignorăm adevărul (cum ar fi pe un dispozitiv Nexus mai vechi, cum ar fi un Nexus 7 2013), este necesară o nouă imagine de kernel, pentru a ocoli protecțiile SELinux care împiedică funcționarea accesului root.

Dacă vrei să faci root astăzi, pe Android Marshmallow, va trebui să folosești o imagine de boot modificată.

Până acum, au fost miezuri modificate pentru a seta SELinux în modul permisiv, dar aceasta este o soluție neideală, deoarece înseamnă că nu beneficiați de beneficiile de securitate ale protecției SELinux. Și, după Emoții de scenăsaga, presupun că puteți vedea beneficiile SELinux și ale altor protecții împotriva exploatărilor de securitate.

Dezvoltator senior recunoscut XDA, Lanț de foc, master of all-things root a lansat un versiunea actualizată a SuperSU care păstrează SELinux în modul de aplicare, dar necesită încă o dată modificări la configurația SELinux a imaginii de boot. Aceasta înseamnă că trebuie să instalați SuperSU, precum și o imagine de boot modificată.

Și asta e bine și bine, până când transportatorii americani intră în amestec. Bastioanele anti-alegerea consumatorului, stăruitorii precum AT&T și Verizon sunt cunoscuți că se bucură de blocarea dispozitivelor, împiedicând utilizatorii să instaleze firmware personalizat prin blocarea bootloader-ului. Într-adevăr, Verizon este deosebit de prost în a nu transmite actualizări de firmware utilizatorilor, cu Sony Xperia Z3v nu se pregătește să primească Marshmallow în timp ce restul gamei Z3 (și într-adevăr gama Z2) va. La naiba, încă nu au lansat Lollipop pe dispozitiv, deși este disponibil pentru ceva timp (noiembrie 2014) pe Z3 obișnuit.

În loc de deblocarea neoficială a bootloader-ului (acestea sunt destul de rare în zilele noastre, fără scurgeri de bootloader de inginerie pentru câteva dispozitive Samsung), pare foarte puțin probabil. că veți obține root pe Android 6.0 fără o intervenție divină - combinația de dm-verity (pentru a opri pornirea telefonului cu orice modificări ale partiția de sistem), și cerința pentru modificările SELinux în discul ram (pentru a permite root-ului să funcționeze), pare să facă lucrurile destul de nedistractive pentru utilizatorii care aspiră la root dispozitive blocate.

Android Pay?

În sfârșit, Android Pay. Probabil că nu are nicio legătură cu restul acestui articol, dar este de fapt destul de relevant. Android Pay se bazează pe noul API-urile SafetyNet în cadrul serviciilor de proprietate Google, care este conceput pentru a furniza atestări de stare a dispozitivului care indică dacă un dispozitiv este rootat sau modificat sau rulează într-o stare neaprobată.

În timp ce există o proiect Privind răspunsurile de falsificare la SafetyNet, în prezent necesită un plugin Xposed, iar acest lucru nu pare să se schimbe, având în vedere modul în care funcționează. Xposed necesită root și face modificări partiției de sistem. Acest lucru face ca acest lucru să fie dificil de realizat pe un dispozitiv blocat cu bootloader. Chiar și atunci, lucruri de genul acesta tocmai intră într-un joc de pisică și șoarece cu Google. Cu SafetyNet, dispozitivele înrădăcinate (sau chiar dispozitivele modificate deloc) sunt privite ca „non-compatibile cu CTS”, ceea ce este un eufemism pentru dispozitivele modificate.

S-au scris mult mai multe despre SafetyNet în această postare pe blog de demontare, dar cu siguranță se pare că putem identifica anumite zone pe care Google dorește să le restrângă. În primul rând, nu le place root, Xposed și nimic care modifică partiția de sistem. În al doilea rând, se pare că Google are în vedere detectarea utilizatorilor care au activată blocarea anunțurilor - strângerea de mână SSL verifică pubads.g.doubleclick.net sugerează-mi cu siguranță că Google vrea să știe dacă blochezi reclamele pe dispozitivul tău. Având în vedere că rădăcina este de obicei o condiție prealabilă acolo, dar API-ul VPN ar putea fi folosit pentru a face asta fără root, se pare că Google cel puțin vrea să aibă o idee cine (sau câți oameni) blochează reclame. Blocarea reclamelor este o problemă de actualitate, având în vedere impulsul Apple de a o susține în browserul web (probabil pentru a încuraja oamenii să folosească mai mult aplicațiile, unde controlează experiența și pot oferi reclame neblocabile), iar aceste mișcări sunt interesant.

Concluzie

Dacă doriți să faceți root astăzi, pe Android Marshmallow (6.0), va trebui să utilizați o imagine de boot modificată. Deși rămâne de văzut dacă acest lucru rămâne valabil pe termen nelimitat, se pare că va fi cazul de ceva timp - modificările SELinux fac mult mai dificilă obținerea accesului root fără a modifica imaginea de pornire. Și deoarece modificarea imaginii de boot necesită un bootloader deblocat, acest lucru ar putea pune capăt root-ului (și Xposed și alte caracteristici root) pe dispozitivele care sunt livrate cu bootloadere care nu pot fi deblocate de utilizatorii finali. Dm-verity își face, de asemenea, apariția și pare să fie activat în modul de aplicare pe dispozitive noi. Acest lucru va face dificilă modificarea /system, chiar dacă ar fi să obțineți acces root, fără a avea din nou un bootloader deblocat.

Acest lucru vă schimbă viziunea asupra dispozitivelor blocate de bootloader? A ajuns Android-ul în stadiul în care ați cumpăra în continuare un dispozitiv blocat cu bootloader dacă operatorul dvs. v-ar oferi o ofertă bună, sau ești interesat doar de dispozitivele deblocate? Ce aplicații sau funcții rădăcină ați rata pe un bootloader blocat?

Simțiți-vă liber să vă împărtășiți gândurile în comentariile de mai jos.