mumbel/ghidra_i960

Ghira processor module for i960 80960

ghidra_i960's Issues

Binary import fails with exception - <pentry> tags

Thank you very much for this project and the i960 processor for Ghidra!
I was trying to import a firmware binary to analyse (firmware bin file, using an 0xe0000100 offset via options), however the import fails with below error message.
Have you come across this?

Exception reading i960:LE:32:default/default(i960.cspec): <pentry> tags within a group must be distinguished by size or type ghidra.program.model.lang.CompilerSpecNotFoundException: Exception reading i960:LE:32:default/default(i960.cspec): <pentry> tags within a group must be distinguished by size or type at ghidra.program.model.lang.BasicCompilerSpec.<init>(BasicCompilerSpec.java:157) at ghidra.app.plugin.processors.sleigh.SleighLanguage.getCompilerSpecByID(SleighLanguage.java:1143) at ghidra.app.util.opinion.BinaryLoader.loadProgram(BinaryLoader.java:278) at ghidra.app.util.opinion.AbstractProgramLoader.load(AbstractProgramLoader.java:112) at ghidra.plugin.importer.ImporterUtilities.importSingleFile(ImporterUtilities.java:404) at ghidra.plugin.importer.ImporterDialog.lambda$okCallback$7(ImporterDialog.java:350) at ghidra.util.task.TaskBuilder$TaskBuilderTask.run(TaskBuilder.java:306) at ghidra.util.task.Task.monitoredRun(Task.java:126) at ghidra.util.task.TaskRunner.lambda$startTaskThread$0(TaskRunner.java:106) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833)

Importing ROM data imports as RAM

I'm not sure if this is a Ghidra 9.1.2 thing or specific to the language definition, but in the disassembly, the header lists the memory map as ram and follows that with the address space ram: 00000000-000fffff. Renaming the area to ROM in the memory map alters the first instance of ram to ROM but not the address space listed. I'd like to assign the actual RAM space to 0x500000 with a length of 0x100000 and a secondary RAM allocation at 0x200000 for the length of 0xCF218.

[Feature Request] - Initial Boot Record support

Greetings,

So I was talking with @DrItanium regarding my disassembly, and they mentioned that the beginning of i960 executable is something called an "Initial Boot Record".

For example this is taken from an .exe:

This is taken from a PS3 .elf executable:

This is an example of an i960 Initial Boot Record provided by DrItanium:

DrItanium goes on to state that a specific example of the Initial Boot Record for the 80960 KX architecture can be found in the NINDY source code file kx_init.s.

For that matter, I think a lot of what's shown in the KX_INIT.S file could (should) be implemented in the disassembly if it's common to basically all 80960 architecture. Granted this could be quite the feat to implement, I feel it would be beneficial for research purposes.

Warnings and errors analyzing Intel's NINDY 3.01 binary

Greetings again,
After realizing I had a binary of Intel i960 software dumped from some floppy disks I own, I decided to throw it into Ghidra 9.1.2 to see how this repo would fare against it. And it does pretty well, but I thought I would document warnings and errors along the way so they could be looked into at a future date:

Warning: Auto Analysis Summary: Function Start Search> Could not initialize a search state.
Error: Analyzer Error: Analysis Task: Stack - Bit length must be >= 1 and = 64

Analysis Task: Stack - Bit length must be >= 1 and <= 64
java.lang.IllegalArgumentException: Bit length must be >= 1 and <= 64
	at ghidra.program.model.scalar.Scalar.<init>(Scalar.java:62)
	at ghidra.program.util.VarnodeContext.extendValue(VarnodeContext.java:1267)
	at ghidra.program.util.SymbolicPropogator.applyPcode(SymbolicPropogator.java:1092)
	at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:491)
	at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:389)
	at ghidra.program.util.SymbolicPropogator.flowConstants(SymbolicPropogator.java:188)
	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:54)
	at ghidra.app.plugin.core.analysis.AnalysisScheduler.runAnalyzer(AnalysisScheduler.java:185)
	at ghidra.app.plugin.core.analysis.AnalysisTask.applyTo(AnalysisTask.java:39)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:685)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:785)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:664)
	at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:629)
	at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:62)
	at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:101)
	at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:315)
	at java.base/java.lang.Thread.run(Thread.java:832)

---------------------------------------------------
Build Date: 2020-Feb-12 1149 EST
Ghidra Version: 9.1.2
Java Home: /usr/lib64/jvm/java-15-openjdk-15
JVM Version: N/A 15-internal
OS: Linux 5.6.12-1-default amd64
Workstation: 0.0.0.0

The binary for NINDY 3.01 is uploaded as follows: image.bin.zip. Again, this is an Intel provided binary which should provide insight into improving repo as opposed to video game programs which may not be defined as ELF or COFF executables.

Commit 67744fb cause errors in auto analysis

Looks like I'm encountering a few errors loading my binary:
The first two are NullPointerExceptions

Analysis Task: Data Reference -
java.lang.NullPointerException
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:760)
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:612)
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:605)
at ghidra.app.util.PseudoDisassembler.isValidSubroutine(PseudoDisassembler.java:366)
at ghidra.app.plugin.core.analysis.OperandReferenceAnalyzer.added(OperandReferenceAnalyzer.java:458)
at ghidra.app.plugin.core.analysis.AnalysisScheduler.runAnalyzer(AnalysisScheduler.java:185)
at ghidra.app.plugin.core.analysis.AnalysisTask.applyTo(AnalysisTask.java:39)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:685)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:785)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:664)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:629)
at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:62)
at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:101)
at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:315)
at java.base/java.lang.Thread.run(Thread.java:834)

---

Build Date: 2019-Oct-23 1737 EDT
Ghidra Version: 9.1
Java Home: C:\Program Files\Java\jdk-11.0.2
JVM Version: Oracle Corporation 11.0.2
OS: Windows 10 10.0 amd64
Workstation: DESKTOP-GHRIIHN

Analysis Task: Reference -
java.lang.NullPointerException
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:760)
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:612)
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:605)
at ghidra.app.util.PseudoDisassembler.isValidSubroutine(PseudoDisassembler.java:366)
at ghidra.app.plugin.core.analysis.OperandReferenceAnalyzer.added(OperandReferenceAnalyzer.java:458)
at ghidra.app.plugin.core.analysis.AnalysisScheduler.runAnalyzer(AnalysisScheduler.java:185)
at ghidra.app.plugin.core.analysis.AnalysisTask.applyTo(AnalysisTask.java:39)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:685)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:785)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:664)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:629)
at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:62)
at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:101)
at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:315)
at java.base/java.lang.Thread.run(Thread.java:834)

---

Build Date: 2019-Oct-23 1737 EDT
Ghidra Version: 9.1
Java Home: C:\Program Files\Java\jdk-11.0.2
JVM Version: Oracle Corporation 11.0.2
OS: Windows 10 10.0 amd64
Workstation: DESKTOP-GHRIIHN

Followed by an Analysis Task error:

Analysis Task: Create Address Tables - One Time -
java.lang.NullPointerException
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:760)
at ghidra.app.util.PseudoDisassembler.checkValidSubroutine(PseudoDisassembler.java:612)
at ghidra.app.util.PseudoDisassembler.isValidCode(PseudoDisassembler.java:399)
at ghidra.app.plugin.core.disassembler.AddressTable.getFunctionEntries(AddressTable.java:759)
at ghidra.app.plugin.core.disassembler.AddressTableAnalyzer.added(AddressTableAnalyzer.java:195)
at ghidra.app.plugin.core.analysis.OneShotAnalysisCommand.applyTo(OneShotAnalysisCommand.java:47)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager$AnalysisTaskWrapper.run(AutoAnalysisManager.java:685)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:785)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:664)
at ghidra.app.plugin.core.analysis.AutoAnalysisManager.startAnalysis(AutoAnalysisManager.java:629)
at ghidra.app.plugin.core.analysis.AnalysisBackgroundCommand.applyTo(AnalysisBackgroundCommand.java:62)
at ghidra.framework.plugintool.mgr.BackgroundCommandTask.run(BackgroundCommandTask.java:101)
at ghidra.framework.plugintool.mgr.ToolTaskManager.run(ToolTaskManager.java:315)
at java.base/java.lang.Thread.run(Thread.java:834)

---

Build Date: 2019-Oct-23 1737 EDT
Ghidra Version: 9.1
Java Home: C:\Program Files\Java\jdk-11.0.2
JVM Version: Oracle Corporation 11.0.2
OS: Windows 10 10.0 amd64
Workstation: DESKTOP-GHRIIHN

I feel as though the information produced by these errors won't be very helpful, so I will go back to each commit and reload the binary to see exactly when things broke

EDIT: Can confirm commit 67744fb broke auto-analysis.

Compare and branch src1 not disassembling correctly.

Using Ghidra 9.1.2, when the data disassembles as cmpib or cmpob the src1 value is incorrect. The src1 value displays bits 4-0 instead of bits 23-19.

As an example, highlighted in green I have 00070978 10 20 2d 3d cmpibne 0x10,g4,LAB_00070988

But I know that it should be cmpibne 0x5,g4,LAB_00070988 instead because the game is looking to compare the value of 5 and bits 23-19 match up correctly. This was also true in other instances and not just this one.

Looking at the scrape.py file, it shows this structure commented for COBR so I'm not sure what's causing the issue.

Debug file parsing

p521v79_int.zip
Have you run across this format before? I have several of these oddball output files.

endian

What are the endian options here? So far my only examples are little, is there anything special about big endian, does it do anything weird like big endian instruction / little endian data or vice-versa?

The elf/coff compiles linked from the other issue look like they only support little, are there any public samples to just do quick tests with?

Status on processor module repo vs proposed ghidra i960 tree?

Greetings again,

A friend of mine is switching to Ghidra and we are planning on fully migrating from IDA to Ghidra. I wanted to see what the most up to date way to begin reverse engineering and I see you've made pull requests to the main Ghidra repo with your own i960 tree.

Would cloning and building this version of Ghidra be the most promising for i960 RE work?

Thanks as always for your contributions to this defunct architecture! :)