Fix Ghidra 11.2 renamed package and class

[v-p-b]

This fixes #43 for me

[joxeankoret]

Thank you very much @v-p-b

[clearbluejar]

nice one! Just rebuilding some docker images and found this same issue

[clearbluejar]

Also might need the code to handle old versions? Not sure if it would require two versions of the plugin, or something like https://github.com/dod-cyber-crime-center/pyhidra/blob/c878e91b53498f65f2eb0255e22189a6d172917c/pyhidra/core.py#L169-L172

[v-p-b]

Also might need the code to handle old versions? Not sure if it would require two versions of the plugin, or something like

I thought that would be an easy one because I can dynamically import stuff in Python, but if you look at the current diff you see

• that it is Java, and
• you'd need to dynamically define a base class :S

I don't think this can be done at least without creating a terrible mess...

[clearbluejar]

@dc3-tsd will know best, but if a dynamic change to the java base class is needed to support 11.2, there might need to be two versions of the plugin / java base class. This could potentially be handled in the start method, just install the plugin version based on the version of Ghidra being used?

https://github.com/dod-cyber-crime-center/pyhidra/blob/c878e91b53498f65f2eb0255e22189a6d172917c/pyhidra/launcher.py#L288-L293

if ghidra_ver >= 11.2:
    install_new
else:
    install_old

[dc3-tsd]

Thank you for reaching out about this and we're sorry for the confusion.

This change of behavior was a side effect of our efforts to integrate Pyhidra into Ghidra directly as PyGhidra. Some of the changes that made this work possible were put into the 11.2 release of Ghidra and were backwards breaking for Pyhidra. As such we just uploaded Pyhidra 1.3.0 which includes a set of changes that will allow us to keep it running in the current state until PyGhidra goes fully live as a native part of Ghidra.

[clearbluejar]

PyGhidra goes fully live as a native part of Ghidra

This is amazing!