Ghidra on MacOS (M3): java.io.IOException: Could not initialize 7zip native libraries

[roadkillsanta]

Describe the bug
Ghidra is not able to load any PDB files due to library issues.

To Reproduce
Steps to reproduce the behavior:

1. Open a dll
2. In the top menu bar, go to File -> "Load PDB File..."
3. In the new window, load any PDB (from local or from server)
4. Error window pops up

Expected behavior
PDB file is loaded and parsed by ghidra

Screenshots

Environment (please complete the following information):
Build Date: 2024-Sep-26 1444 EDT
Ghidra Version: 11.2
Ghidra Origin: homebrew cask
JVM Version: Oracle Corporation 22.0.2
OS: Mac OS X 14.6.1 aarch64

[dev747368]

Could you look in your ghidra log file and see if any stack trace was logged for this error and paste it here?

[roadkillsanta]

Relevant logs

(SymbolServerService) SymbolServerService: querying <pdb file>, <pdb guid>, 1, 0, ???
(SymbolServerService) SymbolServerService: got 1 results from <pdb folder>
(SymbolServerService) SymbolServerService: skipping untrusted symbol server <symbol server>
(SymbolServerService) SymbolServerService: found 1 matches
(SymbolServerService) SymbolServerService: getting symbol file: <pdb file>
(SymbolServerService) SymbolServerService: decompressing file <pdb file>
(FileSystemFactoryMgr) Error during fs factory create: 7zip, class ghidra.file.formats.sevenzip.SevenZipFileSystem java.io.IOException: Could not initialize 7zip native libraries
at ghidra.file.formats.sevenzip.SevenZipFileSystem.mount(SevenZipFileSystem.java:70)
at ghidra.file.formats.sevenzip.SevenZipFileSystemFactory.create(SevenZipFileSystemFactory.java:75)
at ghidra.file.formats.sevenzip.SevenZipFileSystemFactory.create(SevenZipFileSystemFactory.java:32)
at ghidra.formats.gfilesystem.factory.FileSystemFactoryMgr.mountUsingFactory(FileSystemFactoryMgr.java:175)
at ghidra.formats.gfilesystem.factory.FileSystemFactoryMgr.probe(FileSystemFactoryMgr.java:331)
at ghidra.formats.gfilesystem.FileSystemService.openFileSystemContainer(FileSystemService.java:827)
at pdb.PdbUtils.extractSingletonCabToFile(PdbUtils.java:100)
at pdb.symbolserver.SymbolServerService.ensureLocalUncompressedFile(SymbolServerService.java:242)
at pdb.symbolserver.SymbolServerService.getLocalSymbolFileLocation(SymbolServerService.java:214)
at pdb.symbolserver.ui.LoadPdbDialog.prepareSelectedSymbolFileAndClose(LoadPdbDialog.java:592)
at pdb.symbolserver.ui.LoadPdbDialog$3.run(LoadPdbDialog.java:818)
at ghidra.util.task.Task.monitoredRun(Task.java:134)
at docking.TaskScheduler.run(TaskScheduler.java:62)
at java.base/java.lang.Thread.run(Thread.java:1570)
 
(LoadPdbDialog) Error Getting Symbol File: java.io.IOException: Could not initialize 7zip native libraries
(FileByteProvider) FAIL TO CLOSE <pdb file>

[dev747368]

Thanks for the logs. That confirms the troubleshooting path I was taking.

In this case, we have this issue:

where the dependency is on the sevenzipjbinding project for a library to uncompress your cabarc compressed pd_ (pdb) file.

The build we have includes native libraries for x86 linux/mac/windows, but no aarch64 binaries.

As a workaround, if you have a way to uncompress the .pd_ file manually, you should be able to find it in your symbol file directory (eg. symbols/yourbinary.pdb/1234565345345345345345/yourbinary.pd_), and if you uncompress it and put the .pdb file in the same directory, Ghidra should find it next time you try to process your binary.

I am going to add the issue of sevenzip on non-x86 macs to our internal issue db and talk with the team about prioritization. (especially since this is a blocker for binaries that refer to a compressed pdb file)

FYI, we do have some accommodation for non-supported platforms, but only when accessing simple .zip files, since we can fall back to java's built-in zip file support.