Et kig på Marshmallow Root & Verity-komplikationer

Efterhånden som støvet lægger sig på Android 6.0 udgivelse, Nexus-brugere dykker i massevis efter OTA'er og Fabriksbilleder, og gør dig klar til den seneste iteration af Android-operativsystemet.

Selvom Android 6.0 udefra (i det mindste visuelt) ser bemærkelsesværdigt ud til Android 5.0 og 5.1 (Lollipop-udgivelserne), er der en række væsentlige ændringer på inde. En af dem har potentielt konsekvenser for den brugerdefinerede ROM og root-fællesskaber. Først lidt baggrund. Hvis du ikke er interesseret i dette, skal du bare springe ned til "Hvorfor er det vigtigt".

En funktion kaldet Verity

Problemet (det er et problem, hvis du kan lide root og ændring af enheder) stammer fra noget, jeg påpegede for lang tid siden, da det først ramte AOSP - introduktionen af dm-verity til Android. Verity er en sikkerhedsfunktion, der oprindeligt blev fundet i ChromeOS, designet til at give sikre og troværdige computerenheder, der forhindrer skadelig software i at ændre en enhed. Tilbage i Android 4.4 annoncerede Google verity for Android, og så forblev alt stille. Mens der har været nogle

forskning i brug af sandhed, for det meste har tingene været stille. Indtil nu, altså.

Med Android 6.0 er Google begyndt at forbedre deres spil på enhedssikkerhed. Et af de grundlæggende krav til dette er at forhindre softwaren på en enhed i at blive ændret uden en brugers viden - mens mange her hos XDA slå rod for givet, forestil dig, at en brugers enhed bliver rootet uden deres viden eller samtykke, og root-adgang bliver brugt til at stjæle deres data. Af denne grund er Google begyndt at implementere verifikation af systempartitionen på nogle enheder. De har også for nylig opdateret deres support sider at dække dette.

Hvad betyder dette for rodfæstede brugere?

Med sandheden på plads, eventuelle ændringer i systempartitionen vil blive opdaget ved opstart eller adgang. Du vil derefter blive konfronteret med en af ​​fejlene som vist ovenfor. Nogle giver dig mulighed for at fortsætte, og nogle vil beskytte dig ved at forhindre enheden i at starte. Der er tre tilgængelige stater. Den ene vises, når bootloaderen er låst op, hvilket indikerer, at du kan være i fare, indtil du låser bootloaderen igen. Dette er tilfældet, da et ændret kernebillede kan omgå verity, da kernens ramdisk indeholder de nøgler, der bruges til at verificere et systems tilstand.

Tingene ser ret usjove ud for root-aspirerende brugere på låste enheder.

Den næste tilstand vises (formodentlig), når verity er deaktiveret eller deaktiveret, eller kan ikke kontrolleres på grund af ændringer af ramdisken. Jeg kan ikke være sikker på grund af min mangel på en Nexus 5X eller 6P at undersøge, men min mistanke (baseret på meddelelserne) er at hvis du indlæser en anden ROM, som derefter placerer sin egen kerne på enheden, vil siden "andet operativsystem" komme til syne.

Den endelige tilstand er den røde advarsel, der angiver, at enheden er korrupt. Jeg formoder, at dette betyder, at billedet indeholder sandhed, men verifikationen mislykkedes på grund af, at systembilledet blev ændret. Igen, vi kan ikke være sikre uden hardware i hånden, men den fejl ser ud til at være den, du vil se, hvis en standardenhed blev ændret af et stykke ondsindet software.

Hvorfor er dette vigtigt?

På Android M (6.0) kræver root i øjeblikket, at der foretages ændringer af kernebilledet ud over filsystemet. Dette betyder, at selvom vi ignorerer sandhed (såsom på en ældre Nexus-enhed som en Nexus 7 2013), er et nyt kernebillede nødvendigt for at omgå SELinux-beskyttelser, der forhindrer root-adgang i at virke.

Hvis du vil have root i dag, på Android Marshmallow, bliver du nødt til at bruge et ændret opstartsbillede.

Indtil nu har der været modificerede kerner at sætte SELinux i permissive mode, men dette er en ikke-ideel løsning, da det betyder, at du ikke får sikkerhedsfordelene ved SELinux-beskyttelse. Og efter Sceneskræksaga, Jeg antager, at du kan se fordelene ved SELinux og andre beskyttelser mod sikkerhedsudnyttelse.

XDA Senior anerkendt udvikler, Kædebål, master of all-things root har udgivet en opdateret version af SuperSU som bevarer SELinux i håndhævelsestilstand, men det kræver endnu en gang, at der skal foretages ændringer i SELinux-konfigurationen af ​​opstartsbilledet. Det betyder, at du skal installere SuperSU samt et ændret boot-image.

