Ghidra: Patch folder not completely functional

[astrelsky]

Describe the bug
Using the patch folder is not fully functional. While the classes are indeed added to the classpath, they don't necessarily get used.

To Reproduce
Steps to reproduce the behavior:

1. Add a new class in Ghidra/Features/Base/src/main/java/ghidra/app/util/exporter extending Exporter.
2. Compile the jar and drop the new Base.jar into the patch folder.
3. Start ghidra and go to export a program.
4. Notice exporter not in list of exporters.
5. Open python
6. Enter ghidra.app.util.exporter.{new exporter class}
7. See <type 'ghidra.app.util.exporter.{new exporter class}'> returned
8. Exit ghidra, move Base.jar from the patch folder and into its correct path.
9. Repeat step 3 and see new exporter.

Environment (please complete the following information):

• OS: Microsoft Windows [Version 10.0.18363.628]
• Java Version: 13.0.2
• Ghidra Version: 9.2

Additional context
This might only affect ExtensionPoints but I cannot say for sure yet. This has been around for a while but I've always written it off as something on my end. Since I saw the new classes were in the classpath I'm sure now that it isn't.

[ryanmkurtz]

I probably broke this when I did the extension point priority stuff.

[astrelsky]

I probably broke this when I did the extension point priority stuff.

I'm not to sure about that. I recall having difficulty with it when writing the gcc rtti analyzer over the summer.

[dragonmacher]

Confirmed.

The ClassSearcher is not scanning jar files from the patch directory in development mode. Further, this is fallout from a change I put in long ago.

[dragonmacher]

I am testing a fix now. In the meantime, if you need this functionality, you can try adding the following system property:
-Dclass.searcher.search.all.jars=true'

[ryanmkurtz]

What should the behavior be between extension point priority and patch directory? Which should be more important?

[astrelsky]

What should the behavior be between extension point priority and patch directory? Which should be more important?

I would think classes in the patch directory would need to be found first and then only insert everything else found if the list doesn't contain it, and then sort by priority. This way extension points can be patched too. If they are added before or after sorting then the same prior issue would be encountered.

I am testing a fix now. In the meantime, if you need this functionality, you can try adding the following system property:
-Dclass.searcher.search.all.jars=true'

I took a quick look at the class searcher to check what container the classes are put in and happened to notice that the class searcher isn't using the SEARCH_ALL_JARS field. I'm not sure if the option would make a difference as far as the class searcher is concerned unless a parameter comes as a result of the field. I don't have time to check tonight though.

[dragonmacher]

I took a quick look at the class searcher to check what container the classes are put in and happened to notice that the class searcher isn't using the SEARCH_ALL_JARS field. I'm not sure if the option would make a difference as far as the class searcher is concerned unless a parameter comes as a result of the field. I don't have time to check tonight though.

The ClassJar class uses it as part of its filtering criteria. I have not tried it,but it passes the eyeball test.

What should the behavior be between extension point priority and patch directory? Which should be more important?

I am operating with the assumption that patch rules all. I have always used this as a means to make the contained code the highest priority.

[astrelsky]

Out of curiosity, is it possible to have .class files loaded directly instead of needing to be in a .jar file? It could make minor quick changes relatively easy outside of a debug environment.

[dragonmacher]

Out of curiosity, is it possible to have .class files loaded directly instead of needing to be in a .jar file? It could make minor quick changes relatively easy outside of a debug environment.

The code used to support this in the past. I cannot recall at the moment why we stop supporting that feature.

[GhidorahRex]

Fixed in 9f66126cef10642b1a56cd2721968b10911af3c7