williballenthin
commented
1 month ago 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 Platformfrom 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.
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.