detect non rooted device as rooted device

[swapnilmusale]

I have used this lib in one of my app, but I feel like that, this lib detect some of the non rooted devices as rooted device. I have received some review on play store saying that My device isn't rooted still then this app will not let me in.

I have received this review from Redmi Note 8 Pro

please check the issue what's wrong or let me know possible reason behind this behaviour.

[stealthcopter]

What version of the library are you using? The latest version has reduced the false positives rates.

The false positives were previously mostly all caused by the busybox binary getting left on production builds by manufacturers and we were incorrectly flagging this as a potential root indicator.

[swapnilmusale]

I'm using this version implementation 'com.scottyab:rootbeer-lib:0.0.8' . Can you tell me what check I have to check to detect device is rooted or not. As I'm using this in production app so I need to fix this quickly...

[stealthcopter]

Install the sample app via the play store on one of the devices that is returning a false positive and see what the output is, this will tell you which is flagging the device as rooted: https://play.google.com/store/apps/details?id=com.scottyab.rootbeer.sample

It may be the device is actually rooted, or a false positive due to manufacture mistakes or something else.

[stealthcopter]

We've had a similar report previously for a Redmi device that upon further inspection had a root application installed: https://github.com/scottyab/rootbeer/issues/137 Might be some of these devices come pre-rooted? ¯_(ツ)_/¯

[aigjermo]

I can contribute an example here. I have a fairphone 3 which is running /e/. The phone is not rooted, and the bootloader is locked, yet it is marked as rooted by this library. I'll include a screenshot:

The dangerous prop in question is ro.debuggable, which is set to 1 because the rom is built in "userdebug" mode. I do not think that it is correct to use this flag as an indicator of a rooted system.

I am not sure about the selinux flag, but it is at least in this specific case a false positive.

[stealthcopter]

@aigjermo I think having this flag set to 1 allows you to become root using adb so it's not actually a false positive. I'm not 100% so would be good if someone can double check.

[aigjermo]

I'm not an expert, so someone else should verify this, but my understanding is that you need both ro.debuggable=1 and ro.secure=0. My phone has ro.secure=1 and it is not possible to become root with adb.

[stealthcopter]

@aigjermo Yes, I think you're right. I can't seem to find anything that states the debuggable alone can get root. @scottyab tagging you in as you might understand this flag more than me? any more insights?

[scottyab]

I think when we added this check initially we thought either ro.debuggable=1 or ro.secure=0 counts as an indication of root (side note all the checks should be thought of as indications of root rather than root checks per say). But based on the above this may have been an invalid assumption for a pure root checking library 🤔 .

❓ Does building the rom in "userdebug" mode make the system or Apps on the system more susceptible to attack?

Wondering with ro.debuggable=1 doesn't that give greater access to potentially manipulate/hook app/system functions?

[stealthcopter]

I've struggled to find documentation on it but I'm assuming when secure is turned on that system apps aren't debuggable, because otherwise I think you could use adb run-as to execute commands as system apps, and get root that way.

@aigjermo As you've got a device with this setup could you confirm that you can't debug system applications?

1. Check if you can debug system apps
2. Attempt to use run-as to execute command as a system app using something like adb exec-out run-as <packagename> id with any system app package

[aigjermo]

Yep, not possible for me at least:

❯ adb exec-out run-as com.android.systemui id
run-as: package not debuggable: com.android.systemui

[udaisshekhawat]

Hey Guys,

@stealthcopter @scottyab

Even I am facing similar issue with the latest version 0.0.8 I could see for devices like Google Pixel 3XL and Pixel 3 (with Android 9), checkForDangerousProps() is returned as true.

I have tried using devices available in Browserstack. So, those devices should not be rooted.

I could see ro.secure=0. Hope that helps.

[campioncino]

I have the same problem with the Blackview BV8000Pro (cheap rugged phone) and others Blackview products

[bricecesarin]

I am developper for a big android App. ATInternet stats show that all BlackView 8000 phones are detected as root.

[Korb]

I have the same problem with the Blackview BV8000Pro

I confirm the specified problem with this smartphone model. Fir this, the Google Pay application is working properly.

