Support Python3 in Ghidra, drop ghidra_bridge

[mahaloz]

Closes #73 and bumps to the next major version.

[mahaloz]

Two separate issues may have killed this attempt:

No Subclassing Java Classes

1. Support for Java class extension from within Python jpype-project/jpype#420

This affects the following line(s):

libbs/libbs/decompilers/ghidra/hooks.py

Line 185 in 40bc932

class GenericDecompilerCtxAction(ProgramLocationContextAction):

This would mean libbs can no longer be used at all to make GUI callback classes unless we can find a workaround.

Implementing Java Classes is Thread Dependent (?)

2. Implementing listening classes don't trigger in seperate threads dod-cyber-crime-center/pyhidra#41

It's possible there is a workaround for this. If not, then we no longer can do this:

libbs/libbs/decompilers/ghidra/hooks.py

Line 17 in 40bc932

class DataMonitor:

That would mean we can no longer detect when any Artifact is changed, which means no caching or special change handling. This also makes the approach dead for BinSync proper.

---

I'll wait for a response from the Pyhidra dev's to see if this PR is dead in the water.

[mahaloz]

Based on the current commit, the following works in UI mode:

from libbs.api import DecompilerInterface
deci = DecompilerInterface.discover()
print(deci.functions.values())

It currently takes about 2 seconds to collect all the functions in light mode!

[mahaloz]

Headless mode now works:

from libbs.api import DecompilerInterface
deci = DecompilerInterface.discover(headless=True, force_decompiler="ghidra", binary_path="./posix_syscall")
for addr, light_func in deci.functions.items():
    print(light_func)
    print(deci.functions[addr]) # decompilation!

After headless is initiated, it takes only 0.7340998649597168 seconds to iterate and decompile every function!

[mahaloz]

Headless mode now works with project loading:

from libbs.api import DecompilerInterface
# load from a project should be 5x faster on this binary after loading once. 
deci = DecompilerInterface.discover(
    headless=True, force_decompiler="ghidra", binary_path="./posix_syscall"
    project_location=".", project_name="posix_syscall_ghidra", analyze=False
)
for addr, light_func in deci.functions.items():
    print(light_func)
    print(deci.functions[addr]) # decompilation!

This is also on CI:

libbs/tests/test_decompilers.py

Line 154 in 104cd93

def test_ghidra_project_loading(self):

[mahaloz]

Summary of PR

This pull request was closed and replaced by #84 since we were unable to fully replace ghidra_bridge backend with pyhidra. The following problems killed the full replacement:

1. Inconsistent thread artifact changer callbacks, which was related to Support Python3 in Ghidra, drop ghidra_bridge #82 (comment). This manifested as inconsistent events being generated when changing something like a function name.
2. Inability to use PySide6 inside pyhidra's interpreter. This problem took a lot of time to debug, and I never fully found the reason. It only manifested on Mac and could be generated with the following code in Pyhidra:

from PySide6.QtWidgets import QApplication
QApplication()

This caused a segfault.

Since libbs is used by other downstream plugins for decompilers, which rely on Qt being available, 2 was the real killer.

I will leave this branch alive since, in its current state, it is usable inside the UI, just without QT and those callbacks being consistent.