hide su file

[julianwi]

Let droidguard helper work on rooted phones.
Successfully tested on cm11.

[ale5000-git]

Is it possible to sync it with the latest commit?

[julianwi]

Theoretically it could, but I think the latest commit does not work yet. @mar-v-in removed the hooking code but didn't add a replacement.

[mar-v-in]

The hooking is no longer required, Google lifted some of their restrictions for DroidGuard and it is the same to run DroidGuard with and without hooking now (if it works with hooking it will also work without, if it does not work without, it will also refuse to work with hooking).

It is not very suitable to go into a cat and mouse game with Google in terms of DroidGuard. This is why I don't think it is a good idea to put something like root hiding in it - it won't hide for all time. You can still use suhide or similar approaches that work with original play services / droidguard, they will work for microG as well.

I am also investigating a different approach that does not require to hook or otherwise trick DroidGuard and will hide su, Xposed and the like

[ale5000-git]

It is just an idea and maybe a lot complicate but can DroidGuard be run inside a sort of virtual machine (like a different OS inside Android) maybe by writing a native driver (that is between the software and the ext3/4 driver) that map all original files to the real version but not others like root?

In this way DroidGuard just see the emulated environment and it can't really see the the real memory in any way.

[mar-v-in]

Technically possible? yes. Useful? no.

Google can always find a way to detect it is running in a container or virtual machine. A method that turns out to be effective in hiding root and Xposed will be blocked as soon as it gets widespread - and everything we put in this app that is effective will become widespread soon.

[ale5000-git]

Well, it is the same for everything once an API is implemented in microG Google can change it and break but we shouldn't desist of trying.

Also it is easier hide it in microG than in the system because the DroidGuard binary is executed inside microG code and changes in DroidGuard helper won't cause problems to other apps instead changes in the system for hiding root can cause compatibility problems with other apps.

[mar-v-in]

No, it's something completely different then the API.
For API changes in play services to be effective it can take several months because it is not only the play services app that has to be updated (which can happen in days) but also the library included in apps (which usually takes weeks to years). Play services is specifically designed in being somewhat downwards compatible.
A DroidGuard binary can be world effective in a few minutes, which means they can ignore downwards compatibility completely. If they decide the binary should do a new check for a certain hiding technique, it can be there in a very short time, but the time to develop the technique it will be a lot larger.

And you are missing an important thing: Google is (at the moment) not actively trying to block microG out of anything (neither play services API, nor legit usage of DroidGuard). If we trick one of their core protection systems, they definitely will.

PS: Regarding this patch: Go, use it for yourself, compile it, share it, etc. (reverting 0ca6fb2 should allow you to merge this commit) But this is not going to end up in the official repo.

[ale5000-git]

I have an idea, maybe can be added support for "plugins" of DroidGuard helper that can be added (and enabled/disabled) like backends for UnifiedNlp.

So anyone can choose what "custom code" run before and after DroidGuard binary.

[julianwi]

Just merged the upstream commits into my fork. Root hiding does still work. If someone wants to test it, I uploaded a debug build here: http://julianwi.square7.ch/files/remotedroidguard/remote-droid-guard-debug-hidesu.apk

[ale5000-git]

@julianw: I'm not sure if it is my provider but my DNS cannot resolve square7.ch

[julianwi]

Download on github:
remote-droid-guard-suhide.apk.zip

[ghost]

Actually, @mar-v-in, I think a cat-and-mouse game (with red and blue pills) would be pretty interesting challenge. Gotta watch out for the DMCA/CD though.