Vessen egy pillantást a Marshmallow Root & Verity szövődményeire

Ahogy a por leülepszik a Android 6.0 kiadás, Nexus felhasználók bőven merülnek az OTA-k és Gyári képek, és készülünk az Android operációs rendszer legújabb iterációjára.

Míg kívülről az Android 6.0 (legalábbis vizuálisan) rendkívül hasonlónak tűnik az Android 5.0-hoz és 5.1-hez (a Lollipop kiadások), számos jelentős változás történt a belül. Egyikük potenciálisan rendelkezik az egyéni ROM és a gyökérközösségek elágazásai. Először is egy kis háttér. Ha ez nem érdekli, ugorjon a „Miért fontos ez” részhez.

A Verity nevű szolgáltatás

A probléma (a probléma, ha szereted a root és a módosító eszközöket) abból adódik, amire már régen rámutattam, amikor először elérte az AOSP-t – a dm-verity Androidra. A Verity egy biztonsági funkció, amely eredetileg a ChromeOS-ben található, és amelyet arra terveztek, hogy biztos és megbízható számítástechnikai eszközöket biztosítson, és megakadályozza, hogy a rosszindulatú szoftverek módosítsák az eszközt. Az Android 4.4-es verziójában a Google bejelentette a valódiságot az Android számára, majd minden csendes maradt. Miközben volt néhány

a valóság használatának kutatása, többnyire csendesek a dolgok. Eddig ez van.

Az Android 6.0-val a Google elkezdte javítani az eszközbiztonsággal kapcsolatos játékát. Ennek egyik alapvető követelménye, hogy az eszközön lévő szoftvert ne módosítsák a felhasználó tudta nélkül – miközben itt sokan az XDA-nál magától értetődőnek kell lennie, képzelje el, hogy egy felhasználó eszközét a felhasználó tudta vagy beleegyezése nélkül rootolják, és a root hozzáférést használják az eszköz ellopására. adat. Emiatt a Google egyes eszközökön megkezdte a rendszerpartíció ellenőrzését. Nemrég frissítették is támogatási oldalak ennek fedezésére.

Mit jelent ez a gyökeres felhasználók számára?

Igazán a helyén, a rendszerpartíción végrehajtott változtatások rendszerindításkor vagy hozzáféréskor észlelhetők. Ekkor a fent látható hibák egyikével kell szembenéznie. Egyesek lehetővé teszik a folytatást, mások pedig meg akarnak védeni azáltal, hogy leállítják az eszköz indítását. Három állam áll rendelkezésre. Az egyik akkor jelenik meg, ha a rendszerbetöltő fel van oldva, jelezve, hogy veszélyben lehet, amíg újra nem zárja a rendszertöltőt. Ez a helyzet, mivel egy módosított kernelkép megkerülheti a valódiságot, mivel a kernel ramdisk tartalmazza a rendszer állapotának ellenőrzésére használt kulcsokat.

A dolgok meglehetősen undorítónak tűnnek a root-törekvő felhasználók számára a lezárt eszközökön.

A következő állapot akkor jelenik meg (feltehetően), ha a hitelesség le van tiltva vagy ki van kapcsolva, vagy ha a ramdisk módosításai miatt nem ellenőrizhető. Nem lehetek biztos benne, mert nincs nálam Nexus 5X vagy 6P a vizsgálathoz, de a gyanúm (az üzenetek alapján) hogy ha betölt egy másik ROM-ot, amely azután a saját kernelt az eszközre helyezi, a "másik operációs rendszer" oldal megjelenik.

A végső állapot a piros figyelmeztetés, amely azt jelzi, hogy az eszköz sérült. Gyanítom, hogy ez azt jelenti, hogy a kép hitelességet tartalmaz, de az ellenőrzés meghiúsult a rendszerkép módosítása miatt. Megint nem lehetünk biztosak kézben lévő hardver nélkül, de úgy tűnik, ez az a hiba, amelyet látni fog, ha egy készleteszközt egy rosszindulatú szoftver módosított.

Ez miért fontos?

Android M (6.0) rendszeren a root jelenleg a fájlrendszeren kívül a kernelkép módosítását is megköveteli. Ez azt jelenti, hogy még ha figyelmen kívül hagyjuk is a valóságot (például egy régebbi Nexus eszközön, mint pl Nexus 7 2013), új kernelképre van szükség a SELinux védelmek megkerüléséhez, amelyek megakadályozzák a root hozzáférés működését.

Ha ma rootolni szeretne, Android Marshmallow rendszeren, akkor módosított rendszerindító lemezképet kell használnia.

Eddig is voltak módosított kernelek hogy a SELinuxot megengedő módba állítsa, de ez nem ideális megoldás, mivel ez azt jelenti, hogy nem élvezheti a SELinux védelem biztonsági előnyeit. És miután a LámpalázsagaFeltételezem, hogy láthatja a SELinux előnyeit és a biztonsági kizsákmányolásokkal szembeni egyéb védelmet.

XDA elismert vezető fejlesztő, Lánctűz, a mindenek mestere root kiadta an a SuperSU frissített verziója amely megtartja a SELinuxot kényszerítő módban, de ehhez ismét módosítani kell a rendszerindító lemezkép SELinux konfigurációját. Ez azt jelenti, hogy telepítenie kell a SuperSU-t, valamint egy módosított rendszerindító lemezképet.

