Consider having some semi-official build of `binexport`

[fuzyll]

What is the feature you'd like to have? Until #6105 gets resolved, customers tend to try and use binexport for binary diffing with Binary Ninja. Unfortunately, building this is non-trivial right now. We should consider having some semi-official build so users will ~stop asking me about it~ have a better experience with the plugin and our product.

Is your feature request related to a problem? Currently, you need this random PR from 8+ months ago and some luck to get things to build. You may also need this much more recent PR now as well, as of the 5.0 release. But, even in absence of needing to scrounge around for PRs to apply to the codebase before building, it's still a pain because we release new builds fairly often and you need to rebuild for dev semi-frequently.

Are any alternative solutions acceptable? If the binexport maintainer is willing to merge the PR(s), or if there's anything else we can do to help them out, we can/should also consider resolving things upstream. Ideally, regardless of how this is solved, we can get this into the plugin manager once we switch over to the new v2 infrastructure as well (maybe in 5.1?).

Also, there is a lot of desire from users to be able to do diffs as a first-party feature, particularly because we could diff on things other than disassembly. But, my assumption is that resolving this issue should be significantly less time investment than #6105.

Additional Information: It's unclear to me if this blocks on #3399 (see comment from binexport maintainer in that thread) or not, given that having a GitHub Action for this seems like a straightforward solution. Regardless, having this in the plugin manager definitely blocks on #2238.

[FuzzySecurity]

I can confirm, it is a ~~terrible~~ "non-trivial" experience compiling this (I compiled on Windows as well which added some interesting problems to the mix). It would be really good to get some movement on this, I regret the time I spent to fix the BN build and wish I would have rather booted an old VM.

[colinmkinsella]

I created a nightly dev build and a check/build for stable releases with reusable workflows in google/binexport#153. If a new tag is found, then a stable build is triggered. Most of the problems with building seem to be dependencies with workflows in github, cmake fun, and not bindiff/binexport core files changing.

Is it a fair assumption that only stable builds will be tagged? API hooks would make this process easier, but checking once a day seems to work from the workflow. Right now I only have the dev/nightly build running once a day. The same method I use for the stable build could be used multiple times in the day to produce a dev build when a new commit is made to the dev branch.

I have a long term plan to build something to use binaryninja's user interface, but allow you to select different algorithms. I think this could possibly satisfy #6105. I was reading some of the white papers from bindiff, and reading up/perusing the code on on how diaphora works.

[psifertex]

Awesome! That helps a ton. I was in the process of doing something similar and integrating it into our build process.

My plan was to actually target both stable and latest dev builds. I was planning on actually producing a dev release that tracks whenever the API version changes if I implemented it as a separate repository.

One way to do this externally would be to have a Python loader that would separately install the native plugin similar to how the native sigscan loader plugin works.

Alternatively, if I just end up integrating the library in our build process we don't have to worry about that and it would always be available.

[colinmkinsella]

Sweet, and thanks for the links! The sigcan loader project combined with tracking API versions definitely seems like a great example for handling as a separate repo.

I am happy to help contribute to what you are building if I am able to, but completely understand if you are doing it internally.

At the end of the day, I just wanted to be able to do bindiffing with Binary Ninja and it seemed easier to get binexport building than to write a port of diaphora.

[plafosse]

I'm putting it on the current milestone but no promises that we'll get it done by then. We are however looking into this.

[psifertex]

Added in builds >= 5.1.7951

You'll need to enable the experimental setting to test it out.

[colinmkinsella]

Thanks for adding! This is a subtle reminder for me to buy a new Mac. I still have the older version with the intel processors.

[Default] Plugin module '/Applications/Binary Ninja.app/Contents/MacOS/plugins/libbinexport.dylib' failed to load
[Default] dlerror() reports: dlopen(/Applications/Binary Ninja.app/Contents/MacOS/plugins/libbinexport.dylib, 0x0006): tried: '/Applications/Binary Ninja.app/Contents/MacOS/plugins/libbinexport.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64h' or 'x86_64')), '/System/Volumes/Preboot/Cryptexes/OS/Applications/Binary Ninja.app/Contents/MacOS/plugins/libbinexport.dylib' (no such file), '/Applications/Binary Ninja.app/Contents/MacOS/plugins/libbinexport.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64h' or 'x86_64'))

I have stubbornly continued to work on this: https://github.com/colinmkinsella/binexport https://github.com/colinmkinsella/binexport-loader

It is a good exercise in building things with Github workflows. I am still working on the loader, and how to only do updates with the version info if a newer version is available. I used the original BinExport project to build a library that I am using to build a plugin that I can customize and version separately. I know this is all a moot point since it looks like you have something working minus my edge case.

[psifertex]

Good catch! We should definitely be shipping a universal binary. I'll get that fixed today. I'm re-opening the issue.

And thanks again for your work on the plugin -- we're actually planning on ~copying~ being inspired by that a bunch for some upcoming work we're doing with automating native plugin development directly with official templates and some changes in the plugin manager!

[colinmkinsella]

Haha, no problem! Please copy as much as you want! I just wanted to learn how to build things with more complicated workflows. Hopefully, I can contribute something in the future to your API. I saw some interesting tickets in the queue that I think would be helpful and fun to work on. Thanks again for all that your team does, I love the product!

[psifertex]

Sorry about that, universal builds are included in >=5.1.7971 which is going through CI now.