Collaborative Reverse Engineering with PSIDA

Introducing Python Scripts for IDA. Making collaborative reverse-engineering possible for Interactive DisAssembler (IDA)!

As a member of the Argus Research Team one of my main responsibilities is penetration-testing embedded automotive components, reversing the binaries of embedded components to find potential exploits and misconfigurations.

Reversing embedded binaries can take a lot of time and effort (mainly due to lack of helpful hints like strings and OS API) so we try to tackle these tasks as a team, which has its own challenges.

Our weapon of choice – IDA Pro – is not made with teamwork in mind; having several team members working on the same binary means you need a way to keep each other in sync. Usually, every team member reverses a different mechanism within the binary, and we take care to avoid repeating each other’s work (this still happens sometimes and can be a major waste of time). So to save time we developed PSIDA (short for Python Scripts for IDA) – a collection of tools designed to share our work and prevent reversing the same code twice.

After some thought we identified two different ways of how people collaborate – one is offline collaboration, where people update each other periodically (say, once a week), and one is online collaboration, where people receive updates in real time.

Let’s Talk About Progress

Just a quick side note before we get going: We need to define what “reverse engineering progress” is. Ideally, you would share every single change you’ve made in your .idb since the last time you shared it. Unfortunately, we’re not there yet, and we’re not sure how far we can get without some serious support from Hex Rays. In any case, since we’re in the business of automotive cyber security and not the business of IDA plugins, we’ll have to make do with these aspects of the .idb file:

• Function names
• Comments of all kinds (regular and repeated comments, anterior and posterior lines)

At first glance, it doesn’t seem like much, but it’s enough to get the team going. Besides, you can always submit a pull request with your own features (or you could wait until we find the time to implement some more features, or maybe Hex Rays will implement some for you).

A Quick Note About Installation

We’re not going to talk too much about setting up your IDA Pro to work with PSIDA; the installation process is described quite in depth in the README in the BitBucket repo, but, to make a long story short, you need to copy some scripts (and, if you plan to use idb_push, install the backend) and you’re done.

Method One: The Offline Use Case (idb_pickle)

This is the simpler use case. Here, your coworker needs to merge your work from the last few days into their own IDB. This is actually quite a simple process: you import idb_pickle and then idb_pickle.pickle() your IDB into a file wherever you like.

Behind the scenes, the script goes over all the segments in your IDB, all the memory defined in each of them and collects the names and comments (which is why it can take a while on large segments). It then uses Python’s pickle to store the results into a file.

In order to merge someone else’s changes into your own IDB, you need to idb_pickle.unpickle() their file.If you don’t have any conflicts, you’re done! If you and your teammates have different names or comments at the same addresses, you’ll need to handle the conflicts in the IDB MERGE window:

We’ve tried to make the conflict resolution interface as intuitive as possible, so in addition to the buttons, you have some keyboard shortcuts:

• Space bar: takes you to the conflict address
• Enter: applies the selected update(s) (as does double-clicking an update)
• Delete or Backspace: discard the selected update(s)

This is pretty much everything you need to know to synchronize your work offline. Now let’s move to the online use case.

Method Two: The Online Use Case (idb_push)

In the (slightly) more complicated use case, you want to see what your coworkers are doing in real time. For this, you’ll need to import idb_push and idb_push.start() to get going. Internally, idb_push installs hooks on the changes you make to the IDB (the same ones as idb_pickle – comments and names) and pushes notifications to everyone else working on the same project. In terms of idb_push, a project is identified by its .idb name.

The communication layer idb_push uses is ZeroMQ, specifically, its publisher-subscriber model, where every project participant is simultaneously a publisher and a subscriber to other project participants working on the same project. In order for the model to work, you’ll need a tiny backend, zmq_forwarder.py, which manages the subscriptions. The zmq_forwarder.py is wrapped as a Windows service, so you can install it from the PSIDA repository, set it to Automatic and forget about it (you will need to remember its host name so that idb_push can connect to it, but I think you’ll manage).

The UI that idb_push uses is very similar to the merge UI in idb_pickle and it uses the same keyboard shortcuts. You get an update every time one of your collaborators changes something, with conflicts shown in text:

Another useful feature of idb_push is the ability to send “look here” messages. Basically, the application allows you to send notifications to all the collaborators on the project. The notification they receive will allow them to double-click (or Apply) and jump in the IDA to the specific line that you wanted them to see:

That’s pretty much everything there is to know about the collaboration scripts in PSIDA. Feel free to review the source code to really see how it works (you can even open an issue if you notice something amiss). We have some plans to further develop PSIDA in the future, but pull requests with features and bug fixes are always welcome!

More About Sharing

We at the Argus research team strongly believe in a collaborative way of work and research. Sharing .idbs is one thing; sharing tools and ideas is a bigger challenge. Although we have just started sharing our tools with the community, we know that other reverse-engineering collaboration tools exist, such as Solidarity.re, Talos FIRST and others, each with their own pros and cons.

We felt this is a first and small step for a bigger collaboration with the RE community and hopefully will bring new and better research tools in the near future.

Happy (collaborative) bug hunting!

Author

Alexei Kovelman
Security Researcher at Argus Cyber Security
Email: [email protected]