És ez mind szép és jó, amíg az amerikai fuvarozók be nem lépnek a keverékbe. A fogyasztói választások elleni védekezés bástyái, az olyan ügyesek, mint az AT&T és a Verizon, köztudottan élvezik az eszközök zárolását, ami megakadályozza, hogy a felhasználók egyedi firmware-t telepítsenek a rendszerbetöltő zárakon keresztül. Valójában a Sony Xperia Z3v esetében a Verizon különösen rosszul tudja átadni a firmware-frissítéseket a felhasználóknak. nincs beállítva Marshmallow fogadására míg a Z3 tartomány többi része (és valóban a Z2 tartomány) igen. A fenébe, még mindig nem vezették be a Lollipop-ot az eszközre, annak ellenére, hogy elérhető jó ideig (2014. november) a normál Z3-ason.

A nem hivatalos rendszerbetöltő feloldás helyett (ezek manapság meglehetősen ritkák, néhány Samsung készülékhez nem számítanak ki kiszivárgott mérnöki rendszerbetöltők), nagyon valószínűtlennek tűnik hogy az Android 6.0 rendszeren minden isteni beavatkozás nélkül lesz root – a dm-verity kombinációja (hogy megakadályozza a telefon elindulását a rendszerpartíció) és a SELinux változtatásainak követelménye a ramdisken (hogy hagyja, hogy a root működjön), úgy tűnik, hogy a dolgok meglehetősen kellemetlenek a root-ra törekvő felhasználók számára. lezárt eszközök.

Android Pay?

Végül az Android Pay. Valószínűleg teljesen függetlennek tűnik a cikk többi részétől, de valójában meglehetősen releváns. Az Android Pay az újdonságra támaszkodik SafetyNet API-k a Google szabadalmaztatott szolgáltatási keretrendszerén belül, amelynek célja, hogy az eszköz állapotának igazolását nyújtsa arról, hogy az eszköz rootolt-e, vagy más módon módosítva van-e, vagy nem jóváhagyott állapotban fut-e.

Míg van a projekt A SafetyNet hamisítási válaszait tekintve jelenleg Xposed beépülő modulra van szükség, és ez nem valószínű, hogy ez megváltozik, tekintettel a működésére. Az Xposed rootot igényel, és módosítja a rendszerpartíciót. Ez megnehezíti a végrehajtást egy rendszerbetöltővel zárolt eszközön. Az ehhez hasonló dolgok még akkor is csak egy macska-egér játékba lépnek a Google-lel. A SafetyNet segítségével a rootolt eszközök (vagy egyáltalán a módosított eszközök) „nem CTS-kompatibilisnek” minősülnek, ami a módosított eszközök eufemizmusa.

Sokkal többet írtak a SafetyNetről ebben a letéphető blogbejegyzésben, de úgy tűnik, meg tudunk határozni bizonyos területeket, amelyeket a Google meg akar szüntetni. Először is, nem szeretik a root, az Xposed és a rendszerpartíció módosítását. Másodszor, úgy tűnik, a Google fontolgatja azon felhasználók észlelését, akiknél engedélyezve van a hirdetésblokkolás – az SSL kézfogás ellenőrzi pubads.g.doubleclick.net határozottan azt sugallják, hogy a Google szeretné tudni, hogy blokkolja-e a hirdetéseket az eszközén. Figyelembe véve, hogy a root általában előfeltétel, de a VPN API potenciálisan használható erre ez root nélkül, úgy tűnik, hogy a Google legalább szeretné tudni, hogy ki (vagy hány ember) blokkolja hirdetéseket. A hirdetések blokkolása aktuális probléma, mivel az Apple arra ösztönözte, hogy támogassa azt a webböngészőben (állítólag azért, hogy ösztönözze az emberek többet használnak alkalmazásokat, ahol ők irányítják az élményt, és nem blokkolható hirdetéseket kínálhatnak), és ezek a lépések érdekes.

Következtetés

Ha ma rootolni szeretne, Android Marshmallow (6.0) rendszeren, akkor módosított rendszerindító lemezképet kell használnia. Bár még látni kell, hogy ez a végtelenségig igaz marad-e, valószínűleg egy ideig így lesz – a SELinux változtatásai sokkal nehezebbé teszik a root hozzáférést a rendszerindító lemezkép módosítása nélkül. És mivel a rendszerindító kép módosításához feloldatlan rendszerbetöltőre van szükség, ez véget vethet a root (és az Xposed és egyéb gyökérfunkciók) azokon az eszközökön, amelyeket olyan rendszerbetöltővel szállítanak, amelyet a végfelhasználók nem tudnak feloldani. A Dm-verity is megjelenik, és úgy tűnik, hogy az új eszközökön kényszerítő módban engedélyezve van. Ez megnehezíti a /system módosítását, még akkor is, ha root hozzáférést szeretne szerezni anélkül, hogy újra feloldott rendszerbetöltővel rendelkezne.

Ez megváltoztatja a rendszerbetöltővel zárolt eszközök nézetét? Az Android elérte azt a szakaszt, hogy még mindig vásároljon rendszerbetöltővel zárolt eszközt, ha a szolgáltató jó ajánlatot adna, vagy csak a feloldott készülékek érdekelnek? Milyen gyökéralkalmazásokat vagy funkciókat hiányolna egy zárolt rendszerbetöltőből?

Nyugodtan ossza meg gondolatait az alábbi megjegyzésekben.