Rootowanie Androida

Dostałem telefon z Androidem. Do rozmów nadaje się tak sobie, wymaga ciągłego podpinania do ładowarki, ma też poważniejszy feler o którym na końcu ale można pograć na FICS albo na chess.com, można zagrać z silnym programem, można zerknąć na partie arcymistrzów, a oczywiście też przejrzeć maila, odhaczyć coś na todo-liście albo poczytać, więc pewnie polubię.

Już pierwszego wieczora pojawił się problem: włożyłem kartę SD, włączyłem telefon i … musiałem bardzo solennie przepraszać małżonkę za rozbudzenie jej ze snu. Jazgotliwy łomot odgrywany po uruchomieniu postawiłby na nogi głuchego. Gdy nazajutrz okazało się jeszcze, że telefon potrafi go wydać sam z siebie w nieoczekiwanym momencie – np. resetując się gdy zbraknie mu z jakiegoś powodu pamięci – a słodka melodia nie jest w żaden sposób konfigurowalna, stało się jasne, że muszę coś zrobić.

Czymś okazało się zrootowanie telefonu (Silent Boot działał bardzo kapryśnie). A poniższy artykuł jest o tym, jak zrobić to wiedząc, co właściwie się robi i szczególnie niczym nie ryzykując.

Rootowanie według tysiąca porad sieciowych

W internecie pełno jest artykułów traktujących rootowanie jako czynność na poły magiczną, z jednej strony trochę niebezpieczną, z drugiej – najczęściej wykonywaną w pełni automatycznie, z jednej pożyteczną, z drugiej – wiążącą się z utratą gwarancji.

To wrzucanie wszystkiego do jednego worka jest mylące. O ile aplikacje zamieniające bazowy obraz systemu lub bootloader są faktycznie ryzykowne (mogą spowodować nieuznanie gwarancji), o tyle inna gama technik jest bezpieczna i nie wprowadza żadnych inwazyjnych zmian na telefonie.

Spośród narzędzi z tej drugiej rodziny najszerzej opisywany jest SuperOneClick. Program z sensownym pomysłem ale działający bardzo kapryśnie. Próbowałem go używać, bez skutku, przy czym problemy (na ile się domyślam) dotyczyły nie samego rootowania ale parsowania wyników komend shellowych, zaś porady ich rozwiązywania magicznymi zabawami typu w tym a tym momencie włącz/wyłącz USB Debugging, wtedy a wtedy zrebootuj telefon, wyjmij kartę SD pozwalały zmarnować trochę czasu ale w niczym nie pomagały.

Dlatego ostatecznie przeprowadziłem cały proces ręcznie i tego typu podejście - zapewniające możliwość szczegółowego monitorowania przebiegu wydarzeń - rekomenduję (przy czym poniższe operacje są zbliżone do tego, co próbuje zrobić SuperOneClick).

Rootowanie bardziej świadomie

Proces rootowania obejmuje dość prostą sekwencję czynności:

• skonfigurowanie shellowego dostępu do telefonu (do czego nie są potrzebne żadne crackerskie narzędzia, można skorzystać z udostępnianych przez Google),

• skopiowanie na telefon i uruchomienie programu typu local root exploit, tj. narzędzia, które - wykorzystując błąd systemu operacyjnego - pozwala eskalować uprawnienia i uzyskać (chwilowy) shell roota,

• wykonanie pożądanych czynności administracyjnych wymagających uprawnień roota - w moim wypadku chodziło o usunięcie irytującej melodyjki,

• (jeśli na tym zakończymy, to po reboocie telefonu sesja roota znika i telefon nie jest nijak zrootowany),

• wykorzystanie powyższego shella roota do zainstalowania program su z ustawionym bitem setuid, a także pomocniczych narzędzi (busybox) ułatwiających zarządzanie systemem. Doinstalowane w tym kroku programy pozostają na przyszłość i pozwalają uzyskać prawa roota w dowolnym momencie.

