As I've been working on the Stock ROM release of 10.1.1.A.1.307 some of my users started reporting that the issues I fixed for my 10.1.1.A.1.253 release started popping up again: whenever anyone with a locked bootloader tried to remount /system writable (remount,rw) it spontaneously sprung a reboot... very annoying, to say the least!
It gets even better (or worse, depends on how you look at it) when you consider any CWM version ever released for our Z/ZL models will ask us if we want it to prevent the ROM from flashing STOCK recovery... /system/etc/install-recovery.sh is the culprit here as it is what CWM disables by making it non-executable when you say YES to the question 'ROM may flash stock recovery on boot, fix?'. It actually is an important part of the rooting process we all know. It stopped the RIC service and prevented the reboots from happening. If someone said YES, the issue mentioned in the previous paragraph would also start happening and some users have even reported loss of root and even bootloops because of this...
I've set out to find a fix for it, one that eliminates the chance a regular run-of-the-mill CWM user will ever encounter the question ever again.
For all of the regular users, download one of these:
Warning for Xperia T [ALL VERSIONS] Users: There is a problem with this patch combined with the CWM package for your phones, it seems to be busybox related. @garik.007 found the solution to this issue: BusyBox by Robert Nediyakalaparambil. Install that app, update your busybox and it will fix CWM and the remount-reboot fix
WINDOWS INSTALLER: [NUT]'s definitive remount-reboot fixer!
Make sure you have USB debugging turned ON.
Download the package, save it somewhere you remember
Unzip it somewhere you remember
Run the install.bat file and choose the superuser app you are using.
Done!
The phone should do what the installer tells you it's doing, so if it says your phone will reboot, it will. If it did NOT explicitly say that it would then something went wrong!
RECOVERY FLASHABLE: [NUT]'s definitive remount-reboot fixer!
This is a flashable ZIP, install using CWM or TWRP and you're done!
It is safe to use on any STOCK (Read: NOT CM Based) ROM version released for all Xperia phones with the ric binary incorporated in the ramdisk (/sbin/ric) up to now. To see if this fix will work for your device, check if the 'ctrlaltdel' command is executed from the init.sony[anything].rc scripts. If it is, this will work!
NOTE: As this fix needs busybox to function and will install or update busybox in /system/xbin if no busybox or no busybox binary which supports the 'nohup' applet was found in /system/bin, /system/xbin or /sbin.
NOTE 2: As soon as you have installed this rootfixer and you saw it replace the already installed busybox, remove any and all busybox installer apps you have, it will probably break the rootfixer if you update busybox using that app. The version this rootfixer installs is rock solid and is used by most if not every kernel dev working on Xperia line kernels.
NOTE 3: If you have an unlocked bootloader, you can actually also install it, it won't hurt and you'll be protected from the reboots if you re-lock your phone!
XDA:DevDB Information
The definitive root Remount-Reboot fix!, Tool/Utility for the Sony Xperia Z
Contributors
[NUT]
Version Information
Status: Stable
Stable Release Date: 2013-06-25
Created 2013-06-27
Last Updated 2015-02-05
Reserved
For the ROM chefs and other devs on XDA:
I'm proud to donate the following to the dev-community on XDA, for anyone who wants to integrate it in his/her ROM or rooting tool, there is no need to ask for permissions: you can!
This hijacks the toolbox command 'ctrlaltdel' executed from init.sony-platform.rc line 13. It will take it's place in a similar way as the chargemon gets replaced to make the recoveries possible on locked bootloaders. As it is a symlink to /system/bin/toolbox there is NO need to create a copy to something else to make this work. The script that takes it's place is this:
Code:
#!/system/bin/sh
#####
#
# Completely demolish the RIC service and make sure the phone will survive a remount of /system
#
# Author: [NUT] from XDA
#
ARGS="$1 $2"
# Check busybox path and export it
if [ -x "/system/xbin/busybox" ]; then
export BUSYBOX="/system/xbin/busybox"
elif [ -x "/system/bin/busybox" ]; then
export BUSYBOX="/system/bin/busybox"
elif [ -x "/sbin/busybox" ]; then
export BUSYBOX="/sbin/busybox"
fi
# Mount rootfs rw, if it isn't already
ROOTFSMOUNTEDRO=`$BUSYBOX grep "rootfs ro,relatime" /proc/mounts | $BUSYBOX wc -l`
if [ "$ROOTFSMOUNTEDRO" = "1" ]; then
$BUSYBOX touch /tmp/remountedrootfs
$BUSYBOX mount -o remount,rw /
fi
# Edit the init.rc so the service never gets to start
$BUSYBOX sed -i '/"# Start RIC"/N;s/service ric /sbin/ric/#service ric /sbin/ric/g' /init.sony.rc
$BUSYBOX sed -i '/"#service ric /sbin/ric"/N;s/ class main/# class main/g' /init.sony.rc
$BUSYBOX sed -i '/"# class main"/N;s/ user root/# user root/g' /init.sony.rc
$BUSYBOX sed -i '/"# user root"/N;s/ group root/# group root/g' /init.sony.rc
# chmod the ric binaries so they can't start anymore, as a failsafe
if [ -x "/sbin/ric" ]; then
$BUSYBOX chmod 644 /sbin/ric
fi
if [ -x "/system/bin/ric" ]; then
$BUSYBOX chmod 644 /system/bin/ric
fi
# Make sure the RIC service gets killed if it manages to start up...
# This process will drop in the background and keeps running untill it did!
$BUSYBOX nohup /system/bin/killric.sh &
# Execute the actual command now
exec /system/bin/toolbox ctrlaltdel $ARGS
As you can see I'm spawning a process into the background to kill the RIC service. Even though I commented out the service in init.sony.rc it still manages to start up as init reads and buffers all of it's scripting before it actually starts to do anything... so the service will run regardless of the changes we make to it. This step was just for any form of runlevel change to prevent that from triggering a restart. As a secondary measure it disables the binary all the way by setting 644 permissions on it.
Code:
#!/system/bin/sh
#####
#
# Check RIC looper, it will exit as soon as it found and killed it!
#
# Author: [NUT] from XDA
#
DoesFileExist() {
if [ -f "/tmp/killedric" ]; then
return 0
else
return 1
fi
}
# As the init.rc scripts seem to be running parallel, lets kill ric if it got started.
until DoesFileExist
do
RICCHECK=`$BUSYBOX ps | $BUSYBOX grep "/sbin/ric" | $BUSYBOX wc -l`
if [ $RICCHECK -gt 1 ]; then
$BUSYBOX pkill -f /sbin/ric
fi
if [ $RICCHECK -eq 1 ]; then
$BUSYBOX touch /tmp/killedric
fi
$BUSYBOX sleep 2
done
exit 0
This does a loop every 2 seconds and tries to pkill /sbin/ric. When successful it will exit.
To double check if these 2 scripts did their job you can check /tmp for 2 empty files:
- /tmp/remountedrootfs
and
- /tmp/killedric
If they exist, checking the processlist should end up empty when trying to find killric.sh, ctrlaltdel and /sbin/ric. If so, on a locked bootloader, you can now safely remount /system and rootfs (/) and survive it
This is my gift to the community, enjoy a trouble free root experience with it!
Thanks go to:
@DooMLoRD for the chat about the init process
@RoberM for testing and suggestions, he found out pkill does successfully kill the ric process in .307
@fards for the brainstorming in my .307 ROM thread
@Carceri for the brainstorming in my .307 ROM thread
Has this fix been implemented in latest dual boot recovery for locked boatloader?
Sent from my C6603 using xda app-developers app
shoey63 said:
Has this fix been implemented in latest dual boot recovery for locked boatloader?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
No, but it will
XZDualRecovery 2.4 will get this fix as well.
In the mean time you can flash this just as well
Ok
Reason I ask is this:-
I Flashed stock .434, rooted it, flashed your dual boot recovery and did an OTA update to .253.
To my amazement, update worked, plus Root and your dual recovery were still intact! Also no reboot when accessing system as R/W:good:
I will apply your patch and see what happens when OTA for .307 comes through (eventually)
My phone switches off after the Xperia wave animation.
Facts:
Locked BL
on .253
Rooted
Did not have the R/W mount issue, but I flashed it anyway
Latest CWM/TWRP recovery
I have Fidelity V4 (If that is of any consequence here)
While flashing it detected that I had busybox (If that is of any consequence as well)
Restoring system from old backup fixed it.
Great job with fixing this and making it easy for other people to use in their ROMs.
At first I thought there was a problem with this fix due to a race condition: As far as I can see rootfs is mounted r/w before ric is killed, so I would expect that sometimes ric might start early, see that / is rw and reboot the phone. I was surprised that this did not happen, but actually it seems that ric does not check permissions on rootfs (I could mount it r/w with ric running without getting a reboot).
chmod 644 /sbin/ric is (for me at least) not just a failsafe. It is needed because otherwise ric keeps being respawned whenever it's killed giving another race condition where sometimes it might have time to reboot the phone before it is killed again.
So: This fix should work as long as ric behaves as it does on the kernel that comes with 307.
As I said I also made my own version of a fix in parallel. I wrote it in C as I needed access to some system calls. Basically it is an executable that can be run from whereever one wants to start a program. It runs as a daemon that waits for /sbin/ric to be started. Once it sees ric, it forces ric and itself to run on the same CPU, schedules itself with realtime priority on that CPU so ric never gets a chance to run, replaces the ric executable in /sbin/ric by a dummy version that justs sleeps and kills the original ric process. I could also have deleted it, but whatever respawns ric now don't have to try to start a new process all the time, since it will see that ric is still running.
I have tested my own solution for the past day or so and it seems to work fine. I'll probably post the binary and source code for it later.
008bond said:
My phone switches off after the Xperia wave animation.
Facts:
Locked BL
on .253
Rooted
Did not have the R/W mount issue, but I flashed it anyway
Latest CWM/TWRP recovery
I have Fidelity V4 (If that is of any consequence here)
While flashing it detected that I had busybox (If that is of any consequence as well)
Restoring system from old backup fixed it.
Click to expand...
Click to collapse
Hmm, maybe your ROM chef built in something that conflicts with this script. His own solution to RIC maybe?
Sent from my C6603 using xda app-developers app
[NUT] said:
Hmm, maybe your ROM chef built in something that conflicts with this script. His own solution to RIC maybe?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
I'm using stock. I think the issue lies with me flashing Fidelity V4.0.
EDIT: I can confirm that Fidelity patch is the issue.
008bond said:
I'm using stock. I think the issue lies with me flashing Fidelity V4.0.
EDIT: I can confirm that Fidelity patch is the issue.
Click to expand...
Click to collapse
Cr*p, I'm out of thanks to give the usual way today, so:
Thanks for the useful info, you scared me a bit there
Carceri said:
Great job with fixing this and making it easy for other people to use in their ROMs.
At first I thought there was a problem with this fix due to a race condition: As far as I can see rootfs is mounted r/w before ric is killed, so I would expect that sometimes ric might start early, see that / is rw and reboot the phone. I was surprised that this did not happen, but actually it seems that ric does not check permissions on rootfs (I could mount it r/w with ric running without getting a reboot).
chmod 644 /sbin/ric is (for me at least) not just a failsafe. It is needed because otherwise ric keeps being respawned whenever it's killed giving another race condition where sometimes it might have time to reboot the phone before it is killed again.
So: This fix should work as long as ric behaves as it does on the kernel that comes with 307.
As I said I also made my own version of a fix in parallel. I wrote it in C as I needed access to some system calls. Basically it is an executable that can be run from whereever one wants to start a program. It runs as a daemon that waits for /sbin/ric to be started. Once it sees ric, it forces ric and itself to run on the same CPU, schedules itself with realtime priority on that CPU so ric never gets a chance to run, replaces the ric executable in /sbin/ric by a dummy version that justs sleeps and kills the original ric process. I could also have deleted it, but whatever respawns ric now don't have to try to start a new process all the time, since it will see that ric is still running.
I have tested my own solution for the past day or so and it seems to work fine. I'll probably post the binary and source code for it later.
Click to expand...
Click to collapse
The way i do the remount of / is no problem in 2 ways: it only remounts when really needed and as it is indirectly executed by init, it will never cause ric to intervene and trigger a reboot. If you have the reboot issue, remounting rootfs (/) from any root explorer app actually does cause a reboot.
About your ric killer application: nice! I've never programmed in C, otherwise I might have attempted something similar. But I know bash/ash scripting, so I fixed it the way I knew best
From my perspective you could make your daemon exit once it has killed /sbin/ric after changing it's permissions to 644. I've been testing my fix for a few days now (on stock kernel and re-locked bootloader) and the method in this thread completely prevents it from starting /sbin/ric ever again :victory:
My daemon does exit once it has killed ric and made sure it cannot start again.
Whatever respawns init keeps checking, so deleting the file, making it non executable or replacing it with a dummy all works. If you chmod 755 it again, ric does respawn on my phone, so something (probably init) keeps trying to start it if it isn't running.
On my phone (before killing ric) mounting / rw does not cause a reboot, but mounting /system rw does. Weird.
Carceri said:
My daemon does exit once it has killed ric and made sure it cannot start again.
Whatever respawns init keeps checking, so deleting the file, making it non executable or replacing it with a dummy all works. If you chmod 755 it again, ric does respawn on my phone, so something (probably init) keeps trying to start it if it isn't running.
On my phone (before killing ric) mounting / rw does not cause a reboot, but mounting /system rw does. Weird.
Click to expand...
Click to collapse
That would be init indeed, as it's a service without 'oneshot' (fires only once, then init stops monitoring) or 'disabled' (init never fires it but it waits for an explicit call to get that service started).
I've found a guide on the Android init daemon/process, I'll post a link to it in this thread tonight, it's an interesting read
I never tried to restart the init process to be able to disable the service though, might be attempting to do so some day. It is what the recoveries do with the chargemon hijack method, they stop all services, unmount everything, cleans up the ramdisk and then unpacks the recovery to start it's init binary.
I'll try that some time soon and see if that will work as well, that would probably be the cleanest way, it would render killric.sh and your application useless as they would no longer be needed, simplifying and 'niceifying' the entire process.
Yep, this fix works perfectly!
Flashed stock .307, unlocked bootloader, flashed @DooMLoRD kernel then rooted through recovery, flashed root fix, flashed stock .307 kernel and then restored TA partition.
Rebooted and used Root explorer in system with R/W permissions. No reboots
Congrats @[NUT] :good:
@Carceri
[NUT] said:
I never tried to restart the init process to be able to disable the service though, might be attempting to do so some day. It is what the recoveries do with the chargemon hijack method, they stop all services, unmount everything, cleans up the ramdisk and then unpacks the recovery to start it's init binary.
I'll try that some time soon and see if that will work as well, that would probably be the cleanest way, it would render killric.sh and your application useless as they would no longer be needed, simplifying and 'niceifying' the entire process.
Click to expand...
Click to collapse
I've been experimenting with that and so far I have not been very successful... apart from not working as i hoped (it reboots after the second init attempt), it also repeats a few parts of the boot process as crtlaltdel is executed too late during the init and thus it will allow you to enter recovery twice for example :silly:
It might be needed to re-hijack the chargemon process as this is executed precisely at the right time for this idea to work... but doing so will break compatibility with all available recoveries... and throws in some caveats for the recovery users... just the thing i was trying to fix for all and any of the Z/ZL lovers
Stuff to ponder on...
*ponders on* Maybe I can use the ctrlaltdel script to 'fix' anything that breaks and then trigger a reboot to make sure the user gets to boot in to a good working android...
chargemon would be my new rickiller script, it checks for the flagfile it creates itself, if it's not found it will do the RIC fix, then create's the flagfile and restarts init. With the second init it will find the flagfile and will execute the re-hijacked chargemon hijack script to offer recovery. If not chosen to enter recovery it will just continue boot.
Once ctrlaltdel gets started it checks if the md5sum of the chargemon script is what it's supposed to be. If not, it will create a backup of that chargemon file for execution by the re-hijacked chargemon script that it copies from a backup file somewhere (probably simply in /system/bin) corrects permissions and then triggers a reboot...
PRECAUTION: This post is on the file attached, it has no meaning regarding the OP: that fix works just fine.
Well, I'm putting my scripting online that i wrote on the above idea for those in the know, I'm not sure why it does not work but
THIS DOES NOT WORK
For anyone who wants to help out, you are welcome to take a look... you can even try it (put the 2 files inside /system/bin) but note the warning above...
To recover from the tantrum it throws, be sure to have an unlocked bootloader and DooMKernel installed. You will need TWRP to get you out of trouble, which is easy: mount system, use advanced -> filemanager and look inside /system/bin. chmod chargemon and ctrlaltdel to 644. Reboot and you're out of trouble.
Who has any idea why this does not work?
well, it sadly doesn't help me.. I'm on Odexed Stock ROM .307
if I try to rename / delete / add an apk into /system/app/ my phone still reboots..
FSN said:
well, it sadly doesn't help me.. I'm on Odexed Stock ROM .307
if I try to rename / delete / add an apk into /system/app/ my phone still reboots..
Click to expand...
Click to collapse
Can you check if there is a file called killedric in /tmp?
Sent from my C6603 using xda app-developers app
[NUT] said:
Can you check if there is a file called killedric in /tmp?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
I don't have this file. Locked BL, flashed w/ TWRP 2.4.0.0
FSN said:
I don't have this file. Locked BL, flashed w/ TWRP 2.4.0.0
Click to expand...
Click to collapse
Right, then check things in succession, stop and report which you stopped at:
1. Check if /system/bin/killric.sh exists.
2. Open /system/bin/ctrlaltdel to see if it looks like the one on the OP.
3. Open a terminal app and see if killric.sh is running by typing the command 'ps | grep killric.sh'
If you have to say no to 1 and 2, reflash the zip. Then try again, if it still fails send me the logs from /cache/recovery
Sent from my C6603 using xda app-developers app
[NUT] said:
Right, then check things in succession, stop and report which you stopped at:
1. Check if /system/bin/killric.sh exists.
2. Open /system/bin/ctrlaltdel to see if it looks like the one on the OP.
3. Open a terminal app and see if killric.sh is running by typing the command 'ps | grep killric.sh'
If you have to say no to 1 and 2, reflash the zip. Then try again, if it still fails send me the logs from /cache/recovery
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
1. Yes
2. Yes
3. If it returns 1 it runs, right?
Could it have something to do with the exFAT patch (for 64GB sd cards)?
Anyone know of a way to hide my root on the nexus 6?
Thanks, Robert
Hide it from what?
From apps that don't work with rooted phones. The one app in particular is puzzles and dragons.
Does Xposed framwork work on Lollipop yet? You could use Root Clock then.
http://repo.xposed.info/module/com.devadvance.rootcloak
Mauk80 said:
Does Xposed framwork work on Lollipop yet? You could use Root Clock then.
http://repo.xposed.info/module/com.devadvance.rootcloak
Click to expand...
Click to collapse
No xposed on Lollipop yet.
Any workaround till today ? this is really frustrating
Wonder why a game should care if you are rooted?
Wonder why *anything* would care if you have root access....?
It isn't like any possible detection method can actually verify that the device *does not* have root.
For example;
cp /system/bin/sh /system/bin/bitemerootchecker
chown root.root /system/bin/bitemerootchecker
chmod 6755 /system/bin/bitemerootchecker
Now you have an "su" command that can't be detected.
So I have a problem here. I rooted my X1049 with kingroot, to get temp root, removed write protection with the remount command on the terminal emulator, and installed Safestrap. It installed just fine. But when I reboot my phone to enter Safestrap, it doesn't show up, because when my phone boots up and I check the system partition with my file explorer, both Su and Safestrap have been removed. I have also tried to replace Kingroot with SuperSU, which doesn't work as when I open SuperSU it says I need to upgrade the Su binaries which fails. And when I reboot my phone, Su is removed, yet again. So to me it seems like the main problem is Android rolling back my changes to /system. I really need help with this, so plz respond as soon as possible.
Sent from my XT1049 using Tapatalk
Write protection cannot be turned off yet, all changes to /system will always rollback.
If anybody finds any way to disable write protection on the Moto X 4.4.4 please post here.
Sent from my XT1049 using Tapatalk
I know that some root methods have it so that when you enter recovery from the bootloader, android boots into write protection off. Does anyone know how this is done? And is it possible to do something like this on 4.4.4?
These modules are not meant for everyday use. They are intended for debugging and modification of a firmware. They significantly lower security of your device while active and even could softbrick it. You've been warned.
ADB Root
Magisk Module that allows you to run "adb root". adb root is not an ordinary root (su), it's adbd daemon running on your phone with root rights. adb root allows you to "adb push/pull" to system directories and run such commands as "adb remount" or "adb disable-verify".
Download v1.0: https://github.com/evdenis/adb_root/releases/download/v1.0/adb_root.zip
Source code: https://github.com/evdenis/adb_root
Support: Telegram
SELinux Permissive
This module switches SELinux to permissive mode during boot process. This module intentionally lowers security settings of your phone. Please don't use it if there is a better solution to your problem, e.g., magiskpolicy. The module will not work if your kernel compiled with always enforcing config, e.g., stock samsung kernels. It's not possible to enable permissive mode on such kernels.
Download v2.0: https://github.com/evdenis/selinux_permissive/releases/download/v2.0/selinux_permissive_v2.0.zip
Source code: https://github.com/evdenis/selinux_permissive
Support: Telegram
Enable Eng
This Magisk Module enables engineering build props. It allows to activate debugging parts of a firmware. Please, disable Magisk Hide for this module. If you don't know what you are doing, don't use this module. It can easily softbrick your device.
Troubleshooting
If your device doesn't boot then you need to reboot to TWRP recovery and
Code:
$ adb shell rm -fr /data/adb/modules/enable_eng
If ADB doesn't work that means adbd in your firmware is build without ALLOW_ADBD_ROOT. You can fix adb autostart either by installing "ADB Root" magisk module or by disabling this module.
Download v1.0: https://github.com/evdenis/enable_eng/releases/download/v1.0/enable_eng.zip
Source code: https://github.com/evdenis/enable_eng
Support: Telegram
Kexec tools for Android
This module adds statically linked kexec binary to your system. Aarch64 only. Kexec is a system call that enables you to load and boot into another kernel from the currently running kernel. Your kernel should support kexec.
Download v1.0: https://github.com/evdenis/kexec/releases/download/v1.0/kexec.zip
Source code: https://github.com/evdenis/kexec
Support: Telegram
GDISK/Parted for Android
The module adds statically linked parted/sfdisk/fdisk/gdisk binaries to your system. Aarch64 only. These utils are standard linux tools to edit the partitions tables on disks.
Download v2.0: https://github.com/evdenis/disk/releases/download/v2.0/disk-v2.0.zip
Source code: https://github.com/evdenis/disk
Support: Telegram
Is also valid for One Plus 5 ?
Inviato dal mio ONEPLUS A5000 utilizzando Tapatalk
tmviet said:
Is also valid for One Plus 5 ?
Click to expand...
Click to collapse
Hi, these magisk modules are device independent. Yes, you can use them on One Plus 5.
evdenis said:
Hi, these magisk modules are device independent. Yes, you can use them on One Plus 5.
Click to expand...
Click to collapse
Tks. A lot [emoji6]
Inviato dal mio ONEPLUS A5000 utilizzando Tapatalk
Thanks @evdenis, this module is great! I haven't gotten the 100% desired behavior (getting adbd with actual root perms) because I'm running a 32-bit architecture (armeabi-v7a) and you've supplied only the 64-bit version of adbd, but I've been using your module to swap out 32-bit versions of different versions of adbd I have lying around (older devices). I'm a n00b when it comes to building adbd from scratch using the latest sources with your patch so I'm planning on using the adbd that came with the device and using a disassembler and a hexeditor to NOP out some calls, such as the call to minijail_enter() and see if I have any success. The original device version of adbd doesn't seem to have the functions in it that you built with the patch, but instead appears to use a bunch of minijail library functions. The device is a rooted android 8.1.0 OS, but it is only rooted systemlessly so many of the ro.* build properties affecting adb are changed well after the OS-essential portion boots rendering my efforts thus-far using the original adbd ineffective I'm guessing. I can now issue the "adb root" command from my machine, but adbd on the device is always being launched with the following command line arg "--root_seclabel=u:r:su:s0" and never gains root permissions by default (the behavior I'm trying to achieve). I can manually use "su" but this doesn't help me with push/pull requests to protected parts of the OS and chainfire's "ADB Insecure" patches adbd successfully, but I still don't get the root perms.
Do you know if the system is starting the process with reduced permissions (i.e. adbd will never be able to gain root access on its own no matter what I modify) and I should go a different route like modifying something else in the system rather than adbd? Again, I've already modified the ro.* properties affecting adbd so it does attempt to re-launch itself as root, it just doesn't end up getting the root perms. Manually launching adbd after killing it from within a shell on the device doesn't seem to affect the permissions in ultimately gets.
If you are anyone has any insight as to what I need to do so that adbd gains root permission, that would be much appreciated.
bpaxda said:
I'm planning on using the adbd that came with the device and using a disassembler and a hexeditor to NOP out some calls, such as the call to minijail_enter() and see if I have any success.
Click to expand...
Click to collapse
It was my initial attempt to gain "adb root" on samsung s10. And noping a couple of calls is not enough on the phone. adbd binary on your device could be compiled without "adb root" branch. This is the case on samsung s10. If "adb root" branch exists one need to force should_drop_privileges() function to return false (https://android.googlesource.com/platform/system/core/+/refs/heads/master/adb/daemon/main.cpp#65) in order to get into the "adb root" branch of code (https://android.googlesource.com/platform/system/core/+/refs/heads/master/adb/daemon/main.cpp#151).
bpaxda said:
ro.* build properties affecting adb are changed well after the OS-essential portion boots rendering my efforts thus-far using the original adbd ineffective I'm guessing.
Click to expand...
Click to collapse
You could try enable_eng magisk module (https://github.com/evdenis/enable_eng). The module changes ro.* props to engineering build props. Depending on a firmware this could help to get "adb root". However, no guaranties that the module will not softbrick your device. In case of softbrick you will need to reboot to TWRP and delete the module, instruction is in the README.md.
bpaxda said:
I can now issue the "adb root" command from my machine, but adbd on the device is always being launched with the following command line arg "--root_seclabel=u:r:su:s0" and never gains root permissions by default (the behavior I'm trying to achieve).
Click to expand...
Click to collapse
Try to disable SELinux either with the magisk module or with a script.
Thanks for your response.
I think you're right. Despite having adjusted the ro properties post-boot, there was nothing in ADB that would change the privileges as if it has been compiled out. By sheer luck, I managed to grab adbd from an identical device that had a recent forced firmware update, but the "improved adbd" actually let me get closer. The updated adbd had code changes to its adbd_main function so that it at least looks at the properties "ro.secure" and "service.adb.root" not to mention new calls to minijail_capbset_drop(), minijail_change_gid() and minijail_change_uid(). Using magisk to dynamically replace my original adbd binary with this updated one actually worked in getting adbd to start root shells without needing to invoke "su"!
However its a weird type of root that can't read certain files like /verity_key but I can see some things I should be able to see as root. I'm no SELinux expert, but my guess is that if everything is functioning correctly, I may be getting an SELinux "restricted" root. In this case, it might be the most I can expect from an SELinux enabled kernel launching adbd as root. Let me explain: since I'm using Magisk, post-boot systemlessly, (the system boots restricted and then I use the mtk_su exploit, to gain root and disable permissive SELinux mode), I'm getting permissive root on a session by session basis. I think the nature of this type of root means the kernel is probably still locked down and thus whatever daemon may be responsible for launching adbd remains locked down. Does this sound correct to you? If so, I can live with that
I'd love to get TWRP on this device, but I'm not sure its possible since TWRP doesn't list my device as supported on their website nor can I get into fastboot mode (I didn't try that hard because I wanted to exhaust other options before flashing anything). Do you think enable_eng would work *after* the ACTION_BOOT_COMPLETE event is processed? I.e. my device is rooted after bootup by a script which runs the exploit, but it is well after the system is fully running and locked-down. Luckily Magisk has a utility to change ro properties, but some of those properties are not looked-at by the system this late in the boot stage. Do you think in this case "enable_eng" would work for me? Thanks again!
bpaxda said:
Let me explain: since I'm using Magisk, post-boot systemlessly, (the system boots restricted and then I use the mtk_su exploit, to gain root and disable permissive SELinux mode), I'm getting permissive root on a session by session basis.
Click to expand...
Click to collapse
I'm not sure that my modules will work with this rooting scenario. As far as I could understand, magisk by default replaces the init process, patches selinux policy before it is loaded and next, calls the original init binary. I don't think that it will be possible to alter selinux policy with different boot scenario for magisk.
bpaxda said:
Do you think enable_eng would work *after* the ACTION_BOOT_COMPLETE event is processed? I.e. my device is rooted after bootup by a script which runs the exploit, but it is well after the system is fully running and locked-down. Luckily Magisk has a utility to change ro properties, but some of those properties are not looked-at by the system this late in the boot stage. Do you think in this case "enable_eng" would work for me?
Click to expand...
Click to collapse
I'm not sure that enable_eng will work. adbd daemon check some properties such as ro.secure dynamically, but they could be cached after the boot. I don't know the ways to drop the cache and re-read these properties (altered with magisk) after the boot. Here are the main properties the modules changes https://github.com/evdenis/enable_eng/blob/master/system.prop
Thanks for making this tool! I'm just wondering if I need to modify my adb to use the module - I run "adb root" normally and get "adbd cannot run as root in production builds" still
Anyone know why when i install SELinux Permissive version 2.0 of the module it still states version 1 in Magisk?
I flashed this in Magisk and rebooted. Now my phone is stuck in a boot loop. Any ideas? I'm using Sony Xperia XZ1 compact.
cheeklitched said:
I flashed this in Magisk and rebooted. Now my phone is stuck in a boot loop. Any ideas? I'm using Sony Xperia XZ1 compact.
Click to expand...
Click to collapse
If you have twrp installed just uninstall and reinstall magisk.
Otherwise,
Boot to bootloader and flash your boot.img file
Code:
fastboot flash boot boot.img
Then let phone boot. Reboot to bootloader again. Flash magisk_patched.img
Code:
fastboot flash boot magisk_patched.img
During startup, as soon as you get to the Google logo, hold the volume button down. This should start the phone in safe mode. See if it loads. If not, reboot phone, and execute this in terminal/command prompt:
Code:
adb wait-for-device shell magisk --remove-modules
This should allow the phone to start up all the way. Enable whatever modules you want. You may need to flash magisk_patched.img again.
This has fixed multiple problems for me. It's redundant, but it tends to work.
I installed the Magisk selinux script, but after installing it no longer shows in Magisk, so how do I dissable/undo/uninstall the script? I installed a Selinux checker and it says it is on permissive, so the scrip must have installed, but I want to remove it. Is there an undo script, or can I manually delete the script in my root filesystem? THX
Hello guys
I used Redmi K20 pro with Eu rom 10.4, android 10.
I used the lastest version of this module but my devices was not found on ADB system on my computer.
So what I do now? I tried to fix it but I cannot find anything about it.
Recently, setting SElinux to permissive is not advised. I had a issue with V4A setting my SElinux to permissive permenantly, but editing the magisk module to set SElinux to enforcing instead of permissive also works.
This is probs the only module that actually sets SElinux properly.
Here's the modded magisk module with the same credited creator, but just sets SElinux to Enforcing instead of permissive
OMFG I THINK THIS IS WHAT IVE BEEN LOOKING FOR. TEH HOLY GRAILLLLL OMGOMGOMG THANK YOU THANK YOU THANK YOUUUUU
Will ADB Root work for Android 8.1?
evdenis said:
These modules are not meant for everyday use. They are intended for debugging and modification of a firmware. They significantly lower security of your device while active and even could softbrick it. You've been warned.
ADB Root
Magisk Module that allows you to run "adb root". adb root is not an ordinary root (su), it's adbd daemon running on your phone with root rights. adb root allows you to "adb push/pull" to system directories and run such commands as "adb remount" or "adb disable-verify".
Download v1.0: https://github.com/evdenis/adb_root/releases/download/v1.0/adb_root.zip
Source code: https://github.com/evdenis/adb_root
Support: Telegram
SELinux Permissive
This module switches SELinux to permissive mode during boot process. This module intentionally lowers security settings of your phone. Please don't use it if there is a better solution to your problem, e.g., magiskpolicy. The module will not work if your kernel compiled with always enforcing config, e.g., stock samsung kernels. It's not possible to enable permissive mode on such kernels.
Download v2.0: https://github.com/evdenis/selinux_permissive/releases/download/v2.0/selinux_permissive_v2.0.zip
Source code: https://github.com/evdenis/selinux_permissive
Support: Telegram
Enable Eng
This Magisk Module enables engineering build props. It allows to activate debugging parts of a firmware. Please, disable Magisk Hide for this module. If you don't know what you are doing, don't use this module. It can easily softbrick your device.
Troubleshooting
If your device doesn't boot then you need to reboot to TWRP recovery and
Code:
$ adb shell rm -fr /data/adb/modules/enable_eng
If ADB doesn't work that means adbd in your firmware is build without ALLOW_ADBD_ROOT. You can fix adb autostart either by installing "ADB Root" magisk module or by disabling this module.
Download v1.0: https://github.com/evdenis/enable_eng/releases/download/v1.0/enable_eng.zip
Source code: https://github.com/evdenis/enable_eng
Support: Telegram
Kexec tools for Android
This module adds statically linked kexec binary to your system. Aarch64 only. Kexec is a system call that enables you to load and boot into another kernel from the currently running kernel. Your kernel should support kexec.
Download v1.0: https://github.com/evdenis/kexec/releases/download/v1.0/kexec.zip
Source code: https://github.com/evdenis/kexec
Support: Telegram
GDISK/Parted for Android
The module adds statically linked parted/sfdisk/fdisk/gdisk binaries to your system. Aarch64 only. These utils are standard linux tools to edit the partitions tables on disks.
Download v2.0: https://github.com/evdenis/disk/releases/download/v2.0/disk-v2.0.zip
Source code: https://github.com/evdenis/disk
Support: Telegram
Click to expand...
Click to collapse
how can i make permissive enfocing because in 2022 i heard thats a BIG security risk and my custom ROM (havoc os) if selinux permissive