Een blik op Marshmallow Root & Verity-complicaties

Terwijl het stof neerdaalt op de Android 6.0-uitgave, Nexus-gebruikers in overvloed duiken naar OTA's en Fabrieksafbeeldingenen u voorbereiden op de nieuwste versie van het Android-besturingssysteem.

Hoewel Android 6.0 van buitenaf gezien (op zijn minst visueel) opmerkelijk veel lijkt op Android 5.0 en 5.1 (de Lollipop-releases), zijn er een aantal belangrijke veranderingen aan de buitenkant. binnen. Eén van hen heeft dat mogelijk wel gevolgen voor de aangepaste ROM- en rootgemeenschappen. Eerst een beetje achtergrond. Als u hier niet in geïnteresseerd bent, ga dan naar "Waarom is dit belangrijk".

Een functie genaamd Verity

Het probleem (het is een probleem als je van rooten en het wijzigen van apparaten houdt) komt voort uit iets waar ik lang geleden op heb gewezen, toen het voor het eerst AOSP bereikte - de introductie van dm-verity naar Android. Verity is een beveiligingsfunctie, oorspronkelijk gevonden in ChromeOS, ontworpen om betrouwbare en betrouwbare computerapparatuur te bieden en te voorkomen dat schadelijke software een apparaat wijzigt. In Android 4.4 kondigde Google waarheid aan voor Android, maar daarna bleef het stil. Terwijl er wel wat zijn geweest

onderzoek naar het gebruik van waarheid, voor het grootste deel is het stil geweest. Tot nu toe, dat is.

Met Android 6.0 is Google begonnen hun spel op het gebied van apparaatbeveiliging te verbeteren. Een van de fundamentele vereisten hiervoor is dat moet worden voorkomen dat de software op een apparaat wordt gewijzigd zonder medeweten van de gebruiker – terwijl velen hier bij XDA wordt root als vanzelfsprekend beschouwd, stel je voor dat het apparaat van een gebruiker wordt geroot zonder hun medeweten of toestemming, en dat root-toegang wordt gebruikt om hun apparaat te stelen gegevens. Om deze reden is Google begonnen met het implementeren van verificatie van de systeempartitie op sommige apparaten. Ze hebben onlangs ook hun ondersteuningspagina's om dit te dekken.

Wat betekent dit voor geroote gebruikers?

Met de waarheid op zijn plaats, alle wijzigingen die in de systeempartitie worden aangebracht, worden gedetecteerd bij het opstarten of openen. U wordt dan geconfronteerd met een van de fouten zoals hierboven weergegeven. Bij sommige kunt u doorgaan, en andere willen u beschermen door te voorkomen dat het apparaat opstart. Er zijn drie staten beschikbaar. Er wordt er één weergegeven wanneer de bootloader ontgrendeld is, wat aangeeft dat je mogelijk risico loopt totdat je de bootloader opnieuw vergrendelt. Dit is het geval omdat een aangepast kernelimage de waarheid kan omzeilen, omdat de kernel-ramdisk de sleutels bevat die worden gebruikt om de systeemstatus te verifiëren.

Het ziet er nogal onplezierig uit voor root-aspirant-gebruikers op vergrendelde apparaten.

De volgende status wordt (vermoedelijk) weergegeven wanneer Verity is uitgeschakeld of uitgeschakeld, of niet kan worden gecontroleerd vanwege wijzigingen aan de ramdisk. Ik weet het niet zeker, omdat ik geen Nexus 5X of 6P heb om te onderzoeken, maar mijn vermoeden (op basis van de berichten) is dat als je een ander ROM laadt, dat vervolgens zijn eigen kernel op het apparaat plaatst, de pagina "ander besturingssysteem" dat zal doen verschijnen.

De laatste status is de rode waarschuwing dat het apparaat beschadigd is. Ik vermoed dat dit betekent dat de afbeelding de waarheid bevat, maar de verificatie is mislukt omdat de systeemafbeelding is gewijzigd. Nogmaals, we kunnen er niet zeker van zijn zonder hardware in de hand, maar het lijkt erop dat deze fout de fout is die je ziet als een standaardapparaat is gewijzigd door een stukje kwaadaardige software.

Waarom is dit belangrijk?

Op Android M (6.0) vereist root momenteel dat er naast het bestandssysteem ook wijzigingen worden aangebracht in de kernelimage. Dit betekent dat, zelfs als we de waarheid negeren (zoals op een ouder Nexus-apparaat zoals een Nexus7 2013), is een nieuw kernelimage nodig om SELinux-beveiligingen te omzeilen die voorkomen dat root-toegang werkt.

Als je vandaag nog wilt rooten, op Android Marshmallow, zul je een aangepaste opstartimage moeten gebruiken.

Tot nu toe is dat zo geweest gemodificeerde kernels om SELinux in de permissieve modus te zetten, maar dit is een niet-ideale oplossing, omdat het betekent dat je niet de veiligheidsvoordelen van SELinux bescherming krijgt. En, na de Plankenkoortssage, neem ik aan dat je de voordelen van SELinux en andere beschermingen tegen veiligheidsmisbruik kunt zien.

XDA Senior erkende ontwikkelaar, Kettingvuur, master of all-things root heeft een bijgewerkte versie van SuperSU die SELinux in de afdwingende modus behoudt, maar het vereist opnieuw dat er wijzigingen worden aangebracht in de SELinux-configuratie van het opstartimage. Dit betekent dat u SuperSU moet installeren, evenals een aangepast opstartimage.

En dat is allemaal goed en wel, totdat Amerikaanse luchtvaartmaatschappijen in de mix komen. Het is bekend dat de bastions van de anti-consumentenkeuze, zoals AT&T en Verizon, graag apparaten vergrendelen, waardoor gebruikers geen aangepaste firmware kunnen installeren via hun bootloader-vergrendelingen. Verizon is met de Sony Xperia Z3v bijzonder slecht in het niet eens doorgeven van firmware-updates aan gebruikers niet ingesteld om Marshmallow te ontvangen terwijl de rest van de Z3-reeks (en zelfs de Z2-reeks) dat wel zal doen. Ach, ze hebben Lollipop nog steeds niet eens op het apparaat uitgerold, ondanks dat het beschikbaar is een behoorlijke tijd (november 2014) op de reguliere Z3.

In plaats van een onofficiële ontgrendeling van de bootloader (die zijn tegenwoordig vrij zeldzaam, afgezien van gelekte technische bootloaders voor een paar Samsung-apparaten), lijkt het hoogst onwaarschijnlijk dat je root zult worden op Android 6.0 zonder enige goddelijke tussenkomst - de combinatie van dm-verity (om te voorkomen dat je telefoon opstart met eventuele wijzigingen aan de systeempartitie), en de vereiste voor SELinux-veranderingen in de ramdisk (om root te laten werken), lijken de zaken nogal onplezierig te maken voor root-aspirerende gebruikers van deze vergrendelde apparaten.

Android Betalen?

Eindelijk Android Pay. Het klinkt waarschijnlijk volkomen los van de rest van dit artikel, maar het is in feite redelijk relevant. Android Pay vertrouwt op het nieuwe SafetyNet-API's binnen het eigen servicesframework van Google, dat is ontworpen om apparaatstatusattesten te bieden die aangeven of een apparaat is geroot, of anderszins is aangepast of in een niet-goedgekeurde staat draait.

Terwijl er een project kijkend naar spoofing-reacties op SafetyNet, vereist het momenteel een Xposed-plug-in, en het lijkt niet waarschijnlijk dat dit zal veranderen, gezien de manier waarop het werkt. Xposed vereist root en brengt wijzigingen aan in de systeempartitie. Dat maakt dit moeilijk uit te voeren op een bootloader-vergrendeld apparaat. Zelfs dan zijn dit soort dingen slechts een kat-en-muisspel met Google. Met SafetyNet worden geroote apparaten (of überhaupt aangepaste apparaten) gezien als "niet-CTS-compatibel", wat een eufemisme is voor aangepaste apparaten.

Er is nog veel meer geschreven over SafetyNet in deze teardown-blogpost, maar het lijkt er zeker op dat we een aantal gebieden kunnen identificeren die Google wil aanpakken. Ten eerste houden ze niet van root, Xposed en alles wat de systeempartitie wijzigt. Ten tweede lijkt het erop dat Google overweegt gebruikers te detecteren waarvoor advertentieblokkering is ingeschakeld - de SSL-handshakecontroles zijn ingeschakeld pubads.g.doubleclick.net stel mij zeker voor dat Google wil weten of u advertenties op uw apparaat blokkeert. Gezien het feit dat root daar meestal een vereiste is, maar dat de VPN API hiervoor mogelijk kan worden gebruikt dit zonder root lijkt het erop dat Google in ieder geval een idee wil hebben wie (of hoeveel mensen) blokkeert advertenties. Advertentieblokkering is een actueel onderwerp gezien de druk van Apple om dit in de webbrowser te ondersteunen (misschien om dit aan te moedigen). mensen gaan meer apps gebruiken, waar ze de ervaring bepalen en niet-blokkeerbare advertenties kunnen aanbieden), en deze bewegingen zijn dat ook interessant.

Conclusie

Als je vandaag nog wilt rooten, op Android Marshmallow (6.0), zul je een aangepaste opstartimage moeten gebruiken. Hoewel het nog maar de vraag is of dit voor onbepaalde tijd waar blijft, lijkt het waarschijnlijk dat dit nog een tijdje het geval zal zijn - SELinux-veranderingen maken het veel moeilijker om root-toegang te krijgen zonder het opstartimage te wijzigen. En omdat voor het wijzigen van de opstartimage een ontgrendelde bootloader nodig is, zou dit een einde kunnen maken aan root (en Xposed en andere rootfuncties) op apparaten die worden geleverd met bootloaders die niet door eindgebruikers kunnen worden ontgrendeld. Dm-verity verschijnt ook en lijkt te zijn ingeschakeld in de afdwingingsmodus op nieuwe apparaten. Dat maakt het moeilijk om /system aan te passen, zelfs als je root-toegang zou krijgen, zonder opnieuw een ontgrendelde bootloader te hebben.

Verandert dit uw kijk op bootloader-vergrendelde apparaten? Heeft Android het stadium bereikt waarin je nog steeds een met een bootloader vergrendeld apparaat zou kopen als je provider je een goede deal zou geven?, of ben je alleen geïnteresseerd in ontgrendelde apparaten? Welke root-apps of functies zou je missen op een vergrendelde bootloader?

Deel gerust uw mening in de reacties hieronder.