Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete this project #188

Closed
linux019 opened this issue Jan 29, 2022 · 6 comments
Closed

Delete this project #188

linux019 opened this issue Jan 29, 2022 · 6 comments

Comments

@linux019
Copy link

Please delete this project, it used in some banking apps to detect root activity

@david-lev
Copy link

That's exactly the point...
And frankly, it's not a pretty reliable identification. An app that really wants to get an root indication, need to check SafetyNet.

@linux019
Copy link
Author

@scottyab
You've done a great job of finding and creating a list of "unsafe apps". Many of these apps are made by enthusiasts for free and they have spent years of their free time developing them. Many of these applications are completely safe. Your library is used in banking applications as an absolutely reliable source for checking the presence of root on the phone. Instead of researching and making a list of defects that can detect the "presence of root", you can help enthusiasts develop and further improve their projects, such as Magisk.
Thats's why I kindly asking you to hide this project on Github.

@stealthcopter
Copy link
Collaborator

Not really sure why all of the hate all of a sudden.

I strongly believe users should have the right to root their devices and this is something both myself and @scottyab do on some devices. We also support many of the apps in the ecosystem and we too have spent lots of time developing apps and libraries for the community.

However, I also believe apps should have the option to try and detect this should they wish. Sure it's annoying if you can't use your banking app, but deleting this library wouldn't change anything and we may prevent some users from having their banking details stolen. What about the apps that use our library so they can offer additional features to power users?

@linux019
Copy link
Author

One of solutions is to change license of this project to GPL2 so proprietary software will not be able to use code of this project without disclosure of source code

@scottyab
Copy link
Owner

I agree SafetyNet is a much more robust way for Apps to verify device integrity and give an indication of root and it's something we encourage developers/Apps to do. Maybe this needs to be worded better/stronger in our Readme? (welcome PR with suggestions)

I'm not 100% clear on the main objection to RotBeer, Is it the term "unsafe apps"? I can see how this could be taken as a negative and agree it could be improved to be more accurate. These apps could just be making use of features that require the device to be rooted which as you say might not mean they are unsafe 🤔 . Perhaps we should rename this in the library and sample app to be "apps that use root" or something similar?

Or maybe you're having issues with a particular app that's using Rootbeer? Incase you're not aware RootBeer can be bypassed on a per user/device basis with Frida,here's an article that walks through how to do this. We could highlight this better in the Readme too to help app developers understand RootBeer's limitations.

apps should have the option to try and detect this should they wish. ... deleting this library wouldn't change anything

I agree with @stealthcopter's comments. I don't see that removing the library or changing the licence would help matters and it's not something we plan on doing. Thanks for the feedback @linux019 and @david-lev. I'm closing this issue as it's not something that we feel needs actioning but welcome further conversation here.

@scscgit
Copy link

scscgit commented Mar 26, 2022

@stealthcopter "and we may prevent some users from having their banking details stolen"

The only thing root prevention helps prevent in context of bank security is any long-term reduction of stupidity in regard to both users and software developers. Banks need to grow their security instead of hiding rubbish under the carpet and building business on top of something they misunderstand. There is no reason for the default to be "not having root" just because Google decided that on a whim and Chinese manufacturers are fine with that (there wouldn't even be a discussion if we talked about OS on PC). In theory, maybe if you had a certified Android One OS, you could claim that you aren't at mercy of arbitrary backdoors of MIUI or similar OSes, nevertheless, there are plenty of issues that have way stronger impact, yet are already being systematically ignored by banks, as they never strive to increase "options" for users to allow them to voluntarily increase their own security (they only care about enforcing the kind of placebo security that can be applied to everyone at once, despite any "last mile" concerns), so it makes no sense to arbitrarily consider root to be the correct abstraction to look at. For analogy sake, it's as if you said that "police state with no privacy and false-positive arrests is better, because at least we prevent some people from committing crime". That said, the root issue (pun not intended) here is that OSes (or root tools) don't allow us to set up protected zones for apps whose data must never be read by other apps, and not that users should hope for the best without ever learning how to use root to increase their security, making them also unable to fix any other issues on their phone (yet we ignore real issues, like how all apps can read your SMS which for some reason is the exclusive point of account security, banks hate any integration with password managers or custom 2FA, and we can't configure different security levels for different actions). </rant>

I know we won't be able to forever run away from compliance with ever-increasing nonsense of developers of "smart banking apps", yet I don't want to live in a world where everyone has to carry two smartphones. Those developers are free to introduce any arbitrary security checks in the future anyway, so instead of arguing for deleting this project (i.e. hoping their ad-hoc solutions will miss something), I'd much rather have this become a de-facto consensus library that all banks will be eventually forced to use, so that we can also centralize any counter-detection here. It's always easier to debug counter-measures if you know what is being tested, which is why it's vital to focus on keeping everything open source.

Specifically, I want to point out how this project is becoming responsible not only for keeping the root checks up-to-date, but also for providing a more extensive documentation of any available counter-measures whenever users disagree about the findings on their device. There are use-cases where we are completely fine with the detection e.g.:

"What about the apps that use our library so they can offer additional features to power users?"

and there are also bank apps that merely notify us that we're continuing at our own risk, which is also what they should do by default, because when an unsuspecting (non-IT) person purchases a phone, they have no way to validate if it has been modified in any way. For example, Xiaomi often acknowledges and supports both root and also unlocking bootloader to install any firmware, and yet they must protect themselves from both manufacturers and resellers in case any party attempts to modify the OS before it reaches the consumer, which they do by displaying a hard-coded message during each device boot. That's merely another example of why these security checks are important and should be carefully performed by banks. And yet, once we understand and acknowledge the risks, we should have the right to use our (any licensed) software on our device, at any point in the future, especially once the market consensus changes and we start losing our rights. Even if that means having to spin on some kind of VM (though VMOS fails on "For RW Paths" check, any help?) only to install and run that single application. If there are any root checks for which we don't yet have any solution how to hide the detection, it should be at least tracked with the purpose of collectively looking for a way to hide it. Preferably, even the RootBeer UI could include this information to make the process easier and, whenever possible, it could let us "patch" the holes automatically (even if only temporarily for purposes of detection avoidance). This train of thought can be continued in the following issue that deals with documentation :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants