ghidra: Another 9.2 "Invalid block name" regression: Importing Mach-O files

Describe the bug When importing a mach-o object file, the following stack trace is printed and the file cannot be imported:

Invalid block name: 
java.io.IOException: Invalid block name: 
at ghidra.app.util.opinion.MachoLoader.load(MachoLoader.java:101)
at ghidra.app.util.opinion.AbstractLibrarySupportLoader.doLoad(AbstractLibrarySupportLoader.java:347)
at ghidra.app.util.opinion.AbstractLibrarySupportLoader.loadProgram(AbstractLibrarySupportLoader.java:83)
at ghidra.app.util.opinion.AbstractProgramLoader.load(AbstractProgramLoader.java:112)
at ghidra.plugin.importer.ImporterUtilities.importSingleFile(ImporterUtilities.java:400)
at ghidra.plugin.importer.ImporterDialog.lambda$okCallback$7(ImporterDialog.java:349)
at ghidra.util.task.TaskLauncher$1.run(TaskLauncher.java:88)
at ghidra.util.task.Task.monitoredRun(Task.java:124)
at ghidra.util.task.TaskRunner.lambda$startTaskThread$0(TaskRunner.java:104)

To Reproduce Steps to reproduce the behavior:

Download the Mach-O fat binary at https://github.com/SafeExamBrowser/seb-mac/blob/9f0b0d082e21bf98628e7299fc8e8adc5bf211be/SEB/Frameworks/libSEBSupport.a

Use the llvm-lipo tool to extract a thin binary, e.g.:

$ llvm-lipo -thin arm64 libSEBSupport.a -output libSEBSupport-arm64.a

Import the file as “Batch Import”
No file could be imported, despite a .o being listed (which is probably a separate UX bug, as it “silently” errors)

In order to see the file, first extract the archive using ar -xvf libSEBSupport-arm64.a and import the (only) resulting object file.

Expected behavior The file is imported correctly, as with Ghidra v9.1. If an import error occurs, the import error is printed, instead of simply silently failing.

~~Screenshots~~ ~~If applicable, add screenshots to help explain your problem.~~

Attachments GitHub doesn’t allow uploading files with a .o extension, so I renamed it .zip: UIWindow+SEBExtensions.o.zip

Environment (please complete the following information):

OS: Current ArchLinux [testing] on 5.10.11-zen2-1-zen
Java Version: tested 11.0.10.u8 and 15.0.1.u9
Ghidra Version: 9.2.2

Additional context The binary loads fine in IDA as well. From https://github.com/NationalSecurityAgency/ghidra/issues/2354 with 9.2:

Block naming constraints have been tightened for 9.2 so it may have gone through without detection in 9.1.

Unfortunately the linked PR https://github.com/NationalSecurityAgency/ghidra/pull/2329 only fixed imports with PE files, not mach-o files.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15

Commits related to this issue

Better support for Mach-O MH_OBJECTs and archives (fixes #2702) — committed to ryanmkurtz/ghidra by ryanmkurtz 3 years ago
Better support for Mach-O MH_OBJECTs and archives (fixes #2702) — committed to NationalSecurityAgency/ghidra by ryanmkurtz 3 years ago

Most upvoted comments

This issue is different from #2329 in that Mach-O object files (file type MH_OBJECT) are specified to have 1 segment with no name:

 * The file type MH_OBJECT is a compact format intended as output of the
 * assembler and input (and possibly output) of the link editor (the .o
 * format).  All sections are in one unnamed segment with no segment padding. 
 * This format is used as an executable format when the file is so small the
 * segment padding greatly increases its size.

All of the no-name segment’s sections specify normal parent segment names, like __TEXT, __DATA, etc. We’ll either go with @LeonardKoenig’s generic approach, or put some more specific support in for these object files.

ryanmkurtz on Feb 1, 2021

I will leave it open until the Macho naming issue is resolved

ghidra1 on Jan 29, 2021