DyldCacheFileSystem exception: "hash has changed"

[antekone]

I'm trying to load a dyld_shared_cache from an arm64e macOS Monterey machine. Ghidra properly detects the file as a filesystem, and can browse through all the files. After trying to import the /System/Library/PrivateFrameworks/ScreenSharing.framework/ScreenSharing, Ghidra displays this error:

Failed to find provider for segment: __LINKEDIT
java.io.IOException: Failed to find provider for segment: __LINKEDIT
    at ghidra.file.formats.ios.dyldcache.DyldCacheDylibExtractor$PackedDylib.getSegmentProvider(DyldCacheDylibExtractor.java:313)
    at ghidra.file.formats.ios.dyldcache.DyldCacheDylibExtractor$PackedDylib.<init>(DyldCacheDylibExtractor.java:236)
    at ghidra.file.formats.ios.dyldcache.DyldCacheDylibExtractor.extractDylib(DyldCacheDylibExtractor.java:61)
    at ghidra.file.formats.ios.dyldcache.DyldCacheFileSystem.getByteProvider(DyldCacheFileSystem.java:64)
    at ghidra.formats.gfilesystem.FileSystemService.getByteProvider(FileSystemService.java:364)
    at ghidra.plugins.fsbrowser.FSBActionManager.ensureFileAccessable(FSBActionManager.java:941)
    at ghidra.plugins.fsbrowser.FSBActionManager.lambda$createImportAction$37(FSBActionManager.java:698)
    at docking.widgets.tree.GTree$1.run(GTree.java:1152)
    at ghidra.util.worker.AbstractWorker$JobCallback.process(AbstractWorker.java:133)
    at ghidra.util.worker.AbstractWorker$JobCallback.process(AbstractWorker.java:123)
    at generic.concurrent.ConcurrentQ$CallbackCallable.call(ConcurrentQ.java:658)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at generic.concurrent.FutureTaskMonitor.run(FutureTaskMonitor.java:76)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
    at java.base/java.lang.Thread.run(Thread.java:831)

---------------------------------------------------
Build Date: 2022-Apr-21 1210 EDT
Ghidra Version: 10.1.3
Java Home: /fasthome/antek/.sdkman/candidates/java/16.0.1.hs-adpt
JVM Version: AdoptOpenJDK 16.0.1
OS: Linux 5.16.12-arch1-1 amd64
Workstation: succubus

To Reproduce Steps to reproduce the behavior:

1. Open Ghidra
2. Click "new project" (non-shared)
3. Import the ARM64e dyld_shared_cache file from /System/Library/dyld/dyld_shared_cache_arm64e
4. Click 'Filesystem' in the 'Container file detected' dialog box
5. In the filesystem dialog, navigate to /System/Library/PrivateFrameworks/ScreenSharing.framework/ScreenSharing
6. Click right mouse button on it, select 'import'
7. Error box appears

Expected behavior Ghidra should load the ScreenSharing file into the disassembler/decompiler.

Screenshots

Attachments

Environment (please complete the following information):

• OS: ArchLinux
• Java Version: 16.0.1-hs AdoptOpenJdk
• Ghidra Version: 10.1.3
• Ghidra Origin: Github

Additional info

The problem is when importing any file from the dyld shared cache, not just ScreenSharing (tried to load a few of them, and all of them have failed with the same error).

Unpacking the dyld_shared_cache with thirdparty tools and loading the ScreenSharing binary into Ghidra works OK.

[ryanmkurtz]

You opened the base file and not the .1 right?

I just made changes to this code this morning. Any chance you can build master and try again?

[antekone]

Thanks for the response! Yes, I'm opening the base file, not the .1 one. I've build Ghidra from master and the error is still there:

(the commit 576c02c36925de50e82793243e58d70eb684f1e2 should be included in the built version).

[ryanmkurtz]

Do you know what version of Monterey your files are from? I'm testing on my 12.3.1 system.

I'm actually getting a filesystem hashing error when I import ScreenSharing from my cache, not the LINKEDIT error. I'm not sure if it's related, or what that's about yet. I can open other files in the cache tho without error. I can also import ScreenSharing from the x86 version of the cache without error.

[antekone]

I'm using:

$ sw_vers             
ProductName:    macOS
ProductVersion: 12.3.1
BuildVersion:   21E258

[antekone]

Okay, it's probably my fault ;(, I didn't have the proper .1 file in the same directory (I guess it's needed even when I try to open the base file).

I've renamed my blob file to the original filename, ensured that I have the proper .1 file in the same directory and this error is gone.

I'm having the "hash" error instead (maybe it's the same as yours):

Unable to retrieve requested file, hash has changed: file:///home/antek/dev/rust/exeparser/dyld_shared_cache_arm64e?MD5=ab132edff2b3a97558c59948cda37ddf|dyldcachev1:///System/Library/PrivateFrameworks/ScreenSharing.framework/Versions/A/ScreenSharing?MD5=392a7b4af1bb94a452cd0e2d8aafde20, new hash: b3c0e74672ac2cbeec6653b554630ca8
java.io.IOException: Unable to retrieve requested file, hash has changed: file:///home/antek/dev/rust/exeparser/dyld_shared_cache_arm64e?MD5=ab132edff2b3a97558c59948cda37ddf|dyldcachev1:///System/Library/PrivateFrameworks/ScreenSharing.framework/Versions/A/ScreenSharing?MD5=392a7b4af1bb94a452cd0e2d8aafde20, new hash: b3c0e74672ac2cbeec6653b554630ca8
    at ghidra.formats.gfilesystem.FileSystemService.getByteProvider(FileSystemService.java:381)
    at ghidra.formats.gfilesystem.FileSystemService.isFileFilesystemContainer(FileSystemService.java:655)
    at ghidra.plugin.importer.ImporterUtilities.showImportDialog(ImporterUtilities.java:176)
    at ghidra.plugins.fsbrowser.FSBActionManager.lambda$createImportAction$37(FSBActionManager.java:701)
    at docking.widgets.tree.GTree$1.run(GTree.java:1289)
    at ghidra.util.worker.AbstractWorker$JobCallback.process(AbstractWorker.java:133)
    at ghidra.util.worker.AbstractWorker$JobCallback.process(AbstractWorker.java:123)
    at generic.concurrent.ConcurrentQ$CallbackCallable.call(ConcurrentQ.java:658)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at generic.concurrent.FutureTaskMonitor.run(FutureTaskMonitor.java:76)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
    at java.base/java.lang.Thread.run(Thread.java:831)

---------------------------------------------------
Build Date: 2022-Apr-30 0718 CEST
Ghidra Version: 10.2
Java Home: /fasthome/antek/.sdkman/candidates/java/16.0.1.hs-adpt
JVM Version: AdoptOpenJDK 16.0.1
OS: Linux 5.16.12-arch1-1 amd64
Workstation: succubus

I can also load the amd64 version without problems!

Sorry for this. If you think the ticket can be closed, then let's close it, because the current error is different than originally reported.

[ryanmkurtz]

Yea, it's not obvious that the .1 file and friends have to be in the same directory.

Ok, I will focus on that hash error for this ticket.

[1wc]

Hello, I used Ghidra 10.1.5 to open macOS 12.4 arm64e DSC and still got a "hash has changed" error. The .1 and base image were in the same directory.

Unable to retrieve requested file, hash has changed: file:///Users/liwc/tmp/dsc/dyld_shared_cache_arm64e?MD5=1e5491043b54719b4aecc021101c6d7f|dyldcachev1:///System/Library/Frameworks/CloudKit.framework/Versions/A/CloudKit?MD5=b2d01e4bdd145504547c20081e5a477e, new hash: a358e4190f2c3d9eb792ffd565ff8d79 java.io.IOException: Unable to retrieve requested file, hash has changed: file:///Users/liwc/tmp/dsc/dyld_shared_cache_arm64e?MD5=1e5491043b54719b4aecc021101c6d7f|dyldcachev1:///System/Library/Frameworks/CloudKit.framework/Versions/A/CloudKit?MD5=b2d01e4bdd145504547c20081e5a477e, new hash: a358e4190f2c3d9eb792ffd565ff8d79 at ghidra.formats.gfilesystem.FileSystemService.getByteProvider(FileSystemService.java:380) at ghidra.plugin.importer.ImporterUtilities.importSingleFile(ImporterUtilities.java:315) at ghidra.plugin.importer.ImporterUtilities.showImportDialog(ImporterUtilities.java:191) at ghidra.plugins.fsbrowser.FSBActionManager.lambda$createImportAction$37(FSBActionManager.java:701) at docking.widgets.tree.GTree$1.run(GTree.java:1152) at ghidra.util.worker.AbstractWorker$JobCallback.process(AbstractWorker.java:133) at ghidra.util.worker.AbstractWorker$JobCallback.process(AbstractWorker.java:123) at generic.concurrent.ConcurrentQ$CallbackCallable.call(ConcurrentQ.java:658) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at generic.concurrent.FutureTaskMonitor.run(FutureTaskMonitor.java:76) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829)

---

Build Date: 2022-Jul-26 1543 EDT Ghidra Version: 10.1.5 Java Home: /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home JVM Version: Eclipse Foundation 11.0.12 OS: Mac OS X 11.4 x86_64

[ryanmkurtz]

The fix for this will be in the upcoming 10.2 release, and is currently available in the master branch if you are able to produce your own build.