Adb cannot run as root in production builds как исправить

Method 1: Using Chainfire’s adbd Insecure App

This app might only be compatible with older Android versions (maybe 5 and below). The changes the app makes are not permanent, so after a reboot, all modifications are reversed requiring you to set up the app again. For simplicity and if you want an automatic setup after each reboot, the app includes a toggle for this – but USB debugging must be ON always. Let’s see how to use this app to run adbd in root mode:

— Root your device

— Enable USB debugging

— Download and install the latest version of adbd Insecure app for free here. You can as well download the app from Play Store but it’s a paid app there – you can do this to support the developer.

— Launch the app, grant root and tick Enable insecure adbd. The patching will start right away and when done, you will see Binary: Insecure under the Current status section. If you want automatic patching after a reboot (because changes will be reversed), consider ticking Enable at boot.

— You can now test things out by running the command adb root. If you don’t get the adbd cannot run as root in production builds error or you get adbd is already running as root, then you got success. If things aren’t successful, then you have to try the next method.

— Note that if you have USB connected when the app activates or deactivates adbd root mode, you may need to unplug/replug the cable or run adb kill-server, then adb start-server on your computer before adb will work again.

— If this app fails to work and instead causes issues like your computer doesn’t recognize your device and other adb or USB debugging issues, then either reverse the patching, reboot your device or uninstall the app.

Method 2: Using ADB Root Module

This is a Magisk module that works on Android 9 and 10 (might not work on lower and higher versions). The module works on arm64 devices only.

For safety, don’t forget to disable the module once you’ve done all the things you need. Don’t use it constantly.

The module provides its own adbd binary, which is the binary obtained from AOSP sources with the following patch that disables props checks and usb auth:

