6 ms·

How do you detect whether a device is Jailbroken/rooted ? [Edit] : Found this - https://github.com/scottyab/rootbeer https://github.com/scottyab/rootbeer I th

by crudbug 10y ago

How do you detect whether a device is Jailbroken/rooted ? [Edit] : Found this - https://github.com/scottyab/rootbeer https://github.com/scottyab/rootbeer I think this will be useful for applications that want to know if the execution environment is safe or not - Banking / Payments etc.

tylorr 10y ago
My first guess would be to attempt an operation that only works if the device is rooted.
elastic_church 10y ago
One thing I used to do was check if the hosts file had been modified, or something like that. I had conditional paths for showing ads, and some rooted phones had blocked ads based on IP address.
irfanka 10y ago
Try executing something that needs root-level access(?)
cprecioso 10y ago
In Android, you can use the Google SafetyNet API, that checks whether the system partition has been modified or mounted r/w, the existence of the su binary and some more clues like those. I don't know the current state of jailbreak detection in iOS, but I do remember that some time ago, as a rudimentary jailbreak detection, iBooks tried to run unsigned code at launch, and if it ran, the app would refuse to open.
- crudbug 10y ago
  Interesting, I am guessing there is some kind of learning net behind SafetyNet API - Harvesting all the device infos.
  - evanreichard 10y ago
    SafetyNet is pretty flexible. It actually isn't implemented inside any APK - "The SafetyNet service reaches out to a Google server and downloads a binary package with the code. It goes to great lengths to validate the integrity of the package, for example using hardcoded certificates (pinning). This binary package is essentially a JAR file that contains a classes.dex file with java bytecode. Play Services caches it in dalvik-cache (snet.dex) and loads it dynamically using reflection." [1]. I think right now the only way "around" it has been Magisk [2]. [1] https://koz.io/inside-safetynet/ https://koz.io/inside-safetynet/ [2] https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445 https://forum.xda-developers.com/apps/magisk/official-magisk...
    - cprecioso 10y ago
      And suhide [1], but that one's a cat and mouse game, as acknowledged by the developer. [1]: https://forum.xda-developers.com/apps/supersu/suhide-t3450396 https://forum.xda-developers.com/apps/supersu/suhide-t345039...
  - cprecioso 10y ago
    I don't think that'd be necessary. Google's stated that SafetyNet's purpose is not excluding power-users, but ensuring the security model of the OS has not been compromised, in order to activate certain sensitive functions (e.g. Android Pay). Given that developments in the root community are few but well-known, it'd only take a weekly visit to the XDA Developers forum by an intern to learn about any new rooting method, and not many resources to successfully block them. No need for a complicated (and expensive) information gathering and mining rig _for SafetyNet_. Could they be gathering that information with other purposes? Given that Play Services de-facto has root powers within Android, maybe.
problems 10y ago
You can try lots of things, detecting su binaries, UI applications, checksumming the entire filesystem, etc. But ultimately if the user doesn't want you to know, you won't know. Rooting or jail breaking your device is taking control of your device into your own hands, if you use something like Magisk, you can fully bypass root detection, even via the nastiest methods on Android. Detecting it as a security problem is moronic. In fact, I'd argue it's actually a security improvement due to things like XPrivacy.
- nissimk 10y ago
  I'm curious to hear other people's opinions about this. I feel like the smartphone security model provides security for the OS developers, the app developers and their advertising customers at the expense of usability for the users. But it also provides real security to the users. I generally choose usability over security, but maybe I should be more paranoid. I do not have android pay enabled on my phone but I'm not sure I'd be comfortable with it even if I wasn't rooted. I insist on root because I want to block ads and install themes. It's possible to do these things without root, but it's harder. Please comment people with deeper knowledge of security.
  - problems 10y ago
    The sandbox has been good in that it hasn't let the Windows model of apps running rampant with admin privileges do whatever they want with your data. It's mostly prevented cross-app data access. But that's not where it stops. You see, there's still plenty of great data they can grab when you blindly click accept on that permissions dialog. Contacts are grabbed by many applications, unique device identifiers, loading your app with ads, even grabbing GPS location are pretty much standard practice now. These practices which used to be labeled spyware or adware and hunted down and removed are now the norm. These apps grab this data and then throw it out onto the open internet, often over unencrypted connections to parties who you don't know or trust, who are often unrelated to the app developer almost entirely, most often just so some advertiser knows you play a certain game or live in a certain city. It depends on your definition of security - if it's strictly clicking on an ad and getting malware - it's great - but if it includes things like leaking contacts, locations and identifying information - it's terrible. XPrivacy is the only solution I've seen to really hit back at it. Rooting your device does NOT immediately lose all sandbox benefits. It only selectively bypasses it. If you don't approve EvilMalware to bypass the sandbox - it still can't break out. As for Android Pay? Go ahead and use it. Rooted or not, to my understanding, you're not liable for fraud on it, your credit card company will still reverse transactions no problem.
rsync 10y ago
"I think this will be useful for applications that want to know if the execution environment is safe or not - Banking / Payments etc." Which is the safe one ? The default ecosystem or the jailbroken one ? I ask because most of the advanced security measures and hardening that I ever considered doing on an android phone required jailbreaking ...
- crudbug 10y ago
  Nothing is safe. The platforms can atleast do a better job to provide feedback or display on the UI, whether the current environment is safe, for monetary txns etc. Secureboot [0] creates trust between hardware and software, but here you have to trust the hardware. An interesting question is how can software audit its hardware that is driving it ? ARM TrustZone [1] is another way to offload all the sensitive computation onto another embedded SoC. But, its hard to know what the application is using. You sort of have to trust the banks to do the best job. [0] https://source.android.com/security/verifiedboot/ https://source.android.com/security/verifiedboot/ [1] https://www.arm.com/products/security-on-arm/trustzone https://www.arm.com/products/security-on-arm/trustzone

