Making a self written plugin available through the RPC API

[root-intruder]

Hi, I want to use objection to log for example the usage of the Android crypto API in my java program. I've developed a objection plugin emitting a log message during objection explore. I've also setup a Java interface to call RPC methods provided through the objection RPC API. Now I'd like to bring these log messages into my java program.

I currently see no way of exporting my plugin or the provided frida version plugin from the examples output into my java program.

Any advice?

[leonjza]

I think you should be able to append to the global rpc variable from within your plugin's agent. This is not something I have tested yet but it makes sense to at least document this if so.

Let's keep this open to test and document this.

[root-intruder]

Hi thanks for your answer!

When I have from the documented example plugin:

s = """
rpc.exports = {
    getInformation: function() {
        console.log('hello from Frida');    // direct output
        send('Incoming message');           // output via send for 'message' signal
        return Frida.version;               // return type
    }
}

I already write to the global rpc.export!? Sorry I'm totally new to JS.

If you give me some code snipplet or further hint I'd try it and reward you with a wiki documentation in return...if it works.

Thanks!

[leonjza]

Damn, I took a closer look at the implementation and realise we are using a separate script object for plugins which makes appending to the objection agents' rpc exports impossible. That sucks.

In my mind there are two things we can do.

• One, consider some refactoring of the plugin script loader to try and make it part of the original script. I am not sure how or if its even possible, but it's something to investigate.
• Two, in your plugin you could use the existing Flask boilerplate (so call create_app() and then append your own blueprints (effectively a copy of the objection rpc blueprint perhaps), but instead glue it to the plugins' script instance and not the global one. This way you can still use the same command to enable the HTTP API, but just have a different HTTP route to call methods exposed by the plugins RPC.

Hope that helps!

[root-intruder]

Hi, thank's for the reply and further suggestions.

The fist option seems like the right way. Unfortunately it seems a bit hard for me to do with my poor JS/TS skills, if even you hesitate.

The second option seems possible for me to implement, however I'd not consider this a clean implementation.

Another option might be not using my scripts as a plugin but making them a fixed implementation. I'm planning on implementing a logger for android crypto api usage with a configuration dump and also scripts for logging sensor usage, like GPS, Mic, and camera access. However, it would only make sense if there is a will to accept these extensions in objection upstream?

Cheers!

[leonjza]

The more I think about the second option, the more I think I am going to extend the Plugin class to make it possible to add endpoints to the API as well.

As for logging interactions, absolutely. It's something I have long wanted to do but just never got round to.

[root-intruder]

I agree...making plugins available would make the API and the CLI interface more uniform.

[leonjza]

I just added a first pass at implementing this which will be available in the next release.

The basic idea is that your plugin should implement the http_api method and return a flask.Blueprint. The example api plugin I included should be enough to get you started in using this, available here: https://github.com/sensepost/objection/blob/a2d988bf8114e27101b27aec461705038e0bb87c/plugins/api/__init__.py

Thanks for the suggestion, this was fun to implement 🎉