In the last blogpost, we covered how to use unidbg from scratch to emulate an Android native library. As some might have noticed, the Proof of Concept code is not production ready as it does not allow for a way to call the signing functionality externally. More importantly, the code is too slow for practical use. Let’s add some time measuring code to our previous main method to see this in action:

public class Main {
    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        Signer signer = new Signer("/tmp/libhellosignjni.so");

        String signature = signer.sign("helloworld");
        System.out.println("Signature: " + signature);

        long end = System.currentTimeMillis();
        System.out.println("Total execution time : " + ((end - start) / 1000.0) + " seconds");
    }
}

Running the above code takes more than 6 seconds for a single signature (on a decent modern computer)!

Signature: c24e48124f5c69ec647a5147193932f2a7aef0a9362163ce0ca29da259b2047c
Total execution time : 6.483 seconds

In this blogpost, we’ll cover how to make unidbg usable for production by pointing out the bottleneck in execution. In addition, we’ll add a layer around unidbg to expose the signing functionality to other services.

The bottleneck

After debugging the code, it is pretty obvious which part of the code takes the longest to run. See the updated code snippet:

public class Main {
    public static void main(String[] args) {
        long t1 = System.currentTimeMillis();
        Signer signer = new Signer("/tmp/libhellosignjni.so");

        long t2 = System.currentTimeMillis();
        System.out.println("Execution time for initialization: " + ((t2 - t1) / 1000.0) + " seconds");

        String signature = signer.sign("helloworld");
        System.out.println("Signature: " + signature);
        long t3 = System.currentTimeMillis();

        System.out.println("Execution time for signing: " + ((t3 - t2) / 1000.0) + " seconds");
    }
}

Running the above code results into the following output:

Execution time for initialization: 6.258 seconds
Signature: c24e48124f5c69ec647a5147193932f2a7aef0a9362163ce0ca29da259b2047c
Execution time for signing: 0.041 seconds

We can conclude that what takes the longest is initializing and setting up the emulator, whereas the signing call only takes a fraction of a second. This is good news, since this means we can create a service where we initialize the emulator object once, and subsequent signing requests will be handled directly without the setup overhead.

Signing as a Service

Emulating the signing procedure is cool but we need to provide a programmatic interface for other applications to integrate with our unidbg signing service. There are many options, but for simplicity’s sake, we’ll create an HTTP API endpoint using Spring boot.

After adding the Spring boot dependency to our pom.xml file, we create the main Spring boot application:

package me.bhamza.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class SpringUnidbgSignerApplication {
    public static void main(String[] args) {
        SpringApplication.run(SpringUnidbgSignerApplication.class, args);
    }
}

Next, let’s create our Spring Service:

package me.bhamza.example;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Service;

@Service
public class SignerService {
    private Signer unidbgSigner;

    public SignerService(@Value("${so-file}") String so_file) {
        this.unidbgSigner = new Signer(so_file);
    }

    String sign(String message) {
        return this.unidbgSigner.sign(message);
    }
}

The Value annotation is used to automatically inject the so_file value which represents the path to the .so file we want to emulate. We can define this value by creating an application.properties file under the resources folder:

spring.application.name=unidbgsigner
so-file=/tmp/libhellosignjni.so

Finally, let’s create a controller for our signing endpoint:

package me.bhamza.example;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.*;

import java.util.Map;

@RestController
public class SignerController {
    @Autowired
    public SignerService signerService;

    @GetMapping("/")
    public String index() {
        return "Hello signer!";
    }

    @RequestMapping(path = "/sign", consumes = MediaType.APPLICATION_JSON_VALUE, method = {RequestMethod.POST})
    public String sign(@RequestBody Map<String, String> payload) {
        return signerService.sign(payload.getOrDefault("message", ""));
    }
}

@AutoWired is used to inject our unidbg signing service. Upon starting the Spring boot application, the service is instantiated. This might take a few seconds, but only on startup!

Test it out

Let’s run it and test it out:

A quick curl command to confirm it is working!

curl -H "Content-Type: application/json" --request POST --data '{"message":"hellosign"}' http://localhost:8080/sign

c15991f870f43089493b8750718e0b88e7d020e6018a7faa73b8e21f609859a6

Check out the final source code here.
Do you have questions? Want to see more? DM me.

Unidbg is an open-source framework to emulate Android native libraries (and to a certain extent has experimental iOS emulation capabilities). There are a few use cases where emulating Android libraries is beneficial. I will cover a single use case to demonstrate how to use unidbg as I believe the security and reverse engineering scene lacks English written tutorials regarding this powerful tool. This blogpost will contain a step-by-step guide on how to use unidbg along with some errors you might encounter and how to fix them.

If you have never heard of unidbg or unicorn, I would suggest reading this introductory blogpost as it contains some background information when it comes to binary analysis, reverse engineering, tooling and where unidbg fits.

Unidbg is interesting because unlike other tools, it understands and is able to emulate JNI calls such as JNI_Onload and Java_*. This means that calls to the JVM can be mocked. In addition, it supports ARM32, ARM64, filesystem, hooking (dobby, xHook), debugging and more!

Some context

In general, a mobile app communicates with a single or several backends. Developers might make it harder for third party developers, reverse engineers or hackers to integrate with their backend using various tricks including binary obfuscation, root/hook/tamper detection, TLS pinning, request & response encryption and more. Another way is by implementing a signature mechanism where each request is signed. This could look as simple as:

hmac(request payload, secret)

The backend subsequently grabs the request payload and verifies it with the shared secret. This relatively simple routine is often easily defeated by a seasoned reverse engineer. Some developers take it a step further by creating a more complex signing method and incorporate various other variables such as device ID, OS version, URL, and time. The time parameter is interesting as it prevents to a certain extent to replay requests if the adversary does not know the signing procedure and the secret.

Native Android apps are commonly written in Java/Kotlin. However, since the source code of these are often easily recoverable, developers might opt for a more obscure approach by implementing the signing mechanism in C/C++ using the Android NDK. This is done through the Java Native Interface (JNI).

Use case

Let’s say we are pentesting an Android app and its respective backend in a black-box manner. If the requests are signed, pentesting the backend is not straightforward since we first have to figure out how to sign our modified requests. In general, there are a few approaches:

1. Entirely reverse engineer the signing function: I would recommend trying this method first time-boxed. Most apps do not implement any signing method and if they do, it is quite basic. The signing method can then be re-implemented as a standalone script or as a Burp plugin.
2. Hook relevant signing function: sometimes reverse engineering and re-implementing the entire signing function can be complex and time consuming. Another approach is to use Frida or a similar hooking framework to sign custom payloads. This requires identifying the function responsible for signing payloads and figuring out a way to call it using a hooking framework with the right parameters. Brida is a nice Burp plugin that helps in these types of endeavors. The “downside” of this approach, is that you’d still need an active device in order to sign requests.
3. Emulate the signing function: this brings us to emulation, or more precisely, partial emulation. Sometimes we do not necessarily want to emulate the full app as it could be resource intensive, and/or requires bypassing other checks including emulation detection. This approach allows us to reduce our reverse engineering efforts and directly emulate the relevant signing function. Once implemented, it eleminates the need for an active device.
   Note that a major drawback of this approach is that it can get tricky to setup correctly. It is therefore important to investigate the level of obfuscation and determine the ultimate goal while keeping in mind how much time is allocated for such task.

In this blogpost, I’m going to show how to leverage unidbg and emulate an Android native library. I have created a PoC Android app based on hello-jni and hmac_sha256 that implements a YOLO signing mechanism which is going to be used as an example. Grab the APK from here to follow along.

Some reverse engineering

First, we have to determine where the signing procedure is occuring using a reverse engineering tool like Ghidra or JEB Decompiler. This might take some time to figure out with bigger and more complex apps. However, since our PoC app is small and does not have any obfuscation, it is quite straightforward. The native method modifier and an invocation call using System.loadLibrary in Java are quick giveaways that something is implemented using the JNI API. In the following recovered code, the library hellosignjni is loaded and a call to the native sign function is exposed which accepts a String as parameter:

Checking the contents of the APK file, we indeed will find a libhellosignjni.so file. In addition, the sign function implemented in C++ can be found and (partially) decompiled as well:

Note that the function name follows the convention of Java_ + package name + class name + method name. This is not always the case. For more information, see “JNI register natives”.

After a quick analysis, we can conclude that the app accepts an input string from the user, calls the native sign function with the user string as parameter. The native sign function returns a signature. This is a relatively simple routine and we could attempt to reverse engineer the signing function and re-implement it. However, for demonstration purposes, we are going to take the unidbg route.

Forking unidbg

Navigating and reviewing the test cases is arguably one of the best ways to figure out how to use unidbg:

I tend to git clone the source code from GitHub and work directly on top of the source code. Mostly because the maven repository is not updated regularly:

Let’s first clone the unidbg repository and open it using Intellij IDEA:

➜  IdeaProjects git clone https://github.com/zhkl0228/unidbg --depth 1
Cloning into 'unidbg'...
remote: Enumerating objects: 1915, done.
remote: Counting objects: 100% (1915/1915), done.
remote: Compressing objects: 100% (1351/1351), done.
remote: Total 1915 (delta 454), reused 1264 (delta 216), pack-reused 0 (from 0)
Receiving objects: 100% (1915/1915), 143.32 MiB | 506.00 KiB/s, done.
Resolving deltas: 100% (454/454), done.
Updating files: 100% (1473/1473), done.

Unidbg is written in a modular way, which is also why it might be better to create our own module. On the left side, it can be seen which modules are available within unidbg:

We’ll name our module pocsigner, use Maven, add some sample code, and set a custom GroupId:

The module depends on the unidbg-android module. We’d need to add it as a dependency in the pom.xml file of our pocsigner module:

    <dependencies>
        <dependency>
            <groupId>com.github.zhkl0228</groupId>
            <artifactId>unidbg-android</artifactId>
            <version>0.9.9-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>

Creating and configuring the emulator

Time to add a new class in our module which will contain all the signing emulation logic:

This class should extend the AbstractJni class. We’ll add a constructor to load the path of the .so file we will emulate:

package me.bhamza.example;

import com.github.unidbg.linux.android.dvm.AbstractJni;

public class Signer extends AbstractJni {
    private final String soFilePath;
    public Signer(String soFilePath) {
        this.soFilePath = soFilePath;
    }
}

