Lær om de nyere komplikasjonene som verity og Marshmallow fører med seg til å roote låste enheter.
Når støvet legger seg på Android 6.0 utgivelse, Nexus-brukere i massevis dykker etter OTA-er og Fabrikkbilder, og gjør deg klar for den siste iterasjonen av Android-operativsystemet.
Mens Android 6.0 fra utsiden fremstår (i det minste visuelt) bemerkelsesverdig lik Android 5.0 og 5.1 (Lollipop-utgivelsene), er det en rekke betydelige endringer på innsiden. En av dem har potensielt konsekvenser for tilpassede ROM- og rotfellesskap. Først litt bakgrunn. Hvis du ikke er interessert i dette, hopper du bare ned til "Hvorfor er dette viktig".
En funksjon kalt Verity
Problemet (det er et problem hvis du liker root- og modifiseringsenheter) stammer fra noe jeg påpekte for lenge siden, da det først traff AOSP - introduksjonen av dm-verity til Android. Verity er en sikkerhetsfunksjon, opprinnelig funnet i ChromeOS, designet for å gi trygge og pålitelige dataenheter, og forhindrer skadelig programvare i å endre en enhet. Tilbake i Android 4.4 annonserte Google verity for Android, og så forble alt stille. Mens det har vært noen
Med Android 6.0 har Google begynt å forbedre spillet sitt på enhetssikkerhet. Et av de grunnleggende kravene til dette er å forhindre at programvaren på en enhet kan endres uten brukerens viten – mens mange her på XDA slår rot for gitt, forestill deg at en brukers enhet blir rootet uten deres viten eller samtykke, og root-tilgang brukes til å stjele deres data. Av denne grunn har Google begynt å implementere verifisering av systempartisjonen på enkelte enheter. De har også nylig oppdatert sine støttesider for å dekke dette.
Hva betyr dette for rotfestede brukere?
Med sannheten på plass, eventuelle endringer som gjøres i systempartisjonen vil bli oppdaget ved oppstart eller tilgang. Du vil da bli møtt med en av feilene som vist ovenfor. Noen lar deg fortsette, og noen vil beskytte deg ved å stoppe enheten fra å starte opp. Det er tre tilgjengelige stater. En vises når oppstartslasteren er låst opp, noe som indikerer at du kan være i faresonen til du låser oppstartslasteren på nytt. Dette er tilfelle siden et modifisert kjernebilde kan omgå verity, siden kjernens ramdisk inneholder nøklene som brukes til å verifisere et systems tilstand.
Ting ser ganske u-morsomt ut for root-aspirerende brukere på låste enheter.
Den neste tilstanden vises (antagelig) når verity er deaktivert eller av, eller ikke kan sjekkes på grunn av modifikasjoner på ramdisken. Jeg kan ikke være sikker på grunn av mangelen på en Nexus 5X eller 6P å undersøke, men min mistanke (basert på meldingene) er at hvis du laster en annen ROM, som deretter plasserer sin egen kjerne på enheten, vil siden "annet operativsystem" vises.
Den endelige tilstanden er den røde advarselen som sier at enheten er korrupt. Jeg mistenker at dette betyr at bildet inneholder sannhet, men verifiseringen mislyktes på grunn av at systembildet ble endret. Igjen, vi kan ikke være sikre uten maskinvare i hånden, men den feilen ser ut til å være den du vil se hvis en lagerenhet ble modifisert av et stykke skadelig programvare.
Hvorfor er dette viktig?
På Android M (6.0) krever root for øyeblikket endringer i kjernebildet, i tillegg til filsystemet. Dette betyr at selv om vi ignorerer sannheten (for eksempel på en eldre Nexus-enhet som en Nexus 7 2013), er det nødvendig med et nytt kjernebilde for å omgå SELinux-beskyttelse som hindrer root-tilgang i å fungere.
Hvis du vil ha root i dag, på Android Marshmallow, må du bruke et modifisert oppstartsbilde.
Inntil nå har det vært modifiserte kjerner å sette SELinux i permissiv modus, men dette er en ikke-ideell løsning, siden det betyr at du ikke får sikkerhetsfordelene med SELinux-beskyttelse. Og etter Sceneskrekksaga, Jeg antar at du kan se fordelene med SELinux og annen beskyttelse mot sikkerhetsutnyttelser.
XDA senior anerkjent utvikler, Kjedebrann, master of all-things root har gitt ut en oppdatert versjon av SuperSU som beholder SELinux i håndhevingsmodus, men det krever nok en gang endringer i SELinux-konfigurasjonen til oppstartsbildet. Dette betyr at du må installere SuperSU, samt et modifisert oppstartsbilde.
Og det er vel og bra, til amerikanske transportører går inn i blandingen. Bastionene av anti-forbruker-valg, de trofaste som AT&T og Verizon er kjent for å ha glede av å låse ned enheter, og hindre brukere i å installere tilpasset firmware gjennom deres bootloader-låser. Faktisk er Verizon spesielt dårlige til ikke engang å sende fastvareoppdateringer til brukere, med Sony Xperia Z3v ikke satt til å motta Marshmallow mens resten av Z3-serien (og faktisk Z2-serien) vil. Pokker, de har fortsatt ikke engang rullet ut Lollipop til enheten, til tross for at den er tilgjengelig for ganske lang tid (november 2014) på den vanlige Z3.
I stedet for en uoffisiell opplåsing av bootloader (de er ganske sjeldne i disse dager, med unntak av lekkede tekniske bootloadere for noen få Samsung-enheter), virker det svært usannsynlig at du får root på Android 6.0 uten noen guddommelig inngripen - kombinasjonen av dm-verity (for å stoppe telefonen fra å starte opp med eventuelle modifikasjoner av systempartisjon), og kravet om SELinux-endringer i ramdisken (for å la root fungere), ser ut til å gjøre ting ganske lite morsomt for root-aspirerende brukere av disse låste enheter.
Android Pay?
Til slutt, Android Pay. Det høres nok helt urelatert ut med resten av denne artikkelen, men det er faktisk ganske relevant. Android Pay er avhengig av det nye SafetyNet APIer innenfor Googles proprietære tjenesterrammeverk, som er utformet for å gi enhetsstatusattester om hvorvidt en enhet er rootet, eller på annen måte modifisert eller kjører i en ikke-godkjent tilstand.
Mens det er en prosjekt ser på spoofing-svar til SafetyNet, krever det for øyeblikket en Xposed-plugin, og dette ser ikke ut til å endre seg, gitt hvordan det fungerer. Xposed krever root, og gjør endringer i systempartisjonen. Det gjør dette vanskelig å utføre på en bootloader-låst enhet. Selv da går ting som dette bare inn i et katt-og-mus-spill med Google. Med SafetyNet blir rotfestede enheter (eller faktisk enheter modifisert i det hele tatt), sett på som "ikke-CTS-kompatible", som er en eufemisme for modifiserte enheter.
Det er mye mer skrevet om SafetyNet i dette blogginnlegget, men det ser absolutt ut til at vi kan identifisere noen områder Google ønsker å slå ned på. For det første liker de ikke root, Xposed og alt som endrer systempartisjonen. For det andre ser det ut til at Google vurderer å oppdage brukere som har annonseblokkering aktivert – SSL-håndtrykket sjekker pubads.g.doubleclick.net foreslå for meg at Google vil vite om du blokkerer annonser på enheten din. Tatt i betraktning at root vanligvis er en forutsetning der, men at VPN API potensielt kan brukes til å gjøre det dette uten root, ser det ut som at Google i det minste ønsker å ha en idé om hvem (eller hvor mange personer) som blokkerer annonser. Annonseblokkering er et aktuelt problem gitt presset fra Apple for å støtte det i nettleseren (uten tvil for å oppmuntre folk til å bruke apper mer, der de kontrollerer opplevelsen og kan tilby ikke-blokkerbare annonser), og disse grepene er interessant.
Konklusjon
Hvis du vil ha root i dag, på Android Marshmallow (6.0), må du bruke et modifisert oppstartsbilde. Selv om det gjenstår å se om dette forblir sant på ubestemt tid, ser det ut til at det vil være tilfelle en stund - SELinux-endringer gjør det mye vanskeligere å få root-tilgang uten å endre oppstartsbildet. Og ettersom endring av oppstartsbildet krever en ulåst oppstartslaster, kan dette sette en stopper for root (og Xposed og andre rotfunksjoner) på enheter som leveres med oppstartslastere som ikke kan låses opp av sluttbrukere. Dm-verity dukker også opp, og den ser ut til å være aktivert i håndhevingsmodus på nye enheter. Det vil gjøre det vanskelig å endre /system, selv om du skulle få root-tilgang, uten igjen å ha en ulåst oppstartslaster.
Endrer dette synet ditt på oppstartslasterlåste enheter? Har Android nådd et stadium hvor du fortsatt ville kjøpt en oppstartslasterlåst enhet hvis operatøren din ga deg en god avtale, eller er du bare interessert i ulåste enheter? Hvilke rotapper eller funksjoner ville du savnet på en låst oppstartslaster?
Del gjerne tankene dine i kommentarene nedenfor.