Unable to intercept function issue

[dodaeche]

I'm playing Frida with Windows binary. The code below is what I'm playing with.

003d3e5e c6430f00        mov     byte ptr [ebx+0Fh],0
003d3e62 3b45ac          cmp     eax,dword ptr [ebp-54h]
003d3e65 7606            jbe     codemap+0x3e6d (003d3e6d)
       ...
003d3ec9 5d              pop     ebp
003d3eca c3              ret

Because I want hooking 0x003d3e65 and 0x003d3eca address, I scripted a test.js like below.

var base = Module.findBaseAddress('target.exe')
var hook_one = base.add(0x3E62);
var hook_two = base.add(0x3ECA);

Interceptor.attach(hook_one,
	{ onEnter: function(args) {
			console.log('one');
		}});

// Does not work.
Interceptor.attach(hook_two,
	{
		onEnter: function(args) {
			console.log('two');
		}} );

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

[Palacee-hun]

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,
GUM_INTERCEPTOR_REDIRECT_CODE_SIZE, NULL))
return FALSE;

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.

[Palacee-hun]

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.

[oleavr]

Hooking such addresses is perfectly sane and has practical significance, so this problem group should be fixed asap.

Absolutely – I've actually been hoping for somebody to run into this so it eventually gets addressed. ;-) Our arm and arm64 backends are currently ahead of the x86 one in this area. Interested in taking a stab at implementing it and opening a PR?

[Palacee-hun]

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.
Nevertheless I am trying to find approaches to tackle this.

[apaly]

Hooking such addresses is perfectly sane and has practical significance, so this problem group should be fixed asap.

Absolutely – I've actually been hoping for somebody to run into this so it eventually gets addressed. ;-) Our arm and arm64 backends are currently ahead of the x86 one in this area. Interested in taking a stab at implementing it and opening a PR?

Hi,
I would like to lend a hand to work on this issue, if I could get the necessary guidance.

[apaly]

Helllo,
May I please ask if my offer to help will be accepted or needed?
Please let me know.

Hooking such addresses is perfectly sane and has practical significance, so this problem group should be fixed asap.

Absolutely – I've actually been hoping for somebody to run into this so it eventually gets addressed. ;-) Our arm and arm64 backends are currently ahead of the x86 one in this area. Interested in taking a stab at implementing it and opening a PR?

Hi, I would like to lend a hand to work on this issue, if I could get the necessary guidance.