W szczególności dostępne w Android Markecie aplikacje wymagające zrootowanego telefonu (np. różne backupy czy programy zarządzania systemem) oczekują właśnie powyższego: su i busyboksa (czasem także sqlite3).

Android SDK

Pierwszym krokiem całej zabawy jest instalacja Android SDK. Jest to zasadniczo narzędzie dla developerów ale i dla zwykłego użytkownika telefonu może być całkiem przydatne. Pozwala min:

• zrobić zrzut ekranu telefonu,

• kopiować pliki z telefonu i na telefon bez deaktywowania działających aplikacji (normalna technika podłączania telefonu jako dysku USB wiąże się z jego odmontowaniem w telefonie, programy używające SD lub na nim zainstalowane przestają działać),

• uzyskać z PC dostęp do shellowej konsoli telefonu,

• zerknąć do logów.

Instalacja:

• pobieramy odpowiedni pakiet ze strony Android SDK (w moim wypadku android-sdk_r16-linux.tgz który działa poprawnie i na 32- i na 64-bitowych dystrybucjach),

• rozpakowujemy go w dowolnie wybranym miejscu (np. $HOME/Android),

• uruchamiamy program ./android-sdk-linux/tools/android, który jest swoistym menedżerem pakietów, i doinstalowujemy biblioteki i narzędzia dla odpowiedniej wersji Androida (w moim wypadku było to 2.3.3)

Na telefonie dopukujemy się do Settings → Applications → Development i włączamy opcję Turn On USB Debugging, po czym podłączamy telefon kablem USB do komputera. Nie zaszkodzi też włączenie sąsiadującej opcji Stay awake (unikniemy przypadkowego uśpienia telefonu w trakcie późniejszych operacji).

Po tym wszystkim program … jeszcze nie może porozumieć się z telefonem ze względu na brak linuksowych uprawnień (do plików urządzenia) – chyba, że zostanie uruchomiony z konta roota (stąd rozliczne w sieci porady wiążące się z sudo adb start-server czy nawet sugestie sudo mono SuperOneClick.exe – jedno i drugie moim zdaniem niewskazane).

Aby to rozwiązać trzeba stworzyć plik /etc/udev/rules.d/51-android.rules o treści:

SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="plugdev" 

przy czym 0bb4 jest kodem odpowiednim do rodzaju telefonu. Jaki jest mój sprawdziłem robiąc (mając podpięty telefon) lsusb (wartość po ID):

marcin@platon:~$ lsusb
(…)
Bus 001 Device 123: ID 0bb4:0c03 High Tech Computer Corp. 
(…)

Po stworzeniu 51-android.rules (w pliku chodzi tak naprawdę o nadanie mode 0666 - czyli prawa odczytu/zapisu dla wszystkich użytkowników - dla urządzenia odpowiadającego podpiętemu telefonowi) i restarcie udev:

marcin@platon:~$ sudo restart udev

można zacząć używać narzędzi Google. Najpierw tego niskopoziomowego:

marcin@platon:~/Android$ ./android-sdk-linux/platform-tools/adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached 
0123456789ABCDEF    device

(jeśli powyżej zamiast literek ukażą się znaki zapytania, mamy problem z uprawnieniami - być może trzeba poprawić coś w 51-android.rules, a jeśli lista jest pusta, prawdopodobnie nie jest aktywny USB Debugging na telefonie).

Polecenie adb jest często przydatne, warto je dorzucić do ścieżki, np.

marcin@platon:~/Android$ ln -s \
     ~/Android/android-sdk-linux/platform-tools/adb \
     ~/bin/

Prosty przykład wykorzystania:

marcin@platon:~$ adb shell mkdir /mnt/sdcard/ikony
marcin@platon:~$ adb push \
    /usr/share/icons/oxygen/48x48/categories/applications-graphics.png \
    /mnt/sdcard/ikony/

(stworzyłem katalog /ikony na karcie SD w telefonie i wrzuciłem tam przydatną ikonkę - nie przerywając działania aplikacji, która tej ikonki potrzebowała).

