Spojrzenie na powikłania związane z korzeniem prawoślazu i prawdziwością

Gdy kurz opadnie na Wersja Androida 6.0, użytkownicy Nexusa chętnie korzystają z OTA i Obrazy fabrycznei przygotowanie się do najnowszej wersji systemu operacyjnego Android.

Choć z zewnątrz Android 6.0 wydaje się (przynajmniej wizualnie) niezwykle podobny do Androida 5.0 i 5.1 (wydania Lollipop), wprowadzono szereg znaczących zmian w wewnątrz. Jeden z nich potencjalnie ma konsekwencje dla niestandardowej pamięci ROM i społeczności root. Najpierw trochę tła. Jeśli Cię to nie interesuje, po prostu przejdź do sekcji „Dlaczego jest to ważne”.

Funkcja zwana prawdą

Problem (jest to problem, jeśli lubisz rootować i modyfikować urządzenia) wynika z czegoś, na co zwróciłem uwagę dawno temu, kiedy po raz pierwszy trafiło na AOSP - wprowadzenie dm-verity na Androida. Verity to funkcja zabezpieczeń, pierwotnie dostępna w systemie ChromeOS, zaprojektowana w celu zapewnienia bezpiecznych i godnych zaufania urządzeń komputerowych, zapobiegając modyfikowaniu urządzenia przez złośliwe oprogramowanie. Wracając do Androida 4.4, Google ogłosił prawdę dla Androida, a potem wszystko ucichło. Choć było ich trochę

badania nad wykorzystaniem prawdyw większości było spokojnie. To znaczy do tej pory.

Wraz z wprowadzeniem Androida 6.0 firma Google zaczęła ulepszać swoje działania w zakresie bezpieczeństwa urządzeń. Jednym z podstawowych wymagań w tym zakresie jest zapobieganie modyfikowaniu oprogramowania urządzenia bez wiedzy użytkownika – podczas gdy wiele osób tutaj na XDA traktuj rootowanie jako coś oczywistego, wyobraź sobie, że urządzenie użytkownika jest zrootowane bez jego wiedzy i zgody, a dostęp roota jest wykorzystywany do kradzieży dane. Z tego powodu Google zaczął wdrażać weryfikację partycji systemowej na niektórych urządzeniach. Niedawno zaktualizowali także swoje strony wsparcia żeby to zakryć.

Co to oznacza dla użytkowników zrootowanych?

Z prawdą na miejscu, wszelkie zmiany dokonane na partycji systemowej zostaną wykryte podczas rozruchu lub dostępu. Następnie napotkasz jeden z błędów opisanych powyżej. Niektóre pozwalają kontynuować, a inne chcą Cię chronić, uniemożliwiając uruchomienie urządzenia. Dostępne są trzy stany. Jeden z nich jest wyświetlany, gdy program ładujący jest odblokowany, co oznacza, że ​​możesz być narażony na ryzyko, dopóki ponownie nie zablokujesz programu ładującego. Dzieje się tak, ponieważ zmodyfikowany obraz jądra może ominąć prawdziwość, ponieważ ramdysk jądra zawiera klucze używane do weryfikacji stanu systemu.

Sprawy wyglądają raczej niezbyt zabawnie dla użytkowników aspirujących do rootowania na zablokowanych urządzeniach.

Następny stan jest pokazywany (prawdopodobnie), gdy weryfikacja jest wyłączona lub wyłączona, lub gdy nie można go sprawdzić z powodu modyfikacji ramdysku. Nie jestem pewien, ponieważ nie mam Nexusa 5X lub 6P do sprawdzenia, ale moje podejrzenia (oparte na wiadomościach) są takie, że że jeśli załadujesz inną pamięć ROM, która następnie umieści własne jądro na urządzeniu, wyświetli się strona „inny system operacyjny”. pojawić się.

Ostatnim stanem jest czerwone ostrzeżenie informujące, że urządzenie jest uszkodzone. Podejrzewam, że oznacza to, że obraz zawiera prawdę, ale weryfikacja nie powiodła się z powodu modyfikacji obrazu systemu. Ponownie, nie możemy być tego pewni, jeśli nie mamy pod ręką sprzętu, ale wygląda na to, że ten błąd będzie tym, który zobaczysz, jeśli standardowe urządzenie zostało zmodyfikowane przez złośliwy program.

Dlaczego to jest ważne?

W systemie Android M (6.0) root wymaga obecnie modyfikacji obrazu jądra, oprócz systemu plików. Oznacza to, że nawet jeśli zignorujemy prawdziwość (na przykład na starszym urządzeniu Nexus, np Nexusa 7 2013), potrzebny jest nowy obraz jądra, aby ominąć zabezpieczenia SELinux, które uniemożliwiają działanie dostępu roota.

Jeśli chcesz mieć roota już dziś, na Androidzie Marshmallow będziesz musiał użyć zmodyfikowanego obrazu rozruchowego.

Do tej pory były zmodyfikowane jądra aby ustawić SELinux w tryb zezwalający, ale nie jest to idealne rozwiązanie, ponieważ oznacza, że ​​nie uzyskasz korzyści związanych z bezpieczeństwem ochrony SELinux. I po Tremasaga, zakładam, że widzisz zalety SELinuksa i innych zabezpieczeń przed exploitami bezpieczeństwa.

Starszy uznany programista XDA, Łańcuchowy Ogień, mistrz wszechrzeczy root wydał plik zaktualizowana wersja SuperSU który zachowuje SELinux w trybie wymuszania, ale ponownie wymaga wprowadzenia modyfikacji w konfiguracji SELinux w obrazie startowym. Oznacza to, że musisz zainstalować SuperSU, a także zmodyfikowany obraz rozruchowy.

