Ghidra: Missing code references in MIPS

Created on 12 Feb 2020  路  8Comments  路  Source: NationalSecurityAgency/ghidra

Describe the bug
Hi, I'm trying to use Ghidra's API to automatically recover the parameters of the specified function(e.g., malloc). But it seems that some code references are missing when I tried to do this in MIPS.

In the following picture, the first t9 is recognized, but the second one and the third one are not recognized. But in the decompile view, those functions are recognized as malloc.
Group

And when I tried to search references to malloc, I only got the following results. But in the source program, there are fourteen calls to malloc. It seems like in the listing view, the disasm codes whose comment has "=>malloc" are recognized as malloc's references.
Screen Shot 2020-02-12 at 4 15 38 PM

Expected behavior
Ghidra can provide all code references to the target function.
I'm new to both Ghidra and RE. Thanks for any help!

Attachments
An binary example and its source code.
mallocexample.zip

Environment (please complete the following information):

  • OS: macOS 10.15.3
  • Java Version: 13.0.2
  • Ghidra Version: 9.1.1
Analysis

Most helpful comment

This is a fairly easy fix / oversight with the OR operation. The OR operation is being using to assign S8 from SP. It could be fixed with by splitting the OR operation into OR and MOV where one of the operands is 0. I don't like splitting instructions, as it causes re-disassembly upgrade issues.

I'll make the fix in constant propagation in patch and master. Unfortunately 9.1.2 is coming out soon, so this change won't make that version.

All 8 comments

What does the function definition for malloc look like? The results here lead me to believe it hasn't been properly defined.

Hi @astrelsky , malloc is a C library function. It allocates the requested memory and returns a pointer to it.

void *malloc(size_t size)

Hi @astrelsky , malloc is a C library function. It allocates the requested memory and returns a pointer to it.

void *malloc(size_t size)

Yes, I meant how it was defined in the ghidra project.

Regardless I misunderstood the problem. I see that there is no reference to malloc in the disassembly view. You can add the references through the listing by right clicking the t9->references->add/edit references or through the api with the ReferenceManager. There is a getter for the manager in the Program interface. As long as the reference is set as primary it should appear in both the disassembler and decompiler.

Do you want this?
Screen Shot 2020-02-12 at 10 22 24 PM

Thanks for your advice. I add the references to t9 and it now appears in References view. I just don't understand why malloc is not recognized in the Listing view, but when I click t9, the corresponding malloc function in the Discompile view is highlighted. In other words, the Discompile view recognized malloc, but the Listing view(Disassemble view) does not recognize it.

This is a fairly easy fix / oversight with the OR operation. The OR operation is being using to assign S8 from SP. It could be fixed with by splitting the OR operation into OR and MOV where one of the operands is 0. I don't like splitting instructions, as it causes re-disassembly upgrade issues.

I'll make the fix in constant propagation in patch and master. Unfortunately 9.1.2 is coming out soon, so this change won't make that version.

@emteere I 100% guarentee it won't make it https://github.com/NationalSecurityAgency/ghidra/releases/tag/Ghidra_9.1.2_build

Nice that it's a simple fix though.

The 9.1.2 has a few high priority fixes, especially JDK 11.0.6 support.

@emteere Thank you for your explanation. I'm looking forward to the new version to solve this problem.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

marcushall42 picture marcushall42  路  3Comments

astrelsky picture astrelsky  路  3Comments

rrivera1849 picture rrivera1849  路  3Comments

huettenhain picture huettenhain  路  3Comments

Merculous picture Merculous  路  3Comments