Graficzny interfejs zapewnia komenda ./android-sdk-linux/tools/ddms. Oprócz różnych opcji developerskich jest tam min. (menu Device → Screen capture…) robienie zrzutów ekranowych (aktualny zrzut dostajemy po kliknięciu Refresh, Save pozwala go zapisać w pliku .png):

a także (Device → File Explorer) graficzny podgląd katalogów na telefonie (tutaj możliwość wgrania pliku na telefon czy pobrania pliku z telefonu zapewniają ikonki w toolbarze):

Zdobycie praw roota

Czas na crackerski element operacji, czyli zdobycie (chwilowe) praw roota na telefonie.

W sieci dostępnych jest parę różnych exploitów na to pozwalających. Najpopularniejszym ostatnio jest zergRush, którego skompilowaną wersję można znaleźć min. w ramach SuperOneClick. Ja posługiwałem się zergRush znalezionym wdg. wpisu z forum XDA.

Pobranie pliku może być utrudnione, antywirusy - słusznie - protestują:

VIRUS FOUND
Virus: Exploit.Linux.Lotoor.ab

For security reasons, the file was not downloaded.

Sam exploit wgrywamy na telefon (do katalogu /data/local) przy pomocy ADB i ustawiamy mu bity wykonywalności:

marcin@platon:~$ adb push ~/Android/zergRush /data/local
539 KB/s (23060 bytes in 0.041s)
marcin@platon:~$ adb shell "chmod 777 /data/local/zergRush"

po czym uruchamiamy shella telefonu i w jego ramach sam exploit:

marcin@platon:~$ adb shell
$ ls /data/local
zergRush
tmp
$ /data/local/zergRush

[**] Zerg rush - Android 2.2/2.3 local root
[**] (C) 2011 Revolutionary. All rights reserved.

[**] Parts of code from Gingerbreak, (C) 2010-2011 The Android Exploid Crew.

[+] Found a GingerBread ! 0x00000118
[*] Scooting ...
[*] Sending 149 zerglings ...
[+] Zerglings found a way to enter ! 0x10
[+] Overseer found a path ! 0x00015180
[*] Sending 149 zerglings ...
[+] Zerglings caused crash (good news): 0x4011dcf4 0x0064
[*] Researching Metabolic Boost ...
[+] Speedlings on the go ! 0xafd24fff 0xafd3904f
[*] Popping 8 more zerglings
[*] Sending 157 zerglings ...

[+] Rush did it ! It's a GG, man !
[+] Killing ADB and restarting as root... enjoy!

Sesja shella zostaje po powyższym rozłączona. Po ponownym połączeniu mamy prawa roota (tak naprawdę zyskał je działający na telefonie proces ADB):

marcin@platon:~$ adb shell
# id
uid=0(root) gid=0(root)
# ls /system/app/
(… lista plików w normalnie niedostępnym katalogu …)

Wszystko to jest chwilowe, po reboocie telefonu (albo dowolnej innej formie zatrzymania procesu ADB na telefonie, pewnie wystarczy wyłączenie USB Debugging) przywileje znikną.

Uwaga: przy próbie ponownego uruchomienia (nieopatrznie wyłączyłem telefon po udanym explocie) dostawałem błąd:

marcin@platon:~$ adb shell
$ /data/local/zergRush

[**] Zerg rush - Android 2.2/2.3 local root
[**] (C) 2011 Revolutionary. All rights reserved.

[**] Parts of code from Gingerbreak, (C) 2010-2011 The Android Exploid Crew.

[-] Cannot copy boomsh.: No such file or directory

Pomogło dokładne skasowanie wszystkich (poza zergRush) plików i katalogów z /data/local (zapewne wystarczyłoby też założenie tam nowego pustego podkatalogu i skopiowanie zergRush doń)

Usunięcie słodkiej muzyczki

Czas na podstawowy cel zabawy czyli podmianę straszliwego dźwięku.

