choose() fails on some objects

[newsoft]

Context: I am targeting Apple demo app called "Fox", running on macOS 10.12, compiled with XCode 9.

choose() or chooseSync() methods work on NSString:

[Local::Fox]-> ObjC.classes.NSString.handle
"0x7fff93664f98"
[Local::Fox]-> ObjC.chooseSync(ObjC.classes.NSString)
...
"handle": "0x7f8d49d97ce0"
...
[Local::Fox]-> Memory.readPointer(ptr("0x7f8d49d97ce0"))
"0x7fff93664f98"

Now if I target a slightly more complicated class from this demo app:

[Local::Fox]-> ObjC.classes.AAPLCharacter.handle
"0x10184a430"
[Local::Fox]-> ObjC.chooseSync(ObjC.classes.AAPLCharacter)
[]

I used NSLog()to print the actual object address in memory:

[Local::Fox]-> p = ptr("0x7f8d49e974f0"); # address reported by NSLog()
[Local::Fox]-> Memory.readU64(p);
"0x21d80010184a435"

So it turns out that the actual address in memory & 0x7ffffffffff8 is the proper one to use in choose() method. I have no idea why, but I assume other bits are used as flags internally.

0x7ffffffffff8 as a bitmask makes sense, since:

• Userland pointers are 47-bit wide.
• The last nibble of all system handles seems to be always zero. There must be some allocator magic at work to get those properly aligned.

I'd love to test this hypothesis and provide a patch, but I am at a loss to actually compile and run from sources.

[oleavr]

Thanks a lot for digging into this! Just fixed it and tagged 10.6.8. Binaries should be available within an hour or so.

FWIW this module is published in npm, and Gum's JavaScript bindings, GumJS, contain an embedded copy of the latest stable version with every Frida release. If you ever need to build a local version you can customize it here. For using a local version I would recommend using npm link.

However, for hacking on frida-objc, and for building non-trivial agents, the best option is using frida-compile. This means you don't have to recompile Frida at all if you want to use a modified version of frida-objc, and it is quite handy when using the REPL with -l, which watches the file and auto-reloads on change. Full recipe can be found here – just replace frida-java with frida-objc.

Also, there are a few Frida-specific modules in npm, e.g. frida-trace and frida-screenshot. frida-compile also comes with shims to support the essential parts of the Node.js net and http modules, which means you can easily listen() on or connect() to TCP endpoints, implement a REST API directly inside an app, etc. Another advantage is being able to use the latest JavaScript syntax in Frida's default runtime, Duktape, which only supports ES5. Anyway, frida-compile is only meant for non-trivial agents and hacking on frida-objc and frida-java – for simple agents it's typically overkill.

Cheers!