Args don't appear to be NativePointers in frida-trace handler
petertorelli opened this issue · comments
EDIT: This appears to be Frida issue 226, but that issue was from 2017 and the the comments in the default handlers + documentation seem to imply attach() should work with floats?
Really simple example that isn't behaving as documented. I expected args to be NativePointers according to the comments. Version 15.0.14.
C-code
#include <stdio.h>
void print_hello(int n, char a, float f) {
printf("hello %d %c %f\n", n, a, f);
}
int main(int argc, char *argv[]) {
print_hello(10, 'a', 3.141f);
return 0;
}And the handler for print_hello (abreviated):
onEnter(log, args, state) {
log('print_hello() enter');
log(args[0]);
log(args[1]);
log(args[2]);
log(args[2].readFloat());
},And the output from frida-trace:
% frida-trace -f a.out -i print_hello
Instrumenting...
print_hello: Loaded handler at "/Users/ptorelli/study/frida/01/__handlers__/a.out/print_hello.js"
hello 10 a 3.141000
Started tracing 1 function. Press Ctrl+C to stop.
/* TID 0x103 */
4 ms print_hello() enter
4 ms 0xa
4 ms 0x61
4 ms 0x7ffee3d99d90
4 ms -8.028827138591864e+21
4 ms print_hello() exit
Process terminated
I expected args[0] and args[1] to be pointers, they are instead the values.
args[2] looks like a pointer, but when i call readFloat() on it I get random values.
The comments simply say these should be NativePointers.
Advice?
MacOS Big Sur, Apple clang version 12.0.0 (clang-1200.0.32.28)
Tried this on Ubuntu 20.04 with gcc 9.3.0 (-O0) and frida-trace can't even find print_hello (even if static).
This is expected behavior. Your function is not receiving pointers, it is receiving values. Thus you will see values in the trace handler, not pointers to them. The values will be wrapped in a NativePointer structure, so that 64-bit values (and pointers) can be represented. NativePointer does not introduce any indirection in and of itself.
Closing.
Could you explain the correct way to print the float in my example in the log, or point me to the documentation, or an example, rather than just saying it is wrong with no correction? Because If what you say is true, then why is neither log of args[2] in my example 3.141?
In the first log command args[2] I get 0x7ffee3d99d90 which is a pointer value, not a 32-bit float (nor is it a 64bit double), and on the second when I call the function NativePointer.readFloat(), I get the wrong value.
Ok. I checked. It looks like there is currently no way to convert a NativePointer into a float... We probably need to add a .toFloat method.
OK, thanks. In the issue I cited, the recommendation was to inject a NativeFunction (especially for structs and other datatypes that are machine/program dependent), but I was hoping there had been progress.
If you're feeling adventurous, you could open a PR to add .toFloat to NativePointer. Unfortunately it's not high on the priority list, even though it would be great to have and probably not too much work.
Hi @s1341 ... I am feeling adventurous. I'll take a swing at it.
@s1341 ... It looks like gumv8memory.cpp already implemented it:
case GUM_MEMORY_VALUE_FLOAT:
result = Number::New (isolate, *((gfloat *) address));
break;
case GUM_MEMORY_VALUE_DOUBLE:
result = Number::New (isolate, *((gdouble *) address));
break;But this is reading the pointer memory as float, rather than converting the bytes .toFloat as you suggested. I see the difference now.
@petertorelli looks good in general. I'd recommend trying to get it building. It's quite easy to get setup... Look at the hacking guide and feel free to ask questions here, or in the telegram channel...
I also encountered this problem
I also encountered this problem ，jni jfloat --> float
@petertorelli Have you solved this problem？
I have installed the new latest version，encountered this problem also.