emesare / binja-msvc Goto Github PK

With the components view now being stable enough to enable by default, we should add all symbols to their respective namespaces.

Similar to #28 this focuses mainly on the fact that at ~40k links in the DOT file its never going to render. We need a better solution to visualize the class hierarchy.

Now that stable binaryninja has supported APIs we can move binaryninja-api out of tree and have the CI build for multiple versions. This will likely involve us manually marking the ABI for each tagged version we pull from binaryninja-api. The python loader will also need to be updated to accommodate this by providing the correct build for the users ABI version.

I recently realized (tried to load x64 binary on arm mac lol) that CI does not build for arm platforms. This should be easy to solve.

Right now every test of the release action creates a patch commit that is... annoying. Would be nice to have a dry run version that doesn't actually do anything but pull the build artifacts and put it in a new artifact bundle, one that reflects the release bundle.

This is more so useful for people looking at this repository as a reference for building a native Binary Ninja plugin.

Tagging virtual functions will allow later processes to identify a virtual function apart from its place in a virtual function table, further reducing the work required.

Using github actions we can build the plugin for every supported binja platform and push to github releases for easy installation.

Our CompleteObjectLocator scanner will skip COL_SIG_REV0 colocators, fixing this should allow scanning of 32bit binaries.

You may want to put a license on this repo so that others may use the code

This will require that we have a python frontend that can automate the process of locating and downloading the correct version of the native plugin for the respective version. We would also need to ensure that those releases are not tampered with, possibly checking to make sure that the release artifact was published by a GitHub action, ensuring that binary's code is of the checked-out commit.

Identifying heap constructors will greatly help in generating better class object types as member variables might be assigned in these functions.

If I want to try your plugin with Binary Ninja, how do I do it?

I see you have based the github actions build for this off of https://github.com/CouleeApps/binja-ci-tests/blob/master/binja.patch and I just wanted to let you know that the Windows build this patch produces does not actually work... https://github.com/CouleeApps/binja-ci-tests/issues/1

I haven't had time to go figure out what the correct solution is, but just a heads up in advance that this is a known issue.

In case of COL_SIG_REV1, RTTI will store relative pointers, we should add the appropriate cross references for these.

Generate a graph for constructors as well as for vtables, in case of no RTTI the vtable graph should group together all vtables which share a virtual function.

Using our RTTI information we can identify and symbolize both the throw metadata and the attached catch routine. This should be done in two passes. First pass should symbolize the throw metadata and the second pass should rewrite callsite to illustrate the branching, possibly with an xref to the catch routine and for the non-catch routine we should just be able to make the throw function returnable.

The end result should look something like this, the throw is highlighted orange to illustrate it could jump to the catch routine instead of continuing. Not sure how "correct" this is.

See: https://github.com/emesare/binja-msvc/pull/10/checks

For more information on why: https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

The solution is still unclear, I would like to at least be able to manually request that an action be ran.

Currently RTTI must exist in the binary for vtables to be defined, however we should add the ability to atleast manually create a vtable and possibly scan the entire binary for possible vtables automatically.

This isn't hard however accompanying this we should really cleanup the code so that we are not so dependent on previously ran commands.

The built-in binary ninja MS demangler has improved recently and it now demangles all necessary names. Removing the need for the bundled LLVM demangler.

Right now we freeze binja when we run the RTTI scan (on larger binaries ofc)

The cause of this comes from the VirtualFunction::IsUnique and the subsequent retyping of said virtual function.

There is major lock contention happening inside the callee VirtualFunctionTable::GetCOLocator, this is the reason analysis has been slow ever since class types creation was moved to the first pass.

Example: of the ~23 seconds profiled 91% of that time is spend in VirtualFunction::IsUnique.

The python loader needs to read the ABI version from the release.