Ghidra: Regression in Mach-O (offsetted got / symbol ptr / ...) between 9.1 and 9.1.1

Created on 18 Jan 2020  路  4Comments  路  Source: NationalSecurityAgency/ghidra

The got and symbol ptrs in Mach-O executables is broken (offsetted) sometimes:

2020-01-18-154156_922x794_scrot

Here we can see the addresses to not corresponds properly. This is how it appears in IDA typically where the mapping is correct:

2020-01-18-154315_967x430_scrot

Similarly, all the __la_symbol_ptr table looks off:

2020-01-18-154548_934x571_scrot

In IDA:

2020-01-18-154540_968x533_scrot

After analysis in Ghidra, this results in a completely broken output, because all the function calls are wrong.

The bug is not present in all mach-o executables, and since I don't have a mac, it's hard for me to provide a reproducible test-case. What additional information can I provide?

Env:

  • Linux x86_64
  • Binary: Mach-O 64-bit
  • Ghidra 9.1.1

Edit: I actually realized the issue is not present in Ghidra 9.1, so this is a regression likely related to "Importer:MachO. Improved import/load time of DYLD shared cache files. (GT-3261)".

LoadeMach-O Bug

Most helpful comment

We found the issue and have corrected it in the patch branch and merged the change into main. The issue was a sort done of the symbol table to dramatically improve efficiency for laying down symbol names in the program. The symbol table is also indexed as found in the MachO header.
Thanks for finding the issue. We may get this out in a 9.1.2 patch as this is a significant regression.

All 4 comments

I've ran into this problem, and if you want a good test case, the IOKit framework dylib from macOS 10.15.2, which can be found in /System/Library/Frameworks/IOKit.framework/.

A very easy example can be seen by going to the _IOConnectRelease() symbol. Ghidra reports this as trying to call _IOMasterPort.versionOnce, whilst IDA reports it correctly as _mach_port_mod_refs(). Other functions look okay, so it's hard to tell why certain ones are causing problems. It occurs on both x86_64 and arm64 binaries.

We found the issue and have corrected it in the patch branch and merged the change into main. The issue was a sort done of the symbol table to dramatically improve efficiency for laying down symbol names in the program. The symbol table is also indexed as found in the MachO header.
Thanks for finding the issue. We may get this out in a 9.1.2 patch as this is a significant regression.

We may get this out in a 9.1.2 patch as this is a significant regression.

That might be wise, I can't use 9.1.1 in the current state unfortunately since every symbol name is wrong and I didn't find any workaround.

Fixed in 626f25f1bc471a5c667442d0cccc4b43d782295c

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lab313ru picture lab313ru  路  3Comments

marcushall42 picture marcushall42  路  3Comments

awsaba picture awsaba  路  3Comments

toor-de-force picture toor-de-force  路  3Comments

huettenhain picture huettenhain  路  3Comments