ghidra: enable feature extraction from existing Ghidra project binary

[mike-hunhoff]

Currently, the Ghidra backend creates a new project and loads the target binary for a fresh analysis. We should enable users to specify an existing Ghidra project binary, e.g. to load a sample that has already been analyzed, annotated, etc.. This saves analysis time, and enables annotations to be used for analysis.

[saniyafatima07]

Hello @mike-hunhoff,
I'm interested to work on this issue.
Could you please assign it to me?

[mike-hunhoff]

@saniyafatima07 sure thing! Please devise a plan and discuss it with us here before you start writing any code. I've assigned this issue to you.

[saniyafatima07]

@saniyafatima07 sure thing! Please devise a plan and discuss it with us here before you start writing any code. I've assigned this issue to you.

Sure, thank you @mike-hunhoff.

[saniyafatima07]

Hello @mike-hunhoff ,

I am planning to implement this feature with the following approach.

In main.py:

• Add CLI arguments in install_common_args():
  • --ghidra-project-dir
  • --ghidra-program-path
• Parse and forward these arguments through get_extractor_from_cli().
• Include these options in the main parser setup where common args are registered.
• Pass the values to capa.loader.get_extractor().

In loader.py:

• Extend get_extractor() with optional parameters:
  • ghidra_project_dir: Optional[Path] = None
  • ghidra_program_path: Optional[str] = None
• Add validation:
  • If one Ghidra option is set, require both.
  • If these options are set with a non-Ghidra backend, fail early.
• Add a branch for existing Ghidra project usage.
• Keep existing behavior unchanged as default.
• In existing-project mode:
  • open project with create=False
  • skip temp project creation/import/re-analysis
  • load program via consume_program using ghidra_program_path
  • skip tmpdir cleanup for this path
• Keep the same extractor return path so downstream behavior remains unchanged.

Then I will test both paths:

• Existing behavior (new temp project/import/analyze) still works unchanged.
• New behavior (load existing project/program) works as expected.

Please do let me know if this approach sounds valid.
Thank you!

[mike-hunhoff]

Hello @mike-hunhoff ,

I am planning to implement this feature with the following approach.

In main.py:

• Add CLI arguments in install_common_args():

  • --ghidra-project-dir
  • --ghidra-program-path

• Parse and forward these arguments through get_extractor_from_cli().

• Include these options in the main parser setup where common args are registered.

• Pass the values to capa.loader.get_extractor().

In loader.py:

• Extend get_extractor() with optional parameters:

  • ghidra_project_dir: Optional[Path] = None
  • ghidra_program_path: Optional[str] = None

• Add validation:

  • If one Ghidra option is set, require both.
  • If these options are set with a non-Ghidra backend, fail early.

• Add a branch for existing Ghidra project usage.

• Keep existing behavior unchanged as default.

• In existing-project mode:

  • open project with create=False
  • skip temp project creation/import/re-analysis
  • load program via consume_program using ghidra_program_path
  • skip tmpdir cleanup for this path

• Keep the same extractor return path so downstream behavior remains unchanged.

Then I will test both paths:

• Existing behavior (new temp project/import/analyze) still works unchanged.
• New behavior (load existing project/program) works as expected.

Please do let me know if this approach sounds valid. Thank you!

Thank you @saniyafatima07 , overall, this sounds like a good approach.

To keep the interface clean and avoid adding new command-line arguments, I'd prefer we leverage the existing input_file argument by detecting when a Ghidra project is supplied. We can check if the path contains .gpr and parse it to extract both the project location and the specific program path inside it. This keeps the CLI simple while providing the necessary flexibility for analyzing existing projects.
Here are a few options for how we could format the input name to support this:

• Option 1 (Path-like): /path/to/project.gpr/folder/program (We look for .gpr in the path and treat everything after it as the program path inside the project).
• Option 2 (Separator): /path/to/project.gpr:folder/program (Using a colon to separate the project file from the program path).

I lean towards option 2, thoughts @saniyafatima07 @williballenthin @mandiant/capa-dev ?

[saniyafatima07]

Hello @mike-hunhoff ,
I am planning to implement this feature with the following approach.
In main.py:

• Add CLI arguments in install_common_args():

  • --ghidra-project-dir
  • --ghidra-program-path

• Parse and forward these arguments through get_extractor_from_cli().

• Include these options in the main parser setup where common args are registered.

• Pass the values to capa.loader.get_extractor().

In loader.py:

• Extend get_extractor() with optional parameters:

  • ghidra_project_dir: Optional[Path] = None
  • ghidra_program_path: Optional[str] = None

• Add validation:

  • If one Ghidra option is set, require both.
  • If these options are set with a non-Ghidra backend, fail early.

• Add a branch for existing Ghidra project usage.

• Keep existing behavior unchanged as default.

• In existing-project mode:

  • open project with create=False
  • skip temp project creation/import/re-analysis
  • load program via consume_program using ghidra_program_path
  • skip tmpdir cleanup for this path

• Keep the same extractor return path so downstream behavior remains unchanged.

Then I will test both paths:

• Existing behavior (new temp project/import/analyze) still works unchanged.
• New behavior (load existing project/program) works as expected.

Please do let me know if this approach sounds valid. Thank you!

Thank you @saniyafatima07 , overall, this sounds like a good approach.

To keep the interface clean and avoid adding new command-line arguments, I'd prefer we leverage the existing input_file argument by detecting when a Ghidra project is supplied. We can check if the path contains .gpr and parse it to extract both the project location and the specific program path inside it. This keeps the CLI simple while providing the necessary flexibility for analyzing existing projects. Here are a few options for how we could format the input name to support this:

* **Option 1 (Path-like):** `/path/to/project.gpr/folder/program` (We look for `.gpr` in the path and treat everything after it as the program path inside the project).

* **Option 2 (Separator):** `/path/to/project.gpr:folder/program` (Using a colon to separate the project file from the program path).

I lean towards option 2, thoughts @saniyafatima07 @williballenthin @mandiant/capa-dev ?

Thank you for the suggestion @mike-hunhoff .
I agree with the usage of option 2 in this scenario.

Shall I proceed with the implementation or wait for the opinions?

[mike-hunhoff]

Feel free to proceed 🙂