by crudbug 10y ago

tylorr 10y ago

My first guess would be to attempt an operation that only works if the device is rooted.

elastic_church 10y ago

One thing I used to do was check if the hosts file had been modified, or something like that. I had conditional paths for showing ads, and some rooted phones had blocked ads based on IP address.

irfanka 10y ago

Try executing something that needs root-level access(?)

cprecioso 10y ago

In Android, you can use the Google SafetyNet API, that checks whether the system partition has been modified or mounted r/w, the existence of the su binary and some more clues like those. I don't know the current state of jailbreak detection in iOS, but I do remember that some time ago, as a rudimentary jailbreak detection, iBooks tried to run unsigned code at launch, and if it ran, the app would refuse to open.

crudbug 10y ago
Interesting, I am guessing there is some kind of learning net behind SafetyNet API - Harvesting all the device infos.
- evanreichard 10y ago
  SafetyNet is pretty flexible. It actually isn't implemented inside any APK - "The SafetyNet service reaches out to a Google server and downloads a binary package with the code. It goes to great lengths to validate the integrity of the package, for example using hardcoded certificates (pinning). This binary package is essentially a JAR file that contains a classes.dex file with java bytecode. Play Services caches it in dalvik-cache (snet.dex) and loads it dynamically using reflection." [1]. I think right now the only way "around" it has been Magisk [2]. [1] https://koz.io/inside-safetynet/ https://koz.io/inside-safetynet/ [2] https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445 https://forum.xda-developers.com/apps/magisk/official-magisk...
  - cprecioso 10y ago
    And suhide [1], but that one's a cat and mouse game, as acknowledged by the developer. [1]: https://forum.xda-developers.com/apps/supersu/suhide-t3450396 https://forum.xda-developers.com/apps/supersu/suhide-t345039...
- cprecioso 10y ago
  I don't think that'd be necessary. Google's stated that SafetyNet's purpose is not excluding power-users, but ensuring the security model of the OS has not been compromised, in order to activate certain sensitive functions (e.g. Android Pay). Given that developments in the root community are few but well-known, it'd only take a weekly visit to the XDA Developers forum by an intern to learn about any new rooting method, and not many resources to successfully block them. No need for a complicated (and expensive) information gathering and mining rig _for SafetyNet_. Could they be gathering that information with other purposes? Given that Play Services de-facto has root powers within Android, maybe.

problems 10y ago

You can try lots of things, detecting su binaries, UI applications, checksumming the entire filesystem, etc. But ultimately if the user doesn't want you to know, you won't know. Rooting or jail breaking your device is taking control of your device into your own hands, if you use something like Magisk, you can fully bypass root detection, even via the nastiest methods on Android. Detecting it as a security problem is moronic. In fact, I'd argue it's actually a security improvement due to things like XPrivacy.

nissimk 10y ago
I'm curious to hear other people's opinions about this. I feel like the smartphone security model provides security for the OS developers, the app developers and their advertising customers at the expense of usability for the users. But it also provides real security to the users. I generally choose usability over security, but maybe I should be more paranoid. I do not have android pay enabled on my phone but I'm not sure I'd be comfortable with it even if I wasn't rooted. I insist on root because I want to block ads and install themes. It's possible to do these things without root, but it's harder. Please comment people with deeper knowledge of security.
- problems 10y ago
  The sandbox has been good in that it hasn't let the Windows model of apps running rampant with admin privileges do whatever they want with your data. It's mostly prevented cross-app data access. But that's not where it stops. You see, there's still plenty of great data they can grab when you blindly click accept on that permissions dialog. Contacts are grabbed by many applications, unique device identifiers, loading your app with ads, even grabbing GPS location are pretty much standard practice now. These practices which used to be labeled spyware or adware and hunted down and removed are now the norm. These apps grab this data and then throw it out onto the open internet, often over unencrypted connections to parties who you don't know or trust, who are often unrelated to the app developer almost entirely, most often just so some advertiser knows you play a certain game or live in a certain city. It depends on your definition of security - if it's strictly clicking on an ad and getting malware - it's great - but if it includes things like leaking contacts, locations and identifying information - it's terrible. XPrivacy is the only solution I've seen to really hit back at it. Rooting your device does NOT immediately lose all sandbox benefits. It only selectively bypasses it. If you don't approve EvilMalware to bypass the sandbox - it still can't break out. As for Android Pay? Go ahead and use it. Rooted or not, to my understanding, you're not liable for fraud on it, your credit card company will still reverse transactions no problem.

rsync 10y ago

"I think this will be useful for applications that want to know if the execution environment is safe or not - Banking / Payments etc." Which is the safe one ? The default ecosystem or the jailbroken one ? I ask because most of the advanced security measures and hardening that I ever considered doing on an android phone required jailbreaking ...

crudbug 10y ago
Nothing is safe. The platforms can atleast do a better job to provide feedback or display on the UI, whether the current environment is safe, for monetary txns etc. Secureboot [0] creates trust between hardware and software, but here you have to trust the hardware. An interesting question is how can software audit its hardware that is driving it ? ARM TrustZone [1] is another way to offload all the sensitive computation onto another embedded SoC. But, its hard to know what the application is using. You sort of have to trust the banks to do the best job. [0] https://source.android.com/security/verifiedboot/ https://source.android.com/security/verifiedboot/ [1] https://www.arm.com/products/security-on-arm/trustzone https://www.arm.com/products/security-on-arm/trustzone