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

Args don't appear to be NativePointers in frida-trace handler #59

Closed
petertorelli opened this issue Aug 18, 2021 · 13 comments
Closed

Args don't appear to be NativePointers in frida-trace handler #59

petertorelli opened this issue Aug 18, 2021 · 13 comments

Comments

@petertorelli
Copy link

petertorelli commented Aug 18, 2021

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).

@s1341
Copy link

s1341 commented Aug 19, 2021

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.

@s1341 s1341 closed this as completed Aug 19, 2021
@petertorelli
Copy link
Author

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.

@s1341
Copy link

s1341 commented Aug 19, 2021

I'm not sure how to 'cast' the NativePointer to a float. @oleavr Can you chime in?

@s1341
Copy link

s1341 commented Aug 19, 2021

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.

@petertorelli
Copy link
Author

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.

@s1341
Copy link

s1341 commented Aug 23, 2021

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.

@petertorelli
Copy link
Author

Hi @s1341 ... I am feeling adventurous. I'll take a swing at it.

@petertorelli
Copy link
Author

petertorelli commented Aug 26, 2021

@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.

@s1341
Copy link

s1341 commented Aug 26, 2021

@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...

@chongbo2013
Copy link

I also encountered this problem

@chongbo2013
Copy link

I also encountered this problem ,jni jfloat --> float

@lawindman666
Copy link

@petertorelli Have you solved this problem?

@lawindman666
Copy link

I have installed the new latest version,encountered this problem also.

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