Najpierw przemontowałem system telefonu w tryb read-write (z innego terminala, nie zrywając shella roota):

marcin@platon:~$ adb remount

a potem po prostu:

marcink@platon:~$ adb shell \
    mv /system/media/bootaudio.mp3 /system/media/bootaudio.mp3-preczztym

i dla pewności

marcink@platon:~$ adb push ~/Android/silence.mp3 /system/media/bootaudio.mp3

Plik silence.mp3 zrobiłem przy pomocy audacity (menu Generate → Silence, ustawiając 2 sekundy i zapisując wynik przez File → Export z typem .mp3).

W podobny sposób, bez trwałego rootowania, można skopiować wybrane pliki, usunąć niepotrzebne aplikacje czy dokonać innych normalnie niedostępnych rekonfiguracji telefonu.

Trwałe rootowanie - po co

Trwałe rootowanie przede wszystkim daje możliwość uzyskania roota w dowolnym momencie przez polecenie su:

marcink@platon:~/Android$ adb shell
$ id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)
$ su
# id
uid=0(root) gid=0(root)

a na wyższym poziomie, pozwala korzystać z aplikacji wymagających zrootowanego telefonu (a wymaga go sporo programów narzędziowych).

Aplikacje takie jak Titanium Backup czy Cache Cleaner wymagają też obecności BusyBoksa a niekiedy też SQLite3.

BusyBox to po prostu chmara narzędzi shellowych w jednej binarce, od ls, cp czy find po traceroute, unzip albo grep (patrz pełna lista). Projekt jest intensywnie używany na ruterach, modemach itp ale przyda się wszędzie, gdzie mamy ograniczone miejsce i pamięć. Na Androidzie znakomicie przydaje się min. busybox sh

marcink@platon:~/Android$ adb shell
$ busybox sh
/ $ cd /mnt/sdcard
/mnt/sdcard $ 

i nagle mamy shell obsługujący przywoływanie poprzedniego polecenia strzałką do góry, dopełnianie tabulacją poleceń itd itp i prezentujący bieżący katalog w znaku zachęty. Pojawia się też cała masa normalnych poleceń linuksowego shella, których Android domyślnie nie zawiera.

Ostatnim elementem układanki jest aplikacja Superuser (patrz też tutaj). Stanowi ona graficzny interfejs do su - decydując które (graficzne) aplikacje mają prawo uzyskać prawa roota, a które nie (su, gdy zostanie wywołane, sprawdza wpisy w konfiguracji generowanej przez program SuperUser):

i pozwalając zarządzać tymi uprawnieniami:

 

(ikonka śmietnika usuwa wpis dotyczący danej aplikacji – pytanie, czy ma dostać prawa roota, zostanie ponownie zadane gdy ich zażąda).

Trwałe rootowanie - instrukcja

