Ghidra: Ghidra extension development workflow

[jroimartin]

I'm developing an extension for Ghidra that basically includes the following components:

• Library (/src/main/java): with several packages, where most of the functionality is implemented.
• Ghidra scripts (/ghidra_script): multiple scripts that depend on the previous library.

I'm using the GhidraDev plugin for developing this library, but I find myself repeating the following steps once and again:

1. Edit code in Eclipse
2. Run Ghidra via Eclipse's "Run Configuration" or "Debug Configuration"
3. Wait for Ghidra to start
4. Run script
5. Check results
6. Close Ghidra
7. Go to step 1

Spawning a Ghidra instance every time I want to test changes slows down this workflow. Of course, when I'm just editing a script, I don't have to close Ghidra and re-run. But, when I'm editing parts of the library, changes are not reflected until Ghidra is restarted.

In debug mode, I can use hot swapping to test small changes without restarting Ghidra, but this is very limited. For instance, hot swapping does not support adding new methods to a class.

I tried to decouple the library as much as possible from Ghidra, so I can test parts of the library independently. But, at the end of the day, I still find my self launching Ghidra quite a lot to check that my changes work with my target. The same happens with components like Loaders, Analyzers, etc. that are necessarily coupled to Ghidra.

Is this the proper workflow when developing extensions? Can I test new changes in a faster way?

[jroimartin]

Keeping the CodeBrowser (in the proper address) and the Script Manager open when I close Ghidra speeds up the testing phase quite a bit. This way I don't have to repeat the "setup" every time I run a new instance. But I would still like to know if the workflow I described is right or I'm missing something.

[ryanmkurtz]

That's always been my workflow. You could also try launching Ghidra headlessly if you don't always need to look at the GUI. Something even faster than headless would be writing JUnit tests (there are many examples in the Ghidra repo). There would be some overhead in getting that working correctly, but the pain might be worth it to you if your current workflow is problematic. If you did that, you'd have the added benefit of having functional unit tests in the end.

[astrelsky]

Utilizing JUnit tests is definitely the best approach. Albeit a bit messy if you would like to see an example of an external ghidra extension with JUnit tests you can take a look here. The setup method in GenericRttiTest is to ensure all of Ghidra's classes are loaded. You may need to do that, you might not. I don't exactly remember why I had to do so and it's my own fault for not commenting why.

[jroimartin]

Thanks for your answers. I've adapted my scripts to run then headlessly and it's working perfectly for my use-case. I will definitely look into writing JUnit tests also for the Ghidra-related code.