capa: migrate to PyGhidra

[darshan-crypto]

Hi @mike-hunhoff and @mandiant/flare-gsoc ,

I am Darshan sojitra. I'm interested in contributing to the "capa: migrate to PyGhidra" project for GSoC 2025. I've reviewed the project description and understand the goal is to migrate the capa Ghidra backend from Ghidrathon to PyGhidra for better long-term support and compatibility.

I have the necessary skills including Python programming, Capa tool, experience with Git/GitHub, and familiarity with Ghidra and its scripting capabilities.

I'd like to hear any initial guidance or suggestions from you and the team. Also, are there any specific areas of the migration that you'd recommend focusing on first?

Thank you.

[mike-hunhoff]

Hi @darshan-crypto , please review our contributor guidance and reach out here if you have any questions. This project will primarily focus on migrating the code found under https://github.com/mandiant/capa/tree/master/capa/features/extractors/ghidra so I'd recommend starting there while also reviewing capa's documentation, if you haven't already 😄

[darshan-crypto]

Hi @mike-hunhoff,

Thank you for your response! I've reviewed the contributor guidance, GSOC time management guide, and the code under capa/features/extractors/ghidra, and explored capa's documentation to understand its architecture and functionality.

To familiarize myself with the migration process, I tried migrating the is_supported_ghidra_version function in capa/ghidra/helpers.py to PyGhidra.This was just a test to understand how the migration will work and I successfully mitigated this function.

If you'd like, I can share the code snippet of the mitigated function for review to ensure I'm heading in the right direction. Let me know what you think!

Thank you.

[mike-hunhoff]

Great, feel free to share the code snippet here.

[darshan-crypto]

Hi @mike-hunhoff,

To familiarize myself with the migration process, I tried to migrate the is_supported_ghidra_version function in capa/ghidra/helpers.py to use PyGhidra.

Old Implementation (Ghidrathon)

def is_supported_ghidra_version():
    version = float(getGhidraVersion()[:4])  # type: ignore [name-defined] # noqa: F821
    if version < 10.2:
        warning_msg = "capa does not support this Ghidra version"
        logger.warning(warning_msg)
        logger.warning("Your Ghidra version is: %s. Supported versions are: Ghidra >= 10.2", version)
        return False
    return True

Above function was used in capa/ghidra/capa_explorer.py at line 349 as:

if not capa.ghidra.helpers.is_supported_ghidra_version():

In Ghidrathon, both the REPL and all Python modules had direct access to all Instance variables and methods of GhidraScript class. Here helpers.py can access getGhidraVersion function directly.

New Implementation (PyGhidra)

def is_supported_ghidra_version(ghidraScript: GhidraScript):
    version = float(ghidraScript.getGhidraVersion()[:4])  # type: ignore [name-defined] # noqa: F821
    if version < 10.2:
        warning_msg = "capa does not support this Ghidra version"
        logger.warning(warning_msg)
        logger.warning("Your Ghidra version is: %s. Supported versions are: Ghidra >= 10.2", version)
        return False
    return True

Now, this function is used in capa/ghidra/capa_explorer.py at line 349 as:

if not capa.ghidra.helpers.is_supported_ghidra_version(this):

Here this variable points to the GhidraScript Object.

In PyGhidra, the REPL has direct access to all instance methods and variables of the GhidraScript class. However, Python modules do not have this direct access.

In this case:

• helpers.py is a part of capa's Python module, meaning it does not have direct access to GhidraScript.
• capa_explorer.py, on the other hand, has direct access to the GhidraScript class.
• Since helpers.py is imported into capa_explorer.py, it must explicitly receive GhidraScript as an argument when calling its functions.

This migration was mainly to adapt to PyGhidra's behavior, where GhidraScript needs to be explicitly passed as an function argument.

Could you review this and let me know if I’m on the right track? Any feedback would be greatly appreciated!

Thank you for your support.

[mike-hunhoff]

That sounds reasonable 😄

[darshan-crypto]

Hi @mike-hunhoff,

As per your suggestion, I created a toy script to test whether my modification works in Ghidra Script Manager, and I can confirm that it works as expected. For your reference, I’ve attached video samples below:

Capa’s existing codebase with PyGhidra

https://raw.githubusercontent.com/darshan-crypto/gsoc2025/refs/heads/main/not_working.webm

Capa’s modified code with PyGhidra

https://raw.githubusercontent.com/darshan-crypto/gsoc2025/refs/heads/main/working.webm

As you can see, the original is_supported_ghidra_version function does not work in PyGhidra, but my modified version works correctly in Ghidra Script Manager. This confirms that the issue described in mandiant/capa#2600 is resolved.

I’d like to hear your thoughts on this!

[mike-hunhoff]

Awesome, please be sure to highlight this work in your final application, including any additional thoughts, discussion, ideas surrounding the migration.

[darshan-crypto]

Hi @mike-hunhoff,

I will add this in final appliacation and Where can I send my application for review?

Also, do you have any suggestions on how I can increase my chances of getting selected for GSoC?

Thank you.

[mike-hunhoff]

Please create a Google document and share it with [email protected]. We only have time to provide one review per application per project that is submitted at least 10 days prior to the application deadline so be sure it's mostly finalized when you share it.

Our contributor guidance lists all steps needed to apply to projects supported by our organization. I can't speak for other organizations 😄