Dystrybucję powyższych narzędzi można pobrać z różnych miejsc, ja posługiwałem się pakietem DooMLoRDa pobranym w trakcie poszukiwań działającego narzędzia do rootowania (więcej informacji w tym wpisie na forum XDA.

Powyższy pakiet zawiera - jako skrypt .bat - listę czynności podobną do tej, którą właśnie opisuję. Radzę wykonywać je raczej pojedynczo i obserwować, czy nie pojawiają się jakieś błędy.

Podobny zestaw (acz z dużo starszą wersją Superuser) jest zawarty w SuperOneClicku, binarkę Busyboksa można zrobić samemu a Superusera pobrać stąd.

Sam proces przebiega następująco (cały czas używamy shella roota zdobytego przy pomocy exploita).

\1. Instalujemy busyboksa

# Kopiujemy plik busybox na telefon
adb shell mkdir /data/local/tmp
adb push files/busybox /data/local/tmp/
adb shell "chmod 755 /data/local/tmp/busybox"
# O ile jeszcze nie przemontowaliśmy /system w tryb rw, robimy to
adb shell "/data/local/tmp/busybox mount -o remount,rw /system"
# Kopiujemy busybox do /system/xbin i nadajemy mu odpowiednie uprawnienia
adb shell "dd if=/data/local/tmp/busybox of=/system/xbin/busybox"
adb shell "chown root.shell /system/xbin/busybox"
adb shell "chmod 04755 /system/xbin/busybox"
# Tworzymy w /system/xbin chmarę symlinków dla wszystkich komend busyboksa
adb shell "/system/xbin/busybox --install -s /system/xbin"

Ostatni krok (busybox --install) tworzy w /system/xbin kilkaset linków symbolicznych do polecenia busybox. Dzięki temu można pisać unzip -l cośtam.zip a nie busybox unzip -l cośtam.zip.

Nie jestem pewien, czemu busybox dostaje setuid, ale konwencja ta wydaje się regularnie stosowana przy rootowaniu Androida. Można spróbować ją pominąć (wówczas zamiast chmod 04755 /system/xbin/busybox będzie po prostu chmod 755 /system/xbin/busybox).

\2. Instalujemy su i dajemy mu setuid oraz setgid (tj. prawo działania z uprawnieniami roota).

adb push files/su /system/bin/su
adb shell "chown root.shell /system/bin/su"
adb shell "chmod 06755 /system/bin/su"
adb shell "rm /system/xbin/su"
adb shell "ln -s /system/bin/su /system/xbin/su"

\3. Instalujemy aplikację SuperUser

adb push files/Superuser.apk /system/app/

\4. Sprzątamy i restartujemy telefon

adb shell "cd /data/local/tmp/; rm *"
adb reboot

I to już wszystko.

Jak to odwrócić

Proste skasowanie zainstalowanych narzędzi (busyboxa wraz z symlinkami, su i aplikacji Superuser) przywraca telefon do niezrootowanego stanu.

Podobne konsekwencje powinien mieć Factory Reset.

Co może pójść inaczej

Zależnie od wersji Androida i telefonu (i w miarę łatania luk bezpieczeństwa), mogą być potrzebne różne exploity. Przed ZergRushem popularny był psneuter, w przyszłości zapewne pojawią się następne.

Niektóre telefony mają wbudowane zabezpieczenie przed nieautoryzowanymi zmianami partycji /system (tzw. NAND lock) - bootloader sprawdza, czy nie nastąpiły tam nieautoryzowane zmiany i w razie ich wykrycia, odmawia startu. W niczym nie utrudnia to „chwilowego uzyskania roota” przy pomocy exploita ale w celu wprowadzenia trwałych modyfikacji trzeba posłużyć się bardziej inwazyjnymi technikami wiążącymi się ze zmianami bootloadera lub recovery image (jak np. unrevoked).

Niezły szczegółowy opis całego procesu i różnych jego wariantów można znaleźć tutaj.

A mój telefon jest tryfny

Na koniec jeszcze ostrzeżenie na inny temat. Szef eksperymentalnie kupił parę telefonów w Chinach (mój to B68). Urządzenie jest całkiem fajne, paru chińskich aplikacji można nie używać albo (po zrootowaniu) je skasować, darmowe aplikacje z Android Marketu instalują się bez problemu, ale…

… ale płatnych instalować się nie da. Bez problemu mogę kupić na co tylko mam ochotę i nakazać instalację, plik najwyraźniej jest pobierany na telefon (poniższe dobrą chwilę trwa):

niemniej efekt końcowy jest jednaki:

Wynika to, jeśli dobrze zrozumiałem, z nie wykupienia przez producenta licencji od Google (i odbywa się na poziomie weryfikacji praw do kopiowania - jakiś androidowy DRM).

Można to obchodzić przenosząc ręcznie pliki .apk pobrane na innym (nie-chińskim) telefonie (udało mi się skopiować od kolegi i zainstalować - via adb install - aplikację, którą kupiliśmy obaj, czy mógłbym skopiować nie płacąc, nie testowałem) ale jest to co najmniej uciążliwe.