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

Confusing/non-consistent type representation in overload(...) #4

Open
oleavr opened this issue Jan 19, 2017 · 1 comment
Open

Confusing/non-consistent type representation in overload(...) #4

oleavr opened this issue Jan 19, 2017 · 1 comment

Comments

@oleavr
Copy link
Member

oleavr commented Jan 19, 2017

(Continuation of frida/frida-gum#117.)

As described by @stevielavern:

When using Java.method.overload(...), the full name of native types must be used and not the letters representing these types in Java signatures. For instance int instead of I, byte instead of B, etc.

But when the parameter is an array of a native type, the letter must be used and not the full name.
For instance, if the method is method(int x, int y[]), overload must be used like this: method.overload("int", "[I") and not with [int orint[].

While not a big issue, this can be misleading/counter-intuitive.
A simpler way to avoid any confusion could be to use the signature of the method in overload(), for instance for the previous example I[I.

@iamahuman
Copy link
Contributor

iamahuman commented Apr 25, 2017

Actually, Java's Class.forName has the same issue where ordinary type names are passed in like int or java.io.InputStream, while array types are given in the "internal" format like [Ljava/lang/Object; (an Object[]) or [[[Z (a boolean[][][]). Since there's also an issue where an obfuscated app may have bizzare class names like int or long which certainly won't work with frida-java, there may be a need for normalizing type representations for arguments passed in for such methods.

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

2 participants