Try a different browser, I just tried the link and it works for me
Sent from my SCH-R220
[2016.10.10] suhide v0.55 [CLOSED]
- Thread starter Chainfire
- Start date
- Status
Sent from my SCH-R220
Yes I can download it but it won't flash via twrp
Sent from my SM-G935F using Tapatalk
If I had a brain I would be dangerous lol. Thanks
Sent from my SM-G935F using Tapatalk
many thanks @Chainfire
It works perfectly on my Huawei P9 Lite.
magisk V7
SuperSU SR1
Suhide 0.55 + 06
Greetings.
---------- Post added at 06:47 PM ---------- Previous post was at 06:40 PM ----------
I do not get Xposed framework 86.6, whenever me how active work. let me run the Root, I always get binary SU need to update
Any ideas, thanks in advance.
It works perfectly on my Huawei P9 Lite.
magisk V7
SuperSU SR1
Suhide 0.55 + 06
Greetings.
---------- Post added at 06:47 PM ---------- Previous post was at 06:40 PM ----------
I do not get Xposed framework 86.6, whenever me how active work. let me run the Root, I always get binary SU need to update
Any ideas, thanks in advance.
Last edited:
I use Super su 2.78 systemless + suhide 0.55 + Root Switch procedure from this link ( https://www.reddit.com/r/pokemongodev/comments/57gpcq/how_to_root_and_run_pogo_as_of_10142016/ ) . This method is actual working for me. Now, Safetynet is passed again with this method and Pokemon go is working now on my Sony M4 Aqua.
Is your SELinux Enforcing?
I used Termux and it failed, I then removed the file and instead used an ADB shell to create it. It works like a charm.
Connect the phone to a computer and run the ADB shell from there.
Here pass OK.. Supersu 2.78 SR1 systemless, suhide 0.55, 06suhide, xposed 86.2 systemless.
Attachments
Super su 2.78, such hide 55 and 06 script doesn't work for Playstation vue. I'm running pure nexus 7.0 on my nexus 6p so no xposed options. Rootcloaker + xposed works on my marshmallow S5
Sucks. My kernel is permissive. I cannot find a way to change it. There's very little development for SM-G901F kernels.
I think if you had SU systemless installed after you fully unroot you have to do a dirty install of your ROM in order to replace original boot.img . i AM not sure bit this is what i think
Thanks, dirty install of ROM did the trick!
After installing new rom, I did full unroot again but I still had root somehow from my OctOS ROM. Prompts "Privacy Guard" when app tries to get root. I had to manually delete /system/bin/su and /system/xbin/su and now I'm passing Safetynet!!!
I think my OctOS ROM is more nifty than I thought. I pretty does what Superuser + suhide does because I'm able to enable root in developer options and it still passes both Safetynet Helper (GREEN) and Safety Playground. When an app needs root, I get a prompt for "Privacy Guard" to grant it root access.
oh, sorry, I have misunderstood you. I used Terminal emulator before and it was lacking the copy/paste function, so I switched to this one and so far it works ok.
- Status
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
463THIS 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)286Hiding 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.167v0.54 released
This release fixes the detection for yesterday's SafetyNet update. This one was trivial to bypass. Download available from the opening post.
I have not had time to really look into the two biggest remaining issues:
- Systemless xposed only working so-so
- Google Play Services sometimes crashing
Though at least on that crashing issue I now have an idea how to fix it, but will need to build it first. It still doesn't happen on any of my own test devices though...98Now that we know what the issue is, yes, it can be fixed. In fact I'm surprised it took them this long to detect it this way, as it's arguably the easiest way to detect SuperSU (lol). The thought of getting rid of that has been nagging me for a while, but so far haven't gotten around to it.
The SuperSU binaries will probably need an update to work around this properly, but a fix is certainly possible. It will just not be today! Of course, if you're looking for a quick and dirty workaround:
From a su shell:
... and rebootCode:echo '#!/su/bin/sush\nmount -o rw,remount rootfs /\nchmod 0751 /\nmount -o ro,remount rootfs /'>/su/su.d/06suhide; chmod 0700 /su/su.d/06suhide
This works for me on my 5X @ 7.0, your mileage may vary. This workaround will be easy to detect, but it'll probably hold over the weekend.
Note that SafetyNet Helper has been acting up a lot for me lately, though SafetyNet Playground reports success for me.
IMPORTANT: If you implement the above, you're going to have to rm /su/su.d/06suhide before installing the next suhide update.81Just attached v0.55 to the first post of this thread. Also added info to the changelog post.
I've added support to hide root based on process name, rather than just UID that was used before. This way, suhide can block the SafetyNet portion of Google Play Services but not Google Play itself (they share the same UID). This may fix some of the crashes some users have been seeing ( @Ch3vr0n ? ).
While some users will be tempted to start using package names instead of UIDs for the blacklist, it should be noted that:
- Process and package names are often the same, but certainly not always. Using UIDs is generally more reliable.
- Using UIDs is faster than using process names. It's probably not noticable, though.
Important: To start blocking SafetyNet by process name rather than UID, and potentially fix crashes, you must uninstall the old suhide before installing v0.55. Alternatively, you can manually remove com.google.android.gms 's UID from the blacklist, and add com.google.android.gms.unstable (as process name).
