-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
Wrong symbol resolved from LC_DYLD_INFO_ONLY on iOS MachO binary #6994
Comments
Sorry for the delay in getting back to you.
This is ancient...I'll remove it.
ghidra/Ghidra/Features/Base/src/main/java/ghidra/app/util/opinion/MachoProgramBuilder.java Lines 889 to 984 in 6805c6b
|
I will try to find the same flaw in my set of samples...hopefully there is something consistently wrong. |
This is typically due to an older memory block convention we use that creates a 2nd block for the padded out part of the memory block, which we make as uninitialized. The PE loader has dropped this convention, but the Mach-O loader hasn't yet. |
I think i have reproduced the issue in one of my binaries. I will begin looking into a fix. |
I take it back, i am not reproducing it. Looking at your initial screen shot, it looks like |
@ryanmkurtz I put a breakpoint all over the range you indicated in MachoProgramBuilder but none of them actually get triggered. This is by the way the stack trace of that previous debugger screenshot; maybe I'm in a different code path? |
Any way you can share the binary with me privately? If so, making a private GitHub repo and inviting just me to it has worked in the past. i understand if you can't do that tho. |
Describe the bug
I have a (non-public) MachO iOS file for which Ghidra identifies the wrong symbol/linked library for certain imports. Hopper and LIEF do identify the correct symbol and I've confirmed this via dynamic analysis. I can't share the binary, but I'm trying to debug Ghidra to figure out the error, so some hints as to where to continue my examination could help me in fixing the bug.
The dynamic linking info is available in LC_DYLD_INFO_ONLY and it does get processed, but not applied for some reason (see further down)
There is also a MachoProcessBindScript.java script, which seems related, but this does not fix the problem and it appears that the bind processing is already done by one of the general analyzers? So not sure if this script actually still serves a purpose?
Specifics
Ghidra is showing
uname
as the import at 0x1c85288 while it should beSwift.String.hasSuffix
:In Hopper, it's String.hasSuffix, which is correct:
And in LIEF it's correct too:
Additional Binary info
There are two __LINKEDIT sections:
(Actually not entirely sure where the second one comes from)
And inside of it there are the following commands:
The second section starts at
1c84000
so add1288h
becomes1c85288
and so hasSuffix should be set where _uname currently is set.I've debugged the analyzer a bit and the __LINKEDIT commands are read by dyld/BindingTable.java:
I wasn't able to figure out yet where the binding table is further used in the flow.
Environment:
The text was updated successfully, but these errors were encountered: