Related
@Chainfire: I've a request for SuperSU
Please add an option to load some user defined SELinux rules
I've the problem wiht a Nexus7+Lollipop that the Landscape/Portrait does not change because sensor is not accessible because auf missing SELinux rules. Also the fingerprint of the current device connected by adb could not be saved. Appling the missing rules if the system is started does not help, there's a soft reboot needed then...
So it would be great if i could set some own rules which are applied very early at system start
call "supolicy" from "su.d" to load your custom policies ...
Thanks! But it seems to be executed to late. With command there + full reboot the sensors are not accessible to change landscape/portrait. But after an additional soft-reboot it woks well. So I think its executed to late?
Btw, do the scripts need a special shebang? With /system/bin/sh it was not executed so i removed it
The changes are lost upon reboot (but the script is re-executed...). If soft-reboots work, it may be these scripts are executed too late, but they cannot be executed any earlier. You'd need to modify the ramdisk (kernel image). Not sure if shebang is needed - the script is executed via the current shell, which may or may not require that.
Okay, thanks!
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 ,
My understanding of how SuperSU works since SELinux hit the scene is that Chainfire did a whole lot of work to allow SuperSU to function in SELinux enforcing mode by loading scripts at boot (in su.d) that grant SuperSU specific permission for the things that were causing problems. However, because of all of this work that Chainfire did in order to allow SuperSU to load through SELinux enforcing, he also effectively made it so that a process called SUPolicy can run scripts placed in su.d, which can allow other software to also bypass problematic parts of SELinux if a proper .sh script is inserted in su.d.
However, it seems like, from the documentation and discussions that I have read, that this whole SUPolicy thing does not actually need SuperSU to run, since it is actually the thing that SuperSU needs to run in an SELinux enforcing environment. So the million dollar question: Would it be possible to create this SUPolicy process and su.d script-loading without having to install SuperSU. That is, could it be made a standalone installation without SuperSU?
THIS IS CURRENTLY NOT WORKING
A newer version is available here: https://forum.xda-developers.com/apps/supersu/suhide-lite-t3653855
suhide is an experimental (and officially unsupported) mod for SuperSU that can selectively hide root (the su binary and package name) from other applications.
Pros
- Hides root on a per-app base, no need to globally disable root
- Doesn't need Xposed
- Even supports SuperSU's ancient app compatibility mode (BINDSYSTEMXBIN)
- Passes SafetyNet attestation by default on stock ROMs (last officially tested on 2016.10.07)
Cons
- Ultimately a losing game (see the next few posts)
- No GUI (at the moment) - Unofficial GUI by loserskater
Requirements
- SuperSU v2.78 SR1 or newer (link)
- SuperSU installed in systemless mode
- Android 6.0 or newer
- TWRP (3.0.2 or newer, with access to /data - link!) or FlashFire (link)
Xposed
Xposed is not currently officially supported, but if you want to use it directly, you must be using @topjohnwu 's systemless xposed v86.2 exactly (attached at the bottom). It seems to mostly work during my non-extensive testing, but there are still some performance issues (both boot-time and run-time). Proceed with caution, expect bootloop.
Alternatively, there are some reports that the latest Magisk version + the latest systemless xposed (for Magisk) also works. I have not personally tested this.
CyanogenMod
I've personally tested with CM13 on i9300 without issue, however, several users are reporting it doesn't work for them. Proceed with caution, expect bootloop. Also, aside from just flashing SuperSU, you need to make sure /system/bin/su and /system/xbin/su are removed, or CM's internal root will still be used.
Usage
Install/Upgrade
- Make sure you have the latest SuperSU version flashed in systemless mode
- Make sure you are using the latest TWRP or FlashFire version
- Remove any and all Xposed versions
- If you have been having issues, flash suhide-rm-vX.YY.zip first, and note that your blacklist has been lost.
- Flash the attached suhide-vX.YY.zip
- If you are upgrading from suhide v0.16 or older, reflash SuperSU ZIP, and note that your blacklist has been lost.
- Optionally, flash the Xposed version linked above, and pray
At first install SafetyNet is automatically blacklisted.
If you have just flashed a ROM, it is advised to let it fully boot at least once before installing suhide.
Uninstall
- Flash the attached suhide-rm-vX.YY.zip. The version may appear older, the uninstall script doesn't change very often.
Blacklisting an app
You need the UID (10000 to 99999, usually 10xxx) of the app, which can be tricky to find, or the process name. There may be a GUI for this at some point.
(Note that all commands below need to be executed from a root shell)
If you know the package name, ls -nld /data/data/packagename will show the UID - usually the 3rd column.
Similarly, for running apps, ps -n | grep packagename will also show the UID - usually the 1st column.
Note that the process name is often the same as the package name, but this is not always the case. UID is more reliable for identifying a specific app, and it is also faster than blocking based on process names.
When you know the UID or process name:
Add to blacklist: /su/suhide/add UID or /su/suhide/add processname
Remove from blacklist: /su/suhide/rm UID or /su/suhide/rm processname
List blacklist: /su/suhide/list
All running processes for that UID or process name need to be killed/restarted for su binary hiding. For SuperSU GUI hiding, the device needs to be restarted. I recommend just (soft-)rebooting your device after making any changes.
Please keep in mind that many apps store their rooted state, so you may need to clear their data (and then reboot).
Integration into SuperSU
This mod isn't stable, and probably will never be (see the next few posts). As SuperSU does aim to be stable, I don't think they're a good match. But who knows, it all depends on how things progress on the detection side.
Detections
This mod hides the su binary pretty well, and does a basic job of hiding the SuperSU GUI. The hiding is never perfect, and suhide itself is not undetectable either. This will never be a perfectly working solution.
Debugging bootloops
- Get your device in a booting state
- Make sure you have TWRP or a similar recovery
- Install LiveBoot (link)
- If you are not a LiveBoot Pro user, enable the Freeload option
- Enable the Save logs option
- Recreate the bootloop
- In TWRP, get /cache/liveboot.log , and ZIP+attach it to a post here.
Download
Attached below.
Any rm version should work to uninstall any suhide version.
There may be multiple versions of suhide attached, please look carefully which one you are downloading!
YOU ARE EXPLICITLY NOT ALLOWED TO REDISTRIBUTE THESE FILES
(pre-v0.51: 17410 downloads)
Hiding root: a losing game - rant du jour
Most apps that detect root fall into the payment, banking/investing, corporate security, or (anit cheating) gaming category.
While a lot of apps have their custom root detection routines, with the introduction of SafetyNet the situation for power users has become worse, as developers of those apps can now use a single API to check if the device is not obviously compromised.
SafetyNet is of course developed by Google, which means they can do some tricks that others may not be able to easily do, as they have better platform access and control. In its current incarnation, ultimately the detection routines still run as an unprivileged user and do not yet use information from expected-to-be-secure components such as the bootloader or TPM. In other words, even though they have slightly more access than a 3rd party app, they still have less access than a root app does.
Following from this is that as long as there is someone who is willing to put in the time and effort - and this can become very complex and time consuming very quickly - and SafetyNet keeps their detection routines in the same class, there will in theory always be a way to beat these detections.
While reading that may initially make some of you rejoice, this is in truth a bad thing. As an Android security engineer in Google's employ has stated, they need to "make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model".
The problem is that with a rooted device, it is ultimately not possible to guarantee said security model with the current class of SafetyNet tamper detection routines. The cat and mouse game currently being played out - SafetyNet detecting root, someone bypassing it, SafetyNet detecting it again, repeat - only serves to emphasize this point. The more we push this, the more obvious this becomes to all players involved, and the quicker SafetyNet (and similar solutions) will grow beyond their current limitations.
Ultimately, information will be provided and verified by bootloaders/TrustZone/SecureBoot/TIMA/TEE/TPM etc. (Samsung is already doing this with their KNOX/TIMA solutions). Parts of the device we cannot easily reach or patch, and thus there will come a time when these detection bypasses may no longer viable. This will happen regardless of our efforts, as you can be sure malware authors are working on this as well. What we power-users do may well influence the time-frame, however. If a bypass attains critical mass, it will be patched quickly.
More security requires more locking down. Ultimately these security features are about money - unbelievably large amounts of money. This while our precious unlocked bootloaders and root solutions are more of a developer and enthusiast thing. While we're all generally fond of shaking our fists at the likes of Google, Samsung, HTC, etc, it should be noted that there are people in all these companies actively lobbying to keep unlocked/unlockable devices available for us to play with, with the only limitation being that some financial/corporate stuff may not work if we play too hard.
It would be much easier (and safer from their perspective) for all these parties to simply plug that hole and fully lock down the platform (beyond 3rd party apps using only the normal APIs). Bypassing root checks en masse is nothing less than poking the bear.
Nevertheless, users want to hide their roots (so do malware authors...) and at least this implementation of suhide is a simple one. I still think it's a bad idea to do it. Then again, I think it's a bad idea to do anything financial related on Android smartphone that isn't completely clean, but that's just me.
Note that I have intentionally left out any debate on whether SafetyNet/AndroidPay/etc need to be this perfectly secure (most people do their banking on virus ridden Windows installations after all), who should get to decide which risk is worth taking, or even if Google and cohorts would be able to design the systems more robustly so the main app processor would not need to be trusted at all. (the latter could be done for Android Pay, but wouldn't necessarily solve anything for Random Banking App). While those are very interesting discussion points, ultimately it is Google who decides how they want this system to work, regardless of our opinions on the matter - and they want to secure it.
--- reserved ---
Changelogs
2016.10.10 - v0.55 - RELEASE NOTES
- Some code cleanup
- Support for blocking based on process name
- Should fix some crashes (requires uninstall/reinstall to activate)
2016.10.07 - v0.54 - RELEASE NOTES
- Fix for latest SafetyNet update
2016.09.19 - v0.53 - RELEASE NOTES
- Haploid container (monoploid)
2016.09.18 - v0.52 - see v0.51 release notes below
- Fix root loss on some firmwares
2016.09.18 - v0.51 - RELEASE NOTES
- Complete redesign
- Zygote proxying (haploid)
- Binder hijacking (diploid)
- su.d instead of ramdisk modification
- Xposed supported (-ish)
2016.09.04 - v0.16 - RELEASE NOTES
- Fix some SELinux access errors
- Should now work on devices that ask for a password/pattern/pin immediately at boot - for real this time!
- Binderjacking improvements for Nougat
2016.08.31 - v0.12 - RELEASE NOTES
- Fix some issues with suhide-add/rm scripts
- Fix not working at all on 32-bit devices
- Should now work on devices that ask for a password/pattern/pin immediately at boot
- Rudimentary GUI hiding
- No longer limited to arm/arm64 devices: support for x86/x86_64/mips/mips64 devices added
2016.08.29 - v0.01
- Initial release
As always thank you Chainfire! I will try and edit this post.
Edit @Chainfire this seems to work for enabling Android Pay! I didn't get the chance to actually pay yet. But it did let me add my card and did not display the message about a failed authorization of Android check! Before I couldn't even get past that first screen.
Edit 2: @Chainfire It seems to of had an adverse effect on Snapchat. I cleared cache on the app, uninstalled and reinstalled and restarted. It kept Force closing after a photo no matter what. I used suhide-rm and it seems to have fixed the app from any issues. Thanks again and hopefully we'll get you some more reports. Either way your solution works!
Tested on stock rooted 7.0 Nexus 6p.
@Chainfire
What was your reason for doing this project?
Sent from my Nexus 6P using XDA-Developers mobile app
Ofthecats said:
What was your reason for doing this project?
Click to expand...
Click to collapse
For building it, curious if the method I came up with would work well. For releasing, if others are doing it, join them or be left behind.
I'm assuming with custom ROM android pay still won't work right?
HamsterHam said:
I'm assuming with custom ROM android pay still won't work right?
Click to expand...
Click to collapse
I'd just give it a try. It's spoofing the specific app, not the entire ROM that matters. It's fairly simple to try.
Installed on LG G4 w/ V20g-EUR-XX update and rerooted with TWRP 3.0.2-0 and SuperSU-v2.76-2016063161323. seems to be working fine, for the moment. Thank you for the update.
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
djide said:
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
Click to expand...
Click to collapse
What was the UID or process you found to blacklist it with?
Sent from my ONEPLUS A3000 using Tapatalk
how to install it? which file should I flash ? Both?
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Joshmccullough said:
What was the UID or process you found to blacklist it with?
Click to expand...
Click to collapse
Android Pay comes blacklisted out-of-the-box
HamsterHam said:
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Click to expand...
Click to collapse
Are you in Android or TWRP ?
ls -l /data/adb/
Chainfire said:
Android Pay comes blacklisted out-of-the-box
Click to expand...
Click to collapse
Derp. That's what I get for not reading the entire sentence under 'Install' in the OP......thanks!
PedroM.CostaAndrade said:
how to install it? which file should I flash ? Both?
Click to expand...
Click to collapse
Please don't quote a large post like that just to ask a single question.
Please read the first post, so you know what to do.
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
thdervenis said:
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
Click to expand...
Click to collapse
You need to blacklist the UID for your bank. Directions are in the OP.
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