Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing code references in MIPS #1531

Closed
Ji4n1ng opened this issue Feb 12, 2020 · 8 comments
Closed

Missing code references in MIPS #1531

Ji4n1ng opened this issue Feb 12, 2020 · 8 comments
Assignees
Milestone

Comments

@Ji4n1ng
Copy link

Ji4n1ng commented Feb 12, 2020

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
@astrelsky
Copy link
Contributor

astrelsky commented Feb 12, 2020

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

@Ji4n1ng
Copy link
Author

Ji4n1ng commented Feb 12, 2020

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

void *malloc(size_t size)

@astrelsky
Copy link
Contributor

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.

@Ji4n1ng
Copy link
Author

Ji4n1ng commented Feb 12, 2020

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.

@emteere
Copy link
Contributor

emteere commented Feb 13, 2020

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.

@astrelsky
Copy link
Contributor

astrelsky commented Feb 13, 2020

@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.

@emteere
Copy link
Contributor

emteere commented Feb 13, 2020

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

@Ji4n1ng
Copy link
Author

Ji4n1ng commented Feb 14, 2020

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

@ghidra1 ghidra1 added this to the 9.1.3 milestone Feb 26, 2020
@ghidra1 ghidra1 closed this as completed Mar 25, 2020
@ghizard ghizard modified the milestones: 9.1.3, 9.2 Oct 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants