Related
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.
Dear forum,
Long time no talk! I have been able to get "root" for our phones on G925VVRU4BOG7, which anyone can downgrade to. The catch is that even with /system mounted as rw, I am unable to write to it directly through most conventional means. (I can write to /data, though, which means i can patch dalvik-cache, which means my mods are coming ) However, I am able to still write to it using another, more complicated way (I can go into more detail for those interested), as a whole. Here's where you come in-- is anyone still full-rooted? If so, please message me as soon as possible! I may be able to have users who are on newer builds downgrade to older builds and get su properly installed, then manually upgrade back up to the later builds again!
If you are rooted still, all i'm going to have you do is perform this command:
Code:
su
dd if=/dev/block/platform/15570000.ufs/by-name/SYSTEM bs=4096 of=/sdcard/system.img
Then send me that system.img file on your sdcard! It'll be pretty big, so you can zip it or .7z (7-zip), whatever you'd like to do.
I will also need what build you are on. You can just send me your Build number within "Settings->About phone".
First one who does it gets credits on the official release thread i'll make, when I get a procedure down that people can follow!
Thanks!
-Trailblazer101
i have an s6 edge on 5.0.2 rooted. Would that be of help?
Did you get the system.img file? I really wish I could help you. I have this phone on 6.0.1 and stuck without root, but the thing is I really need the root because I bought it used, worked fine the first few days, then didn't get any signal (turns out that it was reported as stolen and of course the IMEI got blacklisted; I tried to contact the seller but he was gone, and his ebay account deleted, so basicly I'm stucked with a ' 5.1" tablet' . I got scammed :/ )
I would be very grateful if you could explain how did you get root on G925VVRU4BOG7 . I know that you want the file mentioned for creating some kind of universal root for the phone, but right now I'm kind of desperate and need root as soon as possible to fix my IMEI issue and I would follow your steps if you made a tutorial.
Thank you very much!
trailblazer101 said:
Dear forum,
Long time no talk! I have been able to get "root" for our phones on G925VVRU4BOG7, which anyone can downgrade to. The catch is that even with /system mounted as rw, I am unable to write to it directly through most conventional means. (I can write to /data, though, which means i can patch dalvik-cache, which means my mods are coming ) However, I am able to still write to it using another, more complicated way (I can go into more detail for those interested), as a whole. Here's where you come in-- is anyone still full-rooted? If so, please message me as soon as possible! I may be able to have users who are on newer builds downgrade to older builds and get su properly installed, then manually upgrade back up to the later builds again!
If you are rooted still, all i'm going to have you do is perform this command:
Code:
su
dd if=/dev/block/platform/15570000.ufs/by-name/SYSTEM bs=4096 of=/sdcard/system.img
Then send me that system.img file on your sdcard! It'll be pretty big, so you can zip it or .7z (7-zip), whatever you'd like to do.
I will also need what build you are on. You can just send me your Build number within "Settings->About phone".
First one who does it gets credits on the official release thread i'll make, when I get a procedure down that people can follow!
Thanks!
-Trailblazer101
Click to expand...
Click to collapse
I am currently running on A0E2 using your rooted rom for this phone. It runs great....except I tried flashing xposed framework using Flashfire and it of course failed...due to the fact that xposed only works on 5.1.1 or above...sucks we are in such a catch 22 with our devices...although I'm happy because I am still rooted.. Anyway...I set up ADB and entered that command you posted and it worked...I just don't know where the storage location of the system.img file is for me to transfer to my PC, 7zip, and send to you. Any help would be excellent....as I desperately want to run xposed framework on my device....but am stuck on 5.0.2
r0ckinb0i said:
I am currently running on A0E2 using your rooted rom for this phone. It runs great....except I tried flashing xposed framework using Flashfire and it of course failed...due to the fact that xposed only works on 5.1.1 or above...sucks we are in such a catch 22 with our devices...although I'm happy because I am still rooted.. Anyway...I set up ADB and entered that command you posted and it worked...I just don't know where the storage location of the system.img file is for me to transfer to my PC, 7zip, and send to you. Any help would be excellent....as I desperately want to run xposed framework on my device....but am stuck on 5.0.2
Click to expand...
Click to collapse
Looking at the last part of the command and if it ran successfully, it should be in /sdcard. Did you ever find it?
gabes100 said:
Looking at the last part of the command and if it ran successfully, it should be in /sdcard. Did you ever find it?
Click to expand...
Click to collapse
Thank you I found it...I'm new to command prompt although I am learning quickly. I found it. I just need to load it onto my computer and compress it so I can send it to Trailblazer. I will do that tomorrow night when I get back home.
I have the img on my computer. It is 4.3G. How do I get it to Trailblazer? Google Drive? EDIT: it is 4.58GB. I am uploading now to google drive, it will an hour
Hi Trailblazer,
Here is a link to system.img:
https :// drive google com / open?id=0B-j3XfGrnj9PbUdwaml5eERvbFU
I am too new to post links the correct way.
Are there any updates on this topic? When I first saw this thread last week, It got me thinking about what a Tethered Root (Temporary/Semi - Root) would still be capable of doing for those of us still on Official Firmware in this day and age.
And really it occurred to me at that moment, that if we could just attain a Root Shell even if it was only for 60 seconds to five minutes, that would be sufficient to get enough root information off of the phone and into a PC editable format.
I ask, because I am in the process of forming a method for the G925V 6.0.1 [PI2] Build. The problem I'm pretty sure I'm going to run into sooner or later in my experiments/research, is the fact that I am one of the few who have the 64GB Verizon S6 Edge. Technically speaking, my device refers to itself in Download/ODIN mode as a SM-G925VZKE model. This also means that my Stock .PIT file is going to be very different than most people's, also meaning my FSTAB configuration probably will be different.
Because there shouldn't be a reason I can't at least get a temporary Root Shell very soon.
So whats up with this? My wife has 6.0.1 on Verizon and I have international much better choice. Will we have root on this phone?
If you are currently on 6.0.1 on your Verizon device. It would serve you well for the time being to disable Automatic Security Updates.
Settings > Lock Screen and Security > Other Security Settings > Security Policy Updates
Turn OFF Automatic Updates, and Turn OFF Wi-Fi Only.
If you leave these on, any potential root option will be patched by Samsung/Google before you know it exists. Disable it for now so you can find an exploit for the build the device is on.
UPDATE:
So apparantly, I've had a rooted 6.0.1 PI2 device persistent through factory resets for over a week, but didn't realize just how much was achieved on my device! According to diagnostics.
I'm already started on writing up the combination of methods that the OP was walking into. Turns out it works up to the September patch too.
But lucky me and not you this time. I got my device essentially decommissioned because I ran my code too soon. But in the sweetest possible way after being so pissed when my tech coach said my warranty was void.
By the end of tomorrow night I should have a thread.
Anyone still working on this?
d0lph said:
Anyone still working on this?
Click to expand...
Click to collapse
Yes. Using the dirtycow vulnerability we've managed to get an arm64 version running that will indeed allow a root console on MM builds.
The last thing standing in the way, for at least a tethered root, is for someone to help me convert the script from the flashable zip version of the SuperSu installer into basically a batch script. Because the how-to guide ChainFire wrote in comments inside his installer script is kind of hard to read because it covers all the different versions of android in a tiny block of text and not every device sets up the same SELinux environment.
Not to mention, if I could get SuperSU to try and install itself as a System Application, it would probably work with what I have already. But for some reason I CANNOT find a single guide anywhere on how to perform a "System" Install of SuperSU, everyone wants to use the "Systemless" version, which is NOT going to work I believe.
We can manage booting the device in the event of DM-Verity Failure, when that happens with the 5.1.1 OG ENG Kernel, we can indeed mount "/system" as read/write, and we can indeed change the contents of the System partition that persist through a reboot.
I just need help setting Perms & Contexts. Because at one point in time, I DID actually manage to get SuperSU to give me a root shell instead of a user shell, but only on the ADB Command Line. In that test I could not get an application to start from the launcher and have Root Permissions.
Delgoth said:
Yes. Using the dirtycow vulnerability we've managed to get an arm64 version running that will indeed allow a root console on MM builds.
The last thing standing in the way, for at least a tethered root, is for someone to help me convert the script from the flashable zip version of the SuperSu installer into basically a batch script. Because the how-to guide ChainFire wrote in comments inside his installer script is kind of hard to read because it covers all the different versions of android in a tiny block of text and not every device sets up the same SELinux environment.
Not to mention, if I could get SuperSU to try and install itself as a System Application, it would probably work with what I have already. But for some reason I CANNOT find a single guide anywhere on how to perform a "System" Install of SuperSU, everyone wants to use the "Systemless" version, which is NOT going to work I believe.
We can manage booting the device in the event of DM-Verity Failure, when that happens with the 5.1.1 OG ENG Kernel, we can indeed mount "/system" as read/write, and we can indeed change the contents of the System partition that persist through a reboot.
I just need help setting Perms & Contexts. Because at one point in time, I DID actually manage to get SuperSU to give me a root shell instead of a user shell, but only on the ADB Command Line. In that test I could not get an application to start from the launcher and have Root Permissions.
Click to expand...
Click to collapse
Thank you for taking the time to still work on this. Subscribed. Following this to the T.
Rand0lph said:
Thank you for taking the time to still work on this. Subscribed. Following this to the T.
Click to expand...
Click to collapse
If you want to follow the complete story of what I just mentioned please follow and contribute to this thread: Injecting Root & Setting SELinux - End Stages?
This is the thread that contains the Greyhat Root console, first designed for the AT&T Galaxy Note 5. But that device uses the same Exynos7420 Mainboard as the Galaxy S6 Edge, so the project is still compatible.
I haven't kept the OP maintained as I should yes. But it is actually worth it to read that whole thread as @droidvoider went out of his way explaining some of his methods. I have a bit of R&D that isn't posted in that thread as well, if you can read up on the project. I'd be more than happy to share what I know with anyone wanting to help as long as they can catch up with what we have accomplished so far.
Look at some of the other threads I've started as well for the initial methods.
Delgoth said:
If you want to follow the complete story of what I just mentioned please follow and contribute to this thread: Injecting Root & Setting SELinux - End Stages?
This is the thread that contains the Greyhat Root console, first designed for the AT&T Galaxy Note 5. But that device uses the same Exynos7420 Mainboard as the Galaxy S6 Edge, so the project is still compatible.
I haven't kept the OP maintained as I should yes. But it is actually worth it to read that whole thread as @droidvoider went out of his way explaining some of his methods. I have a bit of R&D that isn't posted in that thread as well, if you can read up on the project. I'd be more than happy to share what I know with anyone wanting to help as long as they can catch up with what we have accomplished so far.
Look at some of the other threads I've started as well for the initial methods.
Click to expand...
Click to collapse
Sorry, I didn't even acknowledge this is for the EDGE S6. I have a regular Verizon S6.
Rand0lph said:
Sorry, I didn't even acknowledge this is for the EDGE S6. I have a regular Verizon S6.
Click to expand...
Click to collapse
I don't really think that matters as much for the thread I referred to.
I tested the Greyhat Root Console on my S7 Edge, and it worked as well using the September build.
The S6 Line plus the Note 5, all use the same System on a Chip.
If anything, there may be just a couple tweaks to make when compiling it using the NDK.
Unreal.... can a group of professionals get together and spend a day cracking the bootloader and root the Verizon version note 5 not even one custom rom for this device all other models have gotten there attention we need to crack this note 5 please
so far no one can hack n920v bootloader. Me also waiting for this info. Until now my n920v still not root yet. huhuu
It does not bypass bootloader
It's funny, in the UART logs running an engineering s-boot, it will say that an invalid image was detected, and it will reboot to avoid tripping Knox. A t-mobile phone I got, I accidentally flashed a Verizon image, and there went Knox, before I had intended to. Verizon has probably drastically reduced the unexplained returns, with the lies suggested on here to use by doing that. That might be a main motivation to consider.
But back to the subject, before I ever tried attempted to understand Magisk (which I used on my XT1575), which sort of does the same thing I did, but still allows selinux, was to use the engineering kernel, and did the following:
& Mount /system as loopback in /data/systemmirror
& Mount a loop back image over /system, which effectively hides it
& Link to each file in the loopback to the mirror, except for what I didn't want, and add what I did want. I even got xposed, microg/unifiednlp working like that. I didn't want to use supersu, but I imagine it can be done too. Some files had to be on the loopback system because uh I think it didn't like dynamic linking some library files that were links, that was fun to debug again and again and again until it worked.
& Set selinux permissive, because links aren't normally allowed, and I couldn't figure out how to make that work in the policy, and I could have reloaded it with the tools in the supersu apk if I knew what I was doing.
Thus, a tethered root is made. Tethered. Every boot up, you have to log in with adb to run the shell script that mounts everything, changes selinux, and kills system_server, effectively rebooting it. I could not figure out another way. It worked, minus samsung pay.
While that doesn't sound so bad, I went into the subway, was playing my hacked up version of shattered pixel dungeon, and the kernel crashed. Man, I that was a bummer. Still haven't rooted it properly.
If there's a fwbl1 or something that breaks the chain of trust from a developers SDK, sboot could be modified to load any binary without tripping Knox into an existing sboot probably.
I've removed so much stuff from this post so many times while preparing the draft to submit to my comment editor, I wonder how many times before I'm forced to decide whether a sign post visible in 1/9th of a picture is part of a street sign or not.
Hi, all. I am trying to enable multiple users on my S6 Active. I'm aware there's no root exploit for this device, but enabling multiple users normally doesn't require rooting a Samsung device, just installing a custom recovery so that I can boot without read-only applied to the system partition.
Can TWRP (or any recovery that allows adb write access to the system partition) be installed onto an S6 Active, running Android 7.0.1? I read something about how it could trip Knox, but I'm a bit unclear on how bad that is -- I don't understand if tripping Knox totally disables the device or just deactivates Samsung-specific features like Samsung Pay. Personally, so long as Google Play and calling/texting work normally, I couldn't care less about Samsung-specific apps being disabled, and I don't care about the warranty.
Alternatively, any other method to enable multiple users would be warmly welcomed. (If I need to install an app or something to simulate multiple users, that's probably fine, if it works.)
Thanks in advance for any help. I know this is an older device and people have probably moved on from it.
Trying to help a friend install an rclone pluing for Kodi, I found out that on my phone I needed to install this module https://github.com/galeksandrp/app-data-file-exec
The module worked and Kodi was able to run a binary in its data directory. Problem is my friend uses an Nvidia Shield and he wants to use official streaming apps too (Netflix, Prime Video, etc.). Rooting is consequently a no-no, otherwise those would fail to play at highest quality.
I've found a possible workaround but to test I need to reverse this policy:
allow * { app_data_file privapp_data_file } file { execute_no_trans }
Which is pretty much all that the module I installed does.
Uninstalling the module did not remove the policy. Kodi keeps on being able to execute the rclone binary. And I need to restore my system to how it was before that policy modification.
Any help? Thanks in advance!
Edit: while waiting for somebody knowledgeable enough I've been searching and searching. I've found this, from here: https://android.googlesource.com/platform/system/sepolicy/+/master/private/app_neverallows.te#58
Code:
# Block calling execve() on files in an apps home directory.
# This is a W^X violation (loading executable code from a writable
# home directory). For compatibility, allow for targetApi <= 28.
# b/112357170
neverallow {
all_untrusted_apps
-untrusted_app_25
-untrusted_app_27
-runas_app
} { app_data_file privapp_data_file }:file execute_no_trans;
But I am unsure how to proceed, since the module does not completely reverse the above, it's more targeted. I wouldn't want to create a situation where normal apps cannot work properly anymore.
gorman42 said:
Trying to help a friend install an rclone pluing for Kodi, I found out that on my phone I needed to install this module https://github.com/galeksandrp/app-data-file-exec
The module worked and Kodi was able to run a binary in its data directory. Problem is my friend uses an Nvidia Shield and he wants to use official streaming apps too (Netflix, Prime Video, etc.). Rooting is consequently a no-no, otherwise those would fail to play at highest quality.
I've found a possible workaround but to test I need to reverse this policy:
allow * { app_data_file privapp_data_file } file { execute_no_trans }
Which is pretty much all that the module I installed does.
Uninstalling the module did not remove the policy. Kodi keeps on being able to execute the rclone binary. And I need to restore my system to how it was before that policy modification.
Any help? Thanks in advance!
Click to expand...
Click to collapse
every custom allow (ie not compiled into the ROM) I apply on my phone, has to be reinstated on boot.
If you have root, its possible that it is being reinstated by something, on every boot. eitehr a Magisk script, a Magisk module or a rooted app.
However, when compiling ROMs, the opposite of "allow" is "deny". I have never tried to add a deny (or revert an allow), and it cant be done without root, so you are back where you started.
Sorry, I probably did not explain myself fully.
I have root and it's absolutely fine for me to keep root on this device. Withouth that policy my rooted device was behaving the same way as Nvidia Shield TV. And I simply want to restore it to the way it was.
This is why I linked to the module, because to me it seems that it simply issues the command I pasted here. But maybe I am missing something. I have unistalled it, I have deleted the files too. But still Kodi is now able to execute binary code in its own data directory, something that on 11 should be not allowed.
If there are termux commands I can use to check the situation, as stated, I have root, I can do whatever is needed to gather more information.
I simply thought that it was enough for me to uninstall the module to revert but that does not appear to be the case. Unless the privilege Kodi is using is saved once and for all on a per app basis. And since Kodi used it once, it remained (it doesn't sound likely but I'm grasping at straws).
I asked mods to move this, if this is not the correct forum to ask for this.
Edit: it was in general questions and answers
Bump? I hope it's allowed.
Could somebody be so kind as to advise where I could post this so as to get an answer? I realize this might be the wrong forum, maybe.
But I have asked already in two different places and I haven't gotten to the bottom of it.
Thanks!
Bump
Bump... :-(
Bump. I hope somebody could at least point me to somewhere where I could ask.
Please?
Bump.