Ghidra: Analysis hanging for MIPS binary

[aosti]

Describe the bug
I'm using the beta version of Ghidra (9.1-Beta) on my Mac Os to disassemble a binary file for an embedded device. Auto analysis uses all the cores of my machine and memory until it crashes itself.

To Reproduce
Steps to reproduce the behavior:
Load the file provided in the attachment.
Select architecture MIPS 32 Little Endian.
Accept the auto analysis step.

Expected behavior
Auto analysis to execute in few moments.

Screenshots

Attachments
If applicable, please attach any files that caused problems or log files generated by the software.
mips_code.bin.zip

Environment (please complete the following information):

• OS: MacOs 10.15
• Java Version: java 12.0.1 2019-04-16

• Ghidra Version: 9.1-Beta (although the same happens in the previous version 9.0.4)

[astrelsky]

The binary in your attachment appears to be a raw image of some sort of media player/device. (Probably a full nand dump or of some flash memory) It contains images, and at least some xml files. (Noted by the presence of CDATA[)

I would recommend attempting to isolate any executable(s) from the image and analyze them separately if possible. You likely won't get any decent results when the image base/language aren't set correctly.

I noted multiple the decompiler/disassembler encountered issues determining instruction flow which is likely the cause of the crash.

[aosti]

Your suggestion worked perfectly. I used binwalk to locate the prologue of the functions and then created a file containing only the executable part. Then... ghidra worked! Thank you, very much!

[astrelsky]

You're welcome.

[astrelsky]

@aosti out of curiosity what exactly was binwalk able to identify? I'm curious as to why ghidra wasn't able to detect it.

[aosti]

I'm not exactly sure if this is the root cause, but I ran binwalk -A to identify code signatures and it showed MIPSEL instructions, MIPS instructions and some other architectures, as soon as I removed the parts that corresponded to the other architectures and MIPS big endian, the analysis was almost instantaneous and it was able to detect all the functions on the binary.

[astrelsky]

I'm not exactly sure if this is the root cause, but I ran binwalk -A to identify code signatures and it showed MIPSEL instructions, MIPS instructions and some other architectures, as soon as I removed the parts that corresponded to the other architectures and MIPS big endian, the analysis was almost instantaneous and it was able to detect all the functions on the binary.

Ok so there wasn't actually an embedded binary. You might be better off importing the entire thing and using a script to create memory blocks and mark them as executable or read/write data. This was only the executable sections will get disassembled and ghidra can still make references to data.

[aosti]

Your new suggestion worked even better and now there are references to data. Thanks again!

[aosti]

Just a follow up, after I modified the binary to not contain empty infinite loops, by replacing it with nop instructions, Ghidra was able to complete the analysis successfully.