I prefer to setup the emulation logic in the constructor. Unidbg provides a builder class AndroidEmulatorBuilder. Since the .so file is a 64-bit binary, we’ll create an emulator for 64-bit and set the process name the same as the package name. In addition, we’ll create a DalvikVM and set its verbosity to false. You might want to set this to true for debugging purposes. We’ll also load the shared library .so with the instantiated DalvikVM using the loadLibrary() call:

package me.bhamza.example;

import com.github.unidbg.AndroidEmulator;
import com.github.unidbg.linux.android.AndroidEmulatorBuilder;
import com.github.unidbg.linux.android.dvm.AbstractJni;
import com.github.unidbg.linux.android.dvm.DalvikModule;
import com.github.unidbg.linux.android.dvm.VM;

import java.io.File;

public class Signer extends AbstractJni {
    private final AndroidEmulator emulator;
    private final VM dalvikVM;
    private final DalvikModule dalvikModule;
    private final String soFilePath;

    public Signer(String soFilePath) {
        this.soFilePath = soFilePath;

        this.emulator = AndroidEmulatorBuilder.for64Bit().setProcessName("me.bhamza.hellojni").build();
        this.dalvikVM = emulator.createDalvikVM();
        this.dalvikVM.setVerbose(false);
        this.dalvikModule = dalvikVM.loadLibrary(new File(soFilePath), false);
    }
}

Ideally we would add some logic to check if the .so file exists and do some error handling, but we’ll leave that for now. Let’s quickly jump to the main class and instantiate our Signer class in order to start testing if our initial code works:

package me.bhamza.example;

public class Main {
    public static void main(String[] args) {
        Signer signer = new Signer("/tmp/libhellosignjni.so");
    }
}

Fixing LibraryResolver error

After running the code, we are greeted with some errors:

INFO: libhellosignjni.so load dependency libc.so failed
Sept 10, 2024 2:09:58 AM com.github.unidbg.linux.AndroidElfLoader resolveSymbols
INFO: [libhellosignjni.so]symbol ElfSymbol[name=free, type=function, size=0] is missing relocationAddr=RW@0x120d06f0[libhellosignjni.so]0xd06f0, offset=0x0

It seems like the emulator is not able to find a few dependencies (shared libraries), and therefore is not able to find certain symbols. Cross-checking with the sample test code shipped with unidbg, we notice how it is setting a library resolver. After adding this line in the constructor the error is resolved:

this.emulator.getMemory().setLibraryResolver(new AndroidResolver(23));

DvmClass and target method signature

Next we need to create a DvmClass in order to be able to interact with our target class. In addition, we need to define the signature of the sign method within the target class:

public class Signer extends AbstractJni {
    private final AndroidEmulator emulator;
    private final VM dalvikVM;
    private final DalvikModule dalvikModule;
    private final DvmClass dvmMainActivity;
    private final String sign_method_signature;
    private final String soFilePath;

    public Signer(String soFilePath) {
        this.soFilePath = soFilePath;

        this.emulator = AndroidEmulatorBuilder.for64Bit().setProcessName("me.bhamza.hellojni").build();
        this.emulator.getMemory().setLibraryResolver(new AndroidResolver(23));
        this.dalvikVM = emulator.createDalvikVM();
        this.dalvikVM.setVerbose(false);
        this.dalvikModule = dalvikVM.loadLibrary(new File(soFilePath), false);

        this.dvmMainActivity = dalvikVM.resolveClass("me/bhamza/hellosignjni/MainActivity");
        this.sign_method_signature = "sign(Ljava/lang/String;)Ljava/lang/String;";
    }
}

The signature could be manually constructed following this guide. Otherwise, use dex2jar and extract .class files. Search for the target class and run:

javap -s MainActivity.class

Another method is by using apktool d app-debug.apk which will generate smali code. We can then search for class path->method to find the complete method signature as follows:

Calling the sign method

Let’s add a sign function to our Signer class. It accepts a single String parameter (the input that needs to be signed) and returns a String (the signature):

public String sign(String message) {
}

We cannot feed parameters directly to the emulator. For that, we need to use a proxy which basically creates objects (DvmObject) for us within the DalvikVM. If you check the source code of ProxyDvmObject.createObject, you’ll notice various switch cases to handle different types including a Java String:

public String sign(String message) {
    DvmObject<?> dvm_message = ProxyDvmObject.createObject(this.dalvikVM, message);
}

Next we want to call the sign function. We can do this with the DvmClass dvmMainActivity. If you check the available methods using Intellij’s auto-complete, you’ll notice different methods. The main difference is whether the method is static or not, and what type of return value it has:

Since our method is static and returns a String (which is an Object), we’d opt for callStaticJniMethodObject. Notice how the call also returns a DvmObject. We can get the result of that object using the getValue() method:

public String sign(String message) {
    DvmObject<?> dvm_message = ProxyDvmObject.createObject(this.dalvikVM, message);
    DvmObject<String> ret_val = dvmMainActivity.callStaticJniMethodObject(emulator, sign_method_signature, message);
    return ret_val.getValue();
}

Let’s update the main function to call the Signer.sign() function with some value:

public class Main {
    public static void main(String[] args) {
        Signer signer = new Signer("/tmp/libhellosignjni.so");
        System.out.println(signer.sign("helloworld"));
    }
}

Fixing java.lang.IllegalStateException: Please vm.setJni(jni) error

After running the code again, we get the following error:

java.lang.IllegalStateException: Please vm.setJni(jni)
    at com.github.unidbg.linux.android.dvm.Hashable.checkJni(Hashable.java:8)
    at com.github.unidbg.linux.android.dvm.DvmClass.getStaticMethodID(DvmClass.java:101)
    at com.github.unidbg.linux.android.dvm.DalvikVM64$110.handle(DalvikVM64.java:1787)
    at com.github.unidbg.linux.ARM64SyscallHandler.hook(ARM64SyscallHandler.java:121)
    at com.github.unidbg.arm.backend.UnicornBackend$11.hook(UnicornBackend.java:345)
    at unicorn.Unicorn$NewHook.onInterrupt(Unicorn.java:128)
    at unicorn.Unicorn.emu_start(Native Method)

Unidbg luckily can sometimes be quite explicit on what needs to be fixed. Apparently we need to call the setJni function as follows in our constructor:

    public Signer(String soFilePath) {
        this.soFilePath = soFilePath;

        this.emulator = AndroidEmulatorBuilder.for64Bit().setProcessName("me.bhamza.hellojni").build();
        this.emulator.getMemory().setLibraryResolver(new AndroidResolver(23));
        this.dalvikVM = emulator.createDalvikVM();
        this.dalvikVM.setJni(this); // <----- ADDED
        this.dalvikVM.setVerbose(false);
        this.dalvikModule = dalvikVM.loadLibrary(new File(soFilePath), false);

        this.dvmMainActivity = dalvikVM.resolveClass("me/bhamza/hellosignjni/MainActivity");
        this.sign_method_signature = "sign(Ljava/lang/String;)Ljava/lang/String;";
    }

Fixing java.lang.UnsupportedOperationException error

When running the code again, we get another error:

java.lang.UnsupportedOperationException: java/time/LocalDate->now()Ljava/time/LocalDate;
    at com.github.unidbg.linux.android.dvm.AbstractJni.callStaticObjectMethodV(AbstractJni.java:504)
    at com.github.unidbg.linux.android.dvm.AbstractJni.callStaticObjectMethodV(AbstractJni.java:438)
    at com.github.unidbg.linux.android.dvm.DvmMethod.callStaticObjectMethodV(DvmMethod.java:59)
    at com.github.unidbg.linux.android.dvm.DalvikVM64$112.handle(DalvikVM64.java:1836)
    at com.github.unidbg.linux.ARM64SyscallHandler.hook(ARM64SyscallHandler.java:121)
    at com.github.unidbg.arm.backend.UnicornBackend$11.hook(UnicornBackend.java:345)
    at unicorn.Unicorn$NewHook.onInterrupt(Unicorn.java:128)
    at unicorn.Unicorn.emu_start(Native Method)
    at com.github.unidbg.arm.backend.UnicornBackend.emu_start(UnicornBackend.java:376)
    at com.github.unidbg.AbstractEmulator.emulate(AbstractEmulator.java:378)
    at com.github.unidbg.thread.Function64.run(Function64.java:39)
    at com.github.unidbg.thread.MainTask.dispatch(MainTask.java:19)
    at com.github.unidbg.thread.UniThreadDispatcher.run(UniThreadDispatcher.java:175)
    at com.github.unidbg.thread.UniThreadDispatcher.runMainForResult(UniThreadDispatcher.java:99)
    at com.github.unidbg.AbstractEmulator.runMainForResult(AbstractEmulator.java:341)
    at com.github.unidbg.arm.AbstractARM64Emulator.eFunc(AbstractARM64Emulator.java:262)
    at com.github.unidbg.Module.emulateFunction(Module.java:163)
    at com.github.unidbg.linux.android.dvm.DvmObject.callJniMethod(DvmObject.java:135)
    at com.github.unidbg.linux.android.dvm.DvmClass.callStaticJniMethodObject(DvmClass.java:316)
    at me.bhamza.example.Signer.sign(Signer.java:35)
    at me.bhamza.example.Main.main(Main.java:6)

Let’s check what’s at com.github.unidbg.linux.android.dvm.AbstractJni.callStaticObjectMethodV(AbstractJni.java:504):

Basically what is happening is that the compiled C/C++ code is emulated and is making calls to the Java layer through JNI. Unidbg implemented some of these calls and uses signatures to detect them. Once detected, it handles it case by case and returns the appropriate object accordingly. If it does not find the signature, it throws an UnsupportedOperationException exception since it does not know how to handle that specific call.

In our case, as can be seen in the following decompiled code, the shared library performs a call to the Java LocalDate.now() method:

Since we have previously defined our Signer class as an extension of the AbstractJni class, we can override the callStaticObjectMethodV method and implement the missing call ourselves. This looks as follow:

@Override
public DvmObject<?> callStaticObjectMethodV(BaseVM vm, DvmClass dvmClass, DvmMethod dvmMethod, VaList vaList) {
    switch (dvmMethod.getSignature()) {
        case "java/time/LocalDate->now()Ljava/time/LocalDate;":
            return ProxyDvmObject.createObject(dalvikVM, LocalDate.now());
    }
    return super.callStaticObjectMethodV(vm, dvmClass, dvmMethod, vaList);
}

We add our own signature, make a call to LocalDate.now(), wrap it with ProxyDvmObject.createObject and return it, apply the built-in signatures by unidbg by calling the parent method as a default fallback.

If we run the code, we get a similar error again but this time for the LocalDate->toString() method:

