-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to intercept function issue #273
Comments
I've run into the same issue with Frida 11.0.13 and by studying the frida-gum sources I found out the cause. When intercepting (at least in the X86 backend) frida-gum checks whether it can relocate at least 5 bytes from the address to be intercepted (it will do the actual relocation later). It happens in the trampoline creation procedure and it looks like this in the source: if (!gum_x86_relocator_can_relocate (ctx->function_address, If FALSE is returned here, you get this error message. Your second hook points to a ret instruction. As with it a basic block ends within 5 bytes of the address, the X86 relocator gives up because it doesn't know what to do with the remaining 4 bytes. Oops ... The same happens if a ret or short jump instruction (7x opcode family on X86) occurs before the 4th byte from the address to be intercepted and this error message appears. Hooking such addresses is perfectly sane and has practical significance, so this problem group should be fixed asap. As it can be seen applying relocation logic in itself here is not the best idea. It shouldn't be a problem for interceptions if a basic block ends prematurely with a ret or a short jump within 5 bytes. This should be special-cased carefully. |
Another strong reason to fix this problem group is that the Javascript API docs on the Frida website states in connection with Interceptor.attach: "You may also intercept arbitrary instructions by passing a function instead of the callbacks object. This function has the same signature as onEnter, but the args argument passed to it will only give you sensible values if the intercepted instruction is at the beginning of a function or at a point where registers/stack have not yet deviated from that point." It can be seen from frida-gum sources that the check based on relocation logic described in comment 1 also applies to this case together with its consequences of course. Thus currently the hooked instruction cannot be arbitrary until this problem group gets fixed. |
Absolutely – I've actually been hoping for somebody to run into this so it eventually gets addressed. ;-) Our |
I am very much interested, but I am afraid I don't know enough yet about Frida internals to try my hand at implementing this right now. I am into reversing for a long time, but only installed Frida few days ago (I've been working with many other tools so far). I've run into this issue during my first instrumentation project with Frida. Fortunately with this knowledge I documented here I've been able to work around this issue in my case. |
Hi, |
Helllo,
|
I'm playing Frida with Windows binary. The code below is what I'm playing with.
Because I want hooking 0x003d3e65 and 0x003d3eca address, I scripted a test.js like below.
Frida said,
Error: unable to intercept function at 003D3ECA; please file a bug
at frida/runtime/core.js:471
at repl1.js:26
Frida version : 10.7.6
The text was updated successfully, but these errors were encountered: