Bug: PyGhidra incorrectly appends project_name to project_location causing project loading failure

[0x4l3x]

Bug: PyGhidra incorrectly appends project_name to project_location causing project loading failure

Describe the bug

There is a critical bug in the PyGhidra package (on PyPI) where an existing Ghidra project cannot be loaded because of an incorrect path manipulation. Specifically, at line 100 in Ghidra/Features/PyGhidra/src/main/py/src/pyghidra/core.py, the code project_location /= project_name incorrectly appends the project name to the project location. This prevents loading existing projects, as Ghidra's internal engine already concatenates the project path and name when locating a project.

To Reproduce

The issue can be reproduced in two ways:

Prerequisite

1. First create a Ghidra project and (optional) insert and auto-analyze a binary:
2. Ensure all required PyGhidra configurations have been made (GHIDRA_INSTALL_DIR environment variable is set, etc.)
3. Create a dummy python script, so everything works.

Method 1: Using Python API

import pyghidra
pyghidra.run_script(
    binary_path=None,
    script_path="/home/ghidra/ghidra_scripts/count_binaries.py",
    project_location="/home/ghidra",
    project_name="project_a",
    analyze=False,
)

Method 2: Using CLI

pyghidra --project-location="/home/ghidra" --project-name="project_a" --script="/home/ghidra/ghidra_scripts/count_binaries.py"

Expected behavior

PyGhidra should correctly load an existing project by using the provided project location and name as separate parameters. The internal Ghidra engine is designed to handle the concatenation of these paths.

Actual behavior

The code at line 100 causes project_location to be modified to include project_name twice:

1. First in the PyGhidra code (line 100): project_location /= project_name
2. Then again when Ghidra internally concatenates the path

If you add a debug statement print(project_location, "------", project_name) after line 100, you'll see output like:

/home/ghidra/project_a ------ project_a

This causes PyGhidra to never find the existing project and instead creates a new one at the incorrect path /home/ghidra/project_a/project_a.

Proposed fix

The fix is straightforward: remove line 100 from Ghidra/Features/PyGhidra/src/main/py/src/pyghidra/core.py:

# Remove this line:
project_location /= project_name

After removing this line, I confirmed that PyGhidra correctly opens the existing project at /home/ghidra/project_a and the script runs as expected without any errors or creating duplicate projects.

Environment

• OS: Ubuntu 24.04
• Java Version: 21.0.7
• Ghidra Version: 11.3.2
• Ghidra Origin: Official GitHub distribution
• Python: 3.11
• PyGhidra version: 2.1.0 (from PyPI)

Additional context

This issue makes PyGhidra unable to work with existing projects when using either the Python API or CLI interface, which significantly impacts automation workflows that depend on script execution against existing projects.

[ryanmkurtz]

Thanks, I'll look at this on Tuesday.

[ryanmkurtz]

I agree that the extra directory that PyGhidra creates/expects is odd, and inconsistent with how Ghidra-proper expects things to be laid out. I assume the creators of PyGhidra expected it to work more with projects created by PyGhdira, rather than existing projects. Regardless, I'll look into getting it fixed.

[ryanmkurtz]

I'm thinking I'll just add another optional parameter to pyghidra.open_program() that if set, will not append the project name. Maybe call it something like nested_project_location=True to maintain backwards compatibility, but if set to False will make it work the way you want it to. How does that sit with you?

Ultimately i'd like to deprecate these methods in favor of some new ones that I'm working on.

[0x4l3x]

Thanks for diving into this. Since you’re already planning to deprecate these methods, feel free to pick the approach that best fits your roadmap. A temporary nested_project_location flag serves as a workaround, but removing the project_location /= project_name line may be easier. Anyway, you know the codebase and the framework far better than I do, so I trust your judgment on which path to take :).

Thanks again for all your work on ghidra!!