Dlaczego nie można po prostu skopiować pliku binarnego su (proszę o odpowiedź techniczną)

Zrootowałem kilka urządzeń Samsunga i podstawowym celem jest, że tak powiem, uzyskanie supliku binarnego /system/xbini zainstalowanie Superuser.apk .

Moje pytanie brzmi: dlaczego trzeba skakać przez wszystkie te obręcze, aby zrootować telefon (zainstalować niestandardowe odzyskiwanie i flashować wstępnie zrootowaną pamięć ROM lub wykorzystać bieżącą instalację)? Czy nie można po prostu pobrać wstępnie skompilowanego su, przenieść go na kartę SD i uruchomić za pomocą adb? Rzeczą, która sprawia, że ROM jest „wstępnie zrootowany” jest to, że ma on Superuser i su binary w swoich ścieżkach systemowych. Nie rozumiem, dlaczego tak ważne jest, aby był uruchamiany /system/xbin.

— użytkownik974896
źródło

Odpowiedzi:

Plik binarny su wymaga zarówno wykonania, jak i ustawienia bitu uprawnień setuid. Po pierwsze, plik musi być wykonany, a po drugie, że automatycznie uruchamia się z prawami właściciela pliku (ustaw identyfikator użytkownika lub setuid. W tym przypadku właścicielem jest root. Przeczytaj więcej tutaj ).

Pliki w pamięci zewnętrznej nie mają ustawionych bitów uprawnień do plików wykonywalnych i setuid i nie można ich przyznać bez uprawnień roota. Zauważ też, że karta SD jest zamontowana z flagą „noexec”, aby zasadniczo uniemożliwić uruchomienie:

shell@android:/sdcard $ ./su
/system/bin/sh: ./su: can't execute: Permission denied
126|shell@android:/sdcard $ chmod 4755 su
Unable to chmod su: Operation not permitted
10|shell@android:/sdcard $ mount | grep /mnt/sdcard
/dev/block/mmcblk0p1 /mnt/sdcard vfat [...],noexec,[...]

Właśnie dlatego nie można po prostu skopiować suna kartę SD, a następnie uruchomić go, aby uzyskać uprawnienia roota.

— eldarerathis
źródło

Więc to jedyna rzecz, która zapobiega rootowaniu, fakt, że / sdcard nie jest wykonywalny i nie możesz chmod? Gdy su znajdzie się w odpowiednim miejscu, w którym można go chmod wykonać, twój złoty. Wydaje mi się, że istniałaby warstwa bezpieczeństwa, która uniemożliwiłaby po prostu uruchomienie su. Na moim serwerze i debianie nie mogę po prostu uruchomić su jako zwykły użytkownik, pojawia się monit o hasło. Domyślam się, że jeśli ktoś może zainstalować su, może zastąpić plik cienia, aby zmienić hasło?

— user974896,

@ user974896: Cóż, nie jest nic innego, jak użytkownik niesystemowy mógłby powiedzieć, że można go uruchomić, a Android i tak nie ma passwdani shadowplików. Dosłownie potrzebujesz roota, aby umieścić suw wykonywalnej lokalizacji, dlatego metody rootowania albo wykorzystują exploit eskalacji uprawnień, albo przechodzą do niestandardowego odzyskiwania (gdzie wszystkie zakłady są w zasadzie wyłączone).

— eldarerathis

Tak. Oto odpowiedź.

— Android Quesito,

@ user974896: oprócz montowanej / sdcard noexec, wywołanie systemowe setuid można wywołać tylko wtedy, gdy bit uprawnień suid jest ustawiony w pliku wykonywalnym, a wywołanie systemowe chown i chmod pozwoli tylko rootowi ustawić bit setuid pliku własnością root (w rzeczywistości tylko root może utworzyć plik wykonywalny, który będzie działał z uprawnieniami roota). Każdy może wywołać su, ale jeśli osoba dzwoniąca nie może tego zrobić w bazie danych Superuser (lub w tradycyjnym systemie Linux, w bazie danych passwd / shadow), połączenie się nie powiedzie. Tylko aplikacja Superuser (i procesy uprzywilejowane) może modyfikować bazę danych Superuser.

— Lie Ryan,

@ user974896: To, oprócz normalnego systemu bezpieczeństwa w Androidzie, w którym każda aplikacja Dalvik działa jako własny użytkownik, oznacza, że aplikacje, które tylko aplikacja z białej listy Superuser mogą eskalować się do rootowania bez pytania, wszyscy inni zostaną odrzuceni (jeśli jest to na czarnej liście) lub spowoduje, że Superuser poprosi użytkownika o zgodę.

— Lie Ryan,

Rootowanie polega na wykorzystaniu słabości w zależności od wersji Androida, stąd „ przeskocz przez wszystkie obręcze, aby zrootować telefon ”

To jest kurczak i jajko!

Aby móc korzystać z roota, potrzebujesz niezabezpieczonego demona adb (tj. Możliwości ponownego zamontowania /system) na telefonie, a żeby mieć niezabezpieczone adb, potrzebujesz roota! A także potrzebujesz odblokowanego bootloadera.

Spójrz na jeden exploit o nazwie zergRush znaleziony na github; funkcja będąca przedmiotem zainteresowania jest wywoływana w do_fault()przypadku próby „rozbicia” ramki stosu volddemona przez połączenie się z potokiem będącym jego własnością i spowodowania awarii przez nadpisanie wskaźnika stosu w celu wskazania skopiowanej wersja powłoki, z boomshktórej następnie działa /data/local/tmp.

Po przeczytaniu źródła zrozumiesz, dlaczego kopiowanie pliku subinarnego nie wystarczy, aby telefon został „zrootowany” i dlaczego trzeba przeskakiwać obręcze. A także, ponieważ bit wykonywalny na poziomie systemu plików dla karty SD jest zablokowany, więc nie idź tam - to z oczywistych powodów! :)

— t0mm13b
źródło

Dzięki za linki, przeczytam je później. Więc nawet jeśli sdcard został chmodded 777 z fabryki, nadal nie mogłem się zrootować po prostu pobierając go i wykonując?

— user974896,

poprawny! Nie idź! Nie robi to żadnej różnicy, a ponieważ zainstalowana fabrycznie pamięć ROM będzie miała taką ochronę, musisz root, aby to chmodzrobić - z uprawnieniami karty SD! :)

— t0mm13b,

Co sprawia, że su jest tak wyjątkowy, jeśli znajduje się w katalogu / system / xbin? Jeśli wpiszesz powłokę adb (lub uruchomisz aplikację jako zwykły użytkownik), będziesz użytkownikiem nieuprzywilejowanym. Dlaczego wykonanie su, gdy jest w / system / xbin, powoduje, że rootujesz, a nie uruchamiasz go w naszej teoretycznie chmod 777 / sdcard?

— user974896,

/system/xbinjest katalogiem, do którego przechodzą narzędzia busybox i ... w zrootowanym telefonie, wydanie to echo $PATHda / sbin: / vendor / bin: / system / sbin: / system / bin: / system / xbin <- zauważ to! Jest na drodze! Aby to mieć, potrzebujesz korzenia, stąd wiele sytuacji z kurczakiem i jajami ...: D

— t0mm13b

Tak, wiem, że tam jest domyślnie. Chodzi mi o to, co jest takiego specjalnego w uruchomieniu go tam. Dlaczego wykonywanie ./su w / sdcard /, / data / lub innym katalogu innym niż root nie działa, zakładając, że fabryka dostarczyła ROM z katalogiem chmodded na 777. To, co mam na myśli, to jedyna rzecz, która powstrzymuje jedną od pobrania a uruchomienie ./su to fakt, że katalogi, w których użytkownik inny niż root może to zrobić, nie są wykonywalne lub jest większy obraz.

— user974896,