migrate Ghidra backend from Ghidrathon to PyGhidra

[williballenthin]

Ghidra 11.3 was recently released with the built-in PyGhidra Python API bindings: https://github.com/NationalSecurityAgency/ghidra/blob/Ghidra_11.3_build/Ghidra/Configurations/Public_Release/src/global/docs/WhatsNew.md#pyghidra

We should consider migrating capa's Ghidra backend from Ghidrathon, which is a third-party binding that requires installation and maintenance, to PyGhidra. We'd want to ensure the performance remains acceptable (PyGhidra relies on JPype). Otherwise, I expect the migration to be fairly straightforward, particularly because of our unit tests.

[akh7177]

Hello! @colton-gabertan @williballenthin

This project is still one of the projects under GSoC 2025 right?

[colton-gabertan]

Hi @akh7177 !

Looks like it should be. You can check out the current project ideas here:

https://github.com/mandiant/flare-gsoc/blob/2025/doc/project-ideas.md

Seems that this year's will involve creating a full plugin for the ghidra backend as well as porting it over to PyGhidra :). @mike-hunhoff should know more.

[akh7177]

Hi @colton-gabertan ,

Thanks for the reply! I'm planning to take that up and I saw it was already assigned to you, so just dropped in a message to check it out 😸

[colton-gabertan]

I got the chance to tinker with this idea and rooted out a key difference between the Ghidrathon environment vs. the PyGhidra one.

Ghidrathon maintains the GhidraScript state variables, preserving the context in which capa modules are able to work with (i.e. currentProgram and FlatProgramAPI methods; however, PyGhidra implemented direct access which entails having to initialize the context each time a capa module would have to access them.

See: https://github.com/mandiant/Ghidrathon/tree/main?tab=readme-ov-file#writing-ghidra-python-3-scripts

Example issue:

$ pyghidra ../../desktop/test/pma01-01.exe

Python Interpreter for Ghidra 11.3.1 PUBLIC
Python 3.12.3 (main, Feb  4 2025, 14:48:35) [GCC 13.3.0] on linux
>>> from capa.ghidra.helpers import is_supported_ghidra_version
>>> is_supported_ghidra_version()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/gaber/ghidra_scripts/capa/capa/ghidra/helpers.py", line 73, in is_supported_ghidra_version
    version = float(getGhidraVersion()[:4])  # type: ignore [name-defined] # noqa: F821
                    ^^^^^^^^^^^^^^^^
NameError: name 'getGhidraVersion' is not defined
>>> getGhidraVersion()
'11.3.1'

using the same runtime environment, getGhidraVersion() is available to the repl's context, but not the capa module. To initalize it, PyGhidra's docs suggest using with pyghidra.open_program('sample.exe') as flat_api in order to access the method from capa's module.

I have a feeling this might need a wrapper similar to the one from Ghidrathon