I to wszystko dobrze, do czasu, aż dołączą do nich przewoźnicy amerykańscy. Bastiony sprzeciwu wobec wyborów konsumenckich, niezłomni gracze, tacy jak AT&T i Verizon, lubią blokować urządzenia, uniemożliwiając użytkownikom instalowanie niestandardowego oprogramowania sprzętowego za pomocą blokad programu ładującego. Rzeczywiście, Verizon szczególnie słabo radzi sobie nawet z nieprzekazywaniem użytkownikom aktualizacji oprogramowania sprzętowego w przypadku Sony Xperia Z3v nie ustawiono odbioru Marshmallow podczas gdy reszta gamy Z3 (i rzeczywiście seria Z2) tak. Cholera, nadal nawet nie wdrożyli Lollipopa na urządzeniu, mimo że jest on dostępny jakiś czas (listopad 2014) na zwykłym Z3.

Zamiast nieoficjalnego odblokowania bootloadera (jest to obecnie dość rzadkie zjawisko, z wyjątkiem wyciekających inżynieryjnych bootloaderów dla kilku urządzeń Samsunga), wydaje się to wysoce nieprawdopodobne że będziesz mieć roota na Androidzie 6.0 bez jakiejś boskiej interwencji - kombinacji dm-verity (aby uniemożliwić uruchomienie telefonu po jakichkolwiek modyfikacjach partycja systemowa) i wymóg zmian SELinux w ramdysku (aby pozwolić rootowi działać), wyglądają na ustawione tak, aby było to raczej mało zabawne dla użytkowników tych komputerów aspirujących do rootowania zablokowane urządzenia.

Android Pay?

Wreszcie Android Pay. Prawdopodobnie brzmi to zupełnie niezwiązane z resztą tego artykułu, ale w rzeczywistości jest dość istotne. Android Pay stawia na nowość Interfejsy API SafetyNet w ramach zastrzeżonych usług Google, których zadaniem jest dostarczanie atestów stanu urządzenia potwierdzających, czy jest ono zrootowane, w inny sposób zmodyfikowane lub działa w niezatwierdzonym stanie.

Chociaż istnieje projekt patrząc na fałszywe odpowiedzi w SafetyNet, obecnie wymaga ona wtyczki Xposed i nie wygląda na to, aby to się zmieniło, biorąc pod uwagę sposób jej działania. Xposed wymaga roota i dokonuje modyfikacji partycji systemowej. To sprawia, że ​​jest to trudne do przeprowadzenia na urządzeniu z zablokowanym bootloaderem. Nawet wtedy takie rzeczy to dopiero zabawa w kotka i myszkę z Google. Dzięki SafetyNet zrootowane urządzenia (lub w ogóle urządzenia zmodyfikowane) są postrzegane jako „niezgodne z CTS”, co jest eufemizmem określającym zmodyfikowane urządzenia.

O SafetyNet napisano znacznie więcej w tym porzuconym poście na blogu, ale z pewnością wydaje się, że możemy zidentyfikować obszary, które Google chce ograniczyć. Po pierwsze, nie lubią rootowania, Xposed i czegokolwiek modyfikującego partycję systemową. Po drugie, wygląda na to, że Google rozważa wykrycie użytkowników, którzy mają włączone blokowanie reklam – sprawdzanie uzgadniania SSL jest włączone pubads.g.doubleclick.net z pewnością zasugeruj mi, że Google chce wiedzieć, czy blokujesz reklamy na swoim urządzeniu. Biorąc pod uwagę, że root jest tam zwykle warunkiem wstępnym, ale potencjalnie można do tego wykorzystać interfejs API VPN to bez rootowania, wygląda na to, że Google przynajmniej chce mieć pojęcie, kto (lub ile osób) blokuje reklamy. Blokowanie reklam to aktualny problem, biorąc pod uwagę naciski firmy Apple na obsługę tej funkcji w przeglądarce internetowej (prawdopodobnie w celu zachęcenia ludzie będą częściej korzystać z aplikacji, w których kontrolują ich działanie i mogą oferować reklamy, których nie można blokować) i te posunięcia są ciekawy.

Wniosek

Jeśli chcesz mieć roota już dziś, na Androidzie Marshmallow (6.0) będziesz musiał użyć zmodyfikowanego obrazu rozruchowego. Czas pokaże, czy tak będzie w nieskończoność, ale wygląda na to, że tak będzie przez jakiś czas – zmiany w SELinux znacznie utrudniają uzyskanie dostępu do konta root bez modyfikowania obrazu rozruchowego. A ponieważ modyfikacja obrazu rozruchowego wymaga odblokowanego programu ładującego, może to położyć kres rootowaniu (i Xposed i inne funkcje roota) na urządzeniach dostarczanych z programami ładującymi, których użytkownicy końcowi nie mogą odblokować. Pojawia się także Dm-verity, który wydaje się być włączony w trybie wymuszania na nowych urządzeniach. Utrudni to modyfikację /system, nawet jeśli chcesz uzyskać dostęp do roota, bez ponownego odblokowania programu ładującego.

Czy to zmienia Twój pogląd na urządzenia z blokadą bootloadera? Czy Android osiągnął etap, w którym nadal kupiłbyś urządzenie z blokadą bootloadera, gdyby Twój operator dał ci dobrą ofertę?, czy interesują Cię tylko odblokowane urządzenia? Jakich aplikacji lub funkcji roota brakowałoby Ci przy zablokowanym bootloaderze?

Podziel się swoimi przemyśleniami w komentarzach poniżej.