[Bug][ghidra2cpg] Ghidra frontend does not support indirect jumps

[Ik0ri4n]

Describe the bug
The Ghidra frontend does not resolve indirect jumps or use Ghidra's analysis for that. Instead, the resulting control flow will simply miss the corresponding edges. The resulting CFG will contain disconnected branches.

This is especially relevant since indirect jumps are frequently used to implement switch-case-expressions. Any flow analysis on such a program will be incomplete.

To Reproduce
Steps to reproduce the behavior:

1. (Optional) Recompile with your compiler of choice
   • You need to verify that the program actually uses a jump table!
   • You may need to modify the program to force that!
2. Import the binary: importCode("../indirect-jump/test", "broken-jumps", language="GHIDRA")
3. Inspect the generated CFG: cpg.method("main").plotDotCfg

Expected behavior
The CFG contains edges for each case branch, if it can be recovered by Ghidra.

Screenshots

Desktop

• OS Ubuntu 25.04
• Joern Version 4.0.468
• Java Version 21.0.9
• GCC Version gcc (Ubuntu 14.2.0-19ubuntu2) 14.2.0 (used to compile the provided binary)

Attachments
test.zip
test.c

[Ik0ri4n]

This clearly corresponds to the missing implementation in JumpPass.

Considering the proclaimed "Maturity: High" of the Ghidra Frontend, I'd consider this a bug or at least relevant enough to be tracked in an issue.

For future reference: From a user perspective, a warning would be extremely useful in any such case. It would document the issue and prevent the issue going unnoticed.

[Ik0ri4n]

During the analysis of this bug and debugging of other errors with generated CPGs, I found two other bugs relevant for the correct and complete generation of CFGs. I believe that these bugs are important and may also be caused by structural issues in the code base.
I wanted to ask beforehand, whether you are interested in a discussion of these issues and what would be the best way to do so? I'd like to avoid creating multiple issues for similar topics.

Also, let me state in advance that I have a lot on my schedule until early June. I would like to help address the issues I found and potentially upstream fixes I implemented, if you are interested in that. Those fixes are temporary fixes though and would likely be better addressed by partial rewrites of the frontend, at least in my opinion. This would require a time commitment I cannot currently make.

Finally, please don't take the issues I described as personal critique. I believe that the Ghidra frontend is already quite powerful and am thankful that it exists. In fact, I did use it quite extensively recently (hence how I encountered these bugs) and it was a great help. Based on my experience, I do however believe that its stability and support for general binaries can be improved.

[psparc82]

During the analysis of this bug and debugging of other errors with generated CPGs, I found two other bugs relevant for the correct and complete generation of CFGs. I believe that these bugs are important and may also be caused by structural issues in the code base. I wanted to ask beforehand, whether you are interested in a discussion of these issues and what would be the best way to do so? I'd like to avoid creating multiple issues for similar topics.

Also, let me state in advance that I have a lot on my schedule until early June. I would like to help address the issues I found and potentially upstream fixes I implemented, if you are interested in that. Those fixes are temporary fixes though and would likely be better addressed by partial rewrites of the frontend, at least in my opinion. This would require a time commitment I cannot currently make.

Finally, please don't take the issues I described as personal critique. I believe that the Ghidra frontend is already quite powerful and am thankful that it exists. In fact, I did use it quite extensively recently (hence how I encountered these bugs) and it was a great help. Based on my experience, I do however believe that its stability and support for general binaries can be improved.

I've ran into the same indirect jump issue and its causing lots of issues. What did you implement to fix this?

[Ik0ri4n]

There are three issues I ran across so far:

1. The unimplemented jump handling I mentioned above
2. Missing edges to return nodes (e.g. X86FunctionPass; same for all function passes)
3. Connecting instructions with flow edges (there are a lot more cases than this one where flow is not linear; it usually is only within a block itself)

I have implemented temporary fixes for each of these by using the Ghidra decompiler API. I can likely publish those fixes on a fork by the end of this week. I hope that is acceptable for you. If so, I can ping you as soon as I released that.

The bugs above feel like symptoms of a larger issue, which is why I called my fixes temporary. While this is a Ghidra frontend, it mainly uses Ghidra for disassembly. This leads to lots of issues where decompiler analysis features are reimplemented with insufficient alternatives. Ultimately, I believe it would be the best to use the information Ghidra provides as much as possible to generate a complete and correct CPG.

[psparc82]

There are three issues I ran across so far:

1. The unimplemented jump handling I mentioned above

2. Missing edges to return nodes (e.g. [X86FunctionPass](https://github.com/joernio/joern/blob/master/joern-cli/frontends/ghidra2cpg/src/main/scala/io/joern/ghidra2cpg/passes/x86/X86FunctionPass.scala#L59); same for all function passes)

3. Connecting instructions with flow edges (there are a lot more cases than [this one](https://github.com/joernio/joern/blob/master/joern-cli/frontends/ghidra2cpg/src/main/scala/io/joern/ghidra2cpg/passes/x86/X86FunctionPass.scala#L42) where flow is not linear; it usually is only within a block itself)

I have implemented temporary fixes for each of these by using the Ghidra decompiler API. I can likely publish those fixes on a fork by the end of this week. I hope that is acceptable for you. If so, I can ping you as soon as I released that.

The bugs above feel like symptoms of a larger issue, which is why I called my fixes temporary. While this is a Ghidra frontend, it mainly uses Ghidra for disassembly. This leads to lots of issues where decompiler analysis features are reimplemented with insufficient alternatives. Ultimately, I believe it would be the best to use the information Ghidra provides as much as possible to generate a complete and correct CPG.

Publishing your fixes would be great, thank you for offering. It does feel like there are larger issues at play which are difficult to comprehend and lead to these types of bugs. I do wonder if that's the reason why ghidra2cpg development has stalled and sometimes the code feels half-baked. Any input from a Joern developer regarding this would be great

[Ik0ri4n]

@psparc82 The changes I made are available on my fork now.

Please note that these fixes are more or less small patches I made when I noticed an issue with something. They are not something I would merge as is. And of course, they are no full rewrite or restructuring. I was working on another project that needed specific features as input and I did not have time to thoroughly test my patches or design a proper fix.

For example, I am not sure if some of the changes I made in the X86FunctionPass and the JumpPass introduce multi-edges. I did not check because my use case filtered them out anyways, if there ever were any.
Also, I often fixed stuff in the way that worked best for me at the moment. If you have other requirements, you may need to generalize some things or introduce some other patches.

I do believe, however, that these patches improve the overall quality of the generated CPGs and can be an example of how the Ghidra API could be utilized to properly extract the analysis information we need for CPG generation while relying on the decompiler to do the heavy lifting and provide flexibility across architectures.