java.lang.UnsupportedOperationException: java/time/LocalDate->toString()Ljava/lang/String;
    at com.github.unidbg.linux.android.dvm.AbstractJni.callObjectMethodV(AbstractJni.java:417)
    at com.github.unidbg.linux.android.dvm.AbstractJni.callObjectMethodV(AbstractJni.java:262)
    at com.github.unidbg.linux.android.dvm.DvmMethod.callObjectMethodV(DvmMethod.java:89)
    at com.github.unidbg.linux.android.dvm.DalvikVM64$32.handle(DalvikVM64.java:559)
    at com.github.unidbg.linux.ARM64SyscallHandler.hook(ARM64SyscallHandler.java:121)
    at com.github.unidbg.arm.backend.UnicornBackend$11.hook(UnicornBackend.java:345)
    at unicorn.Unicorn$NewHook.onInterrupt(Unicorn.java:128)
    at unicorn.Unicorn.emu_start(Native Method)
    at com.github.unidbg.arm.backend.UnicornBackend.emu_start(UnicornBackend.java:376)
    at com.github.unidbg.AbstractEmulator.emulate(AbstractEmulator.java:378)
    at com.github.unidbg.thread.Function64.run(Function64.java:39)
    at com.github.unidbg.thread.MainTask.dispatch(MainTask.java:19)
    at com.github.unidbg.thread.UniThreadDispatcher.run(UniThreadDispatcher.java:175)
    at com.github.unidbg.thread.UniThreadDispatcher.runMainForResult(UniThreadDispatcher.java:99)
    at com.github.unidbg.AbstractEmulator.runMainForResult(AbstractEmulator.java:341)
    at com.github.unidbg.arm.AbstractARM64Emulator.eFunc(AbstractARM64Emulator.java:262)
    at com.github.unidbg.Module.emulateFunction(Module.java:163)
    at com.github.unidbg.linux.android.dvm.DvmObject.callJniMethod(DvmObject.java:135)
    at com.github.unidbg.linux.android.dvm.DvmClass.callStaticJniMethodObject(DvmClass.java:316)
    at me.bhamza.example.Signer.sign(Signer.java:45)
    at me.bhamza.example.Main.main(Main.java:6)

As you might have guessed, the signing function incorporates a date in its algorithm. This time, we need to override the callObjectMethodV method:

@Override
public DvmObject<?> callObjectMethodV(BaseVM vm, DvmObject<?> dvmObject, String signature, VaList vaList) {
    switch (signature) {
        case "java/time/LocalDate->toString()Ljava/lang/String;":
            // System.out.println(dvmObject.getValue().toString()); // print the date
            return new StringObject(dalvikVM, dvmObject.getValue().toString());
    }
    return super.callObjectMethodV(vm, dvmObject, signature, vaList);
}

After running the code for a final spin, the following is printed on screen:

0e1ec4b1498b140528385a8e872bcdfce985c9f51933e8f8542c7e253042cfe7

It is always a good idea to cross-check values with the real app and see if the generated value corresponds to the one from the app. It seems like we have successfully emulated the shared Android library!

Check out the final source code here.
Do you have questions? Want to see more? DM me.

gRPC is getting increasingly popular and as a result, it is encountered more often during security assessments. In this blog post, I explain the different approaches to security test gRPC services depending on the type of assessment. At the end, I will show how to extend the blackboxprotobuf Burp extension to support gRPC-web.

gRPC 101

gRPC is an open source high performance Remote Procedure Call (RPC) framework. It allows developers to write a service definition using Protocol Buffers. The following service definition is a simple example as demonstrated in the gRPC documentation:

// The greeter service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

It is then possible to automatically generate client and server stubs in a variety of languages:

The data exchanged between services is serialized. The serialization depends on the developer’s choice, however by default it is protobuf. Protobuf is a binary data format. Using it is ideal for performance, but it can cause certain hurdles when trying to security assess systems using such protocols.

Security assessments on systems using gRPC

As part of a security assessment, the auditor will try various ways to find security vulnerabilities in the target application. Usually an intercepting proxy software is used to monitor and modify traffic between the client and the server. Since the traffic for gRPC services might be binary due to the usage of protobuf, making sense out of the traffic or modifying it becomes a challenge. This is mainly due to the fact that the protobuf binary encoding strips most type and field information. Having the service definitions (protobuf files) at hand will allow for easy inspection and modification of traffic. However, in practice this is not always the case and depends on the nature of the assessment:

White box

During a white box security assessment, documentation and source code is shared with the auditor. This means that common tools can be used to interact with gRPC services. A good example is Postman, which since 2022, supports gRPC. It is almost always advised to put an intercepting proxy such as Burp Suite in-between to keep a history of traffic. In addition, tools like Burp Suite allows for traffic modification and has a myriad of offensive capabilities compared to Postman. A typical setup would look as follow:

Grey box

Sometimes companies are reluctant to share source code and prefer to have the security engagement performed with limited information. Often this means that user accounts are provided. Sometimes (minimal) documentation is provided as well. It is best to convince the client beforehand to provide at least the gRPC service definition files if a complete source code review is off the table. More often than not, clients are willing to share protobuf files for a better testing coverage. This means that the same setup can be used as the one used during a white box assessment. Otherwise, refer to the black box approach as described next.

Black box

Although not ideal, sometimes clients are not willing to share source code or service definition files. Attacking gRPC based services can get tricky in such cases, but not impossible. Here are a few ways:

• Reflection / introspection: occasionally, developers forget or knowingly leave gRPC server reflection enabled (protip: do some recon for tst/acc environments where reflection might be enabled). This allows clients that do not have the service definition files to query the server for RPC requests and responses, similar to GraphQL introspection. Postman supports gRPC server reflection, which enables testing in a similar fashion as described in the white-box approach.
• Reversing / hooking: If experience in reverse engineering is available, then reversing the generated RPC methods in the target client might also be an option. The RPC methods are often not obfuscated. A quick search for “grpc” in an Android app, might already reveal some interesting functions to hook: Next, use an instrumentation framework like Frida to hook the methods of interest and dynamically change values in memory. The Brida Burp extension might help in this endeavor.
• Blackbox protobuf: The NCC Group released the Blackbox protobuf repository. It allows for working with protobuf messages without having access to the service definition file. It can be used as a Python library or installed as a Burp extension. You might wonder how is this possible without a protobuf file? It basically tries to parse protobuf data and makes a best effort to guess the type. The field name cannot be recovered as it is lost during serialization. It is not ideal, but it is better than nothing as it can recover most/general structures. After following the exact installation instructions for BBPB for Burp Suite, a new tab can be noticed on requests & responses that contain a protobuf message: Sometimes, the wrong type is guessed. In one instance, it interpreted a double as an integer. I knew this from the context of the application as I was testing and expecting latitude and longitude coordinates. Luckily, BBPB allows to manually edit types: Finally, some applications might use protobuf but the BBPB Burp extension does not detect it. This is true for example when gRPC-web is used. Fortunately, BBPB is flexible and can be extended.

Extending Black Box protobuf to support gRPC-web

The BBPB extension can be extended by editing the user_funcs.py file which contains various functions.

The detect_protobuf function is used to help BBPB identify a request/response containing protobuf data. The BBPB protobuf tab appears in the request/response if this function returns True. The protobuf tab does not appear if it returns False. If None is returned, the standard BBPB detection routine is performed. In the case of gRPC-web, searching for a content-type header containing application/grpc-web-text suffices:

def detect_protobuf(content, is_request, content_info, helpers):
    """Function used to display the protobuf tab, three return values are possible:
    - Return true if it's protobuf,
    - Return false if it's not protobuf,
    - Return None to fallback to the built-in header detection mechanism
    """
    for header in content_info.getHeaders():
        if 'content-type' in header.lower() and 'application/grpc-web-text' in header.lower():
            return True
    return None

Next is the get_protobuf_data function. BBPB retrieves by default the protobuf data from the body of the request/response. Data encoding is a bit different in the case of gRPC-web. The comment on grpc/grpc-web#634 gives a good explanation on how to do this:

The payload is base64-encoded. So the first step is to base64-decode it. After that, you get a series of bytes that’s arranged in the “grpc-web” wire format, which is spec’ed out here:

• https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md#protocol-differences-vs-grpc-over-http2.

So in general it goes “marker” “4 bytes denoting length” “X bytes of data / trailer”, and repeat.

A simplified visual representation looks as follows:

Implementing the above logic is straightforward in Python:

def get_protobuf_data(content, is_request, content_info, helpers, request=None, request_content_info=None):
    """Retrieve protobuf data:
    1. Check for content type header and if it's 'application/grpc-web'
    2. Base64 decode payload
    3. Parse data length from bytes position 1,2,3,4 (position 0 denotes the marker)
    4. Retrieve data from position 5 up to (position 5 + data length)
    """
    for header in content_info.getHeaders():
        if 'content-type' in header.lower() and 'application/grpc-web' in header.lower():
            data = base64.b64decode(content[content_info.getBodyOffset():].tostring())
            protobuf_data_len = struct.unpack('>I', data[1:5])[0]
            return data[5:protobuf_data_len+5]

Consequently when changing data in the BBPB protobuf tab, it needs to somehow know how to reconstruct the protobuf data back to the encoded form (in this case gRPC-web). The reverse process is therefore applied as follows:

def set_protobuf_data(protobuf_data, content, is_request, content_info, helpers, request=None, request_content_info=None,):
    """Set protobuf data in case the request is edited:
    1. Check for content type header and if it's 'application/grpc-web'
    2. Calculate data length and encode it in bytes, prefix it with the marker
    3. Concatenate the marker + encoded data length and data
    4. Encode everything in base64
    """
    
    for header in content_info.getHeaders():
        if 'content-type' in header.lower() and 'application/grpc-web' in header.lower():
            protobuf_data_prefix = "\x00" + struct.pack('>I', len(protobuf_data))
            return helpers.buildHttpMessage(content_info.getHeaders(), base64.b64encode(protobuf_data_prefix + protobuf_data))

The complete script can be found in the following repository bbpb-grpc-web.

For a project, I needed to decompile programmatically certain classes from an Android APK file. Usually this is done by first extracting the DEX file using apktool, then converting it to a JAR file using dex2jar, and finally decompiling it using tools like JAD or CFR.

In order to compare results from various decompilers, I wanted to add JEB decompiler to the mix. JEB provides a scripting interface and allows scripts to be executed either through CLI or GUI.

Sample default decompilation script

A good thing about JEB is that it provides several template scripts under:

