Runtime Instrumentation with Objection part 1

2 minute read

Introduction

Objection is as a runtime mobile exploration framework, works with actual mobile devices and emulators, on both iOS and Android. Objection is built in part on the amazing Frida, and comes with a lot of really nice tools like SSL unpinning and live function modification. The Defcon 27 talk Meticulously Modern Mobile Manipulations by Leon Jacobs has a bunch of great examples of mobile runtime modification with Objection.

I will demonistrate how to use Objection to turn enable logging on and android application running on a live device. I want to enable the logging so I can understand the communication between my android device and a BLE lock.

Setup

Objcetion is super powerful but the setup, especially the first time, can be a little daunting. The Objection Wiki has a bunch of great articles on installation and configuration.

After following the wiki instructions I’ve got:

A patched client APK running on my android device, attached to USB
Objection REPL running in one terminal
adb logcat running in another

After installing the patched APK I fed it to the CFR Decompiler to get (heavily obfuscated) Java code.

Finding the logger

Some light poking around in the bluetooth code led me to a class named LogUtil which is called from lots of interesting code like:

LogUtil.d(var2_3.append("receiver data=" + byteArrayToHexString(var1_1), true);
// ...
LogUtil.d(var2_3.append("mReceivedBufferCount:").append(BluetoothLeService.toString(), true);
// .. 
LogUtil.d(var2_3.append("dataLen:").append(var4_5).toString(), true);

Not all of these lines make sense yet but they are exactly the kind of calls I need if I’m going to perform an analysis on this lock.

The (lightly edited) LogUtil looks like:

public class LogUtil {
  private static boolean DBG = false;
  private static final String msg = "%s(L:%d) - %s";

  public static void d(String string2) {
    if (DBG) {
      Log.d((String)callerClazzName, (String)String.format(msg, ..., string2 ));
    }
  }
}

The d method does some formatting and calls the built-in android logger if DBG is true. But the value is false by default - so how can I turn on debugging?

Eanbling debug logging

Frida is behind a lot of the magic of Objection. Frida allows us to inject javascript into a running process to (IE) make method calls against the live application. This is totally bonkers, and I’ll use this funcationlity to turn on debug-level logging (DBG from above ^) so I can inspect the BLE communication between my app and lock.

I want to execute code against the main application class ( MyApplication) instance. In the Objection console I’ll first find the instance of the application

Objection console used to find an instance of MyApplication

Now I want to evaluate a script against the app instance to set DBG to true via the setDBG setter. Here’s the frida script. The clazz var is built in Objection variable pointing to the object we’re running against.

var c = Java.use("com._._.sdk.util.LogUtil");
clazz.DBG = true;
console.log(c.isDBG());
c.setDBG(true);
console.log(c.isDBG());

And the interactie output:

Objection console turning on debug logging via javascript

The false,true log lines make me think the script has run but we need to look at the logs to verify.

Verify the output

Checking in on the logcat session shows us lines that look very similar to the examples above

Now that debug logging is on I can interact use the app to interact with the lock and have a record of all the operations like network calls and BLE transfers.

Conclusion

Objection and Frida are incredible tools – I really don’t understand how they are free. And this use case barely scratches the surface of what is possible with them. I look forward to exploring topics like hooking functions and disabling SSL pinning in future blog posts.

Jason