[TestereNecmi]

I'm getting same result with Samsung Galaxy C8

[lokesh-se]

Hi, On ASUS Zen9 Android 7.0. On a Non Rooted Phone.

RootBeer rootBeer = new RootBeer(context); if (rootBeer.isRooted()) ------> Return True.

How can we solve this problem?

[alviss7]

I have myself this problem on my Xiaomi mi a2, the ro.debuggable=1, personally the problem is blocking for me because French banks use your lib for their applications. And because of that, I can't buy on internet with dsp2 application :(

[heinrich-peters]

I am also hit by this "issue". My One Plus 3 is running LineageOS 18.1 on Android 11 and the build at https://download.lineageos.org/oneplus3 is created in "userdebug" mode (like @aigjermo's phone) and I am also not able to debug as root... I haven't rooted the device.

[ro.adb.secure]: [1]
[ro.boot.enable_dm_verity]: [1]
[ro.boot.flash.locked]: [1]
[ro.boot.secboot]: [enabled]
[ro.build.type]: [userdebug]
[ro.debuggable]: [1]
[ro.secure]: [1]

[ro.lineage.build.version]: [18.1]
[ro.lineage.build.version.plat.rev]: [0]
[ro.lineage.build.version.plat.sdk]: [9]
[ro.lineage.device]: [oneplus3]
[ro.lineage.display.version]: [18.1-20210614-NIGHTLY-oneplus3]
[ro.lineage.releasetype]: [NIGHTLY]
[ro.lineage.version]: [18.1-20210614-NIGHTLY-oneplus3]
[ro.lineagelegal.url]: [https://lineageos.org/legal]
[ro.modversion]: [18.1-20210614-NIGHTLY-oneplus3]
[ro.odm.build.date]: [Mon Jun 14 05:45:02 UTC 2021]
[ro.odm.build.date.utc]: [1623649502]
[ro.odm.build.fingerprint]: [OnePlus/OnePlus3/OnePlus3:8.0.0/OPR1.170623.032/02281230:user/release-keys]
[ro.odm.build.id]: [RQ2A.210505.003]
[ro.odm.build.tags]: [test-keys]
[ro.odm.build.type]: [userdebug]
[ro.odm.build.version.incremental]: [9d56dc0e28]
[ro.odm.build.version.release]: [11]
[ro.odm.build.version.release_or_codename]: [11]
[ro.odm.build.version.sdk]: [30]

From my understanding [ro.debuggable]: [1] is OK with [ro.secure]: [1], isn't it?

[Art4]

I have the same problem with the Blackview BV8000Pro (cheap rugged phone) and others Blackview products

I have the same false positive result with a not-rooted Samsung Galaxy S5 with LineageOS 18.1 for klte from 2021-10-31. I've tested the RootBeer Sample App and it shows me "Dangerous Props: :negative_squared_cross_mark:"

[tasmo]

As far as I understand, on most phones with LineageOS installed it is necessary to have ro.debuggable=1 because without that you even cannot install the Lineage recovery.

In my opinion LineageOS is even more secure with ro.debuggable=1 then most not customized companion ROMs. I think testing this without a further condition is a false positive.

[Ktirumalsetty]

How to i fix this rod user facing this isues my app doesnt allow to entere into app if rootBeer.isRooted() is false

[zinwalin]

How did you print out this ro. list?

[Korb]

How did you print out this ro. list?

Which list are you referring to?

[patrickdrd]

same screen here, I checked and I have both ro.debuggable=1 AND ro.secure=0 and I've got one banking app that detects root (maybe because of these two?) anyway, my device isn't rooted (I've got orangefox recovery though), can I do something to fix it?

[ghostsquad]

Any news on this?

[GUdokermensz]

[zzpianoman]

The NJTransit app is using your library to detect root, and the Play Store is riddled with reviews of false positives. It's preventing people from accessing tickets they legitimately purchased. This is more the fault of the developers of the app for thinking that blocking root access somehow makes their app more secure (it doesn't, because rooted users will ALWAYS find a way to circumvent root detection methods) but judging from the above comments, this isn't an isolated problem.