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.
Related
POST IS UPDATED REGULARLY.
LINK 1 - Parallel Space: https://play.google.com/store/apps/details?id=com.lbe.parallel.intl&hl=en[/URL][/URL]
LINK 2 - Parallel Space 64-Bit Support: https://play.google.com/store/apps/details?id=com.lbe.parallel.intl.arm64&hl=en[/URL][/URL]
Salutations. (That means 'Hello').
NOTE: For those who are interested, I will include background information about how I came to the solution. All that other jazz too. First and foremost however; the fix!
SOLUTION:
Right at the top of the post, you will find two links. This being a new account and all (don't ask), until I create 10 posts I cannot include any outside links. So once I've done so, I will update the post.
STEP **: So at the top of the post, there are clearly two links. 64-Bit Android devices are becoming increasingly common. This architecture may pose a few problems. give the application framework. Should you own a 64-Bit device, I recommend installing this application too (LINK 2). This will theoretically prevent any obstacles.
Pre-requisite(s): Make sure you have the 'Snapchat' application installed. It is recommended to have installed the latest update from the Google Play Store.
STEP ONE: Download the application appended to LINK 1. This is called Parallel Space. You might recognize the name (its creators are the same who allow you to seamlessly virtualize Windows OS on Mac OS).
STEP TWO: Launch the application.
STEP THREE: You should be prompted with a grid-like interface. Here you will be greeted with a range of familiar icons. In the top right corner of each icon, you will notice a blue check-mark. Make sure that there is one next to the 'Snapchat' icon. This will ensure that the app is 'cloned'.
STEP FOUR: In the 'Parallel Space' app, tap on the 'Snapchat' icon. This will launch the application.
STEP FIVE: From here it is pretty self-explanatory. You are greeted by the standard 'Snapchat' interface. Tap on 'Log In'. Then proceed to do so.
STEP SIX: 'Snapchat' should be functioning as normal.
STEP SEVEN (BONUS): During testing, this worked on and off. --
Remain logged-in to the 'cloned' 'Snapchat' application within the 'Parallel Space' application.
Then proceed to launch the stock 'Snapchat' application.
Next attempt to 'Log-In'.
Should this operation be successful, you are then free to uninstall 'Parallel Space' and any related assets from your device.
HOWEVER, I personally do not recommend this. When logging out or updating the 'Snapchat' application, errors may be re-encountered.
Instead, I recommend that if possible, do use the stock application, but leave 'Parallel Space' installed. Using the stock app will improve efficiency and reduce the load on system resources. But keeping the 'Parallel Space' application on the device, well; you get the point.
Enjoy the fix! If it does not work, please let me know [Device Name and Model No.]. I've tested on various devices, succeeded every-time. Do keep in mind that this is a loop-hole, so may be patched in future or not work at all for some devices.
Background (Because I know someone will ask): The idea came to mind while using a LG G5 as a daily driver. I had tested every custom ROM available for the device. The problem was that with custom ROM's, there was always an issue, Malfunctioning sensors, camera's not working persistently, etc , etc.
The G5's stock ROM left me wanting more. The overbearing interface made it a living hell. Plus, the device just being rooted (NO XPOSED) meant that 'Snapchat' did not work. I looked for fixes for a time, but could not find any.
Development of ROM's for the device is on-going, and I am an active member. But I just couldn't handle not being able to use the camera (one of the device's best features) and no accelerator, screen-rotation, etc. So I went back to stock again. Do keep in mind that I was alternating/dual-booting between custom and stock ROM's just because of the camera; mainly.
This most recent time. instead of flashing stock MM, I flashed stock N for the G5. For 850, it has been officially released in some countries, and a manual flash via TWRP was a peice of cake.
This update is a lot better. I am running Nova Launcher again. So it makes it look a little better. Themes have also been improved. I am using an in-built dark one which makes the device look a lot better aesthetically. Additionally, I'm rocking a white carbon-fibre skin on the exterior; improving grip and overall security. The only issue was again, no 'Snapchat'.
After a few days, I had the idea to attempt this. I tested my theory and it worked! That's it.
Please do keep in mind that I will update this post as often as possible.
P.S This was tested just after updating to the latest version of 'Snapchat' which was a significant update. It included Shazam, Groups, etc. So you know, pretty cool that it worked.
Did not work on Google Nexus 5 running Android 7.1.1. Still gives error message saying that I can't connect to the server.
Same here, not working on freshly reinstalled and rooted 7.1.1 Nexus 5x. No Xposed, no nothing. I get the infuriating "temporarily failed" message in both cloned and regular modes.
It didn't worked. S7 edge exynos (6.0.1)
Holyphe said:
It didn't worked. S7 edge exynos (6.0.1)
Click to expand...
Click to collapse
I'm pretty sure if you get Xposed framework, there's a module that allows you to hide root from apps. Problem is that there is no Xposed framework for Android 7 yet. Hope this helps.
hot_potato said:
I'm pretty sure if you get Xposed framework, there's a module that allows you to hide root from apps. Problem is that there is no Xposed framework for Android 7 yet. Hope this helps.
Click to expand...
Click to collapse
Whats the name of it?
Holyphe said:
Whats the name of it?
Click to expand...
Click to collapse
I personally tried the module on cm13 but it doesnt work for me. I think that somehow snapchat knows when you use xposed too.
The thing is that on aosp roms with root already build in sometimes snapchat do not catch it but if you have xposed, no way you can get in. For that freaky snapchat app here is what i did: install any rom, if if had root build in i then install su uninstaller zip with twrp then log in into snapchat and after that, rooting with super su zip again. The catch is that once you log out of the app and attempt to log in again, you cant get in and you have to repeat the proccess. It's annoying as hell!!! They need to disable the security check, if people want to cheat che system somehow they will, so whats the point. Also there are much more tweaks for jailbroken iphones and they have no problem with it .
Sorry for the rant here buqt im super frustrated.
AndroidFL said:
I personally tried the module on cm13 but it doesnt work for me. I think that somehow snapchat knows when you use xposed too.
The thing is that on aosp roms with root already build in sometimes snapchat do not catch it but if you have xposed, no way you can get in. For that freaky snapchat app here is what i did: install any rom, if if had root build in i then install su uninstaller zip with twrp then log in into snapchat and after that, rooting with super su zip again. The catch is that once you log out of the app and attempt to log in again, you cant get in and you have to repeat the proccess. It's annoying as hell!!! They need to disable the security check, if people want to cheat che system somehow they will, so whats the point. Also there are much more tweaks for jailbroken iphones and they have no problem with it .
Sorry for the rant here buqt im super frustrated.
Click to expand...
Click to collapse
That's the only solution I've seen working so far. unroot and reroot. Root cloak doesn't work, parallel doesn't work. I should've logged in before rooting and I hate to do it again.
Any work arounds yet? I've seen ppl do it using titanium backup but I'm not sure if that works. Can anybody help?
Samsung s5 G900v Not working
I have been searching and searching and still haven't found a way to sign into snapcat. It took me about 6 months to be able to find out how to root my phone.
Dukeboyty said:
I have been searching and searching and still haven't found a way to sign into snapcat. It took me about 6 months to be able to find out how to root my phone.
Click to expand...
Click to collapse
Well todays your lucky day.
Step one turn off xposed.
Step two reboot
Step three sign into snapchat
Step four turn xposed back on
Step five reboot
You should be able to snap now.
Okay. I will try this on monday and will let youknow how it goes. Right now I decided to unroot to use snapchat, so I didn't loose my streaks. Thanks in advane will let you know how it goes.
immorality said:
Well todays your lucky day.
Step one turn off xposed.
Step two reboot
Step three sign into snapchat
Step four turn xposed back on
Step five reboot
You should be able to snap now.
Click to expand...
Click to collapse
Now that i think of it, when i uninstalled xposed it didn't work still. but after i "fully unrooted" through Super su and tried to sign in it worked. so it has to do with root or maybe both but the xposed didnt work for me. Thanks even though it didn't/wouldn't have worked for me!
Dukeboyty said:
Now that i think of it, when i uninstalled xposed it didn't work still. but after i "fully unrooted" through Super su and tried to sign in it worked. so it has to do with root or maybe both but the xposed didnt work for me. Thanks even though it didn't/wouldn't have worked for me!
Click to expand...
Click to collapse
Snapchat detects xposed framework.
Though at a time they did do root they since moved to blocking xposed due to the security concerns with money and also privacy of the user.
Though with certain phones and ect that could be the case I am using a s5 and have no issues.
just install magisk and systemless xposed and turn on magisk hide in magisk manager now snapchat won't detect root
then when u wanna log in just turn off xposed in xposed installer and reboot "it won't take time booting optimizing app when reactivated now" so reboot is easy
and u can have multiple accounts by backing up snapchat with titanium backup and don't ever log out just wibe its data and when u want to relog just restore the backup
and if u want to have multiple accounts access just patch the titanium backup with luckypatcher and have multiple backups (accounts)
ahmedsasker said:
just install magisk and systemless xposed and turn on magisk hide in magisk manager now snapchat won't detect root
then when u wanna log in just turn off xposed in xposed installer and reboot "it won't take time booting optimizing app when reactivated now" so reboot is easy
and u can have multiple accounts by backing up snapchat with titanium backup and don't ever log out just wibe its data and when u want to relog just restore the backup
and if u want to have multiple accounts access just patch the titanium backup with luckypatcher and have multiple backups (accounts)
Click to expand...
Click to collapse
Can u make a instructions how to do it step by step? How can i turn off xposed in xposed installer? It also works when SuperSu is installed or i have to unistall it first?
Fnn.09 said:
Can u make a instructions how to do it step by step? How can i turn off xposed in xposed installer? It also works when SuperSu is installed or i have to unistall it first?
Click to expand...
Click to collapse
make a nandroid backup if u want
1- full unroot by opening supersu and going to settings and press Full unroot and wait till it finishes and restart
2- download xposed uninstaller if u have xposed framework installed and flash it
3- install magisk manager from playstore
4- download and flash last magisk which is (12v) now from : https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
5- flash magisk v12.0 which you downloaded now your phone will have systemless root
6- go into magisk manager app and go to settings and toggle "Magisk Hide" (ON) and restart now your root is hidden
7- remove your current xposed app and install this one : https://forum.xda-developers.com/xposed/material-design-xposed-installer-t3137758
8- flash systemless xposed : https://forum.xda-developers.com/xposed/unofficial-systemless-xposed-t3388268
9- reboot and go to the xposed installer app and toggle the xposed off or on as you want when u restart it won't take time optimizing apps like before so fast now
your root is hidden now but xposed is not but you can disable it and enable it easily
Instead of using Parallel Space (which I believe to be insecure) use Island to clone your apps. It's a little more advanced to setup, but it's a lot more secure. It works for rooted and non-rooted devices. On the 1st page of the thread, it explains how Parallel Space and others repack the apk file locally, which is dangerous. https://forum.xda-developers.com/android/apps-games/closed-beta-test-incoming-companion-app-t3366295
Island never repack apk file locally, which is inherently insecure for users, since all your app data (including password input) are technically in the hand of MoboClean. (The same applies to other similar tools, e.g. LBE Parallel Space)
Instead, Island takes advantage of the underlying mechanism used by "Android for Work". This ensures that all your apps run natively in Android system and their data are securely stored in internal location of Android which is never accessible by Island. It has the same level of security as "Android for Work".
Click to expand...
Click to collapse
Be sure to read the disclaimer!!! The app is still only available in closed beta at the time of writing this, and could possibly cause you're device to bootloop or even possibly brick it, but root, xposed, or other modifications {in my opinion) has a higher chance of bootloops or bricking your device.
You follow the same steps in island to clone snapchat as you would in Parallel Space to login to snapchat. It might be possible to use the play store inside island to download snapchat inside island and login that way. I can't remember exactly how it works. I believe that island is a good way to test apps in a "sandbox environment" to keep the data excluded, safe and secure from the regular apps that you have installed outside of island.
I use Magisk now which bypasses SafetyNet which is what snapchat uses to "block access" to modified/rooted devices.
Probably the easiest method is to download Casper which is an alternative snapchat client that allows you to save snaps, and many other features that the official snapchat client can't do. Find Casper at www.casper.io
FYI Netflix has started to change how they do things as well by hiding the app's play store page from devices that have been modified or rooted, but it's still possible to simply sideload Netflix for now.
suhide-lite is an experimental (and officially unsupported) mod for SuperSU that can selectively hide root (the su binary) from other applications. It can also toggle visibility of packages (such as SuperSU).
SafetyNet verified passing on 2017.08.10.
This is ultimately a losing game (see the next post). suhide may stop working at any time.
Requirements
- SuperSU v2.82 SR2 or newer (link)
- SuperSU installed in SBIN mode (default on O+)
- Android 6.0 or newer
- TWRP (3.0.2 or newer with access to /data), FlashFire is not (yet) supported.
Xposed
Not supported.
CyanogenMod/LineageOS
Not currently tested or supported. Might work, might not.
Custom kernels/ROMs
If they changed build props, they will probably fail SafetyNet check (for now).
Installation
First make sure you are using SuperSU in SBIN mode on Android 6.x and 7.x
- Boot into TWRP
--- adb shell: echo "BINDSBIN=true">/data/.supersu
--- OR: flash SuperSU Config and select Systemless SBIN mode
- Reflash SuperSU v2.82 SR2 or newer
- Reboot into Android at least once
With SuperSU in SBIN mode
- Flash the suhide ZIP in TWRP
- Reboot into Android
If your TWRP does not fully decrypt /data, reflashing the SuperSU ZIP and immediately flashing the suhide ZIP without rebooting in between may sometimes allow suhide to be installed as well where it would otherwise throw an error.
Usage
The suhide GUI available from your app drawer should be fairly self-explanatory. The About tab lists further instructions.
Advanced usage
You can manually add/remove/list entries to suhide's blacklist by using these commands:
/sbin/supersu/suhide/add UID-or-processname
/sbin/supersu/suhide/rm UID-or-processname
/sbin/supersu/suhide/list
App package names are usually the same as the process name, but not always. Using the UID is safer. You can find the UID by running 'ps -n' (6.x/7.x) or 'ps -An' (8.x). The UID is the first column, and is a 5-digit number starting with 10: 10xxx.
Uninstall
Remove /data/adb/su/suhide folder in TWRP's file manager. You can uninstall the suhide app through Android's settings.
Download
UPDATE-suhide-v1.09-20171001222116.zip
In case that bootloops, try the old v1.00 version, and let me know your device and firmware:
UPDATE-suhide-v1.00-20170809130405.zip
Sauce @ https://github.com/Chainfire/suhide-lite
Hiding root: a losing game - rant du jour
Quoting myself from the OP of the old suhide thread:
Chainfire said:
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.
Click to expand...
Click to collapse
I still stand behind this statement I made a year ago.
I will add to this another concern that I've posted before: on the A/B layout devices such as the Google Pixel (XL), it is possible to detect the device is rooted with a handful of lines of code, and I do not see any way to beat this detection aside from custom kernels. As soon as this detection is added to SafetyNet, it is pretty much game over. Frankly I'm surprised it hasn't been added yet.
The new suhide-lite vs the old suhide
The old suhide was completely different under the hood. It proxied zygote and created two different process trees for the real zygote and descendants (apps), one with root and one without, and multiplexed app instantiation calls between them. The new suhide-lite uses a completely different mechanism to achieve a similar outcome (some apps with and some apps without root).
One thing the old suhide had and the new suhide-lite version does not, is full binder interception. It could listen to and change most API calls and responses between apps and the Android system dynamically. While this may not sound like a big deal to some, from a malware-perspective this is almost a holy-grail class hack. suhide only used it to hide application packages (such as SuperSU) from apps selectively, so for example the launcher could still find it, but to some games it was completely invisible.
The binder interception code was the part that really interested me and the desire to get that working was the driving force behind the old suhide implementation. The security measures in Android's November 2016 security update blocked the old mechanism and with it the binder interceptor. Of course, I have actually written the code to bypass those (naive) protections in turn, but since that implementation of suhide was possible to detect in other ways, I kept that patch private. It may still prove useful in other projects, so it didn't make any sense to burn those work-arounds.
It may be possible to port the interceptor to the new mechanism, but it would be a lot of work and I don't think I'll be doing it any time soon, if ever. The lack of this intercepter is what makes the new suhide lite. The new suhide is able to hide packages such as SuperSU from other apps and games, but it does so via a toggle mechanism (3x alternating volup/voldown) that hides and unhides them, rather than handling the whole thing transparently.
Changelogs
2017.10.01 - v1.09
- Remove ODM and OEM mounts
- Setpropex: set multiple properties
- Cleanup: remove /boot
2017.08.15 - v1.08
- Fix a process freeze issue
- Fix framework restart survival (stop && start)
- Fix double free crash
2017.08.11 - v1.07
- Startup: Fix parallelism
2017.08.10 - v1.06
- Startup: Disable parallelism (temporary?), causes things to break sometimes
2017.08.10 - v1.05
- GUI: Synchronize changing items with the same UID
- GUI: Hide system apps (UID < 10000)
- GUI: Fix UID / package display line to ellipsize instead of wrap
- Properties: Adjust various build, adb, debug and security properties
- Startup: Improve performance by running operations in parallel
- ZIP: Allow flashing directly after SuperSU switch from image to SBIN mode, without reboot in between
2017.08.09 - v1.00
- Initial release of new code
- For old code, see https://forum.xda-developers.com/apps/supersu/suhide-t3450396
FIRST! new suhide yay. My 6p is currently running N 7.1.2. STOCK ANDROID, NO customisation whatsoever. Will 2.82 SR2 automatically update the root to sbin mode? If yes is the echo command still needed then?
Sent from my Nexus 6P with Tapatalk
Ch3vr0n said:
FIRST! new suhide yay. My 6p is currently running N 7.1.2. will 2.82 SR2 automatically update the root to sbin mode? If yes is the echo command still needed then?
Sent from my Nexus 6P with Tapatalk
Click to expand...
Click to collapse
Sbin mode is only activated by default on O (as per OP). Everything else requires the echo command.
Cool. I was avoiding using Magisk so far and was without root to be able to use certain apps like Netflix. I have a Pixel XL. Will SuperSU 2.82 SR2 alongwith suhide-lite work on my phone? Will I have to give the commands in TWRP as given in op? I intend to flash August security patch and try this during that update process. Currently I am stock (no root) with ElementalX kernel which I intend to continue using to be able to hide bootloader unlocked status.
Wow.. this works!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Shamusent
@Chainfire
hi,
maybe you can do something about this :crying:
i'm on nougat 7.1.2 (July security patch) been trying for long time to get this to work on citrix secure hub (by zenprise- formally known as worx)
attaching my logs and pics.
this is what i found from the logs attached:
Code:
"com.citrix.work.MAM.PolicyCheck:Found an APK requiring rooted device: eu.chainfire.supersu"
"com.citrix.work.MAM.PolicyCheck:BuildTag Test advisory ----- > is probably rooted"
SuperUser APKs Test advisory ---- > is probably rooted
the only one thing it didnt find:
Code:
D/"SecureHub"(16939): su In Path Test --- > is NOT rooted
i manged to pass safety net as you can see.
please if you can help.
Hi all and Chainfire. Thank you for this app! I tested it with a search if the Netflix app in the Playstore, but it wasn't found. I hided Playstore app in the list. Is there something I have overseen?
Otherwise I am also passing Safety Net. Thank you Chainfire!
rocky78 said:
@Chainfire
hi,
maybe you can do something about this :crying:
i'm on nougat 7.1.2 (July security patch) been trying for long time to get this to work on citrix secure hub (by zenprise- formally known as worx)
attaching my logs and pics.
this is what i found from the logs attached:
Code:
"com.citrix.work.MAM.PolicyCheck:Found an APK requiring rooted device: eu.chainfire.supersu"
"com.citrix.work.MAM.PolicyCheck:BuildTag Test advisory ----- > is probably rooted"
SuperUser APKs Test advisory ---- > is probably rooted
the only one thing it didnt find:
Code:
D/"SecureHub"(16939): su In Path Test --- > is NOT rooted
i manged to pass safety net as you can see.
please if you can help.
Click to expand...
Click to collapse
Does citrix secure hub run constantly in the background, or do you just need it now and then ?
Have you read the instructions in the About screen as stated ?
Have you tried hiding the SuperSU GUI ? (3x volup/voldown alternate) Because that is what it's detecting.
It's not detecting the su binary, I assume you already hid root from the hub ?
TR2N said:
Hi all and Chainfire. Thank you for this app! I tested it with a search if the Netflix app in the Playstore, but it wasn't found. I hided Playstore app in the list. Is there something I have overseen?
Otherwise I am also passing Safety Net. Thank you Chainfire!
Click to expand...
Click to collapse
Try clear Google Play Store and Google Play Services app data.
Netflix shows for me on a freshly installed device.
Chainfire said:
Does citrix secure hub run constantly in the background, or do you just need it now and then ?
Have you read the instructions in the About screen as stated ?
Have you tried hiding the SuperSU GUI ? (3x volup/voldown alternate) Because that is what it's detecting.
It's not detecting the su binary, I assume you already hid root from the hub ?
Click to expand...
Click to collapse
1. i can use it how ever i want (background or now and then). this is an email from my company.
2. yes. tried that.
3. yes i did. i attached a pic for you to see in the previous replay.
rocky78 said:
1. i can use it how ever i want (background or now and then). this is an email from my company.
2. yes. tried that.
3. yes i did. i attached a pic for you to see in the previous replay.
Click to expand...
Click to collapse
But is SuperSU still available from the app drawer? Did you actually press the volume button as instructed? The screenshot does not (can cannot) show that.
Chainfire said:
But is SuperSU still available from the app drawer? Did you actually press the volume button as instructed? The screenshot does not (can cannot) show that.
Click to expand...
Click to collapse
no.
When im pressing in the right order its hidden from app drawer. Also some other apps gets hidden.
p.s.
from the log i uploaded before it looks like "they" are running a search of supersu.apk in my device and mannage to find that.
is there a way to hide/stop that?
rocky78 said:
no.
When im pressing in the right order its hidden from app drawer. Also some other apps gets hidden.
p.s.
from the log i uploaded before it looks like "they" are running a search of supersu.apk in my device and mannage to find that.
is there a way to hide/stop that?
Click to expand...
Click to collapse
In that case I don't know what's going on. They shouldn't be able to iterate over APKs either. But it's all just guess work on my end at this point.
EDIT: actually I do know of a way they could still detect this even when hidden... but really the only way around that is to uninstall the SuperSU APK.
TR2N said:
... I tested it with a search if the Netflix app in the Playstore, but it wasn't found....
Click to expand...
Click to collapse
I think Safetynet is a server side check.Wait till tomorrow with su hided and check again.
Chainfire said:
In that case I don't know what's going on. They shouldn't be able to iterate over APKs either. But it's all just guess work on my end at this point.
EDIT: actually I do know of a way they could still detect this even when hidden... but really the only way around that is to uninstall the SuperSU APK.
Click to expand...
Click to collapse
do you mean if i clean flash my rom (custom) without root i will be able to use it?
And if so... Wft? No way! The hell with them.
rocky78 said:
do you mean if i clean flash my rom (custom) without root i will be able to use it?
And if so... Wft? No way! The hell with them.
Click to expand...
Click to collapse
No, just uninstall the SuperSU app from Android settings. Your apps will still have root access, you just wont have any way to manage it.
Chainfire said:
No, just uninstall the SuperSU app from Android settings. Your apps will still have root access, you just wont have any way to manage it.
Click to expand...
Click to collapse
look at this....
Do you see in the log-pic? After hiding from app drawer took a log file and suhide worked.
Only one more thing left to hide.
wtf is build tag? is it related to ro.build.tags in props?
rocky78 said:
look at this....
Do you see in the log-pic? After hiding from app drawer took a log file and suhide worked.
Only one more thing left to hide.
wtf is build tag? is it related to ro.build.tags in props?
Click to expand...
Click to collapse
Only citrix knows
Code:
getprop | grep build
may show some obvious problems.
UPDATE!NO MORE COMPLICATED SCRIPTS, JUST USE MAGISK 24.1 WITH DENY LIST!
1. Enable Zygisk, add the apps to the deny list
2. Hide Magisk App
3. Install SafetyNet Fix by kdrag0n (Might still need Magisk Hide Props if your device is a little older)
Working on: Poco X3 Pro + Lineage 18.1 (Android 11)
Aurora Store | F-Droid - Free and Open Source Android App Repository
A Google Playstore Client
f-droid.org
^Use aurora store to get the older version of Singapass that's likely to work, I'm using build 100.
V-Key Pte Ltd is basically a IT security technology based in Singapore I suppose.
Some softwares in Singapore, i.e. OCBC Banking, SingPass and maybe some other SEA banking softwares have v-key components which detects magisk.
This is a guide on how to use such softwares with Magisk, because I firmly believe that I get to choose what features I wish to have for my phone, and it is not fair for these banking companies to deny their services just because my device is rooted, I mean, if my banking stuff gets compromised because my phone is rooted and exploited, I'm willing to take the risk.
This guide aims to help mostly Singaporean users or anyone using such softwares with v-key components.
To make things work, the following things must be done:
1. Make sure Magisk manager is hidden
2. Make sure device fingerprint is certified by google (Check out the MagiskHide Props Config module) Please contribute fingerprints to this module for the benefit of everyone, checkout the GitHub page for more details.
3. Add the apps to Magisk Hide list.
4. Use package manager (pm) to disable the following v-key components in terminal (Using POSB Banking App as an example:
pm disable com.dbs.sg.posbmbanking/vkey.android.vos.MgService
pm disable com.dbs.sg.posbmbanking/com.vkey.android.support.permission.VGuardPermissionActivity
pm disable com.dbs.sg.posbmbanking/com.vkey.android.vguard.VGDialogActivity
pm disable com.dbs.sg.posbmbanking/com.vkey.android.internal.vguard.cache.ProcessHttpRequestIntentService
*Some apps may not have one or two v-key components listed above (i.e. SingPass), so getting an error on one or two components being not found should not be a big issue. If things works out you should see out puts on new states being disabled
*Attached a script that deals with OCBC, POSB and SingPass, if you have some weird errors make sure the encoding or format (Not sure of the jargon for it) is Unix or sth and not Windows
Credits:
Reddit User u/Inscythe for giving me a vague idea on the existence of v-key components
Muntashir Akon for his App Manager, allowed me to search for v-key components of apps(tried the disabling features of this app but didn't work, hence the script with pm command)
@Didgeridoohan for MagiskHide Props Config
@vurtomatic for giving me the idea of creating a guide on this.
Hi @Xanth0k1d , thanks for the guide.
I have a rooted LOS 18.1 (OnePlus 3), with magisk 22.1, magisk hide on and magisk manager hidden. All my bank apps work correctly excepts K-PLUS app, the retail bank app from Kasikorn Bank in Thailand.
I can see in the logs of magisk that some vkey components are linked to the app. I followed you guide and was able to disable 2/4 components you listed (2 didn't exist).
Unfortunately this didn't fix the issue.
Do you know how I can search in my phone if other vkey components exist that I might need to disable?
Thanks
Hey @Xanth0k1d, does this still work for you? I noticed that VGuard services are visible with App Manager for DBS but not Government apps. I could disable those services via ADB Root without the use of Magisk just fine.
Seems like GovTech has caught up to this trick :/
erOzeOz said:
Hi @Xanth0k1d , thanks for the guide.
I have a rooted LOS 18.1 (OnePlus 3), with magisk 22.1, magisk hide on and magisk manager hidden. All my bank apps work correctly excepts K-PLUS app, the retail bank app from Kasikorn Bank in Thailand.
I can see in the logs of magisk that some vkey components are linked to the app. I followed you guide and was able to disable 2/4 components you listed (2 didn't exist).
Unfortunately this didn't fix the issue.
Do you know how I can search in my phone if other vkey components exist that I might need to disable?
Thanks
Click to expand...
Click to collapse
Disabling the existing vkey components should be enough.
Did you spoof the device signature with the magisk hideprops module?
KrishvY said:
Hey @Xanth0k1d, does this still work for you? I noticed that VGuard services are visible with App Manager for DBS but not Government apps. I could disable those services via ADB Root without the use of Magisk just fine.
Seems like GovTech has caught up to this trick :/
Click to expand...
Click to collapse
All my apps are working fine, could you please be clear of your problem? i.e. what's working, what's not etc
Xanth0k1d said:
All my apps are working fine, could you please be clear of your problem? i.e. what's working, what's not etc
Click to expand...
Click to collapse
I'm using a OP6, LineageOS 17.1, latest nightly build. I can't use SingPass and Standard Chartered but I can use DBS just fine. I did not root my phone and I don't have Magisk installed either.
I just can't find V-key components in SingPass with App Manager.
KrishvY said:
I'm using a OP6, LineageOS 17.1, latest nightly build. I can't use SingPass and Standard Chartered but I can use DBS just fine. I did not root my phone and I don't have Magisk installed either.
I just can't find V-key components in SingPass with App Manager.
Click to expand...
Click to collapse
The App Mananger by Muntashir Akon?
I think I need to explain this properly, SIngapass and some apps may not work in the following situations:
You installed a custom rom without a Google approved device ID
You rooted your phone
You have Magisk
etc
For your case, Singpass does not work because you installed Lineage - a custom rom, which should not have a Google approved device prop by default. It doesn't matter if you are rooted or you have install Magisk at this point.
My suggestion to you is to install Magisk and follow my guide-hide magisk and spoof you device fingerprint so it looks like you are running a stock rom.
hi @Xanth0k1d. Have been using your method to hide singpass in the past. But the app just recently was able to detect root. As someone mentioned above, the updated app has no v-key components listed in the service. Any idea how to circumvent the situation and what services to disable?
Holy ****, I just saw the update.
Probably some dude saw this post...
I have yet updated so I can't test, if anyone's finding any solutions to this pls update as well.
Xanth0k1d said:
V-Key Pte Ltd is basically a IT security technology based in Singapore I suppose.
Some softwares in Singapore, i.e. OCBC Banking, SingPass and maybe some other SEA banking softwares have v-key components which detects magisk.
This is a guide on how to use such softwares with Magisk, because I firmly believe that I get to choose what features I wish to have for my phone, and it is not fair for these banking companies to deny their services just because my device is rooted, I mean, if my banking stuff gets compromised because my phone is rooted and exploited, I'm willing to take the risk.
This guide aims to help mostly Singaporean users or anyone using such softwares with v-key components.
To make things work, the following things must be done:
1. Make sure Magisk manager is hidden
2. Make sure device fingerprint is certified by google (Check out the MagiskHide Props Config module) Please contribute fingerprints to this module for the benefit of everyone, checkout the GitHub page for more details.
3. Add the apps to Magisk Hide list.
4. Use package manager (pm) to disable the following v-key components in terminal (Using POSB Banking App as an example:
pm disable com.dbs.sg.posbmbanking/vkey.android.vos.MgService
pm disable com.dbs.sg.posbmbanking/com.vkey.android.support.permission.VGuardPermissionActivity
pm disable com.dbs.sg.posbmbanking/com.vkey.android.vguard.VGDialogActivity
pm disable com.dbs.sg.posbmbanking/com.vkey.android.internal.vguard.cache.ProcessHttpRequestIntentService
*Some apps may not have one or two v-key components listed above (i.e. SingPass), so getting an error on one or two components being not found should not be a big issue. If things works out you should see out puts on new states being disabled
*Attached a script that deals with OCBC, POSB and SingPass, if you have some weird errors make sure the encoding or format (Not sure of the jargon for it) is Unix or sth and not Windows
Credits:
Reddit User u/Inscythe for giving me a vague idea on the existence of v-key components
Muntashir Akon for his App Manager, allowed me to search for v-key components of apps(tried the disabling features of this app but didn't work, hence the script with pm command)
@Didgeridoohan for MagiskHide Props Config
@vurtomatic for giving me the idea of creating a guide on this.
Click to expand...
Click to collapse
heya, I'm the reddit user... I had updated the app, but so far has no luck finding where the detection is hiding now... I might just try turning off services one-by-one with servicely, but I'll keep you all updated if I get any success.
@Xanth0k1d since you haven't updated your singpass, can you check what are the available services and listeners currently your version is using? I want to compare the difference with the latest version.
I managed to get Singapore's GPay app to work by blocking this `com.google.android.gms.gmscompliance.ui.UncertifiedDeviceActivity`. Do your devices pass SafetyNet?
The recent Singpass update requires disabling o.InvalidRegistrarException for root detection to be circumvented.
stevenkyk said:
The recent Singpass update requires disabling o.InvalidRegistrarException for root detection to be circumvented.
Click to expand...
Click to collapse
Thanks! Can confirm that this works!
Singpass is a really weird app.
Recently google nuke the api so magisk stopped working, can't pass the safetynet. Magisk released a canary release that fix that.
Yet, singpass continue to stop working so I thought maybe I need do more? Then I coincidently force stop the app to run it again, it magically working again! That is after I reboot twice before that. So now I learn the rebooting and force stop do different things.
I didn't apply anything from this thread, it is really a weird app.
Lu5ck said:
Singpass is a really weird app.
Recently google nuke the api so magisk stopped working, can't pass the safetynet. Magisk released a canary release that fix that.
Yet, singpass continue to stop working so I thought maybe I need do more? Then I coincidently force stop the app to run it again, it magically working again! That is after I reboot twice before that. So now I learn the rebooting and force stop do different things.
I didn't apply anything from this thread, it is really a weird app.
Click to expand...
Click to collapse
The safetynet api did not get nuked, the api changed so code that use the old api won't work, even on the latest stable build safetynet will still pass when using another checker app. While I won't go into the technical details, singpass spawns a new isolated process to check for root, exploiting the fact that isolated processes are treated differently and is difficult for magisk to hide itself. So the solution is to disable the offending process and not let it spawn. There are several other requirements necessary for singpass to run, which are largely beyond the scope of discussion in this thread.
Any idea how to bypass Citibank sg root detection? I am able to use vkey method for posb and ocbc but Citibank doesn't have a vkey service
auggie246 said:
Any idea how to bypass Citibank sg root detection? I am able to use vkey method for posb and ocbc but Citibank doesn't have a vkey service
Click to expand...
Click to collapse
The trick here is to decompile the APK using apktool and inspect the Androidmanifest.xml manually. Search for "ISOLATED" and in the same line you should be able to find the name of the service to be disabled. Of course this assumes that citibank's app used a similar tactic as the other apps.
Edit: I tried the citibank sg app, magisk hide + rename package is sufficient for me to launch the app, don't have an account so I can't test any further.
stevenkyk said:
The recent Singpass update requires disabling o.InvalidRegistrarException for root detection to be circumvented.
Click to expand...
Click to collapse
I guess there's another update to Singpass that circumvent this circumvention as well lol
Apparently it's now using a service called o.ImmutableSetMultimap for checking root (confirmed by magiskhide entry) and it works for a few seconds after loading Singpass before failing again with different error message. I think it checks for both whether the service is active and found a root (gives error T0), or whether the service is running at all (gives error T-1). I think we need something else to block this.
One word ahead: I am a huge fan of Custom Rom (LOS). Nevertheless some feature will be missed (volte) and performance might be not perfect (camera, dolby) due to proprietary firmware.
On the other hand I like to keep away from data collecting companies as google.
Isn't than a rooted and debloated stock image with microG instead of Gapps the best possible option? I did this once for an older Samsung and results was fine. But there is one thing I don't know: How it will act on updates. I don't want to miss security updates.
Any ideas? Or is it a bad idea at all? Curious to your feedback
I will extend this posts. Not only writing a step by step howto, but also explain the ideas behind. Maybe also some steps aside, mistakes I did.
So for the first steps look https://forum.xda-developers.com/t/...est-performance-privacy.4240057/post-84573619
EDIT Mai 1st 2021:
I get for some time a second phone and did some experiments. From what I see new - there is no real need to go the long, long way to root it. Even on a stock RAM you get get back control over your data!
The gapps are less important than I ever thought. If you get curious, just switch over here to get more information:
https://forum.xda-developers.com/t/...est-performance-privacy.4240057/post-84909643
(To avoid misunderstandings: I will not provide a ROM. There are some steps to go with existing stock ROM - as only this gives you full features.)
Isn't than a rooted and debloated stock image with microG instead of Gapps the best possible option?
Click to expand...
Click to collapse
I will assume you are comparing it with the latest LOS available.
Privacy-wise? Not really. Even if you remove GApps from the stock rom, Samsung will still collect data. You can limit that by:
1. Not using Samsung Account/Pay/Pass (as on why, read privacy policy)
2. Removing "com.hiya.star", which collects your location, tho it will break the "Places" feature in the Phone app.
3. Replacing Samsung Keyboard with an open-source alternative or disabling the autocorrect feature as it sends corrected texts to Samsung.
4. Not using Samsung Weather app/widget (as on why, read privacy policy)
After that and using some F-Droid apps I would say you have a pretty decent privacy.
Performace-wise? Absolutely. The battery life is a lot better compared to AOSP ROMs and thats not even taking into account that OneUI has the Ultra Power Saving Mode. The camera is miles ahead too and of course, VoLTE actually works.
How it will act on updates. I don't want to miss security updates.
Click to expand...
Click to collapse
I have tested that. If its just a security update, then it will install flawlessly. If its a feature update, some bloatware and Gapps may reinstall. I haven't experienced any update failing, but that may change in the future.
Any ideas? Or is it a bad idea at all? Curious to your feedback
Click to expand...
Click to collapse
If you really care about privacy, but dont want to miss out on features, then go ahead with debloating and degoogling the stock rom. Just note that some problems with compatibility and some rare random crashes may occur.
Retrecd said:
...
1. Not using Samsung Account/Pay/Pass (as on why, read privacy policy)
2. Removing "com.hiya.star", which collects your location, tho it will break the "Places" feature in the Phone app.
3. Replacing Samsung Keyboard with an open-source alternative or disabling the autocorrect feature as it sends corrected texts to Samsung.
4. Not using Samsung Weather app/widget (as on why, read privacy policy)
After that and using some F-Droid apps I would say you have a pretty decent privacy.
Click to expand...
Click to collapse
Sure, that was the ideas to remove as much of Google/Samsung stuff as possible and also use AFWall to limit data transfer. I am using FDroid already, there are good tools, respecting privacy.
So you went already same approach? There is already a thread about debloating, but I think what I want to do is even behind that. If you like, you can share more details. I would like create some kind of a howto ...
starbright_ said:
Sure, that was the ideas to remove as much of Google/Samsung stuff as possible and also use AFWall to limit data transfer. I am using FDroid already, there are good tools, respecting privacy.
So you went already same approach? There is already a thread about debloating, but I think what I want to do is even behind that. If you like, you can share more details. I would like create some kind of a howto ...
Click to expand...
Click to collapse
Here is an article on using ADB to remove bloatware: https://www.xda-developers.com/uninstall-carrier-oem-bloatware-without-root-access/
Now here is a list of bloatware on the S10, remove it the way showcased in the article: https://forum.xda-developers.com/t/galaxy-s10-s10-debloat-bloatware-removal-list.3912073/
The list is a bit older, but most of the bloatware is still present in the latest version.
The same way you removed the bloatware, you remove the Gapps. Remove the following core Google packages:
Code:
com.google.android.gsf
com.android.vending
com.google.android.gms
If you want to remove more packages that aren't listen in the article install the "App Inspector" from Google Play or any APK site and find out the names of the packages.
Please read and share your ideas. I am sure that we only together can create the best possible solution. Maybe you know othere ways/apps to solve a problem. As of now I share my point of view.
My hope is, that at the end of this to have an "howto" covering as many aspects as required for this.
First thing nevertheless is install TWRP/Magisk, which seems to be more tricky than usual.
While you can debloat your ROM without root, there are imho 3 reasons for doing that:
microG needs be installed as a system-app to have working location service (get your location by GPS or by offline database)
you will have problems to install a firewall and adblocker. There are solution with don't need root (Netguard and Blockada), but both base on a "virtual" VPN connection and you can have only one at a time. So you do have either a Firewall or an AdBlocker, but not both.
The way of create and restore backups are much better with root. I can recommend TWRP itself for a general backup and migrate for apps/settings.
For those like me, coming from unrooted stock fw the recommendation is to
root with Magisk - details here
flash the TWRP - details here
spoofing the signature for usage of microG instead of playservices
install microG and "friends"
debloat stock ROM
migrate data from old to new device
starbright_ said:
First thing nevertheless is install TWRP/Magisk, which seems to be more tricky than usual.
Click to expand...
Click to collapse
Tricky indeed and even more tricky is installing updates. Once you know the procedure it's ok, but it is still a major hassle compared to a stock OTA update.
here
jelbo said:
Tricky indeed and even more tricky is installing updates. Once you know the procedure it's ok, but it is still a major hassle compared to a stock OTA update.
Click to expand...
Click to collapse
Sure, I am aware of that. I just read about it. But there is no other way except you are happy with stock. First time is always a nightmare, but I hope once get used to it.
Retrecd said:
Here is an article on using ADB to remove bloatware: https://www.xda-developers.com/uninstall-carrier-oem-bloatware-without-root-access/
Now here is a list of bloatware on the S10, remove it the way showcased in the article: https://forum.xda-developers.com/t/galaxy-s10-s10-debloat-bloatware-removal-list.3912073/
The list is a bit older, but most of the bloatware is still present in the latest version.
The same way you removed the bloatware, you remove the Gapps. Remove the following core Google packages:
Code:
com.google.android.gsf
com.android.vending
com.google.android.gms
If you want to remove more packages that aren't listen in the article install the "App Inspector" from Google Play or any APK site and find out the names of the packages.
Click to expand...
Click to collapse
How did you managed that switch from Gapps to microG? I assume if you delete Gapps without MicroG installed you will get lot of problems.
How did you manage to spoof Stock Rom? Are you on 11?
Hi all. Very interesting conversation. Has someone successfully used microG on stock rom on a daily usage? In my past experience, using microG without signature spoofing is making a lot of apps not working properly...
lp35 said:
Hi all. Very interesting conversation. Has someone successfully used microG on stock rom on a daily usage? In my past experience, using microG without signature spoofing is making a lot of apps not working properly...
Click to expand...
Click to collapse
I think spoofing is a must have. I just evaluate how this can be done.
With Android 11 it is more difficult. I found that one (but not sure whether signature spoofing works):
https://forum.xda-developers.com/t/module-smali-patcher-7-3.3680053
this one:
https://forum.xda-developers.com/t/signature-spoofing-on-unsuported-android-11-r-roms.4214143/
or via NanoDroidPatcher
https://forum.xda-developers.com/t/...7-microg-pseudo-debloat-f-droid-apps.3584928/
It says:
11.0 / SDK 30 (R)
Patcher does not work from TWRP
Patcher works from Magisk if your ROM's services.jar already contains classes.dex
I checked that and /service/framework/service.jar contains that classes.dex
So I give this a try, downloaded the patcher and started it out of Magisk. Log looks ok so far. It requires reboot.
The problem with enabling Magisk is - you have to boot with "recovery" mode - and not sure, it fails several time (although USB is plugged) or phone reboots again and than Magisk is disabled - while booting into TWRP still works.
So my guess is: This causes some problem.
Step 3) - Spoofing
Have been successful:
I followed that thread:
Signature Spoofing on unsuported Android 11 (R) Roms
How to get Signature Spoofing working on Android 11 (R) Roms that have no support for Signature Spoofing? In my Case here I use a Samsung Galaxy S8 with an unofficial LineageOS 18.1 (Android 11) by stricted I use TWRP recovery but this should...
forum.xda-developers.com
But I just created a spoof_AVDapi30.zip. My thinking just flashing that one for spoofing seems to be wrong. Also flashing both: spoof and microG_AVD....
So what I did was flashing out of Magsik (Module install out of memory) NanoDroid-microG-23.1.2.20210117.zip and followed by spoof_AVDapi30.zip.
Power off. And take care you boot with Power + Vol+ + Bixby + USB Cable pressed until you see the splash-screen.
I really hope stock + MicroG takes off!
It is already. I started debloating - that is another step. See this thread:
Debloating S10e
I am still in testing phase and I would like to see once an FW-update via OTA will happen. Curious what will happen with my system.
starbright_ said:
It is already. I started debloating - that is another step. See this thread:
Debloating S10e
I am still in testing phase and I would like to see once an FW-update via OTA will happen. Curious what will happen with my system.
Click to expand...
Click to collapse
Amazing! Keep us posted!
Debloating is done.
Final step is takeover of my previous installation. I do that with the tool/app migrate. That works rather fine.
I am not using the special sections to export contacts, SMS ...
Contacts will be exported from the app itself and than imported in new device.
Is this dead? Hehe
No it is working. Have you tried that?
I couldn't deinstall com.samsung.android.kgclient and blocking its UID (with awfall) causes some battery drain. Maybe I have to live with not blocking this.
Anyhow, I am wondering whether debloating is required at all. Cutting the connection to Ethernet (to not talk "home") might be enough.
I don't not have enough understanding of what will be better: remove or just block.
A removed app might not spend time on connecting servers again and again, while a missed service can cause trouble if you don't expect that.
Probably it is best to uninstall apps you are really sure there are no dependencies to others and block the others-
starbright_ said:
Step 3) - Spoofing
Have been successful:
I followed that thread:
Signature Spoofing on unsuported Android 11 (R) Roms
How to get Signature Spoofing working on Android 11 (R) Roms that have no support for Signature Spoofing? In my Case here I use a Samsung Galaxy S8 with an unofficial LineageOS 18.1 (Android 11) by stricted I use TWRP recovery but this should...
forum.xda-developers.com
But I just created a spoof_AVDapi30.zip. My thinking just flashing that one for spoofing seems to be wrong. Also flashing both: spoof and microG_AVD....
So what I did was flashing out of Magsik (Module install out of memory) NanoDroid-microG-23.1.2.20210117.zip and followed by spoof_AVDapi30.zip.
Power off. And take care you boot with Power + Vol+ + Bixby + USB Cable pressed until you see the splash-screen.
Click to expand...
Click to collapse
So just install those inside of magisk and reboot? I'll give it a shot.
Dead thread, I see.
steventorres said:
Dead thread, I see.
Click to expand...
Click to collapse
What are you continuously posting about dead thread? Any question or any feedback? Strange. It is is all set and done. What do you expect?
@VenfefulRat:
This wasn't a real question, right. It was stated to do it out of magsik. It would be great to have some feedback.
@All: A forum lives from reading (to gain knowlegde ) and posting (sharing experience, ask questions, give feedback). If someone ask and he gets answer I would expect a feedback or at least a like (as a sign it has been read). Otherwise people stop posting and the only left here are those who ask or feed the troll.
This is the spot for the General Support Discussion of Magisk Alpha "Public Released" fork created by @vvb2060.
Disclaimer: This Magisk Alpha fork is not supported by @topjohnwu and is not an official channel for him. Use at your own risk.
Important : This Magisk Alpha thread was created to share information about Magisk Alpha Public Releases with XDA members that do not use telegram.
If Magisk Alpha doesn't work for you try one of the other versions of Magisk (See Useful links below).
How to install Magisk Alpha?
Magisk Alpha is installed and uninstalled through the Magisk application (App). Generally, it should be done directly in the application. In special cases such as the first installation, the image should be patched and then flashed using the fastboot/odin tool. By customizing Recovery is not a supported way.
Detailed Instructions for the first installation of Magisk Alpha on Google™ Pixel™ phones.
Note: These Instructions may not apply to all Google™ Pixel™ Phones.
If you have another version of Magisk (Beta/Stable [Forks - Cygisk/Delta] Stable) installed:
Open the Magisk Manager app and disable/remove all Magisk modules. If you hid the Magisk manager app the default name for the hidden Magisk app is settings.
If you gave it a different name and you've forgotten the name. Use TB checker to find the name of the hidden Magisk Manager. You can also use TB Checker to check if you have more than one Magisk Manager app installed.
Uninstall Magisk
Extract boot/init_boot.img from Factory Image
Download the latest Factory image to your phone.
Extract the Factory Image file (aaaaaaa-a9a9a.999999.999-factory-99a9a99a.zip) to a folder.
Open the folder you extracted the Factory image to and, extract the Image file (image-aaaaaaa-aa9a.999999.999.zip) into the folder. The, stock, boot/init_boot.img file will be in this folder.
Patch the boot/init_boot.img.
Download Magisk Alpha (app-release.apk)
Install the Magisk Alpha App
Open Magisk Alpha App
Tap Install (next to Magisk)
Tap, Select and Patch a File
Navigate to the folder that you extracted the Stock boot/init_boot.img to and select it.
Tap the ✓ (Check Mark)
Tap Let's Go
When you see done, the boot/init_boot.img has been patched (magisk_patched_xxxxxx.img), and stored in the download folder.
Reboot
Move the patched boot/init_boot.img file to your computer's Platform-tools folder or the folder that has fastboot.exe in it:
Copy it to a USB drive and transfer it to your computer.
Move it to your computer using adb push
Boot fastboot mode
Connect the phone to the Computer with USB cord.
Open a Command Prompt in the folder you copied the patched boot.img to.
Type fastboot flash boot --slot all "name of patched boot".img or fastboot flash init_boot --slot all "name of patched boot".img without the quotation marks at the Prompt and press enter.
When it finishes installing the patched boot.img or init_boot.img, type fastboot reboot at the Prompt and press enter.
Important Notes:If your phone boot loops try one of the following options:
Flash the 'stock' boot/init_boot.img to both slots: fastboot flash boot/init_boot --slot all boot/init_boot.img
Boot Safe Mode - Keep Pressing the Power Off button until you see boot Safe Mode ==> Press Ok.
"...make a 100% clean install of ANY Magisk version or fork without PC or TWRP."
Magisk General Support / Discussion
This is the place for general support and discussion regarding "Public Releases", which includes both stable and beta releases. All information, including troubleshoot guides and notes, are in the Announcement Thread
forum.xda-developers.com
Useful Links
Androidacy Module Manager
Androidacy Module Manager - Releases
Androidacy Download Center
Magisk Alpha 26101 - 12 Apr (Pubic release)
https://github.com/vvb2060/magisk_files/find/alpha/
Tap app-release.apk
Tap the 3 dot menu across from 10.9 MB
Tap Download
Magisk Beta 26.1 - 11 Apr
Magisk Canary 26103 - 23 Jun
https://github.com/topjohnwu/magisk-files/blob/5b2934603f979d7133e67bbc30c6ce3fa0d8e31e/notes.md/
Tap the 3 dot menu across from 5b2934603f
Tap Go to file
Tap app-release.apk
Tap the 3 dot menu across from 10.9 MB
Tap Download
Magisk Cygisk - Click Pages 5 for installation Instructions.
Magisk Delta
Magisk Stable 26.1 - 11 Apr
Magisk Documentation
Fox's Magisk Module Manager
Fox's Magisk Module Manager - Releases
LSPosed Framework
LSPosed - Releases
LSPosed - Shamiko Releases
kdrag0n Safetynet Fix -Releases
If Kdrag0n Safety Net Fix doesn't work for you try Displax's SafetyNet Fix, a "fork" of kdrag0n safetynet-fix.
alpha changelog
Magisk (98874be1-alpha)
- [App] Delete backup file after restoring boot image
- [App] Built-in current version update log
- [General] no longer automatically unlock device blocks
- [App] Compatible with Android 12L
- [App] Added crash statistics
- [App] Allow loading zygisk modules
- [General] Signature Verification
- [MagiskInit] Fix Android 8.0-9 not installed after booting
How to install?
Magisk is installed and uninstalled through the Magisk application. Generally, it should be done directly in the application. In special cases such as the first installation, the image should be patched and then flashed using the fastboot/odin tool. By customizing Recovery is not a supported way.
Upstream changelog
Magisk (704f9154) (24305)
- [App] [MagiskSU] Properly support apps using shared UID
- [Zygisk] Fix function hooking on devices running Android 12 with old kernels
- [BusyBox] Add workaround for devices running old kernels
Diffs to v24.3
- [MagiskInit] Update 2SI implementation, significantly increase device compatibility (e.g. Sony Xperia devices)
- [MagiskInit] Introduce new `sepolicy` injection mechanism
- [App] [MagiskSU] Properly support apps using shared UID
- [Zygisk] Fix function hooking on devices running Android 12 with old kernels
- [BusyBox] Add workaround for devices running old kernels
The author of Magisk Alpha is extremely untrustworthy. It is highly recommended to use the official version.
imma add my 5 cents worth, fwiw
magisk alpha was a good and useful fork (along with custom) after TopJohnWu announced he was removing magiskhide in line with his job at Google and people lost their collective shizz, even though common sense should have told them this was needed and sane. Many of us appreciated the hard work of the alpha and custom devs, but at some point, as announced again by TJW, other hiding methods would come to fruition. And they have. Not to in anyway to devalue the contribution of alpha and custom devs, but there was always goign to be a point where mainstream magisk/magisk canary was going consolidate the attention and focus of the userbase and senior members here long into magisk, again. i for one dont miss testing/switching between 4 different forks anymore. magisk alpha was my chosen fork for a long time
Magisk Alpha is fine to use as long as you understand its shoehorning in things removed from the mainstream magisk, and that was certainly appreciated at times, but those could cease to work, introduce issues not present in mainstream magisk leading to people expecting support from the main magisk threads where it would make life harder for those trying to answer questions. so temper your expectations those of you who choose to use.
For my 5 cents, id recommend using mainstream magisk, unless you have an edge case where it doesnt work, at which point ordinarily, one would file on issue on github
As for the alpha devs personality, ill admit, it could be variable at times
73sydney said:
As for the alpha devs personality, ill admit, it could be variable at times
Click to expand...
Click to collapse
Like the weather? ... But I like you fine too mate... Like the weather...
The real question re. personality here is 'Are you a maverick?'... If not, stick to official Magisk... PW
Homeboy76 said:
This thread is for Magisk alpha users: Support
Hopefully, @pndwal and others with much more knowledge of Magisk alpha ,than I, will share their knowledge with us.
Click to expand...
Click to collapse
Prolly don't qualify then; not a user! PW
mlgmxyysd said:
The author of Magisk Alpha is extremely untrustworthy. It is highly recommended to use the official version.
Click to expand...
Click to collapse
To be very honest: I hate this childish behavior of developers bashing developers.
I love both your work and the work of the LSposed developers and I have donated to both of you. Just because developers could document / announce better there's no need to move against each other.
The reason why I use Alpha is exactly, because of the removal of MagiskHide and John's involvement with Google. imho that's just gonna hurt Magisk in the end.
And your words also mean basically stay away of Shamiko. That's not gonna happen. Unfortunately Google went down that rabbithole against rooting, etc., which is why I'm still very unsure whether I even keep rooting my phones from now on...
dr4go said:
And your words also mean basically stay away of Shamiko
Click to expand...
Click to collapse
You missed the point that alpha is a personal fork, Shamiko is a team of dev work (LSPosed team), alpha's author is one of them, don't scramble between them.
pndwal said:
Prolly don't qualify then; not a user! PW
Click to expand...
Click to collapse
Any help with Magisk alpha is greatly appreciated.
For all intents and purposes, once you enable zygisk thereby removing Magisk Hide functionality, the Alpha fork is the same as the official build.
But with one key difference.
The app and package name are different, so no need to hide it. Or for that matter remember to unhide it before an update "just in case"
This is why I use it.
dr4go said:
To be very honest: I hate this childish behavior of developers bashing developers.
I love both your work and the work of the LSposed developers and I have donated to both of you. Just because developers could document / announce better there's no need to move against each other.
Click to expand...
Click to collapse
dr4go said:
The reason why I use Alpha is exactly, because of the removal of MagiskHide and John's involvement with Google. imho that's just gonna hurt Magisk in the end.
Click to expand...
Click to collapse
Disagree. However, isn't MagiskHide gone from alpha now?
dr4go said:
And your words also mean basically stay away of Shamiko. That's not gonna happen. Unfortunately Google went down that rabbithole against rooting, etc.,
Click to expand...
Click to collapse
When? What? Where?... Think you're a bit confused... But you wouldn't be the first.
dr4go said:
which is why I'm still very unsure whether I even keep rooting my phones from now on...
Click to expand...
Click to collapse
Of course you can!... Who's going to stop you?... Unless you buy late Huawei! PW
Stillhard said:
You missed the point that alpha is a personal fork, Shamiko is a team of dev work (LSPosed team), alpha's author is one of them, don't scramble between them.
Click to expand...
Click to collapse
I never intended to - sorry if that was suggested. I just meant: if one of the developers of Shamiko isn't trusted and it's closed source, would you use it?
pndwal said:
Disagree. However, isn't MagiskHide gone from alpha now?
Click to expand...
Click to collapse
Yes it is. There is still a fork around that uses it, but not Alpha.
pndwal said:
When? What? Where?... Think you're a bit confused... But you wouldn't be the first.
Click to expand...
Click to collapse
See previous post. I am definitely confused, but not regarding that.
pndwal said:
Of course you can!... Who's going to stop you?... Unless you buy late Huawei! PW
Click to expand...
Click to collapse
Google. Once HW backed SafetyNet is enforced there is no way around it. But let's not get offtopic here and keep talking about Alpha if the thread was created for it...
pndwal said:
Mate, I can read and did not disagree... I said "Quite."... as in "I agree... enough is enough... Fine!" ...
You seem to be lifting my remark right out of context, So Please read my edit carefully, (you are the OP) and what I was addressing; it won't change;
You said:
I said:
and that until then I'd prefer to post non-Alpha Magisk information in existing TJW General Support / Discussion thread... If I'm just not interested in taking it to "PM" or "Conversations", what's the problem?
... and I edited the earlier post so as not to further congest this thread...
...three more posts wasted. PW
Click to expand...
Click to collapse
I have now created a cat-and-mouse-game discussion thread:
https://forum.xda-developers.com/t/...ng-and-mod-hiding-cat-and-mouse-game.4425939/
HippoMan said:
I have now created a cat-and-mouse-game discussion thread:
https://forum.xda-developers.com/t/...ng-and-mod-hiding-cat-and-mouse-game.4425939/
Click to expand...
Click to collapse
Thank you!
PSA:
I recently asked here if anyone had been been surprised by unusual actions in the April 1 release of Magisk Alpha (changelog posted in OP post #2 here) being referred to in the TG Alpha Magisk discussion group as the 'April fools limited edition'.
This was in view of these official notices accompanying the build in the separate 'Magisk alpha' update thread (Chinese translated):
Warning to developers: In libsu v4.0.0 and later, Shell.rootAccess() has a behavior change that returns true even if the user refuses to grant root privileges.
Click to expand...
Click to collapse
and
Warning to developers: Magisk 24302 and later, the magiskpolicy tool may not exist or be inconsistent with the Magisk version.
Click to expand...
Click to collapse
My query has been inexplicably deleted from this s thread!
However, those 'Warning' messages are still up, so, as nobody has responded here (not surprisingly), I have just installed this Alpha build and tested it on a secondary device.
I can confirm that, despite some claims of in-app messages stating that root has been granted to apps despite users denying access, I could not produce / have not seen such worrying behaviour...
So it appears that the Dev's "Warning to developers" notices themselves are the only 'April fools' joke.
Of course there is also NO substance to the assertions either that John's libsu root app solution has or is responsible for such behaviour, or that there are inconsistencies with the magiskpolicy tool (or consequently with SELinux policies) post 24302.
This may allay concerns if anyone translates / reads those 'warnings' in Magisk alpha TG.
Regarding the removal of my initial post regarding this and my posts in general, I accept and understand that some have been off topic, and have said that I agree to stay on topic several times (responses now removed). The OP here has however misconstrued my intentions. For whatever reasons, alpha related posts put up in good faith are now being removed without communication. This saddens me...
I hope this thread can become useful for Alpha users / enquiriors... PW
pndwal said:
PSA:
I recently asked here if anyone had been been surprised by unusual actions in the April 1 release of Magisk Alpha (changelog posted in OP post #2 here) being referred to in the TG Alpha Magisk discussion group as the 'April fools limited edition'.
This was in view of these official notices accompanying the build in the separate 'Magisk alpha' update thread (Chinese translated):
and
My query has been inexplicably deleted from this s thread!
However, those 'Warning' messages are still up, so, as nobody has responded here (not surprisingly), I have just installed this Alpha build and tested it on a secondary device.
I can confirm that, despite some claims of in-app messages stating that root has been granted to apps despite users denying access, I could not produce / have not seen such worrying behaviour...
So it appears that the Dev's "Warning to developers" notices themselves are the only 'April fools' joke.
Of course there is also NO substance to the assertions either that John's libsu root app solution has or is responsible for such behaviour, or that there are inconsistencies with the magiskpolicy tool (or consequently with SELinux policies) post 24302.
This may allay concerns if anyone translates / reads those 'warnings' in Magisk alpha TG.
Regarding the removal of my initial post regarding this and my posts in general, I accept and understand that some have been off topic, and have said that I agree to stay on topic several times (responses now removed). The OP here has however misconstrued my intentions. For whatever reasons, alpha related posts put up in good faith are now being removed without communication. This saddens me...
I hope this thread can become useful for Alpha users / enquiriors... PW
Click to expand...
Click to collapse
I saw that on Alpha TG and I was worried about, although I don't use Alpha, since they mentioned libsu
I don't really know if roots grants from the Magisk app go through libsu, but I tested with the latest Canary 24305 and everything was ok:
- I revoked the root grant to the Reboot app (by Petrus).
With the app you can easily reboot, reboot to Recovery or Fastboot.
Obviously, the app requires root grant to work
- I opened Reboot app and chose to reboot, and I was immediately popped-up to grant the root
- I denied to grant the root and I choose again to reboot, but it didn't reboot (correct behavior, without the root grant Reboot app cannot execute reboot)
- Again through Magisk app, Superuser tab, this time I granted the root and then Reboot app worked to reboot
In parallel I was checking in magisk.db, Policies, and everything looked ok (you can see by UID and policy values if the root grant is given/revoked to the particular app)
zgfg said:
I saw that on Alpha TG and I was worried about, although I don't use Alpha, since they mentioned libsu
I don't really know if roots grants through the Magisk app go by libsu,
Click to expand...
Click to collapse
Yup, since Jan 2018, Magisk Manager / App "uses `libsu` for all root related operations".
zgfg said:
but I tested with the latest Canary 24305 and everything was ok:
- I revoked the root grant to the Reboot app (by Petrus).
With the app you can easily reboot, reboot to Recovery or Fastboot.
Obviously, the app requires root grant to work
- I opened Reboot app and chose to reboot, and I was immediately popped-out to grant the root
- I denied to grant the root and I choose again to reboot, but it didn't reboot (correct behavior, without the root grant Reboot app cannot execute reboot)
- Again through Magisk app, Superuser tab, this time I granted the root and then Reboot app worked to reboot
In parallel I was checking in magisk.db, Policies, and everything looked ok (you can see by UID and policy values if the root grant is given/revoked to the particular app)
Click to expand...
Click to collapse
Did similar test on Alpha; just wanted to see if it somehow claimed root granted when denied...
I wasn't worried about TJW Magisk as I was certain libsu & magiskpolicy 'warnings' were an 'April fools' hoax, but I wouldn't have put it past Devs to also implement false indicators... (Appears that if done at all, this must have expired after April 1 ?) I didn't find any...
Have to wonder how John views this hoax, especially since, surprisingly, there's been no retraction...
Thanks for confirming.
Nb. As I speak speak, TG Alpha discussion group name is being changed between names w/ sexual overtones by admin Canyie... Kids!
PW
As per Nb. above, Canyie's original "Alpha 讨论组" (Alpha discussion group)" is currently simply named 西大师 奶子... !?
No real idea why; Joking around? Trying to disguise Alpha discussion group? Deter 'foreigners'?
Members there are also asking questions... PW
... now it's 西大师 live! ... PW