INSTALL_DIR/scripts/samples

One particular script stood out, as its name implies DecompileFile.py. The class contains two methods: a default run method which is the entry point of the script and a decompileCodeUnit method.

Run method explained

The run method performs the following:

1) Has two flags to decompile DEX or native units (or not)

self.decompileDex = False
self.decompileNative = False

2) Checks if the script is run from CLI or GUI to setup required arguments

if isinstance(ctx, IGraphicalClientContext):
  self.outputDir = ctx.displayFolderSelector('Output folder')
  if not self.outputDir:
    print('Need an output folder')
    return
else:
  argv = ctx.getArguments()
  if len(argv) < 2:
    print('Provide an input file and the output folder')
    return
  inputFile = argv[0]
  self.outputDir = argv[1]
  print('Processing file: %s...' % inputFile)
  ctx.open(inputFile)

3) Iterates through code units and calls the decompileCodeUnit per code unit

prj = ctx.getMainProject()
assert prj, 'Need a project'

t0 = time.time()
print('Exectime: %f' % exectime)

decompileCodeUnit explained

The decompileCodeUnit subsequently accepts a code unit and performs the following:

1) Checks if the unit is processed, if not, then process it

if not codeUnit.isProcessed():
  if not codeUnit.process():
    print('The code unit cannot be processed!')
    return

2) In JEB, each unit type (bytecode, binary code, etc…) has its own decompiler, therefore a helper is used to retrieve the appropriate helper

decomp = DecompilerHelper.getDecompiler(codeUnit)
if not decomp:
  print('There is no decompiler available for code unit %s' % codeUnit)
  return

3) Output folder is designated and some filtering is applied depending on flags defined previously

outdir = os.path.join(self.outputDir, codeUnit.getName() + '_decompiled')
print('Output folder: %s' % outdir)  # created only if necessary, i.e. some contents was exported

if not((isinstance(codeUnit, INativeCodeUnit) and self.decompileNative) or (isinstance(codeUnit, IDexUnit) and self.decompileDex)):
  print('Skipping code unit: %s' % UnitUtil.buildFullyQualifiedUnitPath(codeUnit))
  return

4) Next, a DecompilerExporter object is created. Probably the most interesting part of this script as several options can be configured including:

1. an output folder for where to save the decompiled code.
2. a timeout for method decompilation.
3. a timeout for the entire decompilation process.
4. a progress callback, useful to log for example the progress of the decompilation process.

exp = decomp.getExporter()
exp.setOutputFolder(IO.createFolder(outdir))
exp.setMethodTimeout(1 * 60000)
exp.setTotalTimeout(15 * 60000)
class DecompCallback(ProgressCallbackAdapter):
  def message(self, msg):
    print('%d/%d: %s' % (self.getCurrent(), self.getTotal(), msg))
exp.setCallback(DecompCallback())

5) Finally, the decompilation is kickstarted. Good to know is that export is a synonym to process

if not exp.export():
  cnt = len(exp.getErrors())
  i = 1
  for sig, err in exp.getErrors().items():
    print('%d/%d DECOMPILATION ERROR: METHOD %s: %s' % (i, cnt, sig, err))
    i += 1

Tweaking the script

The provided template is a good start. I needed to introduce a few tweaks for my needs.

1) The first of which is to enable decompilation for DEX

self.decompileDex = True
self.decompileNative = False

2) For relatively huge apps, I needed to remove the timeout for the total decompilation process

# DecompilerExporter object
exp = decomp.getExporter()
exp.setOutputFolder(IO.createFolder(outdir))
# limit to 1 minute max per method
exp.setMethodTimeout(1 * 60000)
# limit to 15 minutes (total)
# exp.setTotalTimeout(2 * 60000)

I left the method timeout in case a method is too big/complex.

3) Since the target app is relatively big and I only needed specific packages to be decompiled, I added a pattern matcher using the setSignaturePattern method. It accepts a compiled regex using a Pattern object.

from java.util.regex import Pattern
# ... omitted ...
pattern = Pattern.compile(".*/(cash|ali).*")
exp.setSignaturePattern(pattern)
# set a callback to output real-time information about what's being decompiled
class DecompCallback(ProgressCallbackAdapter):
  def message(self, msg):
    print('%d/%d: %s' % (self.getCurrent(), self.getTotal(), msg))
exp.setCallback(DecompCallback())
# decompile & export
if not exp.export(): # process

Concluding

Without the introduced tweaks, the script would timeout and barely decompile anything interesting. Commenting out the timeout for the entire decompilation process solved that problem. However, the decompilation took forever on my target app and eventually led to JEB crashing. Luckily, there’s a way to reduce the amount of work by matching only classes/methods that are of interest.

The final customized script can be found on GitHub. It can be placed under the scripts folder and called from GUI, or from the CLI:

~/tools/jeb/jeb_macos.sh -c --srv2 --script=/path/to/DecompileFileCustom.py -- /path/to/base.apk /path/to/decompile/folder

In a previous blogpost, I’ve written how to combine Gnirehtet & proxychains in order to intercept traffic from mobile apps over adb while on a VPN. After some time, the setup seemed to be somewhat buggy and slow. A contact of @FSDominguez suggested to look into port forwarding. I’d like to present a revised adb reverse tethering MITM setup.

adb reverse

The Android Debug Bridge (ADB) command-line tool provides several utilities such as performing shell commands on the device, (un)installing apps, pushing/pulling files and port forwarding. Speaking of port forwarding, there’s a nifty yet relatively less known command adb reverse which essentially allows us to create a reverse proxy by forwarding requests on a port on the mobile device to a port available on the host.

A quick hands-on example:

adb reverse tcp:4444 tcp:8888
echo "hello world" > index.php
php -S 127.0.0.1:8888

The last command launches a PHP web server listening on port 8888 (localhost). Opening 127.0.0.1:4444 in a web browser on the mobile device gives us:

Installation steps of the revised setup

Since Android is based on Linux, it is possible to use iptables in combination with adb reverse in order to forward all traffic from mobile apps to the host device. Note that this requires root access and a transparent intercepting proxy.

1. Install an intercepting HTTP proxy, configure it to listen on incoming connections and make sure to enable “transparent proxy”; Example: 127.0.0.1:8844. In Burp Suite, go to Proxy > Options > Edit or add a proxy > Request handling > check “Support invisible proxying”.

2. Connect your phone to your host using a USB cable.
3. Perform the following command on your host: adb reverse tcp:8844 tcp:8844
4. Connect your mobile device to any WiFi network.
5. Next we need to perform administrative commands on the device:

   adb shell            # to perform commands on the device
   su                   # switch to root
   iptables -t nat -F   # flush current rules
   # forward traffic from port 80 & 443 to 8844
   iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 127.0.0.1:8844
   iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:8844
   iptables -t nat -A POSTROUTING -p tcp --dport 80 -j MASQUERADE 
   iptables -t nat -A POSTROUTING -p tcp --dport 443 -j MASQUERADE
   

   ⚠️ if you suspect that your target app performs requests on other ports than 80 and 443, adjust above commands accordingly.

6. In order to see HTTPS traffic in your intercepting proxy, you will need to install a CA certificate on the Android device. Checkout some of NVISO’s blogposts 1 & 2 and of course the manual of your favorite intercepting proxy.
7. To reset and restore your setup:

   adb reverse --remove-all
   adb shell
   su
   iptables -t nat -F
   

Automation

I’ve automated above setup and commands in my Frida Android Helper tool. Just run fah rproxy and you’re good to go!

Traditionally, to inspect traffic for Android apps, the mobile phone and the security analyst’s PC are connected to the same Wi-Fi hotspot. The proxy settings on the mobile phone are configured to point to the analyst’s PC. Typically, an intercepting software such as Burp Suite Pro is configured on the PC to listen on all incoming connections.

This is the simplest setup that should work in most cases. However, in some cases, the previously mentioned setup is not ideal. Consider the case where the analyst’s PC is using a corporate VPN which isolates the PC and blocks all incoming connections from the mobile phone on the same network:

In addition, sometimes it is required to perform a pentest from the corporate IP range, therefore traffic should pass through the analyst’s intercepting software and go through the corporate VPN. In such case, a new setup needs to be prepared.

In this blogpost, I am going to present a setup using Gnirehtet and proxychains.

The setup

Recently I have bumped into Gnirehtet, a project that provides reverse tethering over adb. This allows the Android device to use the internet connection of a PC over adb. The project has two components: an Android APK (client) and a relay server. The relay server has two flavours: Java & Rust. The main difference being that Rust consumes less CPU/memory.

Next, the traffic needs be routed to Burp. I thought of using proxychains for the job. It is a tool that hooks network-related functions to redirect traffic to a proxy according to a configuration file.

Trying to use proxychains with the Java version of Gnirehtet does not work. This is mainly due to the fact that the Java program runs in the Java Virtual Machine (JVM). Proxychains works by hooking libc networking-related functions in dynamically linked programs and is therefore not able to hook the Java Gnirehtet program. For this reason, this setup is going to make use of the Rust version of Gnirehtet (in addition of the performance gain).

Installation steps

1. Install an intercepting HTTP proxy and configure it to listen on incoming connections. Example: 127.0.0.1:8888.
2. Install proxychains. Depending on the platform you are on, this might be as simple as brew install proxychains-ng on MacOS. Otherwise, follow the compilation/installation instructions on GitHub.
3. Grab the latest release of Gnirehtet. MacOS users need to Install Rust in order to compile the program themselves as it is unavailable on the releases page.

   $ git clone https://github.com/Genymobile/gnirehtet
   $ cd gnirehtet/relay-rust
   $ cargo build --release
   

4. Install the Gnirehtet client adb install gnirehtet.apk on the Android device.
5. Create a proxychains configuration file next to the Rust relay server executable with the following content:

   $ cat proxychains.conf
   [ProxyList]
   http 127.0.0.1 8888
   

   Note that depending on the used proxy, it is possible to use other protocols such as socks4 instead of http.

6. Start the relay server using proxychains: proxychains4 -f ./proxychains.conf ./gnirehtet relay.
7. In another terminal, start the Android client: ./gnirehtet start.
8. Note that in order to see HTTPS traffic in your intercepting proxy, you will need to install a CA certificate on the Android device.

In Android land, it is possible to protect specific components (ex: activities) from being screenshotted. This is achieved by adding the FLAG_SECURE flag on the desired component:

FLAG_SECURE

public static final int FLAG_SECURE

Window flag: treat the content of the window as secure, preventing it from appearing in screenshots or from being viewed on non-secure displays.