Og det er alt godt, indtil amerikanske luftfartsselskaber går ind i blandingen. Bastionerne af anti-forbruger-valg, de trofaste som AT&T og Verizon er kendt for at nyde at låse enheder ned, hvilket forhindrer brugere i at installere tilpasset firmware gennem deres bootloader-låse. Faktisk er Verizon særligt dårlige til ikke engang at videregive firmwareopdateringer til brugerne med Sony Xperia Z3v ikke indstillet til at modtage Marshmallow mens resten af ​​Z3-serien (og faktisk Z2-serien) vil. For pokker, de har stadig ikke engang rullet Lollipop ud til enheden, selvom den er tilgængelig for ret lang tid (november 2014) på ​​den almindelige Z3.

I stedet for en uofficiel oplåsning af bootloader (de er temmelig sjældne i disse dage, bortset fra lækkede tekniske bootloadere til nogle få Samsung-enheder), virker det meget usandsynligt at du får root på Android 6.0 uden nogen guddommelig indgriben - kombinationen af ​​dm-verity (for at forhindre din telefon i at starte med eventuelle ændringer af systempartition), og kravet om SELinux-ændringer i ramdisken (for at lade root arbejde), ser ud til at gøre tingene ret usjove for root-aspirerende brugere af disse aflåste enheder.

Android Pay?

Endelig Android Pay. Det lyder nok helt uden relation til resten af ​​denne artikel, men det er faktisk ret relevant. Android Pay er afhængig af det nye SafetyNet API'er inden for Googles proprietære tjenesterramme, som er designet til at give enhedstilstandsattestationer om, hvorvidt en enhed er rootet, eller på anden måde ændret eller kører i en ikke-godkendt tilstand.

Mens der er en projekt ser på spoofing-svar til SafetyNet, kræver det i øjeblikket et Xposed-plugin, og dette ser ikke ud til at ændre sig, givet hvordan det fungerer. Xposed kræver root og foretager ændringer af systempartitionen. Det gør dette svært at udføre på en bootloader-låst enhed. Selv da er ting som dette bare ved at gå ind i et spil kat-og-mus med Google. Med SafetyNet bliver rodfæstede enheder (eller faktisk enheder modificeret i det hele taget) betragtet som "ikke-CTS-kompatible", hvilket er en eufemisme for modificerede enheder.

Der er skrevet meget mere om SafetyNet i dette nedrivningsblogindlæg, men det ser bestemt ud til, at vi kan identificere nogle områder, Google ønsker at slå ned på. For det første kan de ikke lide root, Xposed og noget, der ændrer systempartitionen. For det andet ser det ud til, at Google overvejer at opdage brugere, der har annonceblokering aktiveret - SSL-håndtrykket tjekker pubads.g.doubleclick.net foreslå mig bestemt, at Google vil vide, om du blokerer annoncer på din enhed. I betragtning af at root normalt er en forudsætning der, men at VPN API potentielt kan bruges til at gøre det dette uden root, ser det ud til, at Google i det mindste vil have en idé om, hvem (eller hvor mange personer) der blokerer annoncer. Annonceblokering er et aktuelt problem givet presset fra Apple til at understøtte det i webbrowseren (sandsynligvis for at opmuntre folk til at bruge apps mere, hvor de kontrollerer oplevelsen og kan tilbyde ikke-blokerbare annoncer), og disse træk er interessant.

Konklusion

Hvis du vil have root i dag, på Android Marshmallow (6.0), bliver du nødt til at bruge et ændret opstartsbillede. Selvom det stadig skal ses, om dette forbliver sandt på ubestemt tid, ser det ud til at være tilfældet i nogen tid - SELinux-ændringer gør det meget sværere at få root-adgang uden at ændre opstartsbilledet. Og da ændring af opstartsbilledet kræver en ulåst bootloader, kan dette sætte en stopper for root (og Xposed og andre root-funktioner) på enheder, der leveres med bootloadere, som ikke kan låses op af slutbrugere. Dm-verity dukker også op, og den ser ud til at være aktiveret i håndhævelsestilstand på nye enheder. Det vil gøre det svært at ændre /system, selvom du skulle få root-adgang, uden igen at have en ulåst bootloader.

Ændrer dette dit syn på bootloader-låste enheder? Har Android nået det stadie, hvor du stadig ville købe en bootloader-låst enhed, hvis din udbyder gav dig et godt tilbud, eller er du kun interesseret i ulåste enheder? Hvilke root apps eller funktioner ville du savne på en låst bootloader?

Du er velkommen til at dele dine tanker i kommentarerne nedenfor.