Open mozark24 opened 5 years ago
I think the only to do this is to start a whole notebook server from the plugin that then starts the kernel in this environment.
https://github.com/tmr232/ida_ipython / https://github.com/james91b/ida_ipython are already doing this with IDA and I am currently planning to port this to Binary Ninja.
I have a fork that does this, though there's some installation logic that should be added to setup.py as of now. In particular, I'd need to be able to deduce the installation path on Linux (I'm on a mac myself where it's straightforward) and where to put the kernel spec for jupyter. Does that seem reasonable?
I skimmed your changes, seems good. Haven't tested it yet, but assuming this works, this is definitely a highly welcomed features.
The install path on Linux can be anything really, on Linux you just unpack the zip and run it wherever. So maybe just something that prompts the user to configure that path to their installation (they might have multiple even).
The kernelspecs on my system are in /usr/share/jupyter/kernels/
but maybe both issues are solved by an addition to the README that just tells the users to create the kernel file from the template with their binary ninja path and put it in the location of their Jupyter.
A README is fine, but gets old. I'll spend some time tomorrow on it and we can see where I end up.
Just as a note, the official API appears to assume that Binary Ninja is installed in the user's home directory (if on Linux): https://github.com/Vector35/binaryninja-api/blob/dev/CMakeLists.txt#L30-L35 (if you wish to make this assumption too)
Then I would say that this could be the default value, but it should be documented how and where to change this. E.g. on Arch there is an AUR package that installs into /opt/binaryninja
I was thinking of using the binaryninja.desktop file that is created by linux-setup.sh if it exists. It can be in 2 places and contains the full path to the executable. I realize that not everyone will run that, so having a couple of fallbacks and a way to override it makes sense.
That said, I’ll verify that it works on a default Ubuntu install but no doubt someone will raise an issue if it’s broken on other distros.
I spent most of what little time I had yesterday trying to force setuptools to divulge what arguments were passed to it.
Very useful plugin for exploring the API.
Since the Jupyter developers are still loathe to add
--existing
capability to Jupyter notebook, would it be possible to optionally spawn the BN kernel in a Jupyter notebook instead of the qt console? This could then be used other supporting dev tools on that environment.