Adding support for bypassing RootBeer library.

[haxxinen]

• app: https://github.com/scottyab/rootbeer
• lib: https://github.com/scottyab/rootbeer/tree/master/rootbeerlib
• apk: https://play.google.com/store/apps/details?id=com.scottyab.rootbeer.sample
• blog: https://medium.com/@scottyab/detecting-root-on-android-97803474f694

[leonjza]

Thank you! Will test this soonest! 🙌

[leonjza]

@haxxinen I'm so sorry for the time it took to get to this PR. I've been working on PR's in a fifo, and that has caused a merge conflict here. Could you rebase?

My next question is regarding the obfuscation hooks in the bypassRootBeerObfuscated* functions. Is the proguard rule predictable enough for this to be reliable?

[haxxinen]

@leonjza Fixed conflict. And yes, the obfuscated methods should be predictable enough. Please test when you have the time. Thanks.

[leonjza]

I finally dug into some applications sourced from here (thanks @CDuPlooy for the hint on the URL mentioned in the Rootbeer project page), and found the obfuscated method names to be unpredictable. There was one pattern I saw repeated though, but I still feel that it is not predictable enough. Eg:

    public boolean n() {
        return j() || h() || b("su") || c() || e() || l() || g() || f() || d();
    }

I don't think we're dead in the water here though. In fact, this is a pretty cool case where I think we can enumerate function signatures within com.scottyab.rootbeer.* that return booleans, and just hook all of those to return false. That way, no matter then function name, we can have some confidence we'll have good hook coverage.

I propose two things:

1. Let's strip out the obfuscated hooks from this PR, and land the unobfuscated version quickly. (There are plenty of unobfuscated apps out there that will make this a useful contribution). I'll do a small code review in a moment as well.
2. Get another new PR in that focusses on com.scottyab.rootbeer.*, enumerating functions that return a boolean, hooking all of them to return false.

[leonjza]

Seems like the SELinux flag is still detected with this PR. Thats okay, I'm going to merge and clean this up. Thanks for the contribution! 🙌

[leonjza]

A quick update, I made some small changes post merging this. Mostly to fix a syntax error, small style changes but more importantly I removed the obfuscated hooks for now. I didn't want that to be a blocker to land this entirely, but if theres some evidence that it will actually be useful (aka. there is common proguard rules that make the function renaming predictable), then we can revisit that.

Thanks again for the contribution.