Another approach is using LD_PRELOAD with Frida to be able to write the instrumentation logic in JavaScript:
https://www.frida.re/docs/gadget/
This also supports monitoring the .js file for changes and reloading the instrumentation logic live, which is great for game tweaks. Just save the file and instantly see the results.
Just heard from Tyilo, in #frida on irc.freenode.net, that replacing mach_vm_* with vm_* makes the test-case work on 32-bit devices, where apparently mach_vm_* are missing.
and thanks for checking it out! The currently released version of Frida, 1.6.8, doesn't have the work-around and triggers the kernel panic described in the blog post. The work-around landed in git last night and will be part of 1.6.9 to be released soon; hopefully by tomorrow if all goes to plan. Feel free to clone and build Frida yourself if you'd like to play with it in the meantime (or make sure you never attach more than once to any process). Sorry for the inconvenience!
Feel free to drop by #frida on irc.freenode.net, btw!
Oops, in retrospect I should have resisted my OCD-fueled urge to link every single reference to be consistent. :p
Speaking as its creator and maintainer, it's been a pet project for the last 5 years (7 if you start from frida-gum, the code instrumentation engine), but to this day it's still rather obscure considering its potential. I regret not spending more time marketing the project over the years, so these days I'm doing my best to make up for that. :)
Is it a 64-bit device? Does the program crash or exit gracefully? If it crashes, try bumping the library index argument here:
library = (char *) _dyld_get_image_header (1);
If you're unlucky library at index 1 contains mach_vm_read_overwrite and is suddenly no longer executable (since we change its second memory page from R-X to RW- due to stock kernels not allowing RWX pages).
Where does it crash? Try bumping the argument on line 21 – if you're unlucky library at index 1 contains mach_vm_read_overwrite and is suddenly no longer executable (since we change its second memory page from R-X to RW- due to stock kernels not allowing RWX pages).
I only tested it on 64-bit systems, where it triggers the kernel panic from both 32- and 64-bit processes (i386, x86_64, arm, and arm64). Hardware-wise it crashes every single device I've tried (MacBook Pro, iMac, iPhone 6, etc.), so this is not tied to any specific hardware.
Interesting, that's potentially very good news! To be sure, could you try again with the latest code snippet? I forgot to remove the VM_PROT_EXECUTE flag for non-jailbroken devices.
The mach_vm.h header has been replaced with a dummy version in recent iOS SDKs, so you’ll have to copy it from your OS X SDK and adjust the include. Just updated the post, and also removed VM_PROT_EXECUTE from the mach_vm_protect call for compatibility with non-jailbroken devices.
I'm the founding author of several open source projects like http://www.frida.re, https://github.com/frida/cryptoshark, and https://code.google.com/p/ospy/.
Extremely passionate about reverse-engineering, which started with libmimic, where I reverse-engineered a proprietary video codec from scratch (see: http://tech.slashdot.org/story/05/04/05/0240236/logitech-msn...).
Have a diverse background spanning IM protocols, video conferencing, codecs, automotive hacking, dynamic binary instrumentation, GUI toolkits, web technologies, and most recently the music industry (Soundrop.fm and Show.co).
As you can see from the source code in the projects mentioned, I master C, C++, C#, Vala, Python, JavaScript, etc., and I'm also fluent in assembly for several architectures (IA-32, x86-64, ARM, AArch64, etc.). I also have years of experience building GUI apps for Windows, Mac, Linux, iOS and Android, and did a lot of backend development in Erlang. Through my experience building Frida I implemented features ranging from dynamic rewriting of function prologues for x86 and ARM 32- and 64-bit, dynamic trampolines, all the way to building a code tracer based on dynamic recompilation (see: https://medium.com/@oleavr/anatomy-of-a-code-tracer-b081aadb...)
I am available for both individual projects and long-term positions, but I can only work remotely.
There's internal support for them in Frida, but it's not currently exposed to the public API (which CryptoShark uses). The main focus has been on proprietary apps so far, but it would definitely be a very welcome feature for a future version.
Thanks a lot! This appears to be an issue with the Frida build system and the Linux buildbot slave. We're investigating and will hopefully have a bugfix release out in the next few hours.
Hope we'll get the pip issue sorted in the near future, need to do some more research into what's possible when not relying on eggs for binary releases (ran into issues when we tried to use bdist_dumb, so we postponed it for later).