In doing my taxes, I noticed that the H&R Block app tries to execute su (which I promptly deny) and then nags about my device being compromised (app still works anyways.) It's obviously not, but it got me thinking: Since we're operating in the kernel now, I figure that we should be able to prevent apps from seeing the su binary at all unless we as the device owners explicitly want the app to be able to see it. Maybe even do something like allow creation of an app whitelist and/or blacklist.
If it's tricky to pull off, make it a pro feature (I paid for pro.)
I imagine this would fix Android pay as well (though I don't use it so I don't care) but it might be a motivating reason for others to want such a feature.
Other benefits to this include enhanced security against questionable apps that might, for example, try to take advantage of possible zero day in SuperSU itself.
I could be wrong, but isn't systemless SuperSU installed to ramdisk?
Also since the mount points are still on top of /system (without actually modifying system), doesn't that mean it would be visible anyway?
Sent from my Nexus 6 using Tapatalk
Not if you only exposed the mount point to specific users, and only set the $PATH variable to specific users (which is another possible way to detect root.)
There are a lot of things that can be done, that can be done in theory, that can be done if somebody puts the work in, etc.
Outside of just a time investment, these things are very complicated to do and have them work on a large number of devices.
That's not even considering the legal repercussions.
There are a lot of apps that check for just the existence of 'su' and then you're done. Or if an installed app has a name like 'supersu'.
One that's been a constant thorn in my side has been 'Good for Enterprise'. Only way I've seen where a rooted phone worked past root detection was when it was a Cyanogenmod type that had a custom root (non supersu) built into the development settings and you installed/ran the app with those root settings off.
So agreed with Chainfire that all apps check for root differently.
Use "rootcloak" or simply disable supersu if you are system-less. The only caveat with using rootcloak is that it requires xposed and it is dreadful at hiding xposed meaning any security app looking for xposed will more than likely find it
Related
From this day onwards, apps that Change state of SELinux are forbidden on Google Play Store. Those, who have such apps, have 14 days to fix violations or their apps will be removed.
Here's example of message from google:
This is a notification that your application, SELinux Mode Changer, with package ID com.mrbimc.selinux, is currently in violation of our developer terms.
…
REASON FOR WARNING: Violation of the dangerous products provision of the Content Policy:
“Don’t transmit or link to… items that may introduce security vulnerabilities to or harm user devices, apps, or personal data.”
After a regular review, we have determined that your app lowers a user’s device security by modifying or disabling SELinux on the device. To ensure a safe user experience for Play users, we have determined that apps with this functionality are noncompliant.
Please remove this functionality from your app within 14 days to achieve policy compliance. Once approved, your application will again be available with all installs, ratings and reviews intact.
This notification also serves as notice for other apps in your catalog. You can avoid further administrative action by immediately ensuring that no other apps in your catalog are in violation of (but not limited to) the above policy. Please also ensure your apps’ compliance with the Developer Distribution Agreement and Content Policy.
All violations are tracked. Additional suspensions of any nature may result in the termination of your developer account, and investigation and possible termination of related Google accounts. If your account is terminated, payments will cease and Google may recover the proceeds of any past sales and/or the cost of any associated fees (such as chargebacks and transaction fees) from you.
If you feel we have made this determination in error -or feel that this functionality has been misinterpreted, please submit an appeal to the Google Play policy team through this Google Play Help Center article.
The Google Play Team
New definition of "dangerous product
Google play content policy
Google play distribution agreement
What are we going to do?
I can confirm this issue as I also received this message by Google-Play some hours ago.
My app is using "setenforce 0" to allow the "mediaserver"-process loading an .SO-file from the /data-partition.
The loaded .SO-file is then using some C-commands to modify the internal audio-routings of the device.
As hereby the "mediaserver"-process is executing the by SELinux blocked commands and not the initial commands executed via "su", the modification by SuperSU doesn't take affect here ("SU-commands are always permissive").
What's the workaround? Modifying/scrambling the "setenforce 0" to not get scanned by Google's bots?
funtax said:
I can confirm this issue as I also received this message by Google-Play some hours ago.
My app is using "setenforce 0" to allow the "mediaserver"-process loading an .SO-file from the /data-partition.
The loaded .SO-file is then using some C-commands to modify the internal audio-routings of the device.
As hereby the "mediaserver"-process is executing the by SELinux blocked commands and not the initial commands executed via "su", the modification by SuperSU doesn't take affect here ("SU-commands are always permissive").
What's the workaround? Modifying/scrambling the "setenforce 0" to not get scanned by Google's bots?
Click to expand...
Click to collapse
Same here. Got 4 emails from Google for same violation. Not exactly if I can bypass this problem by using superSU properly.
jerryfan2000 said:
Same here. Got 4 emails from Google for same violation. Not exactly if I can bypass this problem by using superSU properly.
Click to expand...
Click to collapse
Might I ask you which apps and features are affected?
PhinxApps said:
Might I ask you which apps and features are affected?
Click to expand...
Click to collapse
Button Savior (root). Assistive Zoom, oneClick Scroll. In my app, I create a jar with private API invocation in it and start the jar as a shell command by exec or something that I dont quit remember.
I got the same note, too. Oddly, two selinux mode changer apps are still in Play. Maybe they're less worried about apps that say in the title that they turn off selinux. Or maybe they just haven't got to them?
arpruss said:
I got the same note, too. Oddly, two selinux mode changer apps are still in Play. Maybe they're less worried about apps that say in the title that they turn off selinux. Or maybe they just haven't got to them?
Click to expand...
Click to collapse
Hmm, the e-mail is just a warning.. I think the apps will be removed in 13 days.
The title shouldn't matter, I assume it's just a scanner/grep which they run against eg. the classes.dex and search for "setenforce".
My app doesn't use this command normally, nor is it an app which is used by the 0815-user - it cannot be a human who decides about good/bad
But does this help us in any way?
This zip is just as good if not better. Only problem is is I don't think there's a way to go back and forth between permissive and enforcing. I did not make this trip, I'm not a programmer, and I'm taking no credit for it. I just found it awhile ago and decided to hold onto it.. Going to recovery, flash the zip, presto.
https://mega.co.nz/#!jhgA3Spb!oOS9ru9q5dDfS5V9iHLFXUTiuZVTSbNk1iyrLrq-lus
tmjm28 said:
This zip is just as good if not better. Only problem is is I don't think there's a way to go back and forth between permissive and enforcing. I did not make this trip, I'm not a programmer, and I'm taking no credit for it. I just found it awhile ago and decided to hold onto it.. Going to recovery, flash the zip, presto.
https://mega.co.nz/#!jhgA3Spb!oOS9ru9q5dDfS5V9iHLFXUTiuZVTSbNk1iyrLrq-lus
Click to expand...
Click to collapse
Thanks for sharing!
I fear we cannot tell our (sometimes quite stupid) users "flash a permissive kernel" if it's "in theory" simple to temporary make SELinux permissive by a single command.
funtax said:
Thanks for sharing!
I fear we cannot tell our (sometimes quite stupid) users "flash a permissive kernel" if it's "in theory" simple to temporary make SELinux permissive by a single command.
Click to expand...
Click to collapse
... which isn't possible on bootloader locked (exploit freed) devices
Has anyone an idea how to exactly interprete this message from Google?
I assume they parse the APK for "setenforce" and blame all apps which use it.
I fully understand and confirm Google's decision, no matter that it's realy a pain in the a** for some of us.
So, what are your thoughts about the following:
1. use a crypted version of "setenforce 0" which hopefully bypasses Google's scanners
2. do the modifications you need to do and hope this modifications are still working after enforced-mode is active again (how would a "execmod"-exception perform if the text-relocations have been made while SELinux was off?)
3. now call setenforce again but with "1", to re-renable SELinux
In other words:
1. would SELinux recognize that a text-relocation was made while it was disabled and then activated?
2. would it be ok to temporary disable SELinux but then re-enable it shortly after the required modifications?
@Chainfire: maybe #1 is something you might know due to SuperSU?
Removed setenforce 0 and surprisingly my app is still working. Guess newer superSU can bypass selinux restriction to some level.
jerryfan2000 said:
Removed setenforce 0 and surprisingly my app is still working. Guess newer superSU can bypass selinux restriction to some level.
Click to expand...
Click to collapse
Yes, that's correct. SuperSU sets itself to "permissive" in most times afaik - so if you run your restricted commands via SuperSU, you might not get problems with SELinux.
But if another process/pid is running into issues with SELinux, that won't help you.
To anyone still having to modify the SELinux state I would advice you guys to use the Audit messages.
You might not even need to change SELinux to permissive. It's even mentioned in Chainfire's SU documentation in detail.
Catalyst06 said:
To anyone still having to modify the SELinux state I would advice you guys to use the Audit messages.
You might not even need to change SELinux to permissive. It's even mentioned in Chainfire's SU documentation in detail.
Click to expand...
Click to collapse
This might indeed help some of the devs to adjust their commands to work with SELinux enforced - good hint, pretty sure many users are not familar with that
Ohh.. I must adjust myself: I wasn't aware of the SELinux-patcher. Might be an acceptable workaround?
funtax said:
1. use a crypted version of "setenforce 0" which hopefully bypasses Google's scanners
Click to expand...
Click to collapse
If Google catches this, they may be more tough on you.
I got notices for 3 variants of my Spirit FM apps. Was just a debug/test menu item.
Not needed for my Spirit2 app, but the Spirit1 app did direct access to audio and other devices and won't work on Lollipop otherwise. Not a big deal for Spirit1 really though, because I will likely never release a non-beta compatible with Lollipop.
So I removed the code.
Now I have a tricky issue because I was trying to slowly roll out a new version to KitKat users. So now, 80% of my Lollipop users may still have the "bad" app and I can only fix that by increasing the KK rollout to 100%.
Wonder if Google will kick me at the 14 day mark if I don't go to 100%.
mikereidis said:
Now I have a tricky issue because I was trying to slowly roll out a new version to KitKat users. So now, 80% of my Lollipop users may still have the "bad" app and I can only fix that by increasing the KK rollout to 100%.
Wonder if Google will kick me at the 14 day mark if I don't go to 100%.
Click to expand...
Click to collapse
Any news since? It seems Google pulled the trigger...
Sine. said:
Any news since? It seems Google pulled the trigger...
Click to expand...
Click to collapse
I went to 100% with my rollout just to be on the safe side.
I have had no followup problems. My affected apps are still selling.
Would have been nice for Google to send a "Thank you for co-operating" email.
I am sorry to hear that the SCR Pro developer has had his developer account terminated.
Termination is an EXTREME measure seemingly intended for confirmed malware spreaders.
I think it is VERY rare (if not impossible) to get a terminated account re-instated. I don't recall ever hearing of a re-instatement.
All of us small developers dependent on Google Play for our income are just a few Google mouse clicks away from having our indie careers ended and Google just does not care.
Why are they doing this?
I'm not sure if this is a good decision from Google. I fully understand that this could help to protect users, but in my opinion, a warning on the device would have been enough.
Android should be an open System. A user installing a permissive kernel, or changing a existing one to permissive mode, could be expected to know what she or he is doing.
I have to recompile the kernel for my SM-P605 because it was the only way to get it to work in permissive mode. Without the ability to do the mode switching by app, I have
to do this ugly changes by hand or make them persistent. Without this I'm even not able to do a chroot and run another Linux-distro on such a device. Forcing developers
to bypass such restirctions is the bigger security issue. If I'm not able to do such things, I could just as well buy a device made by apple.
What would a normal Linux user say, if he isn't allowed to get root access or couldn't download programs which don't work on a Kernels not enforcing SELinux.
mame82 said:
I'm not sure if this is a good decision from Google.
Click to expand...
Click to collapse
Google doesn't care.
Android is now dominant, and Google is closing it off, going closed source on the increasingly important Gapps/GMS etc.
Android Auto, TV, Wear, Play, etc. etc: closed source.
DRM will come and Google doesn't want us bypassing it. We already have it in locked bootloaders for non-Nexus.
This likely makes business sense for Google. They are the new Microsoft, not quite as evil perhaps, but getting closer all the time.
I'm running Chroma Lollipop with Xposed. I've considered privacy with app permissions but every time I try to implement it I get overwhelmed and give up. I see that Chroma comes with Privacy Guard built in, which looks farily simple, and I've also purchased XPrivacy Pro and tried that but current don't have it. I'm looking for a little feedback on what everyone else is using (or nothing if that's the case), and which route I should go.
A. Turn on Privacy Guard by default. This seems like a simple option.
B. Use XPrivacy crowd sourcing. XPrivacy seems like the more powerful option, but the crowd sourcing doesn't catch everything, and I really don't want to go though all my apps and think about every permission. That seems like a really daunting task (maybe I've overestimating). A balance between privacy and simplicity is important to me.
I'm just using built in 6.0 permissions things where it just asks for permission to do anything for the first time
StykerB said:
I'm just using built in 6.0 permissions things where it just asks for permission to do anything for the first time
Click to expand...
Click to collapse
THAT is the proper way ^^^
HOWEVER, just be aware that there are some significant limitations to the... limitations... that aosp permissions are able to impose. For example, you can't deny INTERNET to any application, since google has deemed that one to be universally required (for distribution of advertisements). BUT, at least it allows you to prevent access to your contact list to applications that use the internet, which means that it can't just automatically send your contact list to spammers without your consent.
Thank you for all you hard work, I have been a user for many releases prior and love that your software has always been "there and working well". So why only speak up when I have a problem, so for that I apologize.
I have managed to obtain a version of Xposed (Systemless) ported for Magisk installed on my phone (SDK 23) and while Magisk lists Xposed in its installed module list with a check box saying it is active, the Xposed menu shows the green notification area that says it is working, when I install XprivacyLua, and while after the installation of XprivacyLUa, in the Modules section of Xposed there is a check box showing that XprivacyLua is installed and active, the problem is that the Xprivacy app thinks it is not loaded. I sent trace logs captured via adb to the Xprivacy developer and he says that Xposed believes the XprivacyLua app is not installed (even though all indications are that it is active).
Someone who knows more about this than me stated my problem was likely with Toybox being on the phone and something about symlinks where he gave another suggestion about loading Busybox and then following with loading a BusyBox binary zip package via TWRP. All this does is render me not able to access MagiskManager any longer.
Do you know anything about such an issue and how I might get around it? I am saddened that using this valuable tool is being made so difficult from all the new hardware changes. I normally stick with age old phones, but accidents happen, the old one's cracked and my new one won't seem to work with Xposed.
Thanks!
BLU STUDIO XL 2 16/2G
MT6737
ARMv7 Processor rev4 (V71)
armv71
Is there anyone who can help me with my issue? I have poor eyesight and need a larger phone like the BLU, plus as often as I drop phones I cannot afford to buy the fancy, expensive and popular gaming models that everyone seems to purchase.
I am willing to do what ever it takes to resolve the issue, including running traces, submitting file structure maps or anything the developer needs to address the issue with Toybox or whatever the problem that is causing XprivacyLua not to be enabled by Xposed.
Thank you again.
Donphillipe said:
Is there anyone who can help me with my issue? I have poor eyesight and need a larger phone like the BLU, plus as often as I drop phones I cannot afford to buy the fancy, expensive and popular gaming models that everyone seems to purchase.
I am willing to do what ever it takes to resolve the issue, including running traces, submitting file structure maps or anything the developer needs to address the issue with Toybox or whatever the problem that is causing XprivacyLua not to be enabled by Xposed.
Thank you again.
Click to expand...
Click to collapse
What about making system run in permissive mode?
have you tried?
I have not "jumped" from superSU to majisk so my method is to use superSU.
I have a recovery install package that sets file in place to make permissive and force superSU to install systemless.
you can give a try.
the updater-script prints out a message it was made for "blu tank xtreme pro" but it is fine for other phones too. I made it for/ with other dev who wanted to have one step to make root and permissive.
I do not know how will respond to majisk, so better off to try ununstall that first, and start fresh.
Just as the title says, the new natwest app update (2018 June) refuses to work when Xposed Framework is enabled, but runs find when the framework is disabled. I am interested to know how it detects when the framework is operational, and how can I fool the app into running while Xposed framework is running.
Here is my system:
Samsung Galaxy S5
running Lineage OS 14.1, rooted
Xposed framework version 89
I have tried a number of methods to hide the running framework with no success
Tried DotMod to hide xposed --> not working
Tried XprivacyLua, denying all sorts of permissions such as view activity and running apps --> not working
Only works when i disable the framework and restart the phone. But that is ofcourse tiresome, cos no one wants to restart their entire phone just to check their bank app.
Current solution is to revert to previous versions of natwest bank app, but again that is trivial, as sooner or later they will refuse to work on outdated apps and force update.
Talking to the dev team, the only clue they mention is their new app checks the memory for running malicious apps, and if it detects anything it refuses to run. So it is not safetynet (infact safetynet fails, but the app runs)
Fair enough, but ive tried denying it literally all permissions, both from Privacy guard of lineage os 14.1 and XprivacyLua, and nothing works. Either the app is using some clever method to bypass these, or they dont do their work properly.
I miss old xprivacy, where you had a billion more options within permissions, with info of when and what did each app accessed.
I need xposed in order to disable my proximity sensor which is broken, and constantly thinks the value is zero, hence blacking out my screen during calls
Any help or advice will be much appreciated.
I believe it was with the 2016 November security update that Google changed something that forced an update to Xposed that made it practically impossible to hide. Xposed is easily detectable in the running zygote (something you can't hide), and the only solution is the one you've already found; disable and reboot.
i keep reading many times now "the only solution is reboot" - that is not a solution, we need to find a way to better hide xposed. Perhaps I need to research a bit more on zygote and find out and how it works exactly, and see if there is a way to mask it. Honestly all these android updates are pissing me off, its getting harder and harder to mod your phone, and I dont get why they struggle so hard to make it difficult for us modders.
I will attempt to flash back to kitkat and try, I would not be suprised if it ends up working.
In the windows enviroment you can always do wtv ur heart desires, and if that means destroying your PC so be it. But in android enviroment is so damn hard, and no devs want to share how they implement things in fear of someone hacking them or wtv. But all this is doing is hurting modders, making us hate some apps with harsh rules and moving away, doesnt do any good for anyone!!
It's perfectly possible to hide Xposed if you downgrade to a security patch prior to November -16. You're likely gonna have to dig around a bit for the proper files and versions though.
And believe me, there have been some pretty brilliant minds that have tried to find a way to hide Xposed and found it not to be possible. Of course, "nothing's impossible" and maybe someone with a brilliant idea finds a miraculous way. You never know...
Currently have a ONEPLUS 3T running Resurrection Remix ROM, which is great.
I guess the P30 hasn't had any development in this area? I was reading in the rom section and it seems even unlocking the bootloader is tricky, let alone loading a custom rom.
Is this something that will come later?
It's my first time thinking about buying a relatively new phone so not sure of the time line of things like this.
Cheers!
anotherxdauser said:
Is this something that will come later?
Click to expand...
Click to collapse
Huawei stopped giving official bootloader unlock codes, which means no TWRP or custom ROM/ Kernels. There are unofficial unlock codes, but they are pricey, may not be available all the time, etc.
But if you're looking to buy a P30 Pro, it shouldn't be for its custom ROM scene or mod capabilities. It should be for its camera. Period. There is a very good reason it's being held so high in all reviews for its camera prowess, you won't be getting tried of admiring what the camera can do, and the built-in image editor can enhance on - be it night, wide or zoom.
To its credit, EMUI does have a few features like very good theme support, a Network speed indicator, the gesture navigation and floating navigation dock are nifty, etc. You can install Netguard for firewall and Ad blocking through hosts, disable or uninstall system apps (bloatware) through ADB, try out custom launchers if you do not like EMUI launcher, and so on - in other words, its not too bad that the phone cannot be officially unlocked.
But if custom ROM/ recovery are more important, you should look at One Plus 7/ Pro, maybe. You'll not have similar kind of a development for this phone. Look up the custom section for, say, Mate 20 Pro to understand the kind of progress you can expect
Thanks
Have been thinking yesterday whether I need root or not.
I don't understand ADB, so try and avoid using it.
This is where a custom recovery excells - I can just load the zip and flash it on to the phone from the phone. But a lot of the time, this is to do with custom roms.
I have AdAway, but don't think that needs root.
I have Solid Explorer, which has a root mode, but I rarely use this and it's more for finding files around the phone than anything else.
I do use Greenify but not sure whether it actually does anything, or if it needs root access.
Nova Launcher is one that may require root, but I can't see anything blindingly obvious as to why. It also hides system apps so I don't bother uninstalling them.
Titanium Backup - but I only use this when upgrading the ROM.
Bouncer is another app I have recently installed. It does have a root mode, but is optional.
I can still sideload apps without root, so don't need it there either.
So it doesn't look like I need root.
Perhaps I only had it to install a custom ROM, but I'm not one of those people who installs a new one every week. I barely update the one I have because it's a fair bit of hassle! I think the only thing I am worried about is after Android 9 and whether there will be a timely update to 10. But then the changes I have seen since abut 3 or 4 versions of Android have been very minimal at best.
Can things run systemlessly without root?
Sorry for all the questions.
Does worry me a little that Huawei don't allow people to fully control their phones - the cynic in me makes me think it's because they're spying, so don't want people to run any other software but theirs! Ha ha.
I may have an opportunity to buy the phone for about £400 less than what Amazon are selling it (Amazon: £899, eBay: ~£500, one I was looking at on ebay: £500 with best offer).
Be careful with ebay. Cheapest isn't always best.
anotherxdauser said:
I have AdAway, but don't think that needs root.
I do use Greenify but not sure whether it actually does anything, or if it needs root access.
Nova Launcher is one that may require root, but I can't see anything blindingly obvious as to why. It also hides system apps so I don't bother uninstalling them.
Can things run systemlessly without root?
Click to expand...
Click to collapse
AdAway will need root (or magisk) - so that won't work. What you can do is use netguard and import the latest hosts created by AdAway (in another, rooted device). Read up about netguard, it's pretty good at what it does
Greenify has a non-root mode, but then the battery life in this phone is monstrous - I get about 2.5 days with 7 hrs of screen time and 1.5 hours of calling - my usage is pretty light though
Nova launcher does not need root for its primary functions - I haven't used it in a while so not sure what else it does that needs root
Nope - systemless/ magisk et all need bootloader unlocking, which ain't straightforward with this device...
Some good thoughts here.
If I can import a hosts file (link to tutorial?) that would be great.
Funny as I only use AdAway to block a banking app contacting its servers to report I'm rooted so I can still use the banking app. However, if I'm not rooted, I may not really require it any more.