search

NationalSecurityAgency / ghidra

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

Broken stack analysis on ARM for Ghidra extension after latest 9.2.X releases #2785

Closed pedro-javierf closed 3 years ago

pedro-javierf commented 3 years ago

Describe the bug Stack analysis on an ARM binary fails with a NullPointerException in the latest Ghidra stable releases (9.2 and 9.2.2).

To Reproduce Steps to reproduce the behavior:

  1. Install NTRGhidra extension (a loader for Nintendo DS games and homebrew)
  2. Analyse the ARM9 binary of any commercial game with the Stack anaylisis option enabled (it is enabled by default)
  3. Analysis will take too much time, finally raising a NullPointerException

Expected behavior A successful analysis. On the previous Ghidra stable release (9.1.2) the same extension worked correctly.

Screenshots image GUI Error Window does not provide much information

image Part of the stack trace seen in the eclipse debugger (full trace below)

Attachments

Any commercial game seems to be useful to reproduce the steps. Cannot link to them because of copyright, but some nds game examples are: FIFA 11 Soccer, Rhythm Heaven, etc.

Environment (please complete the following information):

Additional context

The same extension worked fine on Ghidra 9.1.2 thus there must be some changes in Ghidra or the FlatAPI that break the analysis.

Full Stack Trace: https://gist.github.com/pedro-javierf/5854479c1c804aa470fea0128cd6e4d6

dragonmacher commented 3 years ago

Unfortunately, the stack traces provided do not show the cause or real details of the exception.

ryanmkurtz commented 3 years ago

The real stack trace is here:

Cannot invoke "ghidra.program.model.address.Address.getAddressSpace()" because "this.address" is null
java.lang.NullPointerException: Cannot invoke "ghidra.program.model.address.Address.getAddressSpace()" because "this.address" is null
    at ghidra.program.model.pcode.Varnode.<init>(Varnode.java:52)
    at ghidra.program.util.VarnodeContext.getVarnode(VarnodeContext.java:871)
    at ghidra.program.util.SymbolicPropogator.applyPcode(SymbolicPropogator.java:837)
    at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:495)
    at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:393)
    at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:191)
    at ghidra.app.cmd.function.NewFunctionStackAnalysisCmd.createStackPointerVariables(NewFunctionStackAnalysisCmd.java:340)
    at ghidra.app.cmd.function.NewFunctionStackAnalysisCmd.analyzeFunction(NewFunctionStackAnalysisCmd.java:191)
    at ghidra.app.cmd.function.NewFunctionStackAnalysisCmd.applyTo(NewFunctionStackAnalysisCmd.java:118)
    at ghidra.app.plugin.core.function.StackVariableAnalyzer.added(StackVariableAnalyzer.java:55)
    at ghidra.app.plugin.core.analysis.OneShotAnalysisCommand.applyTo(OneShotAnalysisCommand.java:47)
    at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:688)
    at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:788)
    at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:667)
    at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:632)
    at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:58)
    at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:102)
    at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:315)
    at java.base/java.lang.Thread.run(Thread.java:832)
ghizard commented 3 years ago

I reviewed a bit of code for things that changed and may have caused this, then worked with @caheckman on these hypotheses and he mocked up a program to test this, and we think we have a solution in the works for this.