2

Okay, so I was able to recover my deleted files after all. I am the furthest thing from a software developer, and I don't have more time to spend on this, but I wanted to explain how I fixed it and ask a question about why the solution worked in case it's significant.

People should just read my other questions if they want to know the background; basically I deleted an entire folder of photos on my Android by mistake, went through the trouble of learning how to root phones and use adb.exe, etc. to try and recover them, only to be blocked by SELinux.

I got stuck with SELinux because the kernel in Android 5.1.1 apparently disallows permissive mode in SELinux (or changes from enforcing mode to permissive mode). I didn't have time to learn how to decompile/edit the kernel, so I tried a shot in the dark with an app called DiskDigger that some people recommended (no, I am not a secret advertiser, I am being 100% honest). Surprisingly, DiskDigger worked, and recovered way WAY more than I expected, even some photos that may be from a previous user (refurbished phone). I was surprised that much was recovered; I did keep my phone in airplane mode almost the whole time I was working on this to prevent automatic updates, but I also installed several apps along the way and rooted the phone, so I guess I was lucky or something.

Now for the question:

If DiskDigger was able to do this, it must mean that it was able to get into files that required root access; SuperSU verified this because I had to grant DiskDigger permission to do so. What is it about DiskDigger that enabled it to get past SELinux when I could not?

Is it because it was verified by Google Play as a trusted app? Did it have some special identifier from google that allowed it past SELinux? If there's a way to copy whatever allowed DiskDigger access, maybe other people wouldn't end up getting stuck like I did.

Anyway, that's all. I'm probably not going to have to do this again, but thank you to the people who tried to help me out. If I ever have to delve into this stuff again, I'll be back.

  • 2
    Does this answer your question? Why "adb root" does nothing? – alecxs Aug 29 '20 at 04:17
  • 2
    SuperSU injects it's own sepolicy rules therefore manages privileged access without setting selinux permissive. i have already linked above answer on your first question, there it is explained well why adb root doesn't work (but adb shell su -c does) – alecxs Aug 29 '20 at 04:20
  • 1
    what makes you think you didn't have access to /data from terminal is most likely caused by isolated namespace separation (which you can disable in SuperSU settings) – alecxs Aug 29 '20 at 13:37
  • @alecxs mount namespace separation is only applicable to emulated storage where apps' access to filesystem is subject to Storage permission status. /data is equally visible in all namespaces to all processes. DAC allows apps to only access their private directories in /data. – Irfan Latif Aug 29 '20 at 19:37

0 Answers0