-
Notifications
You must be signed in to change notification settings - Fork 210
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
Additional interceptors: onEnter + onLeave #586
base: master
Are you sure you want to change the base?
Conversation
@@ -23,8 +23,12 @@ namespace Il2Cpp { | |||
return Il2Cpp.exports.free(pointer); | |||
} | |||
|
|||
/** @internal */ | |||
export function read(pointer: NativePointer, type: Il2Cpp.Type): Il2Cpp.Field.Type { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was an interesting one. Parameters are different from eg Fields, in that they don't need to be dereferenced first. If you get a pointer that's meant to be a Il2Cpp.String
, then no need to call ptr.readPointer()
first.
Made this new behaviour backward compatible.
} | ||
|
||
raise(`couldn't read the value from ${pointer} using an unhandled or unknown type ${type.name} (${type.typeEnum}), please file an issue`); | ||
} | ||
|
||
/** @internal */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Err unrelated but could we have these exposed in the API? Bit more low level but super useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That method is indeed here - if you invoke it, it works. It just isn't exposed (yet?)!
wrapOnLeave(block: OnLeaveCallback<T>): ((this: InvocationContext, retval: InvocationReturnValue) => void) { | ||
return (retval: InvocationReturnValue) => { | ||
// TODO grab `this` pointer during `onEnter` | ||
const thisObject = this.class |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we derive this
from the first argument sometimes, I suppose we'll always have to hijack both onEnter and onLeave at the same time, otherwise we can't propagate this
to onLeave
. Edit coming up...
The main reason why I didn't use Ref: frida/frida#266 (comment) However, a lot of time passed since that, and Frida might have implemented the support for it. |
This isn't quite ready, but I wanted to start the conversation.
onEnter
andonLeave
(after Frida's own) are a bit less heavy-handed than replacing the whole implementation, and don't require explicit calls to the original method if you don't want to change output values. They're useful for inspection.It's now possible to do something like
However, one of my real reasons for writing them is that
set implementation
appears to break some methods. There are some types and values for which the sequence offromFridaValue -> toFridaValue
isn't idempotent, and breaks. I'll send a separate PR once I've fully figured out what's happening, but for now this PR helps me debug.I'll leave some comments inline. Also, I'm super not precious about what this API should look and feel like.