Related
Hi, I've been searching for technical details of how root is actually obtained on the Android system. Specifically, I'm interesting in the Nexus One, but I'm curious about any methods that are available.
After reading the adb documentation among others, I've come to the belief that at least on the N1 it's as simple as remounting system as root and changing the permissions of su followed by installing busybox. After that the superuser application is installed, and it updates su with it's own version.
(This is only for updating the application on an already rooted system)
Superuser appears to grant root privileges to itself then overwrites su with it's own variation that uses its database for permissions, and calls the app with:
Code:
sprintf(sysCmd, "am start -a android.intent.action.MAIN -n com.koushikdutta.superuser/com.koushikdutta.superuser.SuperuserRequestActivity --ei uid %d --ei pid %d > /dev/null", g_puid, ppid);
I'm curious how cyanogen handles it without having the user install busybox, etc. before flashing his mod. I would think the Android system would only allow signed updates, but I have a feeling that the custom recovery image bypasses that.
If someone could just link me to a forum link/blog/etc. (if they exist) or give me some advice on things to search for, that would be great.
I'm just now getting into Android kernel development, and would love to know everything I can about it. I've been way to busy with a research project at school, but it's pretty much over at this point. I plan on becoming much more involved here especially with some programming some ideas I have for improvements to both the kernel and Google's applications.
meinhimmel said:
I'm curious how cyanogen handles it without having the user install busybox, etc. before flashing his mod. I would think the Android system would only allow signed updates, but I have a feeling that the custom recovery image bypasses that.
If someone could just link me to a forum link/blog/etc. (if they exist) or give me some advice on things to search for, that would be great.
.
Click to expand...
Click to collapse
bingo. upon unlocking the bootloader, you are able to flash a custom recovery which does not require google keys and you are able to install custom roms. the roms usually have busybox and the other applications built in. custom recovery also has all the binaries require for flashing roms.
a good site would be platform.android.com (something like that) for developing roms/editing kernel. you can also check the "android development" on the xda main forum homepage, there are a couple of stickies there worth reading
After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a
Stickied.
sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?
WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.
Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.
Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?
BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688
Thank you for your work!
Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.
I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.
It reminds me of Korean dramas ,
Please note, this requires SELinux Permissive (included init.d script/instructions for PHH). It will not work on Enforcing, even with supolicy (I've tried. If anyone has an idea how to get it working with "soundserver" and setting supolicy "read write execute", please let me know)
Setting SELinux to Permissive is a security risk.
ViPER4Android for Mate 9
Slightly modified guitardedhero script.
Contains "Kernel" and "Profile" for V4A from auras76 kang rom
Note:
The following files are backed up automatically so you can easily revert with the removal script:
/system/lib/soundfx/libeffectproxy.so -> /system/lib/soundfx/libeffectproxy.so.bak
/system/etc/audio_effects.conf -> /system/etc/audio_effects.conf.bak
/vendor/etc/audio_effects.conf -> /vendor/etc/audio_effects.conf.bak
If those .bak files are not found the removal script won't run (to prevent running it without V4A installed, it would simply just remove the files leaving you with no files at all.)
It does not edit audio_policy.conf as it doesn't have the deep_buffer section in it, so no point in having it edited.
Requirements:
SuperRoot/SuperSU (No verity is probably needed as we're modifying both /system and /vendor)
A way to set SELinux to Permissive (SuperSU init.d/phh 'su --init' or SELinuxToggler, see 'Alternative'.)
If you're on Magisk use the V4A module instead
For SuperSU
If you use the one posted above
Simply flash the zip in TWRP and you should be good to go. It copies the 00selinux script directly to /system/etc/init.d/ and runs at boot so you'll have SELinux set to Permissive after flashing.
For PHH su
Flash the zip in TWRP, boot up fully.
Now open a terminal and issue the command
Code:
su --init /system/etc/init.d/00selinux
Then reboot.
To remove the phh init use 'su --init !/system/etc/init.d/00selinux'.
For Magisk
Search for Viper4Android in the Downloads section in Magisk Manager, it's a module so no need to download anything in this thread
Alternative:
(You still need root for this but no init script.)
SELinuxSwitch by @Ibuprophen
Download:
ViPER4Android 2.5.0.5
Dropbox Mirror
Removal script download:
Removal script
Removal script Dropbox Mirror
Thanks to V4A team,
guitardedhero for his script,
auras76 for the profiles/makers of said profiles,
Ibuprofen for The SELinux Switch.
@ante0 bro thanks for porting it... have a question, we have to mount system in terminal for writting in system partition,,, can i use init to mount system rw for all time so that i dont need to give command everytime
HassanMirza01 said:
@ante0 bro thanks for porting it... have a question, we have to mount system in terminal for writting in system partition,,, can i use init to mount system rw for all time so that i dont need to give command everytime
Click to expand...
Click to collapse
Yes, if you use supersu, make a script in /system/etc/init.d/
Code:
#!/system/bin/sh
mount -o rw,remount /system
Make sure it runs after any other scripts if they remount system to read only. Scripts are loaded in order, so name it accordingly.
If you use phh, place script where you want and from a terminal
Code:
su --init /path/to/script
I wanna put all this in my Kernel... Or boot.img...
I have root in my kernel using phh superuser... I dont want to add anything in system by myself, i want that a zip should do it... Will be best if kernel did all this... In MM, we dont need to do rw ourself, in N we needed...
Also, am not a dev, just a pro member, know how to edit and understand commands etc...
May I ask whats the difference between this and Viper4Arise.
HassanMirza01 said:
I wanna put all this in my Kernel... Or boot.img...
I have root in my kernel using phh superuser... I dont want to add anything in system by myself, i want that a zip should do it... Will be best if kernel did all this... In MM, we dont need to do rw ourself, in N we needed...
Also, am not a dev, just a pro member, know how to edit and understand commands etc...
Click to expand...
Click to collapse
I sent you a pm instead
ante0 said:
I sent you a pm instead
Click to expand...
Click to collapse
Sure bro... Am waiting... And i have somehow injected phh superuser r275 in boot.img... I will be thankful if u tell me the whole correct procedure to inject files of superuser zip in boot.img.... By flashing superuser r275 on stock boot, we can have root but on that root, titanium like apps didnot work :/
SlyUK said:
May I ask whats the difference between this and Viper4Arise.
Click to expand...
Click to collapse
Arise is based off of V4A, but with their own audio effects and a modified V4A app.
https://www.reddit.com/r/androidapps/comments/5dpvcz/slug/da6ux9k
SlyUK said:
May I ask whats the difference between this and Viper4Arise.
Click to expand...
Click to collapse
It's just a skin difference. Viper4Arise is themed by an arise member. The only difference is the theme.
ante0 said:
Arise is based off of V4A, but with their own audio effects and a modified V4A app.
https://www.reddit.com/r/androidapps/comments/5dpvcz/slug/da6ux9k
Click to expand...
Click to collapse
Hello,
Will V4A work on P9, P9 plus and P9 lite if we flash those files?
Coolyou said:
Hello,
Will V4A work on P9, P9 plus and P9 lite if we flash those files?
Click to expand...
Click to collapse
I don't know. But I don't see why it wouldn't.
Backup system and try.
You'll have to use the phh init script though as I don't think supersu works with P9 on emui5?
Edit: actually, if your audio_effects.conf file is not in /system/etc/ or /vendor/etc/ the script needs to be modified. And if your audio_policy.conf contains the deep_buffer section.
You guys can use this app for switching SELinux to Permissive - https://forum.xda-developers.com/android/apps-games/app-selinuxtoggler-t3574688
It was featured a few days back on XDA blog, hope it will help the users.
DJBhardwaj said:
You guys can use this app for switching SELinux to Permissive - https://forum.xda-developers.com/android/apps-games/app-selinuxtoggler-t3574688
It was featured a few days back on XDA blog, hope it will help the users.
Click to expand...
Click to collapse
Oh, he finally released it
I'll update OP, thanks for heads-up.
Works like a charm, thanks
hi..I'm on aura's rom. and I can't install drivers. can you please teach me how can I make it work..thanks
s2pfie said:
hi..I'm on aura's rom. and I can't install drivers. can you please teach me how can I make it work..thanks
Click to expand...
Click to collapse
assuming everything else but the driver is installed,
simply download Viper4android_2.5.0.5_mate9.zip, extract.
go to customize/lib, rename libv4a_fx_jb_NEON.so to libv4a_fx_jb_ics.so
copy it to your phone.
Use a root file manager and copy and paste to /system/lib/soundfx/libv4a_fx_jb_ics.so.
And set permissions of that file to 0644 (RW-R--R--).
Then reboot and open up viper4android again and see if still complains.
If it doesn't, go to "hamburger" menu in V4A and tap on Driver Status, it should say Status: Normal. If it says abnormal something else is wrong.
ante0 said:
assuming everything else but the driver is installed,
simply download Viper4android_2.5.0.5_mate9.zip, extract.
go to customize/lib, rename libv4a_fx_jb_NEON.so to libv4a_fx_jb_ics.so
copy it to your phone.
Use a root file manager and copy and paste to /system/lib/soundfx/libv4a_fx_jb_ics.so.
And set permissions of that file to 0644 (RW-R--R--).
Then reboot and open up viper4android again and see if still complains.
If it doesn't, go to "hamburger" menu in V4A and tap on Driver Status, it should say Status: Normal. If it says abnormal something else is wrong.
Click to expand...
Click to collapse
thanks bro but still an error occurred..still abnormal
update:
just flashed your zip now its normal..thank you
@ante0, I just wanted to give you a quick heads up...
There's a new app (currently being beta tested) that will supercede/replace The SELinux Toggler....
It's a new app called "The SELinux Switch". Though, it will look like "The SELinux Toggler" but, I had to recreate, pretty much, the whole app.
The reason i had to do this is, primarily, to completely sever it from the older package name (or Installation Directory) that was also being used by the "SELinuxModeChanger" app.
I also had made some minor enhancements and a few compatibility improvements but, there's still some more improvements to be made.
In addition, the app has been passing the beta testing extremely well (thankfully after about 6 +/- months into it) and it should be released soon but, when the app has completed the beta testing and, ready for its debut, it will be released under a whole new thread.
Thank you all for your time, understanding and, especially, your support for my development.
Please let me know if you have any questions or concerns.
______________
PLEASE NOTE: I welcome any member to help with further valuable information/clarification for any of my posts.
Has anybody used the ARISE aroma installer (twrp flashable zip)? I've used it on a few other devices, coming to the M9 from a Le Pro 3 and it works nice and easy and patches selinux permanently. It seems the way Huawei does things is much different though, so I'd be suprised if it works as easily as on other phones.
In the end, it's just installing 2.5.0.5 anyway with a few other tweaks and a whole bunch of IRS response profiles. So that part's not very different.
Just a quick heads-up @ante0...
The SELinux Toggler has now Officially been Discontinued for the launching of the new app...
[APP][TOOL][4.2+][OFFICIAL]The SELinux Switch by Ibuprophen
Those of you who currently has The SELinux Toggler, and want to switch to The SELinux Switch, please be sure to read the OP for instructions.
Thank you ALL!
______________
PLEASE NOTE: I welcome any member to help with further valuable information/clarification for any of my posts.
Hi,
First, I'm a noob with some experience!
I know how to root my phone with Magisk and I helped Jen to root the LG G4 Vigor (H731) for Videotron/Telus. She was working on the H735 if I'm not mistaken but it worked for mine too since it's the same phone without the same name. It was with SuperSu, I don't think Magisk was out at this time.
Well... at that time I bought Busybox Pro... I don't know why except everyone had it!!
I'd really like some explanation. I searched for at least 4 days, 1-4 hours per day and it was a LOTS of different things! I'm really confused about the difference between Busybox and Magisk, expect Magisk is SystemLess.
I can install "add-ons" with Magisk like Xposed!!
I really don't know what I can do with Busybox except installing "things" but are those "things" are like a module in Magisk/Xposed?
P.S. I know that if I install Xposed in Magisk, it become systemless like Magisk!
And! I know that I can install Busybox from Magisk! But I bought the Busybox Pro app from Google Play Store.
Can someone tell me all those differences? I'm really messed up and really need help +++ I think a good explanation could help lots of others than me.
Thank you VERY much!!!
Busybox is just a set of tools that some apps/programs/processes/etc use. Magisk actually has its own internal Busybox that it uses for a lot of things, but it's not exposed to the rest of your system, which is why you need to install a separate Busybox if something about your setup needs it. It used to be more common that a separate Busybox installation was needed, but nowadays not so much, since most apps that need it already come with their own version of it to ensure compatibility. You can read more about what Busybox is at https://www.busybox.net.
I actually had the same question. I've rooted a few of my devices already. And years back I've also bought some apps via Play-Store. But a lot of these apps seems to be dated and not maintained annymore.
For instance I've bought a few apps from JRummy back then, from which I still use Busybox and Rootchecker nowadays. But this bussybox seemed to be quite dated when looking to the last update moment.
I'm using Magisk now and I was thinking going to use it's integrated Busybox too. Can it just work next to each other? Or do I need to unstall the JRummy Bussybox before?
Didgeridoohan said:
Busybox is just a set of tools that some apps/programs/processes/etc use. Magisk actually has its own internal Busybox that it uses for a lot of things, but it's not exposed to the rest of your system, which is why you need to install a separate Busybox if something about your setup needs it. It used to be more common that a separate Busybox installation was needed, but nowadays not so much, since most apps that need it already come with their own version of it to ensure compatibility. You can read more about what Busybox is at https://www.busybox.net.
Click to expand...
Click to collapse
You can activate and use busybox by typing or copy and paste the busybox magisk location. Such as
/data/adb/magisk/busybox xz -d /storage/emulated/0/Download/root.img.xz
This is the busybox command to decompress xz archive.. as long as your root with busybox no need to install unless an application requires it.
So I'm running the latest version of Evervolv Android Pie and I'm trying to hide root for apps that can detect it. At first I looked into Magisk as that has it built in, but upon reading, as well as trying it myself, it doesn't want to install. Is there a way to install it that I'm not aware of or is it just not possible? I've also looked into suhide, however I cannot get that to work either. Any info and help would be greatly appreciated, and I can provide any info that's needed. Thanks
Magisk does not work on the Hp Touchpad, it needs to modified the RAMDISK to have access to the Kernel and patch it.
This could be better, I do not know if it could be merge into the current Kernel.
https://www.xda-developers.com/kernel-assisted-superuser-kernelsu/
https://forum.xda-developers.com/android/software/root-backdoor-android-kernel-development-t3870559
Thanks for the reply, and appreciate the help. How would I go about merging it with the kernel? I know you said you didn't know if it could, but I'd want to try to see? Also, is there anyway of installing SuperSU in systemless mode so su-hide would work?
Camry2731 said:
Thanks for the reply, and appreciate the help. How would I go about merging it with the kernel? I know you said you didn't know if it could, but I'd want to try to see? Also, is there anyway of installing SuperSU in systemless mode so su-hide would work?
Click to expand...
Click to collapse
You are welcome,
The developers will have to merge the kernel Assisted SuperUSer ( kernelSU ) into the kernel branch of the Android ROM. Then it will need to be recompile, I provided a guide on how to recompile the HP Touchpad kernel:
Click HERE for the Guide
About Systemless: The boot image ( Ramdisk and Kernel ) is read only and it gets loaded into memory each time. There is no program that will be able to modified the boot image for the HP Touchpad, but the RAMDISK can be modified manually, here is a guide on how to do it:
Click HERE for the Guide to unpack and repack the Ramdisk
The Ramdisk modification only allows /system to have read and write access for SuperSU to work, it does not modified the kernel.
To modified the Kernel for systemless this is what is required and then recompile the kernel.
Click HERE to compile the kernel with root permission.
I have not look into this on the HP touchpad Kernel and I know that all I have posted on here is a lot to do, but if you want, let me know the version of Android you want to have the kernel with root access and the CPU speed and I could try to compile that and then you test it.