detect and use third-party analysis backends when possible

[williballenthin]

capa has analysis backends for third party tools, like IDA, Binary Ninja, and Ghidra. It's possible to invoke capa to use these backends, but you typically have to be an expert to figure out how to do this.

We should investigate whether the standalone capa.exe can automatically detect installations of relevant third party applications and use their backends, when possible. For example, capa.exe could recognize that IDA is installed, figure out where the path is, and try to initialize idalib from that path. Of course, there are a lot of edge cases and possibilities, but I suspect a few common workflows might be achievable. For example, ensuring capa.exe in FLARE-VM uses the best available backend. Worst case, capa.exe continues to use the embedded vivisect backend.

Tasks

Beta Give feedback

1. IDA 9.0 idalib on Linux
2. IDA 9.0 idalib on Windows
3. Binary Ninja on Linux
4. Binary Ninja on Windows
5. Binary Ninja on macOS
6. IDA 9.0 idalib on macOS

[williballenthin]

Binary Ninja on Linux

Installs an XDG Desktop Entry like this:

❯ bat ~/.local/share/applications/com.vector35.binaryninja.desktop -p
[Desktop Entry]
Name=Binary Ninja
Exec=/home/wballenthin/software/binaryninja/binaryninja %u
MimeType=application/x-binaryninja;x-scheme-handler/binaryninja;
Icon=/home/wballenthin/software/binaryninja/docs/img/logo.png
Terminal=false
Type=Application
Categories=Utility;
Comment=Binary Ninja: A Reverse Engineering Platform

from which we can parse Exec=/home/wballenthin/software/binaryninja/ to recover the spot where the binaryninja API is loaded. Then this install_api.py script is used to update the Python environment so the API can be imported.

---

We actually have some functionality already for loading Binary Ninja from the standalone exe, though it uses a different strategy: https://github.com/mandiant/capa/blob/master/capa/features/extractors/binja/find_binja_api.py

It invokes a Python subprocess to find the local install path. This works as long as the binaryninja module is available globally. If not, the import will fail.

The upside is that this is cross platform. The downside is the requirement for global installation.

[williballenthin]

IDA on Linux

IDA v8.0 also uses a Desktop Entry:

❯ bat -p /usr/share/applications/ida64.desktop
[Desktop Entry]
Name=IDA Pro (64-bit targets)
Exec=/opt/idapro/ida64
Icon=/opt/idapro/appico64.png
Terminal=false
Type=Application
StartupWMClass=ida64

However, the IDA 9.0 Beta 4 doesn't add the desktop entry (bug reported). But new in IDA 9.0 is a configuration file ~/.idapro/ida-config.json with an entry that points to the location of the current installation:

The IDA 9.0 idalib installation has a similar script to update the Python environment so that the shared libraries can be loaded. We can pull some of that logic into capa once the base directory is recovered.

[williballenthin]

Windows

I think we can walk the registry to find where IDA/BinaryNinja are installed. Will update here when I try to make it work.

[williballenthin]

macOS

I don't know and I don't have a system to test on. But maybe we can get outside contributors to help out. Alternatively, its OK because we can fallback to viv when necessary.

[williballenthin]

https://github.com/mandiant/capa/compare/push-lsvlznlppuyr

[williballenthin]

https://github.com/mandiant/capa/compare/push-trmuzvmvrzkx

[williballenthin]

search for Binary Ninja API via XDG Desktop Entries in https://github.com/mandiant/capa/compare/push-ltqsxxylmzpy