Android adb shell root android

Android adb shell root android

Platform-tools: r31.0.3
ADB: 1.0.41 (31.0.3-7562133)
Fastboot: 31.0.3-7562133
Make_f2fs: 1.14.0 (2020-08-24)
Mke2fs: 1.46.2 (28-Feb-2021)
Последнее обновление утилит в шапке: 01.08.2021

ADB (Android Debug Bridge — Отладочный мост Android) — инструмент, который устанавливается вместе с Android-SDK и позволяет управлять устройством на базе ОС Android.
Работает на всех Android-устройствах, где данный функционал не был намеренно заблокирован производителем.
Здесь и далее: PC — ПК, компьютер к которому подключено устройство.
ADB — консольное приложение для PC, с помощью которого производится отладка Android устройств, в том числе и эмуляторов.
Работает по принципу клиент-сервер. При первом запуске ADB с любой командой создается сервер в виде системной службы (демона), которая будет прослушивать все команды, посылаемые на порт 5037.
Официальная страница
ADB позволяет:

• Посмотреть какие устройства подключены и могут работать с ADB.
• Просматривать логи.
• Копировать файлы с/на аппарат.
• Устанавливать/Удалять приложения.
• Удалять (очищать) раздел data.
• Прошивать (перезаписывать) раздел data.
• Осуществлять различные скрипты управления.
• Управлять некоторыми сетевыми параметрами.

Поставляется ADB в составе инструментария разработчика Андроид (Android SDK), который, в свою очередь входит в состав Android Studio.

Если что-то неправильно, то в списке подключенных устройств (List of devices attached) будет пусто.

Скрытые команды ADB
adb -d Команда посылается только на устройство подключенное через USB.
Внимание: Выдаст ошибку, если подключено больше одного устройства.

adb -e Команда посылается на устройство в эмуляторе.
Внимание: Выдаст ошибку, если подключено больше одного эмулятора.

adb -s Команда посылается на устройство с указанным серийным номером:

adb -p Команда посылается на устройство с указанным именем:
Если ключ -p не указан, используется значение переменной ANDROID_PRODUCT_OUT.

adb devices Список всех подсоединенных устройств.

adb connect [: ] Подсоединиться к андроид хосту по протококу TCP/IP через порт 5555 (по умолчанию, если не задан).

adb disconnect [ [: ]] Отсоединиться от андроид подключенного через TCP/IP порт 5555 (по умолчанию, если не задан).
Если не задан ни один параметр, отключиться от всех активных соединений.

adb push Копировать файл/папку PC->девайс.

adb pull [ ] Копировать файл/папку девайс->PC.

adb sync [ ] Копировать PC->девайс только новые файлы.
Ключи:
-l Не копировать, только создать список.

adb shell Запуск упрощенного unix shell.
Примеры использования

adb emu Послать команду в консоль эмулятора

adb install [-l] [-r] [-s] Послать приложение на устройство и установить его.
Пример: adb install c:/adb/app/autostarts.apk Установить файл autostarts.apk лежащий в папке /adb/app/ на диске с:
Ключи:
-l Блокировка приложения
-r Переустановить приложение, с сохранением данных
-s Установить приложение на карту памяти
Установка split apk

adb uninstall [-k] Удаление приложения с устройства.
Ключи:
-k Не удалять сохраненные данные приложения и пользователя.

adb wait-for-device Ждать подключения устройства.

adb start-server Запустить службу/демон.

adb kill-server Остановить службу/демон.

adb get-state Получить статус:
offline Выключен.
bootloader В режиме начальной загрузки.
device В режиме работы.

adb get-serialno Получить серийный номер.

adb status-window Непрерывный опрос состояния.

adb remount Перемонтировать для записи. Требуется для работы скриптов, которые изменяют данные на.

adb reboot bootloader Перезагрузка в режим bootloader.

adb reboot recovery Перезагрузка в режим recovery.

adb root Перезапуск демона с правами root

adb usb Перезапуск демона, прослушивающего USB.

adb tcpip Перезапуск демона, прослушивающего порт TCP.

adb ppp [параметры] Запуск службы через USB.
Note: you should not automatically start a PPP connection. refers to the tty for PPP stream. Eg. dev:/dev/omap_csmi_tty1
Параметры:
defaultroute debug dump local notty usepeerdns

FastBoot — консольное приложение для PC. Используется для действий над разделами

fastboot devices Список присоединенных устройств в режиме fastboot.
fastboot flash Прошивает файл .img в раздел устройства.

fastboot erase Стереть раздел.
Разделы: boot, recovery, system, userdata, radio
Пример: fastboot erase userdata Стирание пользовательских данных.