A typical implementation from the app’s perspective looks as follows:

// https://stackoverflow.com/a/9822607
public class FlagSecureTestActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        getWindow().setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE);

        setContentView(R.layout.main);
    }
}

This means that if we want to be able to take a screenshot, we need to disable this feature. In this blogpost I’ll demonstrate a few Frida hooking techniques and patterns along the way to achieve this goal.

Note: In Android, there’s also a SurfaceView which has the method setSecure(). The techniques explained here should also work for SurfaceViews.

The usual hooking pattern

I’ve noticed that most hooks try to disable the FLAG_SECURE attribute by hooking the setFlags() function. Instead of adding the FLAG_SECURE flag, it is removed. Below is a sample xposed hook:

@Override
public void handleLoadPackage(XC_LoadPackage.LoadPackageParam loadPackageParam) throws Throwable {
    // Hook into "setFlags" method in the "Window" class, and replace it with our custom setFlags method
    XposedHelpers.findAndHookMethod(Window.class, "setFlags", int.class, int.class, mRemoveSecureFlagHook);
}

// Custom setFlags hook
private final XC_MethodHook mRemoveSecureFlagHook = new XC_MethodHook() {
    @Override
    protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
        Integer flags = (Integer) param.args[0]; // Get current state of flags
        flags &= ~WindowManager.LayoutParams.FLAG_SECURE; // Substract the FLAG_SECURE value
        param.args[0] = flags; // Update it
    }
};

In Frida, this looks as follows:

1. Java.perform(function () {
2.     // https://developer.android.com/reference/android/view/WindowManager.LayoutParams.html#FLAG_SECURE
3.     var FLAG_SECURE = 0x2000;
4.     var Window = Java.use("android.view.Window");
5.     var setFlags = Window.setFlags;  //.overload("int", "int")
6.
7.     setFlags.implementation = function (flags, mask) {
8.         console.log("Disabling FLAG_SECURE...");
9.         flags &= ~FLAG_SECURE;
10.        setFlags.call(this, flags, mask);
11.        // Since setFlags returns void, we don't need to return anything
12.    };
13. });

1. In (3) we define a FLAG_SECURE variable, this flag is a constant and can be found in the documentation (2).
2. In (4) we create a bridge to interface with the Window Android class.
3. In (5) we create a bridgee to interface with the setFlags method. Note that if this method had several overloads, it would have been necessary to specify which overload to choose by using var setFlags = Window.setFlags.overload("int", "int");. In this case, since there’s only one method called setFlags in the Window class, it is not nessecary.
4. In (7) we hook the setFlags method with our own implementation.
5. In (9) we modify the flags variable by substracting the FLAG_SECURE flag. These are basic bitwise operations in one line.
6. In (10) we finally call the original setFlags method with the modified flags value (ie: with no FLAG_SECURE flag).

The application can then be spawned as follows:

