Extracted dylibs from iOS caches

[nmggithub]

I've noticed that when extracting dylibs from iOS caches (specifically ARM-architecture ones), may references to external functions are red branch instructions. Looking into it, I've determined that this is due to those branches being to a global stubs table (instead of, for example, the stubs in __auth_stubs).

Has this been an issue for a while, or is there some fix that I am missing that requires manual effort?

[ryanmkurtz]

It's working by design. You have to Add To Program for those, like anything else.

[fmagin]

This Add to Program approach sounds like it breaks other Ghidra features like Version Tracking and "analysis composition"? E.g. if i would reverse engineer daemon_foo from the shared cache that uses libA.dylib, libB.dylib and later I want to analyze daemon_bar that uses libB.dylib and libC.dylib I would have to add the Daemon Bar to the initial program to re-use my progress on libB.dylib ?
Which would maybe still kind of work, but if I then if a new iOS version comes out and how could I use the Version Tracking tool to migrate my results from the old daemon_foo to the new version of daemon_foo ? The program would also contain all the other libs which will make the version tracking a lot more complicated?

The whole concept that Ghidra can have multiple programs open at once, but in separate tabs and only connected via external references seems really useful, so I'm wondering why this isn't used instead to fix up the references

[nmggithub]

And you are sure that is my branch? I would have expected a different error message.

I believe it is. However, upon running it I was met with the project I was using to test #7436, but that may just be because that config was stored somewhere locally outside the install directory.

EDIT: I think I was actually building the master branch. I just realized you have it on a different branch. I'll try that one and report back.

[ryanmkurtz]

Ok I have the same dyld_shared_cache as you now and I also fail to import that same address. But, I see my new error message about why it's failing. This is because the shared cache file is too big to fit in a java array now. I will work on a fix for that.

[ryanmkurtz]

This Add to Program approach sounds like it breaks other Ghidra features like Version Tracking and "analysis composition"? E.g. if i would reverse engineer daemon_foo from the shared cache that uses libA.dylib, libB.dylib and later I want to analyze daemon_bar that uses libB.dylib and libC.dylib I would have to add the Daemon Bar to the initial program to re-use my progress on libB.dylib ? Which would maybe still kind of work, but if I then if a new iOS version comes out and how could I use the Version Tracking tool to migrate my results from the old daemon_foo to the new version of daemon_foo ? The program would also contain all the other libs which will make the version tracking a lot more complicated?

The whole concept that Ghidra can have multiple programs open at once, but in separate tabs and only connected via external references seems really useful, so I'm wondering why this isn't used instead to fix up the references

Maybe. These are extracted from a prelinked and optimized lossy blob, so it seemed more logical to just build up the blob with the pieces you need. I had to add in some code that would even fashion fake Mach-O segments. Generally speaking, Ghidra doesn't "build" programs like this so adding even more to make external linking possible is a lot more work . I will think more on it though.

[fmagin]

I definitely see your point of treating this as a "partial view of the full loaded blob" and not an extracted file from a storage container. @nmggithub and me have been discussing the tradeoffs of the respective approaches over the last few days while trying to figure out what's going on and how to potentially fix things. The "partial view of the full loaded blob" approach definitely sounds easier to implement, and like a solid 80/20 solution for most users.

I'm wondering if there is a way to re-use the logic from the "Add to Program" code. For me, I have to do it twice to get the full name. The first time to add the _STUBS.X.0 block, and then to resolve the references inside the stub functions in that block.
After the second step the reference inside the stub is resolved, but the stub isn't yet marked as a function.

If I now turn this into a function it gets recognized as a thunk.

Would it be possible now to change the underlying Thunked-Function to point to a function from a different program of the same project?

The UI only gives me a minimal dialog to provide text, but this seems like it could be extended to picking the program and then function from that program.

Afterwords one could even throw out the added memory blocks for the second dylib again (and just leave the _STUBS.X.0 block, that now consists of thunk functions with proper external references

(all of this is on Ghidra 11.3)

[ryanmkurtz]

I see i have a pending mac update for 15.3. I'll apply that and try again in a few minutes.

[abhishrijoshi]

Did you try it again?