Android adb shell root android

Это руководство для тех, кто хочет получить права root на своем Android телефоне.

Прежде чем начнем сделаем резервную копию данных на всякий случай.

1. Установка ADB

• Скачайте Android-SDK для linux. [Это пакет инструментов для разработчиков под Android] 
• Распакуйте директорию /tools на рабочий стол. [Возможно для этого понадобится установить архиватор 7zip. Он есть в репозиториях Ubuntu.] 
• Создайте директорию «bin» и поместите туда программу ADB:

mkdir -p ~/bin
mv ~/Desktop/tools/adb ~/bin/

2. Сбор необходимой информации

•   На вашем телефоне перейдите (Settings=>Applications=>Development) и включите опцию Отладка по USB(USB debugging)
• Подключите ваш телефон к компьютеру. [*В режиме телефона, не в режиме USB накопителя] 
• В терминале на компьютере выполните «lsusb» без кавычек
• Одна из строк в результате должна быть похожа на что-то вроде (в зависимости от производителя вашего телефона):
  

  Bus 001 Device 002: ID 04e8:681c Samsung Electronics Co., Ltd

• Запишите или запомните первые 4 символа после ID. Это идентификатор производителя (Vendor ID, в нашем примере 04e8). Номера Bus и Device будут разными всякий раз при переподключении телефона к компьютеру или после его перезагрузки.
• В терминале выполните «» без кавычек, эта команда покажет имя и группу пользователя под которым вы вошли в систему (если вы не уверены, что знаете их точно)

3. Установка првила Udev для работы ADB

•   Откройти любимый текстовый редатктор с правами root. Например, в терминале Kubuntu наберите «».
• Вставьте следующую строку без переносов в редактор и измените как указано ниже:
  

  Для нашего примера «идентификатор производителя Vendor ID» заменяем «04e8». Не трогаете кавычки но заменяете < > и все, что в нутри.

• Сохраните файл по этому пути /etc/udev/rules.d/51-android.rules
• И ещё по этому пути /lib/udev/rules.d/51-android.rules

• В терминале, наберите дабы убедиться, что файл на месте, аналогично для второго пути.
• Перезапустите udev или перезагрузите компьютер чтобы изменения вступили в силу

4. Проверяем что получилось

• В терминале наберите «», как делали это ранее
• Одна из строк должна быть похожа на: 
  

  Bus 001 Device 002: ID 04e8:681c Samsung Electronics Co., Ltd

• В данный момент нас интересуют номера после Bus и Device, которые, возможно, изменились если вы перезагрузили компьютер.
• В терминале выполните «ls -l /dev/bus/usb/001/002» ВНИМАНИЕ 001/002 это Bus/Device из примера выше, замените Bus/Device на цифры из вашего вывода команды «».
• Если в результате команды имя пользователя и группа отличаются от «root root» можно продолжать дальше. Если это не так, перечитайте и повторите шаги 2 и 3.
• *Убедитесь что ваш телефон все еще в режиме Отладка по USB. Должен быть красный треугольник с восклицательным знаком в строке состояния вашего телефона (зависит от темы и версии Android).
• В терминале наберите «sudo adb devices» [*sudo понадобится только при первом запуске adb.]

Вы должны увидеть свой телефон в списке.

5. Загрузка Samsung Fascinate Root Package
Эти файлы необходимы, хотя драйвера не нужны для Linux.

6. Распаковка 4-х файлов в

~/bin

7. Переход в  ~/bin

8. Перенос файлов на телефон и запуск root:
Выполните каждую из следующих строк по отдельности в терминале, скопируйте и встаьте (жмите Enter после вставки каждой строки):

./adb push su /sdcard/su
./adb push rage.bin /data/local/tmp/rage.bin
./adb push busybox /sdcard/busybox
./adb shell

chmod 0755 rage.bin

9. Зафиксируем права root

• В терминале вернитесь в директорию ~/bin введите «»

  На этот раз вы должны получить приглашение # вместо $. Это означает, что теперь вы удаленно зашли на телефон как root.

• Скопируйте и вставьте каждую строку по отдельности (жмите Enter после каждой строки):

mount -t rfs -o remount,rw /dev/block/stl9 /system
cd /system/xbin
cat /sdcard/su > su
cat /sdcard/busybox > busybox
chmod 4755 su
chmod 4755 busybox
exit
./adb install Superuser.apk

10. Убедимся что получили права root

• Перезапускаем телефон
• В терминале выполняем «»
  Вы должны получить приглашение $ 
  Выполните «»
  На телефоне должно появиться всплывающее сообщение где запрашивается подтверждение использования прав суперпользователя. После того, как вы разрешите, приглашение должно измениться на #

P.S. Исходный материал взят здесь

ADB and Fastboot are versatile command-line tools for Android devices and emulators. It’s very easy to download and set up ADB and Fastboot on Windows, macOS, and Linux. Since Google doesn’t provide the Android SDK platform tools for Android devices officially, it’s not easy to install ADB and Fastboot on Android devices via the Termux terminal emulator app and Web ADB without root and a laptop or PC.

It’s possible to install ADB and Fastboot on Android by cloning any of the 3 Gits listed below using a terminal emulator like Termux.

Must Read: How to Use ADB to Unlock Android PIN and Pattern Lock

Installing ADB and Fastboot via Termux

Now let’s see how you can install ADB and Fastboot on an Android phone or tablet.

1. Download and install Termux from the Play Store.
2. Having installed the app, you need to grant Storage permission to Termux. To do so, go to Settings > Apps > Termux and tap on Permissions. Then tap on Storage and select Allow.
3. Now open Termux, type the following command, and tap the Enter key on the keyboard.

   pkg update

4. Now, execute the following command to upgrade Termux packages.

   pkg upgrade

5. Since ADB Fastboot Termux is a Python-based script, we need to install Python on the Android device. Issue the following command in Termux.

   pkg install python

   

6. While Python is being installed on your Android device, you might be prompted to authorize the installation by typing ‘Y‘ (for Yes).
7. Since we have to clone Git from Github, you’ll need to install another package called Git using this command.

   pkg install git

   

8. Okay, it’s time now to clone the ADB Fastboot Termux Git using Termux.

   git clone https://github.com/freetheorange905/adb-fastboot-termux.git

   

9. Now that the ADB and Fastboot Git has been cloned to your Android device we need to change the path directory path using cd as shown below (see the screenshot above).

   cd adb-fastboot-termux

10. Finally, execute the following command in Termux.

    python af.py

11. As soon as you tap the Enter key, a new screen will appear and you would be prompted to type 1 to install ADB and Fastboot on your Android device, and 2 to uninstall if already installed them. Type 1 and tap the Enter key.
12. When ADB and Fastboot are installed, you’ll get a message saying, “Tools were successfully installed!“

You can also install the ADB and Fastboot tools on your Android using a single command. This command includes all the above commands in one line.

pkg update && pkg upgrade && pkg install python && pkg install git && git clone https://github.com/freetheorange905/adb-fastboot-termux.git && cd adb-fastboot-termux && python af.py

If you own a Samsung Galaxy device, you can download Samsung firmware on your phone or tablet via Termux. Read my detailed tutorial to learn how you can do that.

adbadb help

As you can see below, you’ll get information such as the Android Debug Bridge version and other ADB options on your phone’s screen.

Please note that if you run the adb devices command, you won’t get any device ID under the list of devices attached because your Android device will now act like an ADB/Fastboot host.

Please note that in order to use ADB and Fastboot commands, your host Android device needs to be rooted as it can be done using a Magisk module called ADB & Fastboot for Android NDK. I’ll be updating this tutorial describing the steps to use ADB commands without a PC or laptop.

Very recently, a developer named Yume Chan launched a website that lets us use ADB commands on Android devices via mobile browsers like Chrome and Microsoft Edge. It means that now we no longer need a rooted Android device to use ADB. Web ADB, as it’s aptly named, makes use of the WebUSB API found in all Chromium-based desktop and mobile browsers.

Web ADB comes with a bunch of features. It lets you send ADB commands from one Android device to another, mirror the screen and control the other device, install APK, browse the files on the other device, capture screenshots, etc.

• Two Android devices (phone or tablet).
• A USB OTG or a USB Type-C to a USB Type-C cable.
• Enable USB debugging on the Android device you want to send ADB commands.

Let’s see how to use Web ADB to run ADB commands on Android devices without root. You can one of two Android devices you have as a host to perform ADB commands on the other device.

1. Open Web ADB website on the Android device you want to use as a host.
2. Tap the 3-dot icon in the Chrome browser and enable the Desktop site option.
3. Insert the USB OTG or the USB Type-C cable on the device you want to use as a host. Now plug in the other end of the USB cable into the client Android device you want to send the command to.
4. Tap on the Add Device option on the Web ADB website. Select your device in the pop-up window and tap on the Connect button.
5. Tap on OK when the browser asks to grant access to your connected device.
6. At this point, you will receive a notification on your second device asking you to Allow USB debugging. Tap on Allow.
7. You’ll see your device codename in the Web ADB command box. It means that both devices have been appropriately connected for ADB operations.
8. You’re now all set to use ADB commands or ADB Shell commands to control the connected Android device. Just keep in mind that you are supposed to omit “adb” and “adb shell” in the commands that you use while executing them on a computer. For example, if you want to reboot the connected Android phone or tablet into the bootloader mode, you should use just reboot bootloader and tap on the Enter key on the keyboard.

You can execute any other ADB command on your Android device without a laptop or PC without rooting your device.

Read Next: List of 500+ Funny Things to Ask Google Assistant

What is rooting?

Rooting in other terms even referred as jailbreaking, is a process of unlocking the operating system, which lets you install any apps including those unapproved by Google, update OS, replace firmware, overclock your device process and so on.  By rooting your Android device you can actually modify all its default settings, graphics and even codes in order to achieve faster performance, better battery life, and more interactive UI. However, here are some of the simple steps to Root your Android devices in an easy way:

Requirements for rooting Android phone

• Your unrooted Android phone
• PC with ADB Drivers Installed. If not installed then Download from Here: adbdriver.com/‎ and set a user defined path to the adb
• Download su, busybox and Superuser.apk files

Steps to root Android device:

Now once you have your ADB setup ready and have all proper exploit files in place, you can begin the rooting process. However, before running commands put your phone in USB debugging mode:  Go to Settings > Applications > Development > Enable USB debugging and connect it to your computer. Then, open command prompt:

• In Windows — click on Start, then Run, and type cmd.exe
• In Linux- open terminal emulator whichever suits you

Once the command prompt is open, enter your platform-tools folder (directory). For this you can use the “cd” or change directory command. Also in case your sdk folder is called “android-sdk” then your command will be:

With this, your shell prompt will be in the platform-tools directory and from here you can run the commands.

• adb devices

• adb root
• adb push su /system/bin
• adb push busybox /system/bin
• adb push Superuser.apk /system/app

• adb shell

• chmod 7655 /system/bin/su
• chmod 755 /system/bin/busybox
• chmod 644 /system/app/Superuser.apk
• chown root:shell /system/bin/su
• chown root:shell /system/bin/busybox
• chown root:shell /system/app/Superuser.apk

With this you have successfully rooted your Android device, now just disconnect your tablet/phone and then reboot it. You can now install any app or customize your Android device as you wish.

I need to make a script that executes a lots of thing on Android device, my device is rooted, when I enter on the shell, I can give the command su, and it works but I need pass this command like:

adb shell "
su;
mv /sdcard/Download/app_test /data/local;
cd /data/local;
./app_test;
exit;
exit;
"

when I put some commands before the su it works, according what I read su creates a new shell that return immediately, but I need give commands on the su shell, how can I do that?

asked Dec 3, 2014 at 14:34

Well, if your phone is rooted you can run commands with the su -c command.

Here is an example of a cat command on the build.prop file to get a phone’s product information.

adb shell "su -c 'cat /system/build.prop |grep "product"'"

This invokes root permission and runs the command inside the ' '.

Notice the 5 end quotes, that is required that you close ALL your end quotes or you will get an error.

For clarification the format is like this.

adb shell "su -c '[your command goes here]'"

Make sure you enter the command EXACTLY the way that you normally would when running it in shell.

13 gold badges80 silver badges91 bronze badges

answered Dec 3, 2014 at 14:39

A-Droid Tech

24 silver badges33 bronze badges

On my Linux, I see an error with

adb shell "su -c '[your command goes here]'"

su: invalid uid/gid ‘-c’

The solution is on Linux

adb shell su 0 '[your command goes here]'

answered May 10, 2020 at 7:45

hannes ach

7 gold badges61 silver badges84 bronze badges

The su command does not execute anything, it just raise your privileges.

Try adb shell su -c YOUR_COMMAND.

answered Dec 3, 2014 at 14:37

13 gold badges59 silver badges112 bronze badges

Adb shell su

C:\>adb shell id
uid=2000(shell) gid=2000(shell)
C:\>adb shell 'su -c id'
/system/bin/sh: su -c id: inaccessible or not found
C:\>adb shell "su -c id"
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
C:\>adb shell su -c id
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0

win msys bash

msys2@bash:~$ adb shell 'su -c id'
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
msys2@bash:~$ adb shell "su -c id"
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
msys2@bash:~$ adb shell su -c id
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0

Adb shell -t

if want run am cmd, -t option maybe required:

C:\>adb shell su -c am stack list
cmd: Failure calling service activity: Failed transaction (2147483646)
C:\>adb shell -t su -c am stack list
Stack id=0 bounds=[0,0][1200,1920] displayId=0 userId=0
...

 shell [-e ESCAPE] [-n] [-Tt] [-x] [COMMAND...] run remote shell command (interactive shell if no command given) -e: choose escape character, or "none"; default '~' -n: don't read from stdin -T: disable pty allocation -t: allocate a pty if on a tty (-tt: force pty allocation) -x: disable remote exit codes and stdout/stderr separation

Android Debug Bridge version 1.0.41
Version 30.0.5-6877874

answered Nov 12, 2020 at 19:19

19 silver badges17 bronze badges

By default CM10 only allows root access from Apps not ADB. Go to Settings -> Developer options -> Root access, and change option to «Apps and ADB».

answered Feb 4, 2016 at 19:21

for my use case, i wanted to grab the SHA1 hash from the magisk config file. the below worked for me.

adb shell "su -c "cat /sbin/.magisk/config | grep SHA | awk -F= '{ print $2 }'""

answered May 28, 2020 at 19:51

adb shell su root <your command>

e.g., to access the external storage (sd card):

adb shell su root ls storage/0/emulated

answered Dec 21, 2021 at 9:56

The main reason for that is the fact that it carries out all the modifications systemless-ly. That is, it doesn’t modify the device’s system partition. As a result, Google’s Safety Net won’t be triggered and the apps dependent on it will continue to function as expected. Apart from that, Magisk also holds some other benefits like the Magisk Hide feature.

This allows you to hide root from apps that don’t work on the rooted devices (like banking apps, Pokemon Go among others). Owing to all these reasons, we will be listing two different methods to root your Android device via Magisk itself. So without any further wait, let us begin with the guide. With that said, here are the 6 most popular universal root tools for Android that you should definitely check out.

• Make a complete backup of your Android device. Although rooting an Android device doesn’t wipe data, still, it is always recommended to be on a safer side.
• Your device should also be having an unlocked bootloader. If that’s not the case, please refer to our guide on how to unlock the bootloader of Android devices.
• Set up the Android SDK Platform Tool on your PC.
• Similarly, enable USB Debugging on your device from Developer Options. This will create a debug bridge between your device and platform tools to successfully execute ADB Commands.
  
• Download the latest Magisk Manager APK and Magisk ZIP. Transfer it to your device’s internal storage or SD Card.

With the requirements now clear, here are both the methods to root your Android devices.

Root Android Phone via TWRP

First off, to root your Android device via recovery, you will need a working TWRP image for your device. Please don’t use any other device’s recovery. You will definitely end up in a bootloop. If there isn’t one for your device, then skip to Method 2. Also, make sure the recovery has been installed on your device. We have a detailed tutorial on installing TWRP on Android. Now with the instructions clear, let us proceed with the steps to root your Android device.

1. Boot your device to TWRP Recovery. Either use the specific hardware key combinations for that or execute the below command. For the latter, head over to the platform-tools folder and type cmd in the address now, and hit Enter.
2. Now enter the given command in the Command Prompt:

   adb reboot recovery

3. Your device will now boot to TWRP Recovery. Go to Install, browse to the Magisk ZIP file and perform a right swipe to install it. This zip file is needed to root your Android device.
4. Now go to Reboot and tap on System. Once your device boots up, install the Magisk Manager APK.
5. That’s it. Open the app and you should now see the message that Magisk is up to date (see screenshot below).

With that, you have successfully rooted your Android device. Let’s now check out the steps to do so via fastboot commands. On that note, also have a look at 10 useful Windows command prompt tricks that you should be aware of.

Root Android with ADB & Fastboot Commands

If there isn’t any working TWRP for your device or you don’t wish to install one for whatever reason, then this method might come in handy. For this to work, you will be needing the stock boot.img file of the same version which is currently installed on your device. You could extract the same from the stock firmware of your device. Just make sure that there is no version mismatch. Otherwise, bootloop is evident.

1. Install Magisk Manager APK on your device. Open it and tap on Install next to “Magisk is not installed” keyword. Again tap on Install in the next pop-up.
2. Now tap on Select and patch a file. Select the boot.img file and wait till Magisk patches it.
3. Connect your device to PC via USB cable. Head over to the Downloads folder on the Internal Storage, copy the magisk_patched.img file and transfer it to the platform-tools folder on your PC. This file is needed to root your Android device.
4. Now, enter cmd in the address bar of platform-tools and press Enter. This will launch the Windows Command Prompt window. Enter the below code to boot your device to fastboot or bootloader mode:

   adb reboot bootloader

5. Your device should now be boot into fastboot mode. Execute the following command to flash this patched boot image onto your device:

   fastboot flash boot magisk_patched.img

6. It should be successfully installed on your device within a matter of seconds. You could now reboot your device via the Power key or the below command:

   fastboot reboot

That’s it. You have now successfully rooted your device via TWRP Recovery. Now go ahead and dive deep into the mods community and give our device a completely new makeover. There are tons of Magisk Modules, Xposed framework, and Custom ROMs, all waiting for a place on your device. Go and give them a shot!

Must Read: How to Android Lock Screen PIN & Pattern via ADB

We have compiled quite a huge list of ADB, ADB Shell, and Fastboot commands with detailed explanations to all commands you may ever need to use.

Android phones come with lots of pre-installed apps that may not be of any use. Since we can’t freeze or uninstall system apps on Android normally, we either need root privilege or take advantage of ADB shell pm uninstall command. If you have a rooted Android phone, you can use a system app remover to delete bloatware.

I recently prepared a list of Samsung system apps and described the easiest way to uninstall preinstalled apps. In this tutorial, we’ll discuss how we can disable or freeze background apps and delete system apps on unrooted Android devices. Besides, we’ll also see how to re-install uninstalled apps using ADB commands. In case your phone has root access, I’ll also lay out the steps to debloat Android devices using the Debloater Magisk module.

The tips given in this tutorial can help you get rid of bloatware on all Android devices including Samsung, OnePlus, Google Pixel, Xiaomi, Redmi, Huawei, Honor, Nokia, Oppo, Realme, Vivo, Motorola, Lenovo, etc. running Android 5.0 or above.

Get Android Bloatware List via ADB

We all recognize apps by their names shown on the device app drawer. However, to be able to uninstall system apps, you must know the package name of the apps you want to remove. There are 3 ways to find the package name of an Android app.

1. Visit a Google Play Store app’s page in a desktop browser. The package name is located right after ‘id=‘ in the URL. An app package name looks like ‘com.google.android.gm‘.  You may not find the package names of the system apps though.
2. Try apps like Package Browser, App Inspector, Package Name Viewer, etc.
3. You can also get the full list of packages installed on your Android phone or tablet using adb shell pm list packages command.

Anyway, let’s check out how we can have the complete list of system apps present on any Android device. Please note that to execute ADB commands you need to set up ADB and Fastboot on your Windows, Mac, or Linux computer and install the appropriate Android USB driver.

Don’t Miss: Use ADB Commands on Android Phone without Root

1. Download the latest Android SDK Platform-tools and extract the zip.
2. Open your device Settings and turn on USB debugging from Developer options.
3. Go to Display under the phone Settings and increase the Screen Timeout duration.
4. Now connect your Android device to the computer via USB.
5. Navigate to the “platform-tools” folder and launch a Command Prompt or PowerShell window. You can get this option in the Windows Context menu by pressing the Shift key + Right-click button on the mouse.
6. Alternatively, you can quickly open a command window from within a folder window by typing “cmd” in the File Explorer’s address bar and pressing the Enter key.

   

   Type ‘cmd’ to launch a command prompt

7. When you have opened the Command Prompt, issue the following command to check if a proper connection between your computer and ADB daemon has been established.

   adb devices

8. Meanwhile, keep an eye on the display of your phone, make sure it’s is not locked, and authorize ADB access on your device when prompted.

   

   Authorize ADB on Android

9. If the connection is made successfully, you’ll see the device ID in the command window as highlighted below.
10. You are now all set to print the list of all bloatware on your Android phone or tablet. Type adb shell and hit the Enter key.

    adb shell

11. Depending on what type of app packages you want to list, use the following commands. Using the 3rd command, you list apps from a certain vendor like ‘samsung’, ‘google’, ‘xiaomi’, ‘huawei’, ‘android’, ‘amazon’, ‘oppo’ ‘coloros’, ‘evenwell’, ‘facebook’ etc.
    #1 List all installed apps
    pm list packages
    #2 List only system apps
    pm list packages -s
    #3 List apps by group
    pm list packages | grep ''
12. Below is how I generated the list of all system apps on my Samsung Galaxy S20 Ultra. The portion highlighted with yellow contains the app package names.

    

    Samsung bloatware list adb

13. Highlight the contents of the command window and press Ctrl + C to copy it. Save this list of system apps to a text file for future use.

Due to the difference between the names of apps and their packages, it might be very difficult to recognize an app by its package. Moreover, it’s also difficult to decide which apps are safe to remove. You can google to find the list of safe to uninstall bloatware for your Android device. Another way to get the real name of an app by its package is to paste the package name into the Google search box. That way, you can shortlist the system apps you can delete without encountering any problems.

I have prepared the list of bloatware present on devices from different Android OEMs.

Don’t Miss: How to Change Android Device Name using ADB Command

Once you have the list of Android bloatware ready, you can easily remove them using ADB uninstall system app command.

1. Launch the Command Prompt as described above. The easiest way to open a command window is to type “cmd” in the File Explorer’s address bar and press the Enter key. You can also launch a command window by clicking on File> Open Windows PowerShell option in the folder window.
2. Connect your Android device to the computer with USB debugging enabled and unlocked screen and execute the following command.

   adb shell

3. Doing so will return your phone’s code name followed by a dollar ($) sign in the Command Prompt. You just need to issue one of these 2 commands to uninstall a system app on your Android.
   #1 To uninstall an app with its data
   pm uninstall --user 0
   #2 To uninstall an app but keep its data
   pm uninstall -k --user 0
4.  Now, type the command you prefer and hit the Enter key. With the removal of each system app, you’ll get a “Success” message.
5. You can thus uninstall as many system apps as you want.

Reinstall Uninstalled Android Apps via ADB

cmd package install-existing 

Don’t forget to execute adb shell before you use the above command as shown below.

app re-installation adb command

Remove Bloatware on Android (Root)

In case you have a rooted device, you can remove system apps easily using apps like System App Remover and Bloatware Remover. Moreover, you can also delete bloatware on Android devices rooted with Magisk with a module called Debloater.

Freeze Background Apps on Android

1. Launch the Command Prompt.
2. Connect your device via a USB cable.
3. Issue the following command.

   adb shell

4. Then execute the following command. Don’t forget to replace in the command below with an app.

   cmd appops set RUN_IN_BACKGROUND ignore

   

   Freeze background apps using ADB

5. To enable the frozen app and allow it to run in the background again, you can use the following command.

   cmd appops RUN_IN_BACKGROUND allow

Disable System Apps on Android via ADB

adb shell
pm disable-user --user 0 

adb shell
pm enable --user 0 

Delete Failed Internal Error in ADB

Failure[Delete failed Internal Error]

adb shell
su
mount -o rw,remount /system
rm -rf /system/app/
rm -rf /data/data/
mount -o ro,remount /system
exit
exit

Read Next: How to Turn Safe Mode On or Off on Android

Disclaimer

This tutorial is quite old and more to serve as inspiration, than a step by step guide. Much have changed in the Android system, and more potent tools are available nowadays (such as «abootimg» included in many GNU/Linux distributions).

How to gain root access on an Android device

Here I describe the generic way to gain root access on an Android device. This description applies to any Android device using a bootloader that is possible to unlock. Most vendors today ship their bootloaders locked with the option to unlocking them, most often voiding the warranty.

If you got a well known and/or not brand new device, there probably already exists ready-made one-click tools rooting your device much easier than this. This tutorial is if you don’t got such a tool, or for some reason don’t want to use them — or if you simply are curious about the methods used.

All tools used here assumes you are using a GNU/Linux environment such as Debian, Ubuntu or so.

Steps

• Unlock the bootloader
• Obtain your boot image
• Unpack the boot image
• Unpack initramfs root file system
• Enable insecure mode
• Pack initramfs
• Pack boot image
• Fastboot device using own boot image
• adb shell to the device

Unlock the Boot-loader

This tutorial assumes you have a device with either an unlocked or unlockable bootloader. This is the most common today. The phone is shipped with the bootloader locked (i.e. tamper proof), but the manufacturer gives you the option to unlock it. This is usually at the cost of the the Digital Rights Manager data (DRM) and also often limits the warranty. This is quite understandable, since you can easily damage the unlocked device for example by overclocking it beyond its thermal capacity, melting the CPU, to mention a worst case scenario.

With the bootloader unlocked, you are able to both boot the device, and/or flash the internal disk, using custom root file system images.

Make sure your vendor allows you to unlock your device before continuing this tutorial. You may wait with the actual unlocking until you created your new boot image, though. If you can’t find any information about the state of your bootloader, just try booting you device with the image you’ll build here. Either it works, or your device politely refuses it.

Obtaining the boot image

Now you’ll need to get hold your original boot image. You can either extract this from the device itself, get it from your manufacturer or from some trusted source on the Internet providing original images. Often the original distribution is a zip archive (but not necessary with the .zip extension). Unzip it to get the boot.img file.

Unpacking the boot image

The boot image (boot.img) is composed of both the kernel and the initial root file system (initramfs). To split this, you’ll need some utility. I’ve written such tool here below. There are several other, often script based, tools out there as well.

Unpacking the root file system

# mkdir rootfs
# cd rootfs
# gzip -cd ../initramfs.cpio.gz | cpio -i

Now the file system is unpacked in the directory «rootfs».

Set the Android to insecure

Android got a security feature you can turn on or off. Usually this should be enabled for production environment and disabled for development devices. By turning security off, you can gain root access.

• Edit /default.prop in the root file system and set the property "ro.secure=0".

Pack the root file system

All done, now we only have to repack everything again. Pack the root file system.

# cd rootfs
# find . | cpio -o -H newc | gzip > ../insecure_initramfs.cpio.gz
# cd ..

Compile the boot image

Now we build the new insecure boot image. Use the same parameters unmkbootimg suggested to get base address and so correct. If unmkbootimg didn’t print out any base address, it’s because default is used, and you won’t need to specify it to mkbootimg neither.

$ mkbootimg --kernel kernel.gz --ramdisk insecure_initramfs.cpio.gz --base 0x20000000 --cmdline 'no_console_suspend=1' -o insecure_boot.img

Please note that the kernel file may be called «kernel.gz«, «zImage» or similar depending on what tools used extracting it from the original boot image.

(instead of mkbootimg you may use the tool abootimg found in some Linux distributions, e.g. Debian and Ubuntu)

Boot the device in Insecure mode

• Device powered off. Press and hold Volume-UP during power on.
• Device powered off. Press and hold Volume-UP and insert USB cable connected to computer.

If this doesn’t work, Google «fastboot» plus your device name.

Once in fastboot, boot the phone using the fastboot command, supplied with the Android SDK.

$ fastboot boot insecure_boot.img

Now the phone will (hopefully) start and look as usual. The only difference is that security is turned off.

Open a root shell on you device

$ adb shell
root@android:/ #

You are now root! Do whatever you want, e.g. installing a su program in /system/bin etc. Remember to remount /system in read/write mode before you can write anything there.

Because you did not flash your device with the insecure boot image, the next time you reboot it, security will be turned on again, for your protection. The modifications you’ve done on /system are of course still there.

$ fastboot flash boot my_boot.img

I don’t recommend using ro.secure=0 as default, though, but there may be other changes you want to apply to the root disk.

It didn’t work?!

Some devices seems not to honor the ro.secure property — but despair not, we still can fix this. We just have to install a root shell in the root file system instead. Back at your computer, cd to your rootfs directory from above and make sure your device is connected via the USB cable and up and running. Then issue the commands below to perform this.

root@ubuntu:~/rootfs# adb pull /system/bin/sh sbin/rootsh
root@ubuntu:~/rootfs# chmod a+x sbin
root@ubuntu:~/rootfs# chown root sbin/rootsh
root@ubuntu:~/rootfs# chgrp 2000 sbin/rootsh
root@ubuntu:~/rootfs# chmod 4750 sbin/rootsh 

Now go back and continue from «Pack the root file system» above to create a new boot image. Once the device is booted using this new image you can execute your root shell to gain root.

root@ubuntu:~# adb shell
shell@android:/$ /sbin/rootsh +p
# 

You are now root.

Selinux

Modern Android devices may run selinux. This will most likely prevent execution of the rootsh above. If this is the case, try disable selinux by setting property "androidboot.selinux=disabled" and report back to me if it did the trick. 😉

Feedback? Questions? Suggestions?

This tutorial too basic? Too complicated? Inaccuracies? Did not work as expected?

Please feel free send me a mail!

/By Mikael Q Kuisma

Мой первый Android телефон Galaxy Note N7000 был приобретен сразу после анонса в октябре 2011 года. Благодаря одному немецкому умельцу под ником bauner, у меня была возможность использовать последнюю версию CyanogenMod (ныне LineageOS). До тех пор, пока полтора года назад телефон не умер от китайской автомобильной зарядки.

Замену искал долго и остановился на Kyocera (да, они и телефоны выпускают) KC-S701. Он отличается брутальным внешним видом и отсутствием сенсорных кнопок. О root доступе к телефону я тогда даже и не задумывался, полагая, что нынче каждый телефон тем или иным способом имеет возможность получения root. И найдется умелец, который сможет под него портировать CyanogenMod. Я ошибался.

За полтора года было выпущено всего одно обновление — фикс падения ядра от специально сформированного ping пакета. А Android KitKat уже год назад был не первой свежести. Root доступ на этот телефон так никто и не получил, и никакой информации о нем не было. Отмечу, что тоже самое железо используется в американской версии телефона Kyocera Brigadier E6782, в котором по-умолчанию активизирован режим fastboot и нет ограничения на запуск неподписанных ядер (именно запуск, а не прошивку, и только при использовании непропатченного bootloader’а, CVE-2014-4325) и присутствует возможность загружаться в эти режимы путём зажатия кнопок телефона. Стараниями Verizon (а может Kyocera?) версия Android на Brigadier была обновлена до Lollipop.

Итак, я решил разобраться с процессом получения root на Android самостоятельно.

Два месяца назад я ничего не знал об устройстве Android (а сейчас я еще больше не знаю). Большую часть знаний пришлось добывать изучением исходных кодов и экспериментами, т.к. информации о взломе Android в интернете очень мало. Последующее описание справедливо для Android 4.4 KitKat, но не исключено, что оно заработает и на более новых версиях.

Хочу обратить ваше внимание на то, что в данном обзоре описан исключительно мой конкретный опыт взлома Android на конкретной модели телефона, поэтому будьте предельно осторожны с его применением в своей практике, если не хотите внезапно получить мертвый телефон. Перед началом исследований я рекомендую забыть о том, что вы пользуетесь взламываемым телефоном в повседневной жизни и сделать backup с последующим hard reset. Это обезопасит ваши данные при совершении ошибки.

В статье описаны не только действия, которые привели к успеху, но и ошибки. Надеюсь, что мои попытки докопаться до истины и многочисленные грабли будут вам интересны.

Все исследования проводились в Linux окружении.

Dirtycow (CVE-2016-5195)

Простыми словами dirtycow (рабочий эксплойт под Android) позволяет заменить память любого процесса (полезно, если хорошо знаешь ASM) или любой доступный для чтения файл, даже если он находится на readonly файловой системе. Желательно, чтобы подменяемый файл был меньше либо равен по размеру заменяемому. Основная атака в dirtycow для Android — подмена /system/bin/run-as — подобие sudo для отладки приложений. Начиная с API android-19 (таблица соответствия версий API и Android) /system/bin/run-as имеет CAP_SETUID и CAP_SETGID capabilities флаги (в старых версиях используется обычный suid bit — 6755).

$ getcap bin/run-as
bin/run-as = cap_setgid,cap_setuid+ep

Если файловая система будет примонтирована в режиме read-write, то всё, что dirtycow подменяет, окажется на файловой системе. Потому необходимо сделать backup оригинального файла и восстановить его после получения доступа, либо не перемонтировать файловую систему в режиме read-write. Как правило раздел /system в Android по умолчанию примонтирован в режиме read-only.

Не зря dirtycow считается одной из серьезнейших уязвимостей, обнаруженных в Linux. И при наличии знаний с помощью dirtycow можно обойти все уровни защиты ядра, в том числе и SELinux.

SELinux

Для начала можно почитать как работают контексты SELinux. Неплохая статья на wiki Gentoo: https://wiki.gentoo.org/wiki/SELinux/Tutorials/How_does_a_process_get_into_a_certain_context

Если коротко, то:

• контекст процесса SELinux менять можно, если подобная операция описана в правилах sepolicy. В версии Android 4.4 (KitKat) есть возможность повысить привилегии, изменяя контекст. Но начиная с 5.x это уже сделать нельзя.
• существуют контексты файлов.
• Кроме контекста файлов и процессов в Android реализованы контексты для параметров property_contexts.

Adbd и консоль

$ capsh --decode=0000001fffffffff

Текущий SELinux context можно просмотреть командой id или cat /proc/self/attr/current. Предыдущий контекст процесса можно просмотреть командой cat /proc/self/attr/prev.

Просмотр context’а файлов: ls -Z
Просмотр context’а запущенных процессов: ps -Z

Получаем root доступ

Root, да не тот

Первое, что я сделал это использовал dirtycow по прямому назначению — подменил /system/bin/run-as, который задал UID/GID в 0 (тоже самое делает su). Однако монтировать файловую систему я не мог, даже tmpfs. Загружать модули ядра я тоже не мог. Просматривать dmesg — нет. Я даже не мог просматривать директории, которые имели права 700 и принадлежали другим системным пользователям. Я мог лишь читать и писать в блочные устройства, а просмотр файлов или директорий был возможен благодаря заданию UID/GID определенного пользователя (написал свой велосипед — аналог su, который мог задавать selinux context и пользователя/группу).

Первым делом я сделал дамп всей прошивки, boot и recovery:

$ dd if=/dev/block/mmcblk0 of=/storage/sdcard1/mmcblk0.img
$ dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/storage/sdcard1/boot.img
$ dd if=/dev/block/platform/msm_sdcc.1/by-name/recovery of=/storage/sdcard1/recovery.img

Изучить дамп можно утилитами kpartx и unpackbootimg. Команда kpartx -a mmbblk0.img создает виртуальное блочное устройство, доступное по пути /dev/mapper/loop0. С ним можно работать как с любым другим блочным устройством. Дампы разделов boot и recovery распаковал утилитой unpackbootimg.

Потом попробовал записать в recovery /dev/zero, проверить и сразу восстановить из дампа.

Раз я мог писать в блочные устройства, значит я мог записать custom recovery. Нашел TWRP от Brigadier, прошил в recovery и перезагрузился в него adb reboot recovery. TWRP я не увидел, а лишь иконку Android’а с восклицательным знаком. Так выглядит стандартный recovery, а значит TWRP не прошился.

Пробуем отключить SELinux

На тот момент я думал, что все ошибки об отсутствии привилегий вызваны SELinux (я полностью забыл о том, что могут быть урезаны capabilities). Логов dmesg я не видел, logcat ничего релевантного не показывал. И я начал думать как отключить SELinux.

Первая зацепка, которую я смог найти:

$ grep -A2 reload_policy boot/ramfs/init.rc
on property:selinux.reload_policy=1 restart ueventd restart installd

Исходники говорят о том, что при изменении этой опции, init перезагружает политики SELinux из файла /sepolicy.

Т.е. я при помощи dirtycow могу перезаписать /sepolicy и командой setprop selinux.reload_policy 1 загрузить обновленную политику.

Для начала нужно выяснить что из себя представляет /sepolicy. Изучить его можно с помощью команды sesearch (пакет setools в Debian).

$ sesearch --allow sepolicy
$ sesearch --neverallow sepolicy
$ sesearch --auditallow sepolicy
$ sesearch --dontaudit sepolicy

В моём случае /sepolicy содержал только allow, что значит — при enforcing режиме SELinux в Android разрешено делать только то, что объявлено в политике. А процессу init разрешалось только загружать политику, но не отключать:

$ sesearch --allow sepolicy | grep 'load_policy' allow init kernel : security load_policy ;

Моей задачей было — разрешить init контексту задать selinux->enforce в permissive (setenforce 0).

Первое, что я сделал — собрал стандартную политику стокового Android, подменил оригинальный /sepolicy, загрузил (под root пользователем setprop selinux.reload_policy 1) и получил сообщение в статусной строке, что телефон находится в незащищенном режиме. После этого телефон отказывался запускать приложения, стал очень задумчив, задать permissive режим мне тоже не удалось и в конечном итоге телефон перезагрузился. Отрицательный результат тоже результат, замена /sepolicy сработала.

Первая же мысль: стоковая политика не подходит этому телефону и он при отсутствии прав начинает тупить.

Я собрал новую политику, в которой просто описал все существующие SELinux context и объявил их permissive. Тоже не помогло.

Потом я решил пересобрать политику и по возможности добавить привилегии для shell контекста.

Я нашел статью, в которой говорится как «декомпилировать» политику. Немного повозившись я смог собрать все зависимости и запустить утилиту sedump. На выходе я получил текстовый файл, который я смог собрать обратно (для KitKat checkpolicy -M -c 26 -o sepolicy.new policy.conf) и даже получить файл с точно таким же размером что и оригинальный sepolicy, но разным hex содержимым. Загрузка новой политики вызвала точно такие же результаты, что и ранее — телефон через какое-то время перезагружался.

Я решил собрать две политики: из policy.conf, который я получил и из policy.conf, в котором добавлены все привилегии для allow init kernel : security, в том числе и setenforce. Сравнить файлы в hex и по аналогии заменить байты в оригинальном sepolicy.

Чуть позже я нашел утилиту sepolicy-inject, которая добавляет привилегии в уже скомпилированный sepolicy файл. Если правило уже существует, то добавление максимальных привилегий не увеличивает конечный размер политики. К сожалению запуск утилиты добавляет всего одно правило за раз. Написал скрипт, который добавляет максимальные привилегии для каждого правила. Результатом был файл с политикой, в которой каждое правило содержало максимальные привилегии. Размер файла совпадал с оригинальным. И это опять не помогло.

Потом я узнал, что в Android есть команда load_policy, которая перезагружает политику по любому пути. Танцы с бубном оказались лишними.

adb shell run-as /data/local/tmp/run -u system -c u:r:init:s0 load_policy /data/local/tmp/sepolicy.new

Можно было добавить любой permissive домен, загрузить новую политику и работать в контексте этого домена (кстати, supersu от chainfire для новых версий Android так и работает). Но даже это не дало возможности отключить SELinux. Я решил копать в другом направлении.

Копаем recovery

Запускаю dirtycow exploit, выставляю UID/GID, записываю файл и запускаю adb reboot recovery. Телефон перезагружается и я попадаю в меню стандартного recovery. Уже что-то. Пробую прошить ZIP файл с supersu через adb sideload. Операция прерывается с ошибкой. Толком не смотрю на ошибку, а лезу в код recovery и ищу место, отвечающее за проверку цифровой подписи ZIP файла.

Выясняю, что initramfs содержит публичный ключ res/keys в формате minicrypt, которым проверяется цифровая подпись ZIP файла. Оказалось это стандартный тестовый ключ Android, и что я могу подписать этим ключём любой архив. Проверить это можно следующим образом:

java -jar dumpkey.jar android/bootable/recovery/testdata/testkey.x509.pem > mykey
diff -u mykey res/keys

Попробовал установить ZIP напрямую с sdcard, но в recovery при монтировании sdcard возникала ошибка. Изучил etc/recovery.fstab, оказалось что в режиме recovery sdcard монтируется как vfat:

$ grep mmcblk1 recovery/ramfs/etc/recovery.fstab
/dev/block/mmcblk1p1 /sdcard vfat nosuid,nodev,barrier=1,data=ordered,nodelalloc wait

Моя 64Gb флэшка была отформатирована в exfat. Нашел старую sdcard на 2Gb, отформатировал её как vfat, записал ZIP, вставил её в телефон. Recovery в этот раз смог примонтировать карточку и я мог просматривать её содержимое на телефоне. Однако при установке ZIP опять возникла ошибка: E:failed to set up expected mounts for install; aborting.

Команда strings recovery показала, что этот recovery отличается от стокового, по крайней мере там присутствовали строки, относящиеся к Kyocera, и скорее всего к чистке раздела /data. Покопавшись в оригинальных исходниках я выяснил, что интересующая меня ошибка возникает в функции setup_install_mounts в файле roots.cpp.

Т.е. перед тем как применить ZIP, recovery отмонтирует все разделы, но в моём случае что-то идёт не так.

Копаем исходники ядра

Лицензия GPL обязывает производителей смартфонов выкладывать исходники ядра. Спасибо Линусу и Столлману за это. Иногда производители выкладывают что-то левое, иногда правильные исходники, но без defconfig файла, иногда правильные и очень редко с инструкцией как их собирать (например LG).

В моём случае были исходники с правильным defconfig но без инструкции. Немного попотев я смог собрать ядро и убедился, что это не полная липа.

Через продолжительное время я остановился на двух файлах:

Hooks

Kyocera долго не думала, а просто запилила хуки на потенциально опасные операции в Android: mount, umount, insmod (к загрузке разрешен всего один модуль — wlan и только если его загрузит init процесс), и прочее. Вот где крылась проблема recovery. Он не мог отмонтировать файловую систему /system! Эти операции позволялись только init процессу. В том числе я не мог отключить SELinux потому что эта возможность была отключена при компиляции ядра. Обойти эти хуки можно было только, если ядро загружено с определенными параметрами (kcdroidboot.mode=f-ksg или androidboot.mode=kcfactory, о них чуть позже).

Restart

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

• adb reboot bootloader — режим fastboot, в моём телефоне не доступен (0x77665500 — hex метка 00556677 в разделе sbl1)
• adb reboot recovery — режим recovery (0x77665502 — hex метка 02556677 в разделе sbl1)
• adb reboot rtc — так называемый ALARM_BOOT. Так и не понял для чего, метки в sbl1 нет. Возможно имеется в виду https://developer.android.com/reference/android/app/AlarmManager.html
• adb reboot oem-X (в моём случае oem-1, 0x6f656d01 — hex метка 016d656f в разделе sbl1). Что происходит во время этого режима устанавливается производителем. Судя по исходникам, в этот режим телефон перезагружается при ошибке аутентификации прошивок из раздела modem.
• adb reboot edl — emergency download, переводит телефон в штатный qualcomm’овский download mode. Телефон определяется как QHSUSB__BULK COM port, по которому можно передать подписанный загрузчик (если не ошибаюсь, то каждый загрузчик предназначен для одного типа SoC и производителя телефонов) и выполнять низкоуровневые операции с телефоном, в том числе и прошить. Обычно используется вкупе с QPST. Для некоторых телефонов загрузчики утекают в сеть, например для Kyocera KYL22. Откуда они берутся — мне неизвестно.
• Некий download mode, в который через adb reboot не зайти. Вот тут интересно… Но об этом позже.

Немного о том, как происходит загрузка на телефонах с процессором Qualcomm:

Встроенный ROM загрузчик Qualcomm (pbl — primary bootloader) загружает раздел sbl1 (secondary bootloader). sbl1 загружает tz (trust zone), затем aboot (android boot, little kernel, lk). Aboot в свою очередь загружает boot, recovery или fota.

Описание разделов, участвующих при загрузке:

• tz — Qualcomm Trust Zone. Выполняет низкоуровневые операции, в том числе работает с QFuses (раздел rpmb).
• rpm — Resource and Power Manager firmware. Прошивка для специализированного SoC, отвечающего за ресурсы и питание.
• sdi — trust zone storage partition. Данные, которые используются Trust Zone.

Все эти разделы подписаны цепочкой сертификатов.

Fota

В некоторых случаях полезно игнорировать обновления прошивки.

FOTA — firmware over the air. В отличие от boot и recovery, fota — это неофициальный режим загрузки Android. Задача fota — обновить прошивку. В Kyocera для этого используется решение от компании Red Bend, которое в 35Mb умещает обновление не только ядра но и раздела /system. Потому запись в раздел /system запрещена, иначе наложение патча на неправильные данные может окирпичить телефон.

На мой телефон имелось обновление. Отважиться на него я мог потому, что я уже имел возможность писать в /cache и прервать обновление в любой момент.

Изучив исходники отвечающего за обновление Java приложения, мне стало ясно как оно происходит:

• Java приложение скачивает специальный файл /cache/delta/boot_delta.bin, создает файл /cache/delta/Alt-OTA_dlcomplete, подтверждающий успешную загрузку файла, и другие файлы с header’ами.
• При подтверждении обновления еще раз проверяется наличие этих файлов.
• Если файлы на месте, то через библиотеку libjnialtota.so происходит модификация раздела fotamng.
• Происходит перезагрузка.

Перезагрузка происходит не моментально, значит у меня есть возможность удалить файл перед перезагрузкой и посмотреть что происходит с разделом fotamng.

Пишу команду, которая непрерывно делает дамп раздела и переименовывает /cache/delta/boot_delta.bin. Запускаю её сразу после соглашения о перезагрузки телефона. Телефон перезагружается в режим FOTA, рапортует об отсутствии обновления и перезагружается в обычный режим.

Начинаю изучать данные, которые сдампил. В разделе /cache бонусом получаю логи fota, в которых даже есть логи dmseg! Сама перезагрузка в fota инициализируется байтами «1» в разделе fotamng:

$ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=16 bs=1 count=1
$ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=24 bs=1 count=1
$ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=131088 bs=1 count=1
$ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=131096 bs=1 count=1

После перезагрузки они обнуляются. В dmesg я обратил внимание на наличие параметра ядра kcdroidboot.mode=f-ksg. Вот оно! Т.е. загрузчик снимает защиту для fota. И чисто теоретически, если я запишу раздел boot в fota и перезагружу телефон в этот режим, то я получу ядро с отключенной защитой Kyocera. Но писать в системные разделы я всё еще не могу.

Изучение исходников little kernel (lk)

То, что находится в разделе aboot — загрузчик Android, ванильные исходники которого находятся по адресу: https://source.codeaurora.org/quic/la/kernel/lk/

Там можно найти и информацию как происходит загрузка в некоторые из режимов. Например я нашел информацию о том, что если в раздел misc записать «boot-recovery», то перезагрузиться в recovery можно без adb reboot recovery. При загрузке в recovery эта метка обнуляется. И если recovery загрузиться не может, то телефон попадёт в boot loop и вы его потеряете. Так что будьте осторожны, а лучше избегайте этого варианта перезагрузки.

Там же можно найти код, который переводит системную область emmc в режим read-only. Ответ на вопрос, почему невозможно перезаписать recovery. Эту защиту можно отключить из ядра Linux , если написать соответствующий модуль ядра. Уже всё написано товарищем из страны восходящего солнца, который, похоже, тоже неровно дышит к телефонам компании Kyocera. Модуль с первого раза не сработал, иногда подвешивает mmc в claim mode. Возможно не всё так однозначно и требуется детальное исследование.

Первые успехи

Dmesg

Uevent_helper

В моём случае, на удивление, была возможность задать /sys/kernel/uevent_helper. Если в этот параметр записать путь до executable файла (shell script тоже сойдёт), то он с определенным интервалом будет запускаться от процесса init в контексте init и что самое важное с full capabilities.

Я написал скрипт:

#!/system/bin/sh
echo 0 > /proc/sys/kernel/dmesg_restrict

Загрузил его на телефон и записал его путь в /sys/kernel/uevent_helper. У меня появилась возможность видеть dmesg!

Патченный adbd

Кстати, этой процедуры можно избежать, скомпилировав lsh и подставить его путь в /sys/kernel/uevent_helper. Желательно обернув запуск lsh в скрипт, который задаёт PATH environment, иначе придется задавать полный путь к каждой команде.

WiFi

WiFi в моем телефоне работает через модуль ядра. WiFi включен — модуль загружен. WiFi выключен — модуль выгружен. Если подменить модуль на свой, то при включении WiFi должен загрузиться подставной модуль. На моё счастье цифровая подпись модулей не проверялась. Первое, что я попробовал, это собрать и загрузить модуль, который отключает SELinux путем замены памяти ядра на Amazon Fire Phone: https://github.com/chaosmaster/ford_selinux_permissive

Чтобы собрать модуль, требуется более-менее соответствующие исходники ядра и файл Module.symvers. Если исходники точно соответствуют тому ядру, что используется на телефоне, то Module.symvers, сгенерированный автоматически при сборке ядра должен подойти.

Если при загрузке модуля ядро будет ругаться (disagrees about version of symbol module_layout), то потребуется извлечь Module.symvers из boot раздела. Это можно сделать, используя скрипт https://github.com/glandium/extract-symvers:

$ unpackbootimg -i boot.img -o boot
$ extract-symvers.py -e le -B 0xc0008000 boot/boot.img-zImage > %PATH_TO_KERNEL%/Module.symvers

Нельзя просто так взять и собрать свой модуль для телефона Kyocera.

Помните список доступных для загрузки модулей? Модуль должен называться wlan и никак иначе. Решается это просто:

• создаю symlink wlan.c на исходник модуля
• правлю Makefile

...
MODULE_NAME = wlan
...

Модуль на удивление загрузился (память, которую занимает модуль wlan сократилась, проверяется командой lsmod), но SELinux не отключился.

Единственное, что я не уяснил, как программно вызвать отключение и включение WiFi. Мне приходится выключать/включать WiFi вручную через интерфейс Android.

Пишем свой модуль

Снимаем защиту

SELinux отключить не удалось, но по аналогии с модулем https://github.com/chaosmaster/ford_selinux_permissive можно попробовать сделать тоже самое, но с Kyocera hooks. Мне нужно лишь задать переменную kc_bootmode или kc_kbfm в единицу.

Получив адрес нужной функции, я мог передать в неё параметр и функция задаст переменную в 1. Опытным путем выяснил, что не все ядра отображают kallsyms для переменных (тип d или D, регистр говорит глобальная переменная или нет), поэтому в примерах я использую указатели на функции. Возможно это определяется опцией CONFIG_KALLSYMS_ALL при компиляции ядра.

$ adb shell "grep kc_bootmode_setup /proc/kallsyms"
c0d19d84 t kc_bootmode_setup

Описываю функцию в модуле:

int (*_kc_bootmode_setup)(char *buf) = (int(*)()) 0xc0d19d84;

И вызываю её:

_kc_bootmode_setup("f-ksg")

Можно адреса найти динамически:

_kc_bootmode_setup = (int (*)(char *buf))kallsyms_lookup_name("kc_bootmode_setup");

Загрузка подставного модуля отключила встроенную защиту! Теперь я могу монтировать /system и загружать любой модуль ядра независимо от его имени.

Системная область emmc всё еще доступна только для чтения и не позволяет редактировать /system раздел на постоянной основе. Файлы редактируются, но при очистке cache все возвращается в исходное состояние.

Всё-таки отключаем SELinux

Из спортивного интереса я всё-таки решил отключить SELinux. Заменить defined значение selinux_enabled мы не можем, но мы можем разыменовать структуру с hooks функциями security_ops.

Это делается вызовом функции reset_security_ops:

void (*_reset_security_ops)(void) = NULL;
... ... ...
_reset_security_ops = (void (*)(void))kallsyms_lookup_name("reset_security_ops");
if (_reset_security_ops != NULL) { _reset_security_ops();
}

После этого защита SELinux работать не будет, но система всё еще будет думать, что она включена. Потому возможны некоторые ошибки в работе системы.

Перезагружаемся в download mode

int (*_enable_dload_mode)(char *str) = (int(*)()) 0xc0d0cc18;
... ... ...
_enable_dload_mode("dload_mode");

Та же операция работает и с download_mode, о котором я писал выше. После загрузки модуля телефон перезагружается в спец режим, который работает как usb mass storage device. Т.е. я имею доступ ко всем разделам телефона без защиты от чтения! Попробовал записать свой recovery.

Пришлось ограничить скорость записи, иначе телефон отваливается и запись прекращается. Возможно это результат переполнения кэша mass storage загрузчика. Пришлось написать хак:

BS=512
nextblock=0
IMG=my-recovery.img
DEST=/dev/sdb12
# 64 - total amount of 512*512b blocks for 16Mb partition (16Mb*1024*1024/(512*512))
for i in {1..64}; do echo $i echo dd if=${IMG} of=${DEST} bs=${BS} seek=${nextblock} skip=${nextblock} count=${BS} oflag=direct dd if=${IMG} of=${DEST} bs=${BS} seek=${nextblock} skip=${nextblock} count=${BS} oflag=direct nextblock=$((nextblock+BS)) echo "nextblock = ${nextblock}" sleep 0.5
done
sync
echo 3 > /proc/sys/vm/drop_caches

Загрузил телефон, выполнил adb reboot recovery и ничего. Только вибрация с последующей обычной загрузкой. Помните про раздел misc, не стоит проверять recovery через запись в этот раздел.

При помощи этого же способа я примонтировал /system раздел к компьютеру и вручную записал на него supersu. Первоначальная задача выполнена: перманентный root доступ получен. Осталось автоматизировать загрузку подставного WiFi модуля, который отключает hooks. И хорошо бы, чтобы WiFi после этого оставался работоспособным. А еще лучше разблокировать загрузчик, чтобы загружать своё ядро.

Для начала можно изучить какие средства применялись для разблокировки других телефонов. При беглом поиске я обнаружил лишь следующие два, к тому же устаревшие:

Цифровая подпись aboot и boot разделов

Я пытался выяснить каким публичным ключём подписаны boot образы. Распаковал ключи из aboot (binwalk -e aboot), извлек подписи из образов и прошелся всеми публичными ключами по ним. Выяснил, что все образы подписаны одни ключём. С ходу не разобрался как вычислить смещение подписи у boot разделов, потому я просто перепаковываю образ и использую его размер как смещение. С aboot чуть сложнее. Мне удалось извлечь подпись и расшифровать sha256 образа. А вот понять как самому вычислять sha256, чтобы сравнить с расшифрованным значением, пока не удалось.

#!/bin/bash
# print der certificate:
# openssl x509 -inform der -in 0xff.crt -text -noout
# mkdir boot
# unpackbootimg -i 09-boot.img -o boot
# cd boot
# mkbootimg --kernel 09-boot.img-zImage --ramdisk 09-boot.img-ramdisk.gz --cmdline "`cat 09-boot.img-cmdline`" --base `cat 09-boot.img-base` --pagesize `cat 09-boot.img-pagesize` --dt 09-boot.img-dtb --kernel_offset `cat 09-boot.img-kerneloff` --ramdisk_offset `cat 09-boot.img-ramdiskoff` --tags_offset `cat 09-boot.img-tagsoff` --output mynew.img
# dd if=../09-boot.img of=signature.bin bs=1 count=256 skip=$(ls -la mynew.img | awk '{print $5}')
# cd ..
# binwalk -e 05-aboot.img
# extract aboot signature
# dd if=05-aboot.img of=signature.bin bs=1 count=256 skip=$(od -A d -t x4 05-aboot.img | awk --non-decimal-data '/^0000016/ { i=sprintf("%d\n","0x"$3); print (i+40)}')
# extract base aboot image
# 40 - aboot header size, refer to: https://android.googlesource.com/kernel/lk/+/caf/master/target/msm8226/tools/mkheader.c#160
# dd if=05-aboot.img of=aboot-base.img bs=1 count=$(od -A d -t x4 05-aboot.img | awk --non-decimal-data '/^0000016/ { i=sprintf("%d\n","0x"$3); print (i)}') skip=40
# how sha256 was calculated?
# openssl dgst -sha256 -sign private_key -out signature.bin aboot-base.img ?
NAME=$1
IMG=${NAME}/mynew.img
SIG=${NAME}/signature.bin
#IMG=aboot-base.img
#SIG=signature.bin
CALC_SHA256=$(sha256sum ${IMG} | awk '{print $1}')
for i in `find . -name *.crt`; do ORIG_SHA256=$(openssl rsautl -inkey <(openssl x509 -pubkey -noout -inform der -in ${i} 2>/dev/null) -pubin -in ${SIG} 2>/dev/null | hexdump -ve '/1 "%02x"') if [ "${ORIG_SHA256}" != "" ]; then echo "sha256 was decrypted using ${i} key - ${ORIG_SHA256}" fi if [ "${ORIG_SHA256}" = "${CALC_SHA256}" ]; then echo "sha256 ${ORIG_SHA256}" echo "$i" fi
done

В качестве эксперимента я попробовал записать boot раздел в раздел fota, зная, что при загрузке fota снимаются все ограничения. Здесь я сильно рисковал, т.к. мог получить bootloop, похожий на bootloop recovery. Метка загрузки в fota записывается в раздел fotamng и если раздел не загрузится, то я получу бесконечную перезагрузку.

 ramdisk: 0x01000000 tags: 0x00000100

 ramdisk: 0x02000000 tags: 0x01e00000

В Secure boot whitepaper от Qualcomm говорится о том, что подписывается sha256 hash от sha256 hash’ей нескольких сегментов ELF загрузчика. Количество сегментов определено в Subject’е сертификата. Например OU=05 00002000 SW_SIZE говорит о том, что в подписи содержится sha256 hash от первых 256 hash’ей областей по 32 байта (0x2000/32=256). Сам по себе aboot не содержит ELF заголовка и описание больше подходит к sbl1 (secondary boot loader).

Есть описание работы little kernel от Qualcomm, но и там нет ничего про алгоритм создания подписи aboot. Задача определить алгоритм все еще актуальна.