frida -U -l usual_flagsecure_disable.js -f com.example.app --no-pause

     ____
    / _  |   Frida 12.7.11 - A world-class dynamic instrumentation toolkit
   | (_| |
    > _  |   Commands:
   /_/ |_|       help      -> Displays the help system
   . . . .       object?   -> Display information about 'object'
   . . . .       exit/quit -> Exit
   . . . .
   . . . .   More info at https://www.frida.re/docs/home/
Spawned `com.example.app`. Resuming main thread!
[Xiaomi Mi A2::com.example.app]-> Disabling FLAG_SECURE...
Disabling FLAG_SECURE...
Disabling FLAG_SECURE...
Disabling FLAG_SECURE...

When the app is already running…

The above hook is used when spawning an app. This means that our hook can intercept the target function on time. But what if the app is already running and we try to attach to the app? Well since the activity is already initialized, the target function will not be called and therefore our hook will not get triggered. How do we proceed further?

With Frida, we can scan the heap for objects (class instances) with the Java.choose() method:

Java.perform(function() {
    Java.choose("com.example.app.FlagSecureTestActivity", {
        "onMatch": function (instance) {
            console.log("Found instance of FlagSecureTestActivity: " + instance);
        },
        "onComplete": function () {
        }
    });
});

With this we can access the Window object from within the activity!

Java.perform(function() {
    Java.choose("com.example.app.FlagSecureTestActivity", {
        "onMatch": function (instance) {
            console.log("Found instance of FlagSecureTestActivity: " + instance);
            console.log(instance.getWindow());
        },
        "onComplete": function () {
        }
    });
});

Now what if we try to call the setFlags() from the Window object?

Java.perform(function() {
    var FLAG_SECURE = 0x2000;

    Java.choose("com.example.app.FlagSecureTestActivity", {
        "onMatch": function (instance) {
            console.log("Found instance of FlagSecureTestActivity: " + instance);
            console.log(instance.getWindow());
            instance.getWindow().setFlags(0, FLAG_SECURE);
        },
        "onComplete": function () {
        }
    });
});

Notice we use -n to attach to the app instead of spawning:

frida -U -l run_flagsecure_disable.js -n com.example.app --no-pause
     ____
    / _  |   Frida 12.7.11 - A world-class dynamic instrumentation toolkit
   | (_| |
    > _  |   Commands:
   /_/ |_|       help      -> Displays the help system
   . . . .       object?   -> Display information about 'object'
   . . . .       exit/quit -> Exit
   . . . .
   . . . .   More info at https://www.frida.re/docs/home/
Attaching...

Found instance of FlagSecureTestActivity: com.example.app.FlagSecureTestActivity@3cb1848

com.android.internal.policy.PhoneWindow@aedcd6f

Error: android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
    at frida/node_modules/frida-java-bridge/lib/env.js:120
    at input:1
    at /run_flagsecure_disable.js:49
    at chooseObjectsArtModern (frida/node_modules/frida-java-bridge/lib/class-factory.js:42)
    at frida/node_modules/frida-java-bridge/lib/class-factory.js:153
    at ve (frida/node_modules/frida-java-bridge/lib/android.js:377)
[Xiaomi Mi A2::com.example.app]->

This results into an interesting error message: Only the original thread that created a view hierarchy can touch its views.

The first Google search result brings us to this Stackoverflow thread which suggest to move the code responsible for UI changes on the UI thread by calling Activity.runOnUiThread():

runOnUiThread(new Runnable() {
    @Override
    public void run() {
        // Change UI
    }
});

So how do we implement above Java code with Frida? We need a custom implementation of the Runnable interface. Luckily we can create custom classes in Frida too using the Java.registerClass() method:

1. Java.perform(function() {
2.     // https://developer.android.com/reference/android/view/WindowManager.LayoutParams.html#FLAG_SECURE
3.     var FLAG_SECURE = 0x2000;
4.
5.     var Runnable = Java.use("java.lang.Runnable");
6.     var DisableSecureRunnable = Java.registerClass({
7.         name: "me.bhamza.DisableSecureRunnable",
8.         implements: [Runnable],
9.         fields: {
10.             activity: "android.app.Activity",
11.         },
12.         methods: {
13.             $init: [{
14.                 returnType: "void",
15.                 argumentTypes: ["android.app.Activity"],
16.                 implementation: function (activity) {
17.                     this.activity.value = activity;
18.                 }
19.             }],
20.             run: function() {
21.                 var flags = this.activity.value.getWindow().getAttributes().flags.value; // get current value
22.                 flags &= ~FLAG_SECURE; // toggle it
23.                 this.activity.value.getWindow().setFlags(flags, FLAG_SECURE); // disable it!
24.                 console.log("Done disabling SECURE flag...");
25.             }
26.         }
27.     });
28.
29.     Java.choose("com.example.app.FlagSecureTestActivity", {
30.         "onMatch": function (instance) {
31.             var runnable = DisableSecureRunnable.$new(instance);
32.             instance.runOnUiThread(runnable);
33.         },
34.         "onComplete": function () {}
35.     });
36. });

1. Whenever trying to hook on the Java layer, we need to encapsulate our hooking code in Java.perform(function() {}); (1).
2. We create a bridge to interface with the Runnable class (5).
3. We create our own custom class (6), give it a name (7) and specify that it implements the Runnable interface (8).
4. Since we need a reference to the activity we want to hook, we add a new field called activity (9-11). We will “inject” the target activity via the constructor (13).
5. We implement our own methods (12), the first one being our constructor which is denoted with $init (13) and the second one being run (14) to conform to the Runnable interface.
6. Our custom run method will contain logic to edit the flags value and remove the FLAG_SECURE flag (20-25).
7. From line (29), we’ll do the same as mentioned previously, scan the heap for an instance of the target activity, if there’s a match (30), we’ll instantiate an instance of our custom Runnable class (31) and call the runOnUiThread() method with it.

Launching the app and then attaching our hook gives us the following result:

frida -U -l run_flagsecure_disable.js -n com.example.app --no-pause
     ____
    / _  |   Frida 12.7.11 - A world-class dynamic instrumentation toolkit
   | (_| |
    > _  |   Commands:
   /_/ |_|       help      -> Displays the help system
   . . . .       object?   -> Display information about 'object'
   . . . .       exit/quit -> Exit
   . . . .
   . . . .   More info at https://www.frida.re/docs/home/

[Xiaomi Mi A2::com.example.app]-> Done disabling SECURE flag...

It is now possible to take screenshots on the opened activity.

fah screen

Above hook is actually part of a tool Frida Android Helper; a side project to automate certain repetitive tasks during mobile app pentests. By invoking fah screenshot command, the tool will try to take a screenshot via the ADB screencap command. If this fails, the current opened app and activity is fetched with some ADB/grep-fu:

def get_current_app_focus(device: Device):
    # Sample: mCurrentFocus=Window{127ced0 u0 com.android.launcher3/com.android.searchlauncher.SearchLauncher}
    # When locked: mCurrentFocus=Window{8f41b66 u0 StatusBar}
    result = perform_cmd(device, "dumpsys window windows | grep mCurrentFocus")

    currentFocus = result.strip("\r\n{}").split(" ")[-1]
    if "/" in currentFocus:
        return currentFocus.split("/")
    else:
        print("⚠️  Device might be locked... (mCurrentFocus={})".format(currentFocus))
        return [currentFocus, ""]

The result (app ID + path to activity class) is passed to another function which sets Frida up, attaches to the app using the app ID, injects our hook and sends an RPC command with the activity to hook:

def disable_secure_flag(device, pkg_name, activity_name):
    js_code = get_js_hook("disable_secure_flag.js")
    device = frida.get_device(device.get_serial_no())
    session = device.attach(pkg_name)
    script = session.create_script(js_code)
    script.on("message", message_callback)
    script.load()
    script.exports.disablesecureflag(activity_name)

The previously written Frida script is wrapped around an RPC call which can be called from the Python side. For more information see Frida RPC and the Frida Android Helper source code.

Certain mobile app pentests are done on a recurrent basis (Agile security). Some of these pentests have common repeating tasks. Since repetition is boring, we want to automate as much as possible.

In this article, I want to demonstrate how to automatically generate Frida hooks using JEB. The demo use case consists of generating a Frida hook to bypass the TLS pinning for OkHttp. Sometimes the library is obfuscated in the target API, making hooks similar to the following unusable:

var CertificatePinner = Java.use('okhttp3.CertificatePinner');

When the target APK does not obfuscate strings, it is possible to search for known strings in JEB to find the target class quickly. For OkHttp, a good magic string candidate is “Certificate pinning failure!”:

The process of manually searching for the magic string and adjusting the frida hook (class path + method name) could be automated using JEB’s scripting API.

JEB Script basic anatomy

It is possible to extend and/or leverage JEB’s functionalities using JEB scripts and plugins. The documentation suggests scripts for automating simple tasks. The scripts are written in Python and saved in the jeb_dir/scripts/ folder. Jython is used to bridge the gap between Python and Java (JEB is a Java based app). The structure of a JEB script looks as follow:

# -*- coding: utf-8 -*-
from com.pnfsoftware.jeb.client.api import IScript, IGraphicalClientContext
from com.pnfsoftware.jeb.core import Artifact

from java.io import File

class GenerateFridaHooks(IScript):
    def run(self, ctx):
        print(u"🔥 JEB scripting")

The first line is used to set the encoding. When using UTF-8 strings, make sure to append the u prefix to your strings. Next are the imports. Notice how you can use Java imports. Finally, there’s your class definition which extends IScript. This class has a method run which is obviously run everytime the script is invoked.

JEB Script CLI vs GUI

JEB scripts can be invoked from both the desktop client or via the command line. If the script is saved in jeb_dir/scripts/ folder, then it is possible to invoke the script by navigating to File > Scripts > Registered > script name.

From the command line, navigate to the JEB folder, depending on the operating system you’re using, you’ll need to use the appropriate bash file:

• On Windows: jeb_wincon.bat
• On Linux: jeb_linux.sh
• On Mac OSX: jeb_macos.sh

To invoke the custom plugin, use:

./jeb_macos.sh -c --srv2 --script=GenerateFridaHooks.py -- "/path/to/target.apk"

Everything after -- are arguments passed to the script which can be retrieved from the context variable ctx.getArguments().

JEB has the concept of Project(s) which contains Artifact(s). When an APK file is opened in the JEB desktop client, a project is created. From the command line, a project needs to be created manually. To support both CLI and GUI, we can check the instance of the context variable:

def run(self, ctx):
    # Hello world
    print(u"🔥 JEB scripting")

    # If the script is run in JEB GUI
    if isinstance(ctx, IGraphicalClientContext):
        project = ctx.getMainProject()
    else:  # assume command line & create a tmp project
        argv = ctx.getArguments()
        if len(argv) < 1:
            print('[-] Did you forget to provide the APK file?')
            return
        self.inputApk = argv[0]

        # Init engine
        engctx = ctx.getEnginesContext()
        if not engctx:
            print('[-] Back-end engines not initialized')
            return

        # Create a project
        project = engctx.loadProject('JebFridaHookProject')
        if not project:
            print('[-] Failed to open a new project')
            return
        
        # Add artifact to project
        artifact = Artifact('JebFridaHookArtifact', FileInput(File(self.inputApk)))
        project.processArtifact(artifact)

Processing DEX with the JEB API

A JEB project can contain several different type of files (units). Since we’re only interested in DEX units, it is possible to search for them specifically:

# loop through all dex files in project & search
for dex in project.findUnits(IDexUnit):
    pass

To find the specific class and method of interest, I’ve opted for a naïve signature based algorithm:

1. Search for the unique magic string such as “Certificate pinning failure!” in OkHttp’s case;
2. Get the class where the string resides and extract the class path;
3. Loop through each method of the above class, and check if the parameters matches our signature;
4. Optionally check the return value.

In the case of OkHttp, finding and hooking findMatchingPins(String hostname) could be done by simply iterating through the target class and checking if the parameter is a single String. We can do this in a modular way:

def do_search(self, dex_unit, needle, params, retval = None):
    results = []
    # find string in DEX
    dex_index = dex_unit.findStringIndex(needle)
    # cross reference string, most probably used by the same class
    for ref in dex_unit.getCrossReferences(DexPoolType.STRING, dex_index):
        # get class name
        # getInternalAddress() returns something like Lcom/squareup/okhttp/CertificatePinner;->check(Ljava/lang/String;Ljava/util/List;)V+50h
        fqname = ref.getInternalAddress().split('->')[0]
        # get class (IDexClass)
        clazz = dex_unit.getClass(fqname)
        # From signature to class path
        # Lcom/squareup/okhttp/CertificatePinner; -> com.squareup.okhttp.CertificatePinner
        class2hook = clazz.getSignature()[1:-1].replace("/", ".")
        # loop through each method; check params & retval
        for method in clazz.getMethods():
            if retval is not None and method.getReturnType().getSignature() != retval: continue
            if self.list_cmp(params, [str(m.getSignature()) for m in method.getParameterTypes()]):
                method2hook = method.getName()
                results.append( {"class": class2hook, "method": method2hook})
    return results

# is there a better way? PR/PM please!
def list_cmp(self, a, b):
    if len(a) != len(b): return False
    for x, y in zip(a, b):
        if x != y: return False
    return True

The do_search function expects a DEX unit, a needle to search for, an array of parameters that we’re looking for and optionally a return value to match against. The function returns an array of dictionaries matching the provided signature. A dictionary contains a class path and a method name.

Putting it all together

First we’ll create three variabes: an array which will contain separate Frida hooks, a Frida main template variable and an OkHttp Frida hook template:

class GenerateFridaHooks(IScript):
    frida_hooks = []
    frida_hook_file = u"""'use strict';
    // Usage: frida -U -f com.example.app -l generated_hook.js --no-pause
    Java.perform(function() {\{
        {hooks}
    }
    }});
    """
    frida_okhttp3_hook = u"""
        var okhttp3_CertificatePinner{idx} = Java.use('{java_class}');
        var findMatchingPins{idx} = okhttp3_CertificatePinner{idx}.{java_method}.overload('java.lang.String');
        findMatchingPins{idx}.implementation = function(hostname) {\{
            console.log('[+] okhttp3.CertificatePinner.findMatchingPins(' + hostname + ') # {java_class}.{java_method}()');
            return findMatchingPins{idx}.call(this, ''); // replace hostname with empty string
        }}; """

Next, in the run() method, we’ll add code that calls the do_search function with the appropriate parameters to generate our hooks:

def run(self, ctx):
    # Hello world
    print(u"🔥 JEB scripting")

    # [ ... init project GUI&CLI code omitted... ]

    # loop through all dex files in project & search
    for dex in project.findUnits(IDexUnit):
        # Generating hooks for OkHttp3
        for idx, result in enumerate(self.do_search(dex, "Certificate pinning failure!", ["Ljava/lang/String;"])):
            self.frida_hooks.append(
                self.frida_okhttp3_hook.format(idx=idx, java_class=result.get("class"), java_method=result.get("method")))

    # output the Frida script
    print("-" * 100)
    print(self.frida_hook_file.format(hooks="\n".join(self.frida_hooks)))
    print("-" * 100)

Finally we construct the hook by concatenating them all and formatting them in the Frida main hook template. The following is a sample CLI output:

➜  jeb-pro ./jeb_macos.sh -c --srv2 --script=GenerateFridaHooks.py -- "/path/to/apk/file.apk"
<JEB startup header omitted>

🔥 JEB scripting
{JebFridaHookArtifact > JebFridaHookArtifact}: 4956 resource files were adjusted
Attempting to merge the multiple DEX files into a single DEX file...
<JEB processing omitted>
{JebFridaHookArtifact > JebFridaHookArtifact}: DEX merger was successful and produced a virtual DEX unit

🔥 Fresh Frida Hooks
----------------------------------------------------------------------------------------------------
'use strict';
    // Usage: frida -U -f com.example.app -l generated_hook.js --no-pause
    Java.perform(function() {

        var okhttp3_CertificatePinner0 = Java.use('<omitted>');
        var findMatchingPins0 = okhttp3_CertificatePinner0.a.overload('java.lang.String');
        findMatchingPins0.implementation = function(hostname) {
            console.log('[+] okhttp3.CertificatePinner.findMatchingPins(' + hostname + ') # <omitted>()');
            return findMatchingPins0.call(this, ''); // replace hostname with empty string
        };

        var okhttp3_CertificatePinner1 = Java.use('com.squareup.okhttp.CertificatePinner');
        var findMatchingPins1 = okhttp3_CertificatePinner1.findMatchingPins.overload('java.lang.String');
        findMatchingPins1.implementation = function(hostname) {
            console.log('[+] okhttp3.CertificatePinner.findMatchingPins(' + hostname + ') # com.squareup.okhttp.CertificatePinner.findMatchingPins()');
            return findMatchingPins1.call(this, ''); // replace hostname with empty string
        };

    });

----------------------------------------------------------------------------------------------------
Done.

Interestingly there were two instances of OkHttp library in this specific app. This is not particularly uncommon as certain dependencies might use their own instance of a library.

It might be handy to check the DEX format, especially when trying to come up with signatures. For example, I wanted to match methods that accept an array of X509Certificate & a String as parameter and returning void. [ is used to denote an array and V is used to denote void:

self.do_search(dex, "NEEDLE", ["[Ljava/security/cert/X509Certificate;", "Ljava/lang/String;"], "V"): # V for Void

Less obvious is Z for boolean though.

Checkout the code from GitHub!

While doing some security research on the Android operating system, I stumbled upon the following blackhat presentation. It turns out that Android has a unique inter-process communication (IPC) mechanism. Although the internal workings of this mechanism is quite complex, it is abstracted away for Android app developers. The gist of the story is that Android uses Binder for inter-process communications and that it might be a good place for malware to eavesdrop for sensitive information.

Sounds like a cool thing to hook using Frida! In this blogpost I’ll describe my journey on how it’s made. I will be using the Google Keep note app for demo purposes.

Finding suitable function to hook

Most of the times there are several functions that reside on different layers that can be hooked in order to achieve a certain goal. The following resources were a great help into understanding the Android Binder architecture and the layers it contains ^{1 2 3}. The following are a rough list of entries that can be hooked, sorted from high to low level:

1. Java implementation layer: a developer might implement a custom protocol to communicate between apps/services. Here we’re going to hook implementation specific functions created by app developers.
2. Framework layer: this layer represents the Android standard Java classes/interfaces which developers might extend. A potential hook candidate would be android.os.Binder.
3. Native layer: this layer is hidden from app developers and provided transparently by Android. It is implemented as a shared library libbinder.so. Particular files of interest are Binder.cpp and IPCThreadState.cpp. This layer communicates with the Kernel layer using ioctl syscalls in order to communicate binder messages.
4. Kernel layer: ioctl syscalls are handled here.

I chose to hook on the native layer. The ioctl call seemed like an interesting function to hook as it requires some manual parsing of messages in Frida. Note that it might be easier to hook higher level functions such as C++ functions or Java functions depending on your goal.

libbinder in Android apps

Apps make use of a shared library called libbinder.so to interact with the Binder IPC framework. In Frida we can show the loaded modules of a particular app as follows:

frida -U -q -n com.google.android.keep -e "Process.enumerateModules();"

[Xiaomi Mi A2::com.google.android.keep]-> Process.enumerateModules();
[
...
    {
        "base": "0x7f91d08000",
        "name": "libbinder.so",
        "path": "/system/lib64/libbinder.so",
        "size": 561152
    },
...
]

Frida options explained:

• -U connect to USB,
  • If you have several devices connected, use -D; frida-ls-devices command to list devices
• -q quiet mode
• -n attach to app, use -f to spawn app
• -e evaluate code
  • "Process.enumerateModules();" JavaScript code to enumerate loaded modules.

We can grab the binary using adb pull /system/lib64/libbinder.so and start analysing the library but we could also grab the source and start reading from there! I prefer to use a combination of both static and dynamic analysis.

Loading the binary in radare2, we can confirm that it uses ioctl:

r2 -A libbinder.so           # -A run 'aaa' command to analyze all referenced code
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze function calls (aac)
[x] Analyze len bytes of instructions for references (aar)
...
[0x00049b10]> afl~ioctl      # list all functions and grep for ioctl
0x00047630    1 16           sym.imp.ioctl
[0x00049b10]>

Hooking C function in shared library on Android with Frida

We’ll be using JavaScript for our Frida hooks. First we need to find the address of ioctl:

Java.perform(function(){
    var ioctl = Module.findExportByName("libbinder.so", "ioctl");
});

Then we can use the Interceptor.attach() with an onEnter callback to intercept ioctl function calls:

Java.perform(function(){
    var ioctl = Module.findExportByName("libbinder.so", "ioctl");
    Interceptor.attach(ioctl, {
        onEnter: function(args) {
            // args is an array containing arguments passed to ioctl
            var fd = args[0]; // see man ioctl
            console.log("ioctl called, fd = " + fd);
        }
    })
});

Next we need to figure out the arguments passed to ioctl. Looking at the code in IPCThreadState.cpp#905 we can deduce that there are three arguments:

1. args[0]: An integer representing a file descriptor.
2. args[1]: An integer representing a certain command. We need to target a specific one BINDER_WRITE_READ. In binder.h#106 this is defined as #define BINDER_WRITE_READ _IOWR('b', 1, struct binder_write_read). I decided to create a sample C++ file to calculate this value: 0xc0306201.
3. args[2]: A pointer pointing to a binder_write_read struct (data). We will need to parse this struct.

The following implements above mentioned flow:

Java.perform(function(){
    var ioctl = Module.findExportByName("libbinder.so", "ioctl");
    Interceptor.attach(ioctl, {
        onEnter: function(args) {
            var fd = args[0]; // int
            var cmd = args[1]; // int

            // value calculated from #define BINDER_WRITE_READ		_IOWR('b', 1, struct binder_write_read)
            if(cmd != 0xc0306201) return;  // if 0xc0306201 then enter BINDER_WRITE_READ flow
            var data = args[2]; // void * -> pointer to binder_write_read

            var binder_write_read = parse_struct_binder_write_read(data);
        }
    })
});

Parsing binder_write_read struct

This particular struct is defined in binder.h#84 as follows:

struct binder_write_read {
    binder_size_t write_size;
    binder_size_t write_consumed;
    binder_uintptr_t write_buffer;
    binder_size_t read_size;
    binder_size_t read_consumed;
    binder_uintptr_t read_buffer;
};

We need to know the size of each element in order to parse the binder_write_read struct correctly. In the same header file, the following definition is declared:

#ifdef BINDER_IPC_32BIT
typedef __u32 binder_size_t;
typedef __u32 binder_uintptr_t;
#else
typedef __u64 binder_size_t;
typedef __u64 binder_uintptr_t;
#endif

Meaning that the size is 8 bytes for each entry on 64-bit devices. Since we’ll be using modern devices, we’ll stick to the x64 architecture. The following JS function parses the struct correctly using the Frida API:

function parse_struct_binder_write_read(binder_write_read) {
    var offset = 8; // 64b

    return {
        "write_size": binder_write_read.readU64(),
        "write_consumed": binder_write_read.add(offset).readU64(),
        "write_buffer": binder_write_read.add(offset * 2).readPointer(),
        "read_size": binder_write_read.add(offset * 3).readU64(),
        "read_consumed": binder_write_read.add(offset * 4).readU64(),
        "read_buffer": binder_write_read.add(offset * 5).readPointer()
    }
}

The binder_write_read parameter is a Frida NativePointer object, which is essentially a bridge to interact with a real pointer in memory on the device. Since structs in memory are adjacent to each other, we can use basic pointer arithmetic to read the values out of this struct.

The data structure contains a read and write section each with a pointer to a buffer, buffer size and the amount of bytes that are consumed. binder_thread_write() and binder_thread_read() are used to handle these sections.

Lost in the data structures

Next I thought I just need to dump the buffer and I will be seeing juicy data. It turns out I was wrong and that I had to parse yet another data structure. Loading the sourcecode in CLion might speed up the process of getting insight on how everything is connected. A neat feature is the call hierarchy:

So far we’ve handled the logic until binder_ioctl_write_read(), next we need to figure out what binder_thread_write() does:

static int binder_thread_write(struct binder_proc *proc,
			struct binder_thread *thread,
			binder_uintptr_t binder_buffer, size_t size,
			binder_size_t *consumed)
{
	uint32_t cmd;
	void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
	void __user *ptr = buffer + *consumed;
	void __user *end = buffer + size;

	while (ptr < end && thread->return_error == BR_OK) {
		if (get_user(cmd, (uint32_t __user *)ptr))
			return -EFAULT;
		ptr += sizeof(uint32_t);
		trace_binder_command(cmd);
		if (_IOC_NR(cmd) < ARRAY_SIZE(binder_stats.bc)) {
			binder_stats.bc[_IOC_NR(cmd)]++;
			proc->stats.bc[_IOC_NR(cmd)]++;
			thread->stats.bc[_IOC_NR(cmd)]++;
		}
		switch (cmd) {
		case BC_INCREFS:
		case BC_ACQUIRE:
		case BC_RELEASE:
		case BC_DECREFS: {
			...
		}
		...
		case BC_TRANSACTION:
		case BC_REPLY: {
			struct binder_transaction_data tr;

			if (copy_from_user(&tr, ptr, sizeof(tr)))
				return -EFAULT;
			ptr += sizeof(tr);
			binder_transaction(proc, thread, &tr, cmd == BC_REPLY);
			break;
		}
	...
}

The first 4 bytes in the buffer represents a command cmd, different actions can be performed depending on this value. From the sources I linked previously, the values BC_TRANSACTION and BC_REPLY are of particular interest to us as they contain data transmitted through Binder. I’ve decided to create a JavaScript dictionary to emulate the enum:

// http://androidxref.com/kernel_3.18/xref/drivers/staging/android/uapi/binder.h#273
var binder_driver_command_protocol = {  // enum binder_driver_command_protocol
    "BC_TRANSACTION": 0,
    "BC_REPLY": 1,
    "BC_ACQUIRE_RESULT": 2,
    "BC_FREE_BUFFER": 3,
    "BC_INCREFS": 4,
    "BC_ACQUIRE": 5,
    "BC_RELEASE": 6,
    "BC_DECREFS": 7,
    "BC_INCREFS_DONE": 8,
    "BC_ACQUIRE_DONE": 9,
    "BC_ATTEMPT_ACQUIRE": 10,
    "BC_REGISTER_LOOPER": 11,
    "BC_ENTER_LOOPER": 12,
    "BC_EXIT_LOOPER": 13,
    "BC_REQUEST_DEATH_NOTIFICATION": 14,
    "BC_CLEAR_DEATH_NOTIFICATION": 15,
    "BC_DEAD_BINDER_DONE": 16,
};

Technically I need to compute the values such as _IOW('c', 1, struct binder_transaction_data) which gives 0x40406301 but I decided to simply discard the first 3 bytes by using & 0xff which will then result into 0x1. Let’s add a new function which parses the command:

// http://androidxref.com/kernel_3.18/xref/drivers/staging/android/binder.c#1754
function handle_write(write_buffer, write_size, write_consumed) { // binder_thread_write
    var cmd = write_buffer.readU32() & 0xff; // hack
    var ptr = write_buffer.add(write_consumed + 4); // 4 = sizeof(uint32_t), the first 4 bytes contain "cmd"
    var end = write_buffer.add(write_size);

    switch (cmd) {
        // Implement cases from binder_driver_command_protocol, we're only interested in BC_TRANSACTION / BC_REPLY
        case binder_driver_command_protocol.BC_TRANSACTION:
        case binder_driver_command_protocol.BC_REPLY:
            // log('INFO', "TRANSACTION / BC_REPLY!");
            // TODO process the rest of the buffer
            break;
        default:
            // log('ERR', 'NOOP handler')
    }
}

Java.perform(function(){
    var ioctl = Module.findExportByName("libbinder.so", "ioctl");
    Interceptor.attach(ioctl, {
        onEnter: function(args) {
            var fd = args[0]; // int
            var cmd = args[1]; // int

            // value calculated from #define BINDER_WRITE_READ		_IOWR('b', 1, struct binder_write_read)
            if(cmd != 0xc0306201) return;  // if 0xc0306201 then enter BINDER_WRITE_READ flow
            var data = args[2]; // void * -> pointer to binder_write_read

            var binder_write_read = parse_struct_binder_write_read(data);

            if(binder_write_read.write_size > 0) {
                handle_write(binder_write_read.write_buffer, binder_write_read.write_size, binder_write_read.write_consumed);
            }
        }
    })
});

Parsing binder_transaction_data struct

Whenever there’s a BC_TRANSACTION or BC_REPLY, a binder_transaction_data struct is allocated and filled with the rest of the write buffer. Then the function binder_transaction is called with this struct as one of its parameters:

case BC_TRANSACTION:
case BC_REPLY: {
	struct binder_transaction_data tr;

	if (copy_from_user(&tr, ptr, sizeof(tr)))
		return -EFAULT;
	ptr += sizeof(tr);
	binder_transaction(proc, thread, &tr, cmd == BC_REPLY);
	break;
}

The struct looks as follows:

// http://androidxref.com/kernel_3.18/xref/drivers/staging/android/uapi/binder.h#129
struct binder_transaction_data {
	/* The first two are only used for bcTRANSACTION and brTRANSACTION,
	 * identifying the target and contents of the transaction.
	 */
	union {
		/* target descriptor of command transaction */
		__u32	handle;
		/* target descriptor of return transaction */
		binder_uintptr_t ptr;
	} target;
	binder_uintptr_t	cookie;	/* target object cookie */
	__u32		code;		/* transaction command */

	/* General information about the transaction. */
	__u32	        flags;
	pid_t		sender_pid;
	uid_t		sender_euid;
	binder_size_t	data_size;	/* number of bytes of data */
	binder_size_t	offsets_size;	/* number of bytes of offsets */

	/* If this transaction is inline, the data immediately
	 * follows here; otherwise, it ends with a pointer to
	 * the data buffer.
	 */
	union {
		struct {
			/* transaction data */
			binder_uintptr_t	buffer;
			/* offsets from buffer to flat_binder_object structs */
			binder_uintptr_t	offsets;
		} ptr;
		__u8	buf[8];
	} data;
};

A union can store different data types in the same memory location. This means that only one value can reside in such memory location. Memory will be allocated according to the biggest value. To emulate this in JS land, I’ve opted for a dictionary. The offsets are calculated manually with x64 architecture in mind:

function parse_binder_transaction_data(binder_transaction_data) {
    return {
        "target": { // can either be u32 (handle) or 64b ptr
            "handle": binder_transaction_data.readU32(),
            "ptr": binder_transaction_data.readPointer()
        },
        "cookie": binder_transaction_data.add(8).readPointer(),
        "code": binder_transaction_data.add(16).readU32(),
        "flags": binder_transaction_data.add(20).readU32(),
        "sender_pid": binder_transaction_data.add(24).readS32(),
        "sender_euid": binder_transaction_data.add(28).readU32(),
        "data_size": binder_transaction_data.add(32).readU64(),
        "offsets_size": binder_transaction_data.add(40).readU64(),
        "data": {
            "ptr": {
                "buffer": binder_transaction_data.add(48).readPointer(),
                "offsets": binder_transaction_data.add(56).readPointer()
            },
            "buf": binder_transaction_data.add(48).readByteArray(8)
        }
    }
}

Glueing it all together

Now that we’ve got the binder_transaction_data struct, we can finally dump data as we got a pointer to the data buffer and a length. The final script looks as follows:

'use strict';

const PYMODE = false;
var CACHE_LOG = "";

function log(type, message) {
    if(message.toString() == CACHE_LOG.toString()) return; // Let's hide duplicate logs...

    CACHE_LOG = message;
    if(PYMODE) {
        send({'type':type, 'message': message});
    } else {
        console.log('[' + type + '] ' + message);
    }
}

// http://androidxref.com/kernel_3.18/xref/drivers/staging/android/uapi/binder.h#273
var binder_driver_command_protocol = {  // enum binder_driver_command_protocol
    "BC_TRANSACTION": 0,
    "BC_REPLY": 1,
    "BC_ACQUIRE_RESULT": 2,
    "BC_FREE_BUFFER": 3,
    "BC_INCREFS": 4,
    "BC_ACQUIRE": 5,
    "BC_RELEASE": 6,
    "BC_DECREFS": 7,
    "BC_INCREFS_DONE": 8,
    "BC_ACQUIRE_DONE": 9,
    "BC_ATTEMPT_ACQUIRE": 10,
    "BC_REGISTER_LOOPER": 11,
    "BC_ENTER_LOOPER": 12,
    "BC_EXIT_LOOPER": 13,
    "BC_REQUEST_DEATH_NOTIFICATION": 14,
    "BC_CLEAR_DEATH_NOTIFICATION": 15,
    "BC_DEAD_BINDER_DONE": 16,
};

// http://androidxref.com/kernel_3.18/xref/drivers/staging/android/uapi/binder.h#77
function parse_struct_binder_write_read(binder_write_read) {
    var offset = 8; // 64b

    return {
        "write_size": binder_write_read.readU64(),
        "write_consumed": binder_write_read.add(offset).readU64(),
        "write_buffer": binder_write_read.add(offset * 2).readPointer(),
        "read_size": binder_write_read.add(offset * 3).readU64(),
        "read_consumed": binder_write_read.add(offset * 4).readU64(),
        "read_buffer": binder_write_read.add(offset * 5).readPointer()
    }
}

// http://androidxref.com/kernel_3.18/xref/drivers/staging/android/uapi/binder.h#129
function parse_binder_transaction_data(binder_transaction_data) {
    return {
        "target": { // can either be u32 (handle) or 64b ptr
            "handle": binder_transaction_data.readU32(),
            "ptr": binder_transaction_data.readPointer()
        },
        "cookie": binder_transaction_data.add(8).readPointer(),
        "code": binder_transaction_data.add(16).readU32(),
        "flags": binder_transaction_data.add(20).readU32(),
        "sender_pid": binder_transaction_data.add(24).readS32(),
        "sender_euid": binder_transaction_data.add(28).readU32(),
        "data_size": binder_transaction_data.add(32).readU64(),
        "offsets_size": binder_transaction_data.add(40).readU64(),
        "data": {
            "ptr": {
                "buffer": binder_transaction_data.add(48).readPointer(),
                "offsets": binder_transaction_data.add(56).readPointer()
            },
            "buf": binder_transaction_data.add(48).readByteArray(8)
        }
    }
}

// http://androidxref.com/kernel_3.18/xref/drivers/staging/android/binder.c#1754
function handle_write(write_buffer, write_size, write_consumed) { // binder_thread_write
    var cmd = write_buffer.readU32() & 0xff;
    var ptr = write_buffer.add(write_consumed + 4); // 4 = sizeof(uint32_t), the first 4 bytes contain "cmd"
    var end = write_buffer.add(write_size);

    switch (cmd) {
        // Implement cases from binder_driver_command_protocol, we're only interested in BC_TRANSACTION / BC_REPLY
        case binder_driver_command_protocol.BC_TRANSACTION:
        case binder_driver_command_protocol.BC_REPLY:
            // log('INFO', "TRANSACTION / BC_REPLY!");
            var binder_transaction_data = parse_binder_transaction_data(ptr);

            // Show me the secrets
            log("INFO", "\n" + hexdump(binder_transaction_data.data.ptr.buffer, {
                length: binder_transaction_data.data_size,
                ansi: true,
            }) + "\n");
            break;
        default:
            // log('ERR', 'NOOP handler')
    }
}

Java.perform(function(){
    var ioctl = Module.findExportByName("libbinder.so", "ioctl");
    Interceptor.attach(ioctl, {
        onEnter: function(args) {
            var fd = args[0]; // int
            var cmd = args[1]; // int

            // value calculated from #define BINDER_WRITE_READ		_IOWR('b', 1, struct binder_write_read)
            if(cmd != 0xc0306201) return;  // if 0xc0306201 then enter BINDER_WRITE_READ flow
            var data = args[2]; // void * -> pointer to binder_write_read

            var binder_write_read = parse_struct_binder_write_read(data);

            if(binder_write_read.write_size > 0) {
                handle_write(binder_write_read.write_buffer, binder_write_read.write_size, binder_write_read.write_consumed);
            }
        }
    })
});

Let’s run it with Frida on Google Keep notes app:

frida -U -l frida_android_libbinder.js -f com.google.android.keep --no-pause

There’s a lot of traffic, so be sure to have “unlimited” buffer in your terminal. I played around with the app until the following popped up!

Not sure how useful this is but it was fun anyways. You can find the source code on GitHub!

There are two “main” ways to use Frida on Android:

• Repackage the target APK with a Frida Gadget;
• Use a rooted Android device and install Frida server.

Since I need a rooted Android device to perform my security tests anyways and the repackaging process is time consuming, I usually opt for the second option. With the fast paced development of Frida, I sometimes encounter the following error:

➜ frida-ps -Uai
Failed to enumerate applications: unable to communicate with remote frida-server;
please ensure that major versions match and that the remote Frida has the feature you are trying to use

Installing the latest Frida is easy as described in the documentation:

1. Grab the latest release from GitHub.
2. Extract the release.
3. Push the release to the device.
4. chmod 755 it.
5. Run as root in background.

After a few times of doing this I thought: why not automate this process? Enter Frida Android Helper. A command line tool written in Python and makes use of pure-python-adb to interface with the ADB server.

For starters I’ve added a server module to start, stop, reboot and most importantly update the Frida server to the latest release. The GitHub API is used to fetch the latest Android Frida server based on the architecture of the device (arm/x86 32/64).

There is one hack though:

def perform_cmd(device: Device, command: str, root: bool = False, timeout: int = None):
    if root:
        command = "su -c {}".format(command)
    try:
        return device.shell(command, timeout=timeout)
    except:
        pass

def launch_frida_server(device: Device):
    # hack: launch server, "forever sleep" and put in background. Short timeout to break off connection
    perform_cmd(device, "/data/local/tmp/frida-server && sleep 2147483647 &", root=True, timeout=1)

The frida-server needs to be launched as root and put in the background. I’ve hacked around with fork &, double fork (./frida-server &) &, nohup, setsid, su -c etc… Either the frida server exits directly, or the command line “hangs” since TTY (socket?) is still open. Therefore the hack consists of running frida-server as root, sleeping infinitely, putting this into the background and then abruptly closing the connection from client side using timeout=1. The python ADB library throws a timeout exception which is caught in perform_cmd(). Ideas for a cleaner solution are welcome!

Hopefully I’ll add more modules to make the Frida experience on Android smoother. Ideas and bug reports are therefore welcome!