diff --git a/adb/daemon/main.cpp b/adb/daemon/main.cpp
index d064d0d..a520bfd 100644
--- a/adb/daemon/main.cpp
+++ b/adb/daemon/main.cpp
@@ -51,48 +51,11 @@
 static const char* root_seclabel = nullptr;
 
 static bool should_drop_capabilities_bounding_set() {
-#if defined(ALLOW_ADBD_ROOT)
-    if (__android_log_is_debuggable()) {
-        return false;
-    }
-#endif
-    return true;
+    return false;
 }
 
 static bool should_drop_privileges() {
-#if defined(ALLOW_ADBD_ROOT)
-    // The properties that affect `adb root` and `adb unroot` are ro.secure and
-    // ro.debuggable. In this context the names don't make the expected behavior
-    // particularly obvious.
-    //
-    // ro.debuggable:
-    //   Allowed to become root, but not necessarily the default. Set to 1 on
-    //   eng and userdebug builds.
-    //
-    // ro.secure:
-    //   Drop privileges by default. Set to 1 on userdebug and user builds.
-    bool ro_secure = android::base::GetBoolProperty("ro.secure", true);
-    bool ro_debuggable = __android_log_is_debuggable();
-
-    // Drop privileges if ro.secure is set...
-    bool drop = ro_secure;
-
-    // ... except "adb root" lets you keep privileges in a debuggable build.
-    std::string prop = android::base::GetProperty("service.adb.root", "");
-    bool adb_root = (prop == "1");
-    bool adb_unroot = (prop == "0");
-    if (ro_debuggable && adb_root) {
-        drop = false;
-    }
-    // ... and "adb unroot" lets you explicitly drop privileges.
-    if (adb_unroot) {
-        drop = true;
-    }
-
-    return drop;
-#else
-    return true; // "adb root" not allowed, always drop privileges.
-#endif // ALLOW_ADBD_ROOT
+    return false;
 }
 
 static void drop_privileges(int server_port) {
@@ -183,9 +146,7 @@ int adbd_main(int server_port) {
     // descriptor will always be open.
     adbd_cloexec_auth_socket();
 
-    if (ALLOW_ADBD_NO_AUTH && !android::base::GetBoolProperty("ro.adb.secure", false)) {
-        auth_required = false;
-    }
+    auth_required = false;
 
     adbd_auth_init();
 
diff --git a/adb/services.cpp b/adb/services.cpp
index 8518f2e..24f9def 100644
--- a/adb/services.cpp
+++ b/adb/services.cpp
@@ -78,12 +78,6 @@ void restart_root_service(int fd, void *cookie) {
         WriteFdExactly(fd, "adbd is already running as rootn");
         adb_close(fd);
     } else {
-        if (!__android_log_is_debuggable()) {
-            WriteFdExactly(fd, "adbd cannot run as root in production buildsn");
-            adb_close(fd);
-            return;
-        }
-
         android::base::SetProperty("service.adb.root", "1");
         WriteFdExactly(fd, "restarting adbd as rootn");
         adb_close(fd);

The binary is required because adb root is usually disabled in compile time by most vendors.

— You should be rooted.

— Download the latest version of the module here.

— Flash it in Magisk and reboot your device.

— You can now test things out by running the command adb root. If you don’t get the adbd cannot run as root in production builds error or you get adbd is already running as root, then you got success. If things aren’t successful, then you have to try the next method.

Method 3: Editing The default.prop File

This method should work for development builds. By default, you should be able to get adbd running as root in eng and userdebug builds but in case this doesn’t happen, then this method should definitely let adbd run as root.

— You should be rooted.

— Go to the system root directory and open the file default.prop in a text or code editor. If adbd wasn’t running as root it was because ro.debuggable was set to 0. Replace 0 with 1 (i.e ro.debuggable=1) and save the file, then reboot your device.

— Test to see that adbd is now running as root. ro.debuggable=1 tells adbd it’s allowed to run as root. This may work, but if it doesn’t, it’s probably because the version of Android you’re using wasn’t compiled with the ALLOW_ADBD_ROOT flag, and the adbd code isn’t configured to check the ro.debuggable setting – which might be the case in production builds.

— Note that the default.prop file can be found in other areas like /vendor but that is not the one you need (it won’t even have the ro.debuggable setting). In my case, the required default.prop file was located as /default.prop as you can see in the photo above.

Method 4: Patching The adbd Binary To Run As Root

Using this method, you can also get luck if the others have failed – but it might only work on older Android versions. You have to extract and unpack the boot image on your device in order to get the adbd binary. You need to Google around a bit how to extract the boot image in case you don’t know – I have even written an article how it’s done if your device comes with a MediaTek chipset (see here). An easier way is downloading the stock firmware of the current build on your device – sometimes, you can come across boot images of specific devices that have been uploaded online – if you are lucky to see that of your device, the boot image should be the same build as that on your device. After getting hold of the boot image, you need to unpack it. There are many tools available for unpacking/repacking the boot image. Let’s consider the magiskboot and AIK tools here.

Magiskboot:

You can find the  magiskboot tool in the Magisk zip in some of the released Magisk versions here. In my case, I got it under Magisk v21.4 (listed as Magisk-v21.4.zip). It is also found under Magisk v21.3 (listed as Magisk-v21.3.zip) and others. You need to click on Assets below any of the sections to display a dropdown list for the download. After downloading, extract it and open the extraction folder. The tool will be located in arm and x86 subfolders – use any depending on your chipset. Not that the common subfolder contains the magisk.apk that you can install manually (as seen in photo three below – click any photo to enlarge).

Another way of getting the tool is when you rooted your device using the Magisk versions that have the Magisk zip. The tool will be installed in /data/adb/magisk [Did you know? magisk modules are installed in /data/adb/modules].

To unpack the boot image and ramdisk, the respective commands are:

magiskboot unpack boot.img
magiskboot cpio ramdisk.cpio extract

The adbd binary is located in the sbin directory of ramdisk (might not be present on some boot images). You can then use Ghidra or Hex Editor to modify the binary as explained here. After doing everything, you need to use magiskboot to patch your ramdisk, and package up a new boot image. The repack command should create a new-boot.img file, that you can upload back to your Android device.

magiskboot cpio ramdisk.cpio "add 750 sbin/adbd patched_adbd"
magiskboot repack boot.img

AIK Tool:

The Android Image Kitchen tool will also lets you unpack the boot image. You will get the ramdisk folder containing the sbin subfolder where the adbd binary is located. You can then skip to this section to modify the binary. After that, you need to repack a new boot image that you can upload back to your Android device. See how to use the AIK tool here.

Others:

There are also many other tools that you can use to unpack/repack boot images e.g carliv image kitchen, mkbootimg, abootimg, etc

Rooted Devices:

Another way of getting the adbd binary is if you are rooted. Having a root file manager, the binary is located in /system/bin or /bin. If you don’t see it there, check /sbin. First make a backup of the binary to a save place. Now move it to the internal storage and do the editing as explained here. After editing the binary, move it back to its location and set permission as it was previously (usually 755 or rwxr-xr-x). Reboot your device. If things don’t work or you face issues, delete the edited binary and replace with the backup you made earlier. Set permission and reboot.

Patching The adbd Binary

Like this guide and this one will suggest, you can easily edit the binary in Ghidra or Hex Editor. Note that Hydra doesn’t do a great job at directly modifying ARM binaries, so consider using a generic hex editor like HxD in such a case.

— The first guide is for Android versions older than Nougat where you have to search for the Local port disabled string, or 0x7d0, which is the shell user’s id in hex. This should bring you to the part of the code where adbd switches from root to the shell user. The goal here is to comment out that code, so the program never stops running as root.

// Don't run as root if running in secure mode.
if (should_drop_privileges()) {
    drop_capabilities_bounding_set_if_needed();
    minijail_change_gid(jail.get(), AID_SHELL);
    minijail_change_uid(jail.get(), AID_SHELL);
    // minijail_enter() will abort if any priv-dropping step fails.
    minijail_enter(jail.get());
    D("Local port disabled");
}

— In the second guide (for Nougat and higher), you have to remove the calls to minijail_change_gid and minijail_change_uid. This can be done by searching for them and replacing the bytes with a series of NOP (no operation) commands i.e 00 BF.

Below is the call to minijail_change_gid in my case (your own values might be different):

To remove the call to minijail_change_gid, I had to find and replace the following series of bytes:

6D 69 6E 69 6A 61 69 6C 5F 63 68 61 6E 67 65 5F 67 69 64  <--- before
00 BF 00 BF 00 BF 00 BF 00 BF 00 BF 00 BF 00 BF 00 BF 00  <--- after

Below is the call to minijail_change_uid in my case (your own values might be different):

To remove the call to minijail_change_uid, do the same.

— You can now save the patched adbd binary. See a sample on how to use HxD here.

Method 5: Custom Kernel

This method is much more easier. You need to install a different adbd on your phone or install a custom kernel/distribution that includes a patched adbd. This can be done by searching online. Though some custom kernels don’t come with adb root, they allow you to easily patch the adbd which is usually hard to do in production builds. Sometimes, you can come across the patched stock boot image of your device online where the developer has modified adbd to run as root. But keep in mind to always use the same version of a boot image as the one on your device.

Are There Any Other Options?

If you are not able to get adbd running as root no matter how hard you’ve tried, there’s still a workaround, capable of substituting commands like adb pull and adb push (of system files/directories), and adb remount, etc. Adb shell commands are there to save you. Though adb shell commands might take much time, but you will also be able to achieve what you wanted if adbd was running as root. Let’s look at some examples below:

— To get started, you should have a rooted device and USB debugging should be enabled on your phone.

— Before doing anything, you will have to first grant root rights to the interactive shell on your Android device using adb shell su (or adb shell, then su) since you will be working with the system root directory.

— To remount ro partitions as rw, the command is mount -o rw,remount /<partition> e.g mount -o rw,remount /system and mount -o rw,remount /vendor.

— Transferring to a PC. You have to copy items from the system root directory to the internal storage first using.

cp <path-in-root>/<filename.extension> <path-on-sdcard>

Most files in the root directory don’t have file extensions, so the command should be:

cp <path-in-root>/<filename> <path-on-sdcard>

If you choose to change directory first, then the commands should be:

cd <path-in-root>
cp <filename.extension> <path-on-sdcard>

Once the item is in the sdcard, you can then pull it to your computer using the adb command:

adb pull <path-on-sdcard>/<filename.extension> <path-on-PC>

Note that copying to sdcard can also be done manually if you have a rooted device and a root file manager installed. This is way easier.

— You should be very careful when doing operations in the root directory. It’s recommended never to use the adb shell mv command (adb shell cp is safe) unless you know what your are doing.

— Transferring from a PC. This is just the reverse of the above process. adb push <path-on-PC>/<filename.extension> <path-on-sdcard> will copy the item from your computer to the sdcard of your device. Now adb shell su and then cp [or mv] <path-on-sdcard>/<filename.extension> <path-in-root> will copy [or move] the item to the root directory. See a list of adb shell commands in this article.

ADB Under Recovery

Some recovery will let you run adb commands. This can be possible on eng and userdebug builds. Some custom recoveries as well can allow adb in recovery mode. This is because custom recoveries come with a lot of modifications and provide much of their own custom binaries like adbd, sh, etc. If you unpack a custom recovery like TWRP using say AIK, you can go to the ramdisk folder then sbin to realize many of these binaries which might not be found in a stock recovery.

— A device should be listed under adb devices, either in recovery or sideload state when you run adb devices.

$ adb devices
List of devices attached
05169339CG105301    recovery

— If adb devices shows the device, but in unauthorized state, then the recovery image doesn‘t honour the USB debugging toggle and the authorizations added under normal boot (because such authorization data stays in /data, which recovery doesn’t mount), nor does it support authorizing a host device under recovery. We can use one of the following options here instead.

$ adb devices
List of devices attached
05169339CG105301    unauthorized

Eng & Userdebug Builds

— adbd service should be running as root by default under recovery in development builds if ro.debuggable=1 in prop.default. If adbd is not running as root in recovery mode, unpack the recovery image. Look inside the ramdisk folder and you will see a file named prop.default. Open it in a text or code editor. Change ro.debuggable=0 to ro.debuggable=1 and save.

Repack the image and flash to your device. You can then test to see if adbd is running as root while in recovery mode. This might not be possible in production builds.

— By default, adbd is always included into recovery image, as /system/bin/adbd. init starts adbd service automatically only in debuggable builds. This behaviour is controlled by the recovery specific /init.rc, whose source code is at bootable/recovery/etc/init.rc.

— Although recovery adb is built from the same code base as the one in the normal boot, only a subset of adb commands are meaningful under recovery, such as adb root, adb shell, adb push, adb pull, etc. Since Android Q, adb shell no longer requires manually mounting /system from recovery menu.

Custom Recovery

— Custom recoveries come with numerous features. You are also able to use shell commands while using a custom recovery and your device is usually detected in adb mode from recovery. This means custom recoveries should come with numerous binaries and command files. Extracting TWRP for example and going to the sbin subfolder of ramdisk, you should be able to see many binaries including sh, adbd, etc – most of the binaries that you will find in /system/bin. These might not be present in stock recoveries. The photos below show the unpacked ramdisk > sbin directory of a stock recovery (in production build) and a custom recovery (TWRP):

Stock recovery

For stock recovery that adb doesn’t run, the only time that the device is detected in adb mode under recovery is during the sideload start.

TWRP

Take note, there’s the twrp app (me.twrp.twrpapp) in one of the photos below which is installed on your device when you choose to install the TWRP app from recovery. You can manually install the app now that you have access to it [click on any of the photos below to enlarge]. The contents in the sbin subfolder have not been shown all.

Contents

• When Does the Adbd Cannot Run as Root in Production Builds Bug Happen?
  • – Running a Database Without Root Privileges
• How To Fix the Adbd Cannot Run as Root in Production Builds Exception?
  • – Running the Adequate Emulator and Entering the Adbd Command
  • – Modify the Binary Values Before Launching the Commands
• Conclusion

C: #Users#Ji Hoon #AppData#Local #AndroidWSdk#platform-tools>

C: #Users#Ji Hoon #AppData#Loca I WAndroidWSdk#platform-tools> #AndroidWSdk#platform-tools>

C: #Users#Ji Hoon #AppData#Local #AndroidWSdk#platform-tools> user sa

#Users#Ji Hoon #AppData#Loca IWAndroidWSdk#platform-tools> se sa

C: #Users#Ji Hoon #AppData#Local Dalam uca kaman Lo KAPPALOOTTO LOUTK

#Users#Ji Hoon #AppData#Local #AndroidWSdk#platform-tools> users WAPDALLO LOUTK

Users#Ji Hoon #AppData#Loca I WAndroidWSdk#platform-tools> muser sa Dalam Mo LOOTS

Users#Ji Hoon #AppData#Loca | #AndroidWSdk#platform-tools> user sa kala

Users#Ji Hoon #AppData#Loca I WAndroidWSdk#platform-tools> user sa kala

Users#Ji Hoon #AppData#Loca I WAndroidWSdk#platform-tools> user sa kala

Users#Ji Hoon #AppData#Loca | #AndroidWSdk#platform-tools> user sa kala PayOOTSK

Users#Ji Hoon #AppData#Loca I WAndroidWSdk#platform-tools> user sa kala

Users#Ji Hoon #AppData#Loca I WAndroidWSdk#platform-tools> users on IWAPDALAM LO

Users#Ji Hoon #AppData#Loca | #AndroidWSdk#platform-tools> users on IWAPDALAM LO

Users#Ji Hoon #AppData#Loca I WAndroidWSdk#platform-tools> users on IWAPDALAM LO

Users#Ji Hoon #AppData#Loca I WAndroidWSdk#platform-tools> se sa KAPPALOOTTO LOUTK

Users#Ji Hoon #AppData#Loca I WAndroidWSdk#platform-tools> se sa KAPPALOOTTO LOUTK

#Users#Ji Hoon #AppData#Local #AndroidWSdk#platform-tools> st #AndroidWSdk#platform-tools>

#Users#Ji Hoon #AppData#Local

#Users#Ji Hoon #AppData#Local muser sm

#AndroidWSdk#platform-tools>

#UsersWJi Hoon #AppData#Loca I WAndroidWSdk#platform-tools>

C: #Users#Ji Hoon #AppData#Loca | #Android#Sdk#platform-tools> WAndroidWSdk#platform-tools>Is

C: #Users#Ji Hoon #AppData#Loca I AdbWinApi.dll AdbWinUsbApi.dll dmtracedump.exe

NOTICE.txt, etcltool.exe

(adb.exe, fastboot.exe)

C: #Users#Ji Hoon #AppData#Local api TATTOFOTOMS Andron aron hprof-conv.exe

libwinpthread-1.dll make_f2fs.exe lib64 COUTSK 123 make_f2fs_casefold.exe mke2fs.conf

mke2fs.exe package.xml #Android#Sdk#platform-tools> source.properties sqlite3.exe systrace X

adb shell setprop ro.debuggable 1

adb shell setprop persist.service.adb.enable 1

adb root

C:#Users#Ji Hoon #AppData#Loca IWAndroid#Sdk#platform – tools > adb devices

List of devices attached

Emulator – 1564 offline

C:#Users#Ji Hoon #AppData#Loca IWAndroid#Sdk#platform – tools > adb devices

List of devices attached

Emulator – 1564 offline

C:#Users#Ji Hoon #AppData#Local #AndroidWSdk#platform – tools > adb devices

List of devices attached

Emulator – 7264 offline

C:#UsersWJi Hoon #AppData#Loca I WAndroidWSdk#platform – tools > adb root

restarting adbd as root

C:WUsersWJi Hoon #AppData#Local #Android#Sdk#platform – tools > adb shell

generic_x86: # cd /data/data/com.Hellow.example54

/system/bin/sh: cd: /data/data/com.Hellow.example54: No such file or directory

2 generic_x86:/ # cd /data/data

generic_x86:/data/data # Is android

com.android.apps.tag

com.android.backupconfirm

com.android.theme.color.purple

com.android.theme.color.space

com.android.theme. font.notoser ifsource X A

if (should_drop_privileges ()) {

drop_capabilities_bounding_set_if_needed();

minijail_change_gid (jail.get (), AID_SHELL);

minijail_change_uid (jail.get (), AID_SHELL);

// the minijail_enter() command will abort if any priv-dropping step fails.

minijail_enter (jail.get ());

D (“Local port disabled”);

}

01 BF 002 BF 03 BF 04 BF <- replaced with NOPs

• Author
• Recent Posts

1