Skip to content
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

getting types of function arguments in Interceptor hooks #14

Open
chib0 opened this issue Mar 20, 2019 · 5 comments
Open

getting types of function arguments in Interceptor hooks #14

chib0 opened this issue Mar 20, 2019 · 5 comments

Comments

@chib0
Copy link

chib0 commented Mar 20, 2019

the only way I can find to get the types of arguments to functions in hooks (or from the function signature in general) is using the argumentTypes property.

this property strips away reader and writer information leaving you only with the type of data, namely 'pointer', 'boolean' etc.

while this works find for basic types, it inhibits deep inspection of objects, since all pointer types get the type of 'pointer':
an Object (encoded as @) is a pointer.
a char * (encoded *) is a pointer.
a block (@?) is also just a pointer.

the information is ready and used while parsing the function signature and reading the arguments, it would be great if it could be exposed through argumentTypes as well.

@chib0 chib0 changed the title asd getting types of function arguments in Interceptor hooks Mar 20, 2019
@s1341 s1341 closed this as completed Mar 20, 2019
@s1341 s1341 reopened this Mar 20, 2019
@s1341
Copy link

s1341 commented Mar 20, 2019

Hit the wrong button there. Sorry.

@chib0
Copy link
Author

chib0 commented Mar 21, 2019

No worries.
I can close the issue and open a pull request instead, let's just see if my way of solving this is acceptable.
I'm thinking of exposing a new 'argReader' property for methodInvocationWrapper ( which is what I believe is returned from ObjC.classes.someclass['<selector>'] )

This property will expose reader(index) and typeName(index) that return a c'tor function and the true parsed type name respectively.

I would rather not override the original argTypes so I don't break existing code.

@oleavr
Copy link
Member

oleavr commented Dec 13, 2019

(Sorry for the delay here.)

How about something like obj.method.argumentTypes.toObjC(), which returns an array? We already expose types, so it would be a chopped up version of that, with stack frame offsets omitted.

@oleavr
Copy link
Member

oleavr commented Dec 13, 2019

(But we should ideally wait until @gebing's TypeScript porting efforts are complete.)

@gebing
Copy link
Contributor

gebing commented Dec 14, 2019

I think the convert between native and javascript is also very useful for processing native export functions, so in my utility code, i ported the toNative and fromNative from frida-objc-bridge to a more universal version, and i also made some utility functions converting between ObjC's NSString/NSArray/NSDictionary and Javascript's string/array/class.

@oleavr
Do you think whether we should change frida like this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants