JavaScript API can't handle 64-bit integers

[tyilo]

As Numbers in JavaScript are stored as doubles, they can't represent all 64-bit integers.

Problematic example:

$ cat > fail.c
#include <stdio.h>
#include <stdint.h>

uint64_t a = 0x8888888888888888;
uint64_t b = 0x8888888888888889;

int main(void) {
    printf("&a, a: 0x%p, %llu\n", &a, a);
    printf("&b, b: 0x%p, %llu\n", &b, b);
    getchar();

    return 0;
}
^D
$ cc fail.c -o fail
$ ./fail
&a, a: 0x0x108520020, 9838263505978427528
&b, b: 0x0x108520028, 9838263505978427529

(leave running)

$ frida-repl fail
Attaching...
>>> a = Memory.readU64(ptr(0x108520020))
9838263505978427000
>>> b = Memory.readU64(ptr(0x108520028))
9838263505978427000
>>> a == b
true

As you can see the JavaScript API thinks that the memory contents of a and b are the same, when they in fact differ by 1.

[oleavr]

This is not a bug per se, as the ptr() constructor is not meant to be used with JavaScript Number as an argument when dealing with actual pointers. It's helpful if you want to stick an enum value into a pointer, but probably more confusing than useful. Maybe the issue here is that we should remove that option entirely. ptr() (alias for new NativePointer()) is meant to be used like this: ptr("0xdeadbeef").

[tyilo]

The problem is not ptr it's the return value from Memory.readU64.
You can use Memory.readU64(ptr('0x108520020')) and Memory.readU64(ptr('0x108520028')) instead and you will still get the same output.

[oleavr]

Ahh sorry I missed that part. You're absolutely right. Memory.readU64() / Memory.readS64() are fundamentally broken, they should not return Number objects.

[tyilo]

Moved issue to frida-gum (frida/frida-gum#16)