Resources in the `data` extension directory aren't available from Ghidra run configurations.

[agatti]

Describe the bug:

As per subject, accessing resources bundled in an extension's data/ directory is not possible from a Ghidra run configuration. Application.getModuleDataFile and similar functions in the Ghidra framework will fail as they will search for files in the compiled classes root (usually under build/classes/{kotlin,java}/main) rather than in the root of the zip file the extension is packaged as (see Application.getMyModuleRootDirectory in ghidra.framework).

Steps to reproduce:

Put some files in an extension's data/ directory and try to access them from your extension code.

Expected behavior:

The extension can access the bundled files correctly.

Additional context:

I suppose this also affects extensions that package their own Sleigh files which, coincidentally, should be put in the data/ directory as well. I was going to see how to have the IntelliJ plugin launch Ghidra with custom Sleigh files in an extension at a later stage but I stumbled on this issue earlier than I thought.

Now, I'm not sure if this is something that should be handled on the plugin's side by copying or linking the data/ directory in the appropriate place or if it is the Gradle build script's task to do that. I guess either way works for me, but one has to remember to add the copy/link operation in the Gradle script on every project as it is not part of the generated template (and I cannot really fault Ghidra's developers for that...).

[garyttierney]

Hm, I see. I assume this is only happening with extensions that aren't yet installed as a .zip and are being loaded from the class loader the plugin creates?

If I'm understanding correctly then I think it's a common enough case that we can have the run configuration copy the data/ folder if it exists as a pre-launch task if it wasn't found in the Gradle task listing (or if the user isn't building with Gradle).

[agatti]

Yes, this only applies to extensions being loaded from the plugin's classloader.

However things are a bit more complicated than I expected. Ghidra's loader is using the base path of the class file that is opening the data file. For a packaged extension this is fine as classes are all in one place, but on an unpacked extension classes might be in multiple places inside the $buildDir directory.

So for example, with Gradle, if a Java class is calling Application.getMyModuleRootDirectory Ghidra will look at $buildDir/java/$sourceSet, if a Kotlin class/file does the same the target path will be $buildDir/kotlin/$sourceSet, Scala will use $buildDir/scala/$sourceSet, and so on. Same goes for tests, of course, but with a different source set.

[garyttierney]

Ah, that's tricky. I think the easiest way forward might be to copy all build outputs to a single build directory or see if there's any way to get the pre-Gradle 5.0 behavior of a single build directory back without violating any of the users' expectations on how things are assembled.

I'll put together a patch later based on the former idea as a workaround, though it'd be nice to avoid what could potentially be a substantial amount of unnecessary IO.

[agatti]

Actually I might have spoken a tad too soon :( Turns out there are a couple more places in Ghidra where modules are registered - I'll keep looking and I'll see if this can be fixed without having to patch Ghidra's source first.

[agatti]

Basically the fastest way to get this done would be to patch GhidraApplicationLayout.findExtensionInstallationDirectories to accept additional directories either via command line parameters to the main launcher, java properties set in the launcher or through environment variables. I guess I'll have to make the changes and, if they work, push them upstream before any change in the plugin would be necessary.

[garyttierney]

Hey @agatti, if you're still working with Ghidra do you know if this has changed at all from the Ghidra side? I'm looking at what you've suggested above r.e. adding an additional installation directory and wondering if there's any simpler route forward now.

[agatti]

I haven't looked at it with recent Ghidra versions to be honest, but I think nothing really changed. I solved this in code by creating a symlink to /data in <module>/src/main/resources and loading resources with the following snippet.

private const val MODULE_NAME = "..."
private val RESOURCES_ROOT_PATH = Path("/data")
private class DummyResourceAnchorClass

fun getExtensionResourceFile(path: Path): File? = getExtensionResourceFile(path.toString())

@Throws(URISyntaxException::class)
fun getExtensionResourceFile(path: String): File? =
    try {
        Application.getModuleDataFile(MODULE_NAME, path)?.getFile(true)
    } catch (_: FileNotFoundException) {
        DummyResourceAnchorClass::class
            .java
            .getResource(RESOURCES_ROOT_PATH.resolve(path).toString())
            ?.let { url -> File(url.toURI()) }
    }