Overhead Data: Frida-gum VS Static Instrumentation

[xiejingwei]

What is the approximate overhead introduced by inline hook mechanism in frida-gum?

Could you please share any performance comparison data between them?

I conducted an informal test, and the extra overhead reached up to 80%. Could it really possibly reach this level？

[oleavr]

This snippet from our JavaScript API docs may be helpful:

The callbacks provided have a significant impact on performance. If you only need to inspect arguments but do not care about the return value, or the other way around, make sure you omit the callback that you don't need; i.e. avoid putting your logic in onEnter and leaving onLeave in there as an empty callback.
On an iPhone 5S the base overhead when providing just onEnter might be something like 6 microseconds, and 11 microseconds with both onEnter and onLeave provided.
Also be careful about intercepting calls to functions that are called a bazillion times per second; while [send()](https://frida.re/docs/javascript-api/#communication-send) is asynchronous, the total overhead of sending a single message is not optimized for high frequencies, so that means Frida leaves it up to you to batch multiple values into a single [send()](https://frida.re/docs/javascript-api/#communication-send)-call, based on whether low delay or high throughput is desired.
However when hooking hot functions you may use Interceptor in conjunction with [CModule](https://frida.re/docs/javascript-api/#cmodule) to implement the callbacks in C.

However, that's about attach(). Did you measure with replaceFast()? Note that attach() and regular replace() have a lot more overhead because they save all registers, flags, etc., so your hook can make use of them/change them, and also so the hook can be safely applied when the target uses a non-default calling convention.

[xiejingwei]

@oleavr Thanks for your response.

Actually I measured with the dynamic library I implemented myself with the raw interceptor API provided by frida-gum, rather than those in gumjs. I speculate that such implementation is at least equivalent to attach() in terms of performance, or perhaps slightly better, as it appears to be analogous to CModule implementation.

In listener_on_enter(), I used gum_invocation_context_get_nth_argument() to retrieve the arguments of the corresponding function, and left listener_on_leave() as empty.

In the static scenario compared with it, I did almost the same: Recording the arguments in a wrapper at each function call.

In this case, the additional overhead may arise from the inline hook mechanism and the process of retrieving arguments by accessing registers. Is this understanding correct?