fastboot update Прошивка из файла имя_файла.zip

fastboot flashall Прошивка boot + recovery + system.

fastboot getvar Показать переменные bootloader.
Пример: fastboot getvar version-bootloader Получить версию bootloader.

fastboot boot [ ] Скачать и загрузить kernel.

fastboot flash:raw boot [ ] Создать bootimage и прошить его.

fastboot devices Показать список подключенных устройств.

fastboot continue Продолжить с автозагрузкой.

fastboot reboot Перезагрузить аппарат.

f astboot reboot-bootloader Перезагрузить девайсв режим bootloader.
Перед командами fastboot можно использовать ключи:
-w стереть данные пользователя и кэш
-s Указать серийный номер устройства.
-p

Указать название устройства.
-c Переопределить kernel commandline.
-i Указать вручную USB vendor id.
-b Указать в ручную базовый адрес kernel.
-n

Указать размер страниц nand. по умолчанию 2048.

Команду logcat можно использовать с машины разработки
$ adb logcat
или из удаленного shell
# logcat Каждое сообщение лога в Android имеет тэг и приоритет
Тэг – это строка указывающая компонент системы, от которого принято сообщение (например: View для системы view)
Приоритет – имеет одно из нижеследующих значений (в порядке от меньшего к большему):
V — Verbose (Низший приоритет).
D — Debug
I — Info
W — Warning
E — Error
F — Fatal
S — Silent (Наивысший приоритет, при котором ничего не выводится).

Получить список тэгов, используемых в системе, вместе с их приоритетами можно запустив logcat. В первых двух столбцах каждого из выведенных сообщений будут указаны / .
Пример выводимого logcat сообщения:
I/ActivityManager( 585): Starting activity: Intent

Для уменьшения вывода лога до приемлемого уровня нужно использовать выражения фильтра. Выражения фильтра позволяют указать системе нужные комбинации и , остальные сообщения система не выводит.
Выражения фильтра имеют следующий формат : . где указывает нужный тэг, указывает минимальный уровень приоритета для выбранного тэга. Сообщения с выбранным тэгом и приоритетом на уровне или выше указанного записываются в лог. Можно использовать любое количество пар : в одном выражении фильтра. Для разделения пар : используется пробел.

Пример ниже выводит в лог все сообщения с тэгом «ActivityManager» с приоритетом «Info» или выше, и сообщения с тэгом «MyApp» и приоритетом «Debug» или выше:
adb logcat ActivityManager:I MyApp:D *:S
Последний элемент в выражении фильтра *:S устанавливает приоритет «silent» для всех остальных тэгов, тем самым обеспечивая вывод сообщений только для «View» и «MyApp». Использование *:S – это отличный способ для вывода в лог только явно указанных фильтров (т.е. в выражении фильтра указывается «белый список» сообщений, а *:S отправляет все остальное в «черный список»).

При помощи следующего выражения фильтра отображаются все сообщения с приоритетом «warning» или выше для всех тэгов:
adb logcat *:W

Если logcat запускается на машине разработчика (не через удаленный adb shell), можно также установить значение выражения фильтра по умолчанию задав переменную окружения ANDROID_LOG_TAGS:
export ANDROID_LOG_TAGS=»ActivityManager:I MyApp:D *:S»

Следует обратить внимание что задав переменную окружения ANDROID_LOG_TAGS она не будет работать в эмуляторе/устройстве, если вы будете использовать logcat в удаленном shell или используя adb shell logcat.
Вышеописанная команда export работает в ОС *nix и не работает в Windows.

Контроль формата вывода лога

Сообщения лога в дополнение к тэгу и приоритету содержат несколько полей метаданных. Можно изменять формат вывода сообщений показывая только конкретные поля метаданных. Для этого используется параметр -v и указывается один из ниже перечисленных форматов вывода.

brief Показывать приоритет/тэг и PID процесса (формат по умолчанию).
process Показывать только PID.
tag Показывать только приоритет/тэг.
thread Показывать только процесс:поток и приоритет/тэг.
raw Показать необработанное сообщение, без полей метаданных.
time Показывать дату, время вызова, приоритет/тэг и PID процесса.
long Показывать все поля метаданных и отдельно сообщения с пустыми строками.

При запуске logcat можно указать формат вывода используя параметр -v:
adb logcat [-v

Источник

Есть ли способ запустить оболочку Adb от имени пользователя root без ввода ‘su’?

Есть ли способ запустить оболочку Adb от имени пользователя root без ввода su ? Я хочу иметь возможность иметь root-доступ, не заходя в оболочку.

Если я правильно понимаю ваш вопрос, вы спрашиваете, как автоматически получить root-доступ при запуске adb shell , чтобы вам не приходилось заходить в оболочку и вводить su команду от имени root на вашем телефоне.

Это контролируется флагом в вашем загрузочном разделе, который большинство пользовательских ПЗУ изменили, чтобы разрешить права root по умолчанию. Если $ при использовании adb shell вы перешли на a , то у вас есть два постоянных варианта и один временный (временный, что означает, что он не будет зависать при перезагрузке):

1. Прошить ROM, который включает в себя модификацию
2. Создайте собственный boot.img и прошейте его на свой телефон
3. Перезапустите adbd на своем устройстве с правами root

Номер 2 на самом деле не так уж и сложен, но он может быть несколько опасным, если вы небрежны. Существует вики статья здесь , которая объясняет этот процесс и включает в себя несколько сценариев Perl , чтобы помочь вам. Эти инструкции предполагают среду Linux / Unix. Я лично использовал эти инструкции для Fedora Linux и могу сказать вам, что они работают, но я не знаю о других * nix средах, таких как Mac. Я также не знаю каких-либо аналогичных инструкций для Windows, но я мог бы попытаться отследить их, если вы используете Windows. Точные команды будут отличаться от телефона к телефону, поскольку разные устройства используют разные таблицы разделов.

Тем не менее, в общем, вам нужно вытащить ваш текущий boot.img из телефона, распаковать его, извлечь виртуальный диск и найти файл default.prop . Это обычный текстовый файл, который необходимо открыть в текстовом редакторе, а затем найти строку, содержащую значение ro.secure . Если строка говорит, ro.secure=1 то вам нужно изменить его на ro.secure=0 . После этого вы можете перепаковать ramdisk и boot.img, а затем прошить его на свой телефон. Как только вы перезагрузите компьютер, вы получите # приглашение при выполнении adb shell без необходимости запуска su .

В качестве альтернативы, если вы используете пользовательское ПЗУ, но оно не имеет этой модификации, вы можете просто разархивировать ПЗУ и изменить файл boot.img, который входит в него, используя описанные выше шаги. Затем вы можете заархивировать ПЗУ с помощью недавно модифицированного boot.img и прошить zip-файл, как обычно.

Это, вероятно, само собой разумеется, но будьте осторожны при этом. Перепутывание вашего загрузочного раздела может довольно легко испортить ваш телефон и заставить вас восстановиться через HBoot. Я настоятельно рекомендую протестировать Fastboot, чтобы убедиться, что вы можете использовать расширенные команды Fastboot и выполнить восстановление. Это зависит от вашей модели, но большинство телефонов имеют программное обеспечение для настольных компьютеров, которое также можно запускать для перепрошивки телефона.

Третий вариант заключается в том, что во многих случаях возможно перезагрузить adbd устройство с правами root. Одной из возможностей является выполнение adb root с терминала ПК, хотя это не будет работать на всех конфигурациях ПЗУ (ПЗУ должно быть построено как пользовательская отладка). Вы также можете попробовать небезопасное приложение adbd в Chainfire . Это не будет сохраняться после перезагрузки, поэтому вам нужно будет использовать приложение или adb root снова каждый раз, когда вы перезагружаете свой телефон.

Источник

Мини блог

Поиск по этому блогу

Получаем временный и постоянный root_shell на android

• Получить ссылку
• Facebook
• Twitter
• Pinterest
• Электронная почта
• Другие приложения

Как получить временный root_shell думаю многие ромоделы уже знают. Для этого нам нужно:
— root-права в прошивке (желательно по средствам SuperSU)
— adbd Insecure от разработчика SuperSU

Скачиваем adbd Insecure, запускаем и настраиваем как на скриншоте

Вот и все, мы получили временный root_shell на телефоне до перезагрузки телефона или до отключения в самом приложении

Теперь рассмотрим получения root_shell на постоянной основе . Для этого нам нужно:
— root-права в прошивке (желательно по средствам SuperSU)
— adbd Insecure от разработчика SuperSU
— инструмент для распаковки и запаковки boot.img. Я использую CarlivImageKitchen. (Как пользоваться этим инструментом не буду описывать)
— кастомное рекавери (желательно TWRP) для бекапа и для легкосьи прошить полученный кастомный boot.img
— все делаем так же как получение временного root_shell-а
— копируем патченный /sbin/adbd (я использую плагин adb plugin для тотал коммандера)
— распаковываем boot.img
— заменяем adbd патченым по пути ramdisk/sbin/adbd (пути могут чуть отличаться в зависимости от инструмента для распаковки boot.img)
— файл /ramdisk/default.prop приводим примерно к такому виду

— собираем boot.img
— прошиваем любым вам удобным методом. К примеру через TWRP или SP FlashTool для MTK. Кому как удобнее.

Данный метод проверено на телефоне Lenovo K3 Note с прошивкой S424 ROW на android 6.0

Источник

Android Rooting Using ADB

You have an Android Device and you are familiar with Linux-based operating systems. Maybe, you like SSH or telnet to communicate with the device; you want to setup your device as a router to connect home PC to the Internet. However, you will be surprised. Android has neither login screen nor possibility to gain privileged user access to the system to do these things. This is one of the Android security principles to isolate applications from the user, each other, and the system.

In this article, I will describe you how to obtain root access on Android device in spite of security, so basically we will discuss some Android exploit development tips. I will delve deeply into one of the Android rooting principles — the adb exhaustion attack, one of the Andoid vulnerabilities, which is simpler to understand than a previous udev exploit. It is suitable for all Android-powered devices with the version 2.2 and lower.

Android rooting explained: principles

Overview

In three words, the main rooting idea is to get super user rights on a device shell. Like a standard Linux shell, it allows you to interact with the device by executing commands from the shell. The shell can be accessed via ADB (Android Debug Bridge) command tool. The main purposes of the ADB on Android-powered devices are debugging, helping to develop applications and also, in some cases, it is used for synchronization purposes (when syncing HTC Wildfire, it is required to turn on the USB Debugging). We will use the ADB tool for uploading and executing the exploit, working with rooted device via super user shell with full access to whole device file system, programs and services.

ADB includes three components:

1. A client, which runs on your machine. Windows users can invoke it from the cmd and Linux users — from the shell;
2. A server, which runs as a background process on your machine. It manages communication between the client and the daemon running on the Android-powered device;
3. A daemon, which runs as a background process on the device.

We are interested only in the third component. The daemon runs on a device and communicates with a client through a server. When you issue the ADB command like a shell, the daemon will create a shell instance on a device and redirect its output to the client. Obviously, the shell new instance created by the daemon inherits rights and environment from its parent. As the daemon runs with the AID_SHELL rights, the shell new instance and all processes created by the shell will have the same access rights. Hence, to get super user rights in the shell, we just need the daemon to be running with these rights.

To understand why the ADB daemon has the ADT_SHELL user space, we will consider how it is started up and look at its initialization script.

The first user land process started after the Android device booting is the init process. After initialization and starting of internal services like property service, ueventd service etc., it begins parsing the init.rc configuration script. The ADB daemon is mentioned in the script as the service and it is started by the init service on the boot if the USB Debugging is enabled.

Let’s look at the ADB daemon initialization source code. The main daemon entry point, where it starts its execution, is adb_main. I skipped non significant pieces of code to focus your attention on the daemon security.

So, what we see here. When the ADB daemon is starting, it has super user rights, like the init process has. However, the daemon reads some properties from the system and decides to set secure flag or not. Usually, if the device is not a development device and it is not an emulator, the properties have such values:

After properties are checked, the secure flag is set to true, and we hit to such code section:

Starting from this point, the daemon continues its execution with the AID_SHELL user id as it drops root privileges. All processes, started by the ADB daemon, like sh , will inherit its rights and will work in very limited environment. It is really sad, isn’t it?

How to root Android programmatically: Exhaustion attack

The main Android device rooting principle of the exploit described in this article is the setuid exhaustion attack. The setuid function changes the user id for a process only in case if there are resources available, otherwise it fails and the process remains with that user id, with which it was started. Let’s look at the resources that can be limited by the Linux operating system. We are interested only in the RLIMIT_NPROC resource. This resource limits maximum numbers of processes that can be created with the same user id. If you have reached the limit, you can’t create more processes with this user id. The setuid function doesn’t create processes, but it follows this rule. Once, the NPROC limit for the AID_SHELL user is reached, setuid fails and the process continues its execution with the user id set before the setuid call. It means, when the ADB daemon starts with the AID_ROOT user id and tries to change it for AID_SHELL , for which NPROC is reached, setuid fails and the daemon user id remains AID_ROOT .

It is easy enough, isn’t it?

In files attached to the article, you can find the binary file and Android root exploit source code. They implement the adb exhaustion attack explained above. The rooting process is easy for a user and I will describe how to use it below, but now, I will go into detail about the attack implementation. I will touch upon the Android rooting code structure and go into detail about a few important points.

Let’s look at the root() function in the impl.cpp file. It implements the main logic of the exploit.

At the beginning, after it gets and prints the NPROC limits, it runs the ADB daemon PID and saves it into a variable. It will be used later to kill original process. Next, look at the fork loop:

The code above represents an infinite loop. It forks calling process and exits from a child. That is enough because PID , allocated for current user, remains active until the parent process exits. The loop works until the fork function returns negative value. It means that we have reached the NPROC limit. Let’s look at the next code piece. The PID is negative, but we have to remember that there is one more shell user process that will be terminated soon. This process is the ADB daemon that is still running. We couldn’t kill it on start because the init process would start it again and it is an advantage for us. So, as soon as we reach that condition, we read the ADB daemon PID and check if its user id is AID_SHELL or AID_ROOT (because we could reach the condition from the second or third iteration).If it is AID_SHELL , the program just sends SIGKILL to it and continues the loop (soon, we will reach it again). Once the daemon is killed, one more PID for this user is freed. We have to allocate this PID for the AID_SHELL user as soon as possible to prevent the daemon setting its user id as AID_SHELL . Ideally, there will be two additional loops: the first one forks and allocates a new PID for the AID_SHELL user and, as the result, the second one reaches the limit again, checks the daemon PID that should be AID_ROOT and exits. However, because of lack of resources or lots of delays, there could be rather more iterations.

To prevent the exploit infinite loop in case if it is impossible to start the ADB daemon as root, there is a respawn guard for each forked child. Ten iterations and one second timeout have been chosen empirically when I was working with several devices and I found that some devices had a too big NPROC limit. It is obvious. They enquire too much processor resources to handle all created child processes. So, you may change the guard to fit your requirements or device.

Configuration & Build

The exploit was configured to be built with the NDK toolset both on Linux, and on the Windows platform. If you are working on Linux, it will be enough for you to download NDK only; however, on the Windows platform, you have to download and install the Cygwin environment on your machine. In this paragraph, I will tell you how to configure and build the exploit on the Windows platform.

First of all, download and install the Android SDK. We need only a platform-tools package from the SDK to communicate with a device through ADB, so, at the SDK root directory, start the SDK Manager and check the platform-tools package. Install it.

You can add a path to platform-tools into your PATH variable or type the absolute path to the adb.exe executable any time later.

The second step is to download and install the Android NDK package and the Cygwin environment. Install them in the same location with SDK and add a path to your NDK package into the PATH variable or into your Cygwin .bash_profile . Then unpack a project archive attached to this article into your working directory available for Cygwin.

The project structure is very simple. In the AndroidExploit root, you will find two directories. In the bin directory, I have placed a precompiled exploit binary and a windows shell script file. The jni directory contains sources and the NDK build scripts.

To build the project, run the Cygwin environment, change a directory to the project/jni directory, and execute ndk-build. The Compiler output should look like this:

You can find an executable at libs/armeabi/exploit. The path is relative to the root of the project.

Running

The next paragraph describes how to use the binary file. You download the Android SDK, install platform-tools and make them available from the PATH variable. At first, enable the USB Debugging on your device. For this, from the main screen, go to Settings -> Applications -> Development and check the USB Debugging option, then connect your device to the PC and check that it has been detected by Windows Device Manager. Otherwise, install the Android USB drivers for your device from the manufacturer site.

Type the adb devices command in the command line. It will show you devices connected to your PC. If there are no devices connected, check that Windows Device Manager and Android USB drivers are installed.

We are on the right way! Let’s go to the device. Type the adb shell command, which will start the device shell, and then check your id to see who you are.

As it was expected, you are a shell user that has no privileges, no access, nothing … The only things you can do are installing programs and listing some directories. In other words, you can perform only permitted actions. I was very surprised when I couldn’t read /data/data directory, it was impossible for me to list it and see what programs were installed on my device.

Break the law. Go to the exploit bin directory and type adb push exploit /data/local/tmp . This command will upload the exploit in the device temporary directory available for the user. Then, type adb shell and change the directory to /data/local/tmp. The ls –l command will show you its content and permissions on recently uploaded files. Make the file executable by executing chmod exploit 776 and run it by ./exploit root.

The output shows NPROC and ADB daemon PID. Then, as soon as RLIMIT is reached, the shell will be disconnected. Wait for

5 seconds and type adb shell again. As a result, you should see root # shell. Type id to make sure you are a root.

Yes, you are! Now, you can do anything even… let me think … even damage your device! So, all things you will do next are at your risk. Be careful!

In this article we discussed how to root Androidusing ADB. One more time I want to notice that the exploit works only on Android devices with versions 2.2 and older.

Источник