Lär dig om de nyare komplikationerna som verity och Marshmallow medför för att rota låsta enheter.
När dammet lägger sig på Android 6.0 version, Nexus-användare i överflöd dyker efter OTAs och Fabriksbilder, och gör dig redo för den senaste versionen av Android-operativsystemet.
Även om Android 6.0 från utsidan verkar (åtminstone visuellt) anmärkningsvärt likt Android 5.0 och 5.1 (Lollipop-versionerna), finns det ett antal betydande förändringar på inuti. En av dem har potentiellt förgreningar för de anpassade ROM- och rotgemenskaperna. Först lite bakgrund. Om du inte är intresserad av detta, hoppa bara ner till "Varför är detta viktigt".
En funktion som kallas Verity
Problemet (det är ett problem om du gillar root och modifiering av enheter) härrör från något jag påpekade för länge sedan, när det först träffade AOSP - introduktionen av dm-verity till Android. Verity är en säkerhetsfunktion, som ursprungligen finns i ChromeOS, utformad för att tillhandahålla säkra och pålitliga datorenheter, som förhindrar skadlig programvara från att modifiera en enhet. Tillbaka i Android 4.4 tillkännagav Google verity för Android, och sedan förblev allt tyst. Medan det har varit några
forskning om att använda sanning, för det mesta har det varit tyst. Fram till nu, alltså.Med Android 6.0 har Google börjat förbättra sitt spel på enhetssäkerhet. Ett av de grundläggande kraven för detta är att förhindra att programvaran på en enhet modifieras utan användarens vetskap – medan många här på XDA slå rot för givet, föreställ dig att en användares enhet rootas utan deras vetskap eller samtycke, och root-åtkomst används för att stjäla deras data. Av denna anledning har Google börjat implementera verifiering av systempartitionen på vissa enheter. De har också nyligen uppdaterat sina supportsidor för att täcka detta.
Vad betyder detta för rotade användare?
Med sanningen på plats, alla ändringar som görs i systempartitionen kommer att upptäckas vid uppstart eller åtkomst. Du kommer då att ställas inför ett av felen som visas ovan. Vissa låter dig fortsätta, och vissa vill skydda dig genom att stoppa enheten från att starta. Det finns tre tillgängliga stater. En visas när starthanteraren är upplåst, vilket indikerar att du kan vara i riskzonen tills du låser starthanteraren igen. Detta är fallet eftersom en modifierad kärnavbildning kan kringgå verity, eftersom kärnans ramdisk innehåller nycklarna som används för att verifiera ett systems tillstånd.
Saker och ting ser ganska olustiga ut för root-aspirerande användare på låsta enheter.
Nästa tillstånd visas (förmodligen) när verity är inaktiverat eller avstängt, eller inte kan kontrolleras på grund av modifieringar av ramdisken. Jag kan inte vara säker på grund av min brist på en Nexus 5X eller 6P att undersöka, men min misstanke (baserat på meddelandena) är att om du laddar en annan ROM, som sedan placerar sin egen kärna på enheten, kommer sidan "annat operativsystem" dyka upp.
Det slutliga tillståndet är den röda varningen som säger att enheten är korrupt. Jag misstänker att detta betyder att bilden innehåller sanning, men verifieringen misslyckades på grund av att systembilden modifierades. Återigen, vi kan inte vara säkra utan hårdvara i handen, men det felet ser ut att vara det du kommer att se om en standardenhet modifierades av en skadlig programvara.
Varför är detta viktigt?
På Android M (6.0) kräver root för närvarande ändringar i kärnavbildningen, förutom filsystemet. Detta betyder att även om vi ignorerar sanning (som på en äldre Nexus-enhet som en Nexus 7 2013), behövs en ny kärnavbildning för att kringgå SELinux-skydd som förhindrar root-åtkomst från att fungera.
Om du vill ha root idag, på Android Marshmallow, kommer du att behöva använda en modifierad startavbildning.
Fram till nu har det funnits modifierade kärnor för att ställa in SELinux i tillåtande läge, men detta är en icke-ideal fix, eftersom det innebär att du inte får säkerhetsfördelarna med SELinux-skydd. Och efter Scenskräcksaga, jag antar att du kan se fördelarna med SELinux och andra skydd mot säkerhetsexploater.
XDA Senior Recognized Developer, Kedjeeld, master of all-things root har släppt en uppdaterad version av SuperSU som behåller SELinux i upprätthållande läge, men det kräver återigen att ändringar görs i SELinux-konfigurationen av startavbildningen. Det betyder att du måste installera SuperSU, samt en modifierad startavbildning.
Och det är väl och bra, tills amerikanska flygbolag går in i mixen. Bastionerna av anti-konsumentval, de ståndaktiga som AT&T och Verizon är kända för att njuta av att låsa ner enheter, vilket hindrar användare från att installera anpassad firmware genom sina bootloader-lås. Verizon är faktiskt särskilt dåliga på att inte ens skicka firmwareuppdateringar till användarna, med Sony Xperia Z3v inte inställd på att ta emot Marshmallow medan resten av Z3-intervallet (och faktiskt Z2-intervallet) kommer att göra det. Heck, de har fortfarande inte ens rullat ut Lollipop till enheten, trots att den är tillgänglig för en bra stund (november 2014) på vanliga Z3.
I stället för en inofficiell upplåsning av bootloader (de är ganska sällsynta nuförtiden, med undantag för läckta tekniska bootloaders för några Samsung-enheter), verkar det mycket osannolikt att du kommer att få root på Android 6.0 utan något gudomligt ingripande - kombinationen av dm-verity (för att stoppa din telefon från att starta med några modifieringar av systempartition), och kravet på SELinux-ändringar i ramdisken (för att låta root fungera), ser ut att göra saker och ting ganska olustiga för root-aspirerande användare av dessa låsta enheter.
Android Pay?
Slutligen, Android Pay. Det låter förmodligen helt orelaterade till resten av den här artikeln, men det är faktiskt ganska relevant. Android Pay förlitar sig på det nya SafetyNet API: er inom Googles proprietära tjänsterramverk, som är utformat för att tillhandahålla enhetstillståndsbekräftelser om huruvida en enhet är rootad, eller på annat sätt modifierad eller körs i ett ej godkänt tillstånd.
Medan det finns en projekt när man tittar på spoofingssvar till SafetyNet, kräver det för närvarande ett Xposed-plugin, och det ser inte ut att förändras med tanke på hur det fungerar. Xposed kräver root och gör ändringar i systempartitionen. Det gör detta svårt att utföra på en bootloader-låst enhet. Även då börjar saker som detta bara gå in i ett katt-och-råtta-spel med Google. Med SafetyNet ses rotade enheter (eller faktiskt enheter modifierade överhuvudtaget) som "icke-CTS-kompatibla", vilket är en eufemism för modifierade enheter.
Det finns mycket mer skrivet om SafetyNet i detta rivningsblogginlägg, men det verkar verkligen som att vi kan identifiera några områden som Google vill slå fast. För det första gillar de inte root, Xposed och allt som modifierar systempartitionen. För det andra verkar det som att Google överväger att upptäcka användare som har aktiverat annonsblockering - SSL-handskakningen kontrollerar pubads.g.doubleclick.net Jag föreslår verkligen att Google vill veta om du blockerar annonser på din enhet. Med tanke på att root vanligtvis är en förutsättning där, men att VPN API potentiellt kan användas för att göra det detta utan root, det ser ut som att Google åtminstone vill ha en uppfattning om vem (eller hur många personer) som blockerar annonser. Annonsblockering är en aktuell fråga med tanke på pressen från Apple att stödja det i webbläsaren (förmodligen för att uppmuntra människor att använda appar mer, där de kontrollerar upplevelsen och kan erbjuda icke-blockerbara annonser), och dessa drag är intressant.
Slutsats
Om du vill ha root idag, på Android Marshmallow (6.0), kommer du att behöva använda en modifierad startavbildning. Även om det återstår att se om detta förblir sant på obestämd tid, ser det troligt ut att vara fallet under en tid - SELinux-ändringar gör det mycket svårare att få root-åtkomst utan att modifiera startavbildningen. Och eftersom modifiering av startavbildningen kräver en olåst starthanterare, kan detta sätta stopp för root (och Xposed och andra rotfunktioner) på enheter som levereras med starthanterare som inte kan låsas upp av slutanvändare. Dm-verity dyker också upp och den verkar vara aktiverad i upprätthållande läge på nya enheter. Det kommer att göra det svårt att ändra /system, även om du skulle få root-åtkomst, utan att återigen ha en olåst starthanterare.
Ändrar detta din syn på låsta enheter med bootloader? Har Android nått det stadium att du fortfarande skulle köpa en bootloader-låst enhet om din operatör gav dig en bra deal, eller är du bara intresserad av olåsta enheter? Vilka rotappar eller funktioner skulle du missa på en låst bootloader?
Dela gärna dina tankar i kommentarerna nedan.