4 ms·

Edit: This is COMPLETELY INCORRECT (as pointed out by wallflower) but left for context. I can't test right now, but if your phone has ADB enabled, can't you pu

• wallflower 15y ago
  No, /data/data/* is protected (as it should be) on non-rooted phones. mediapc:platform-tools media$ ./adb shell $ ls /data/data opendir failed, Permission denied $
  • chopsueyar 15y ago
    But if you have physical access to the phone, why couldn't you root it?
    • ConstantineXVI 15y ago
      1) Official root methods (see `fastboot oem unlock`, as made famous by the Nexus phones) as well as many less official methods require a wipe, thus rendering this attack moot. 2) In the event your phone isn't covered by the situation in #1, having a passcode lock and not enabling ADB (developer mode) should be sufficient to protect from a root attack in most cases. It's worth noting that you're still vulnerable to a root attack that doesn't wipe and can bypass your passcode (runs from fastboot/recovery, or a hole in the passcode lock itself); though I've yet to come across a phone personally with this situation. And it goes without saying, if you've rooted your phone yourself, any OS security is null and void. If you're rooting, you should realize this already.
      • 1880 15y ago
        > if you've rooted your phone yourself, any OS security is null and void Are you sure? If I am not mistaken, even with a rooted phone, a program has to ask the user for root permission via the Superuser.apk app.
        • crazysim 15y ago
          If a phone was rooted like as a action, the exploit to get root in the first place is probably still there.
        • inportb 15y ago
          Ah, but how does this Superuser.apk achieve root privileges? By calling the setuid root `su` program, you say. And how does this setuid root program actually gain root privileges? Why, the OS is able to execute arbitrary code with arbitrary privileges, and it makes an exception for `su`. Wait... so Android could run processes with root privileges without asking you? Whoa! Now consider that adbd on a rooted device runs with root privileges...
          • vetinari 15y ago
            Jumping to conclusions, are we? Superuser.apk does not achieve root privileges and su does not blindly run your program with root privileges. su asks superuser.apk, if your program is allowed to run as root and only when superuser.apk agrees (and displays toast), then your program is run. Also, the arbitrary privileges are reserved for setuid programs, which is not easy to achieve. Basically, su and Superuser.apk are gatekeepers to uid 0, which short of bugs, you can't get around. Also, did you know, that you can disable adbd? Or remove root privileges from it?
            • inportb 15y ago
              You forget that init executes as root, and is therefore able to spawn root children.
        • rcxdude 15y ago
          But, if you're rooted, you likely have a custom recovery and bootloader which will accept commends freely, so it is pretty trivial to pull arbitrary stuff from the phone. You should, however, be safe from other routes, so long as you disable adb (which also freely accepts commands as root in most ROMS), Filesytem encryption would close all these attacks, but I'm not aware of any particular implementations (I'm pretty sure there aren't any popular ones)
• kgermino 15y ago
  Thank you for leaving the original for context, it's drives me nuts when people delete a message or edit out the content when there's a string of replies.