search

NationalSecurityAgency / ghidra

Ghidra is a software reverse engineering (SRE) framework
https://www.nsa.gov/ghidra
Apache License 2.0
51.12k stars 5.82k forks source link

Gradle Plugin (GhidraDev Backend) #3050

Open astrelsky opened 3 years ago

astrelsky commented 3 years ago

Is your feature request related to a problem? Please describe. While the use of Eclipse for development isn't a problem for the dev team, having the GhidraDev plugin only support Eclipse is something many users aren't fond of.

Describe the solution you'd like Create a Gradle plugin which would serve as the GhidraDev plugin backend. It could be placed in the support folder and be used in place of the buildExtension.gradle script. Having the plugin setup the project for modules, plugins, scripts, etc would be a big step forward for users in the community that wish to create a dev plugin for their favorite ide.

Describe alternatives you've considered Use Eclipse.

garyttierney commented 3 years ago

FYI, I put this together to help with development of Ghidra things in IDEA: https://github.com/garyttierney/intellij-ghidra. I'd be happy to help work on something more general.

astrelsky commented 3 years ago

FYI, I put this together to help with development of Ghidra things in IDEA: https://github.com/garyttierney/intellij-ghidra. I'd be happy to help work on something more general.

I remember seeing that in the past and thought it was similar to how I am doing it for vscode. What you have now is more advanced I think. I would have gone further with vscode, but uh typescript...

Anything that uses the eclipse.jdt.ls really just needs gradle eclipse to properly setup the .project and .classpath files. Everything else is just setting launch arguments and then ide specific stuff.

garyttierney commented 3 years ago

Anything that uses the eclipse.jdt.ls really just needs gradle eclipse to properly setup the .project and .classpath files. Everything else is just setting launch arguments and then ide specific stuff.

I think that sounds like a good approach. You could generate a build.gradle inside your user_scripts folder which loads the plugin to get a nice editor experience out of the box. Extensions could have a Gradle task to launch Ghidra with the newly built extension included (by including it on the classpath, similar to what I do in intellij-ghidra) and Scripts could have a Gradle task to attempt to run the script in a running Ghidra instance as a first pass.

What do you think of that?

astrelsky commented 3 years ago

The build.gradle would be generated by the gradle plugin. What I was thinking was you would just do gradle init and then the Ghidra project types would be an option. All that would be left for ide plugins to do would be to use that and setup launching. I'm not sure how well it would work out for having gradle launch Ghidra but it could definitely provide things like the proper vmargs and such. This way if there need to be certain arguments for an ide they can be appended.

agatti commented 3 years ago

Out of curiosity, would this enable being able to straight import Ghidra as a Gradle project and have IntelliJ resolve internal paths correctly? Right now scripts and processor analysis code cannot resolve symbols and there are other intra-module dependencies that aren't picked up.

garyttierney commented 3 years ago

Out of curiosity, would this enable being able to straight import Ghidra as a Gradle project and have IntelliJ resolve internal paths correctly? Right now scripts and processor analysis code cannot resolve symbols and there are other intra-module dependencies that aren't picked up.

Do you have an example of processor analysis code that isn't resolving correctly? As far as I can tell this is working fine for me in IntelliJ. Maybe I've misunderstood, but I'm checking the modles inside Ghidra/Processors. That aside, making scripts "just work" when you open them in your favorite Gradle supporting IDE would be a goal of mine here. I'm not sure if that's also what @astrelsky is going for with the project types solution (scripts project, extension project, SLEIGH module project?).

astrelsky commented 3 years ago

Sleigh is something different but it should work out for all the java projects.

agatti commented 3 years ago

@garyttierney turned out my project that I kept updating all this time either had its indices corrupted along the way or things have been fixed in the latest version of IntelliJ. I've tried with a fresh clone after updating to IntelliJ 2021.1.2 and indeed things seem to work ok on the symbol resolution front, bar script issues that are already known to be there.

agatti commented 3 years ago

@garyttierney spoke too soon. Just found a case of missing inter-module dependency. It all started when trying to see why IntelliJ reported errors on missing javadoc references in ghidra.app.merge.MergeProgressModifier - and turns out that ghidra.app.merge.MergeResolver (from Base) is hidden in Project:

Screenshot 2021-06-06 at 02 57 50

Trying to create variables of type MergeResolver in Project fails, even when fully specifying the package name:

Screenshot 2021-06-06 at 03 00 18