It is, but I could never get it to work on my Windows machine. Process is always suspended upon startup, and only continues after I detach frida. I am working with his examples here:
http://ospy.org/frida/windows/examples/
The author linked to the site something like 37 times in the article. It made me not want to click through, thinking the article was just a shill blog post. Your short comment reinforces this.
I haven't tested it yet but I like to be able to inject into running native apps and control them, debug them, etc.
On MacOSX, there is the SIMBL project which enables such a plugin architecture for any OSX apps. E.g. you can get extra features like window-always-on-top, window-transparency, etc. And you can automate / script some apps which would not be scriptable otherwise or to such extend. Or you could add specific features to applications. E.g. Dropbox on MacOSX uses a technic like this to display some state-icon of its Dropbox directory in Finder.
SIMBL would inject other native code into to some app. In most cases you would inject other ObjC code.
I like the idea to dynamically script or mess around with an app. For that reason, I used SIMBL to inject Python + iTerm + PyObjC. That way, you can interactively interact with any app with Python. https://github.com/albertz/Pyjector
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. :)
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.
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.
Just tried with iOS 8.1 SDK. It seems that <mach/mach_vm.h> is not supported on iOS. So far, I failed to reproduce the crash/kernel panic with code snippet from the original post.
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.
Includes don't control linking, and traditional C did not require function prototypes, so most compilers (in non-C++ mode at least) will happily compile calls to unknown functions, it just assumes a default signature.
I know that and mach_* are supposed to be dynamically loaded. But what I failed to get is to reproduce the kernel panic, not to build and run on my iPhone 5. By now that piece of code could run but only result in normal crash, not kernel panic.
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.
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).
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).
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!
You know what's wrong and mean? Getting "You're submitting too fast. Please slow down. Thanks." the moment you fall under the radar of the same moderator who encourages users to downvote dissenting opinions.
I kid, I kid. Down with the toxic, up with the awesome (with the definitions up to the people in power)!
"Hacking" isn't exclusive to computers and software.
Also, at the time of writing this, the #1 article on Hacker News is "Most types of cancer not due to “bad luck” [pdf]" which has little to do with computers or software.
I'm a developer of 20+ years and have no idea how to patch most open source software and have it "just work".
Software has progressed to the point where the complexity and interconnectedness is far beyond what any one developer can do. Everyone just knows a few subsections.
It was quite common for the Linux kernel to panic, 15 years or so ago. I bet that even now it is much easier to make Linux panic than Darwin. HN became way too passive-aggressive in recent years... :(
I run a Linux kernel 'tainted' with binary modules on my desktop and I don't remember the last time I saw a kernel panic. Maybe a couple of years ago when I ran the nVidia proprietary drivers along the generic framebuffer even though the documentation advised against it.
