Closed petertorelli closed 3 years ago
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.
I'm not sure how to 'cast' the NativePointer to a float. @oleavr Can you chime in?
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.
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
And the handler for
print_hello
(abreviated):And the output from
frida-trace
: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).