🍻In-Depth Rootbeer SDK Bypass (Native) pt 2

Well, so you have returned for more bypassing shenanigans, well then, lets begin.

We will now take a look at the SU binary check and the 2nd SU binary check. Why they separated this in two categories? I guess we will never know.

But as they separated it, we will do it too.

SU Binary Check

First things first, as always, lets take a look at the code of the check.

the function calls a generic checkForBinary function with a string located at the Constants of the rootbeer SDK

If anybody is curious, the string is 'su', well, this was certaintly surprising.

Now lets see the CheckForBinary function

so yeah, it searches for a file described at consts and sends to a native class java.io.file to the method exists(), so, lets take a look

well you might know that from this point we have two options, we may send a fake path for the java.io.file, or just send False to everything that it tries to check, we will simply go for the second one, as my phone just have su installed, it should not be too much trouble.

for this we will need to know what path we are dealing with when we execute this exists() method, as it could break the application if it's running this for other checks. So, for this we will be using another method from Java.io.File, that is getName(path)

Yeah, so i think we have everything we need to make a native bypass for that rootbeer method as well

        //Here we declare that we are going to hook the file class
var file = Java.use('java.io.File');


file.exists.implementation = function() {
//now we make sure that we return false when the app calls the exists for su
        var path = file.getName.call(this);
        if ("su") {
            console.log("[+] GOTCHA")
            return false;
        } else {
            return this.exists.call(this);
        }
    };

Using this code we are able to bypass our next check :)

as it was too easy to bypass this one we will analyse the next protection. and that one is kinda crazy haha.

the 2nd SU Binary check

Lets see what its doing

Yeah, so its using this Runtime.getRuntime().exec. that comes from java.lang.Runtime native class, lets see what this does ...

jdk7u-jdk/Runtime.java at master · openjdk-mirror/jdk7u-jdkGitHub

and the exec that it does

As the application is trying to execute which against su we can do a LOT of things, the first and most obvious one is to rename which or delete it haha, we will try is just for fun.

haha well, it works, you probably didn't even know that we could do the "which which", yeah, me neither.

Well surely that was expected, but we will try to make it harder right, that's the same as putting a return false on the damm method of the rootbeer and we are not going at the easy path. So take my hand and let's go into a adventure of bypassing the exec function.

So we will be doing the other approach that we did not use on the java.io.file.exists() method, so we will send a fake command to the application in order to bypass this one.

var runtime = Java.use('java.lang.Runtime');
var execw1arg = runtime.exec.overload('java.lang.String');

runtime.exec.overload('java.lang.String', '[Ljava.lang.String;', 'java.io.File').implementation = function(cmd, env, dir){

        if (cmd == "which") {
            var notwhich = "TotallyNotWhich";
	    console.log("GOTCHA")
            return runtime.execw1arg.call(this, notwhich);
        }
 return runtime.exec.call(this, cmd, env, dir);
      }

After that one we were able to do the bypass the proper way so...

Yeah, that is the end of part 2. in the next one we will try to bypass the "For RW Paths" & Dangerous Props.