frida-core icon indicating copy to clipboard operation
frida-core copied to clipboard

Incompatibility with Dopamine's "Spinlock Panic Fix"

Open opa334 opened this issue 10 months ago • 2 comments

First of all, as I explained here, the logic for finding the dyld header is sort of wrong, and on Dopamine 2.4 - 2.4.1 it finds the wrong header. I have added a workaround for this in Dopamine 2.4.2 by removing the magic values of the wrong mach headers, but even with this fixed, I'm still seeing the process crash afterwards.

Basically I fix a stock issue with a race condition by making a private mapping of all dyld_shared_cache __TEXT on top of the (originally shared) mapping inside dyld before anything ever accesses the dyld_shared_cache. For some reason this causes the process that Frida attempts attach to, to crash. I have tried debugging this for a while now, but haven't been able to figure out what causes this, it is unlikely this issue is caused by Dopamine, since what it does is "simple" and mandatory to have the system be stable.

Dopamine logic that triggers this crash: https://github.com/opa334/Dopamine/blob/2.x/BaseBin/dyldhook/src/spinlock_fix.c

Crash log: https://pastebin.com/HcbRKiKV

opa334 avatar Mar 06 '25 19:03 opa334

Hey! (And apologies for the delay!)

  1. I agree that it would be good to simplify the dyld load address detection so it uses mach_vm_region_recurse() instead of walking memory pages backwards from PC looking for a Mach-O header.
  2. Regarding the crash, it seems that the real crash is masked by Gum.Exceptor, Frida's abstraction for cross-platform exception observation/handling, running into a stack overflow / accidental infinite recursion. If you patch [this])https://github.com/frida/frida-gum/blob/482e67e6f9f30c420f14377b6c94f41506823ae3/gum/gumexceptor.c#L53) line so FALSE is assigned instead, you should be able to see the real crash. We should also figure out how to fix the Exceptor edge-case that makes it go haywire, but that's a rabbit-hole for another day.

I'll keep my eyes on this issue so we can hopefully iron out the remaining issues ASAP.

oleavr avatar Mar 13 '25 12:03 oleavr

New crash log: https://pastebin.com/0ay65nT7

It seems like there is an issue with some hook done by Frida, it's really weird, I don't really see what impact making the text segments private would have on this :/

The call to mach_vm_remap comes from gum_code_segment_try_remap_locally.

opa334 avatar Mar 13 '25 21:03 opa334