You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You might have been in a scenario were you wanted to trace a set of methods during the startup of the target process. Unfortunately, due to how Il2Cpp::perform and the internal Il2Cpp::initialize were designed, you might not have found what you were looking for.
In fact, Il2Cpp::perform always tried to execute the given block on the thread it was called from (e.g. the Frida's one). It means that it was not possible to execute the given block in a blocking fashion: the main thread was able to perform possibly a lot of method calls and frida-il2cpp-bridge had no chance to catch them.
I'm thrilled to announce early instrumentation is now possible - just pass "main" to Il2Cpp::perform:
Il2Cpp.perform(()=>{// code here},"main");
The "main" flag has a double function:
If IL2CPP has not been initialized yet, your code is executed right after il2cpp_init, so that the rest of the original execution flow is resumed only after your callback. For instance, you now have all the time to set up your Il2Cpp::Tracer.
If IL2CPP has already been initialized, your code is just scheduled on the main thread - i.e. a shorthand for:
In other words, the "main" flag ensures the given callback is executed on the main thread.
Better Il2Cpp::perform flag names
The second optional Il2Cpp::perform parameter now accepts:
"free" (it was "always") immediately detaches the caller thread after executing the given block;
"bind" (it was "lazy") (default) detaches the caller thread only when the script is going to be reloaded or destroyed
"leak" (it was "never") never detaches the caller thread explicitly.
"main" (new): ensures the given callback is executed on the main thread.
Relevant changes
Drop Il2Cpp.Thread::schedule::delayMs:
It relied on Frida's setTimeout, which schedules the callback on the Frida's thread. It didn't play well with our threading model.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Here we are with a new, small release.
Early instrumentation
You might have been in a scenario were you wanted to trace a set of methods during the startup of the target process. Unfortunately, due to how
Il2Cpp::perform
and the internalIl2Cpp::initialize
were designed, you might not have found what you were looking for.In fact,
Il2Cpp::perform
always tried to execute the given block on the thread it was called from (e.g. the Frida's one). It means that it was not possible to execute the given block in a blocking fashion: the main thread was able to perform possibly a lot of method calls andfrida-il2cpp-bridge
had no chance to catch them.I'm thrilled to announce early instrumentation is now possible - just pass
"main"
toIl2Cpp::perform
:The
"main"
flag has a double function:il2cpp_init
, so that the rest of the original execution flow is resumed only after your callback. For instance, you now have all the time to set up yourIl2Cpp::Tracer
.In other words, the
"main"
flag ensures the given callback is executed on the main thread.Better
Il2Cpp::perform
flag namesThe second optional
Il2Cpp::perform
parameter now accepts:"free"
(it was"always"
) immediately detaches the caller thread after executing the given block;"bind"
(it was"lazy"
) (default) detaches the caller thread only when the script is going to be reloaded or destroyed"leak"
(it was"never"
) never detaches the caller thread explicitly."main"
(new): ensures the given callback is executed on the main thread.Relevant changes
Il2Cpp.Thread::schedule::delayMs
:It relied on Frida's
setTimeout
, which schedules the callback on the Frida's thread. It didn't play well with our threading model.Full Changelog: v0.8.1...v0.8.2
Beta Was this translation helpful? Give feedback.
All reactions