DIY: kernel panic OS X and iOS in 10 LOC | Hacker News Reader

DIY: kernel panic OS X and iOS in 10 LOC

medium.com

117 pointsoleavr49 comments

http://www.frida.re/ looks actually very interesting.

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.

Why exactly do you think Frida looks interesting?

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.

Some links to SIMBL: https://github.com/norio-nomura/EasySIMBL https://code.google.com/p/simbl/wiki/SIMBLPlugins

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

A similar project is this: https://github.com/albertz/FScriptAnywhereSIMBL

And this Frida looks like a similar more modern project with JavaScript and support for Windows, Mac, Linux, iOS and Android.

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

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/

That's interesting. Does it work for any processes at all? Would you be interested in trying to reproduce it with the latest Frida from git?

What does it look like when it crashes on iOS? Does just the app crash, springboard crashes or the device restarts?

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.

It is supported, just need an expanded SDK or you can provide the OS X variant of mach_vm.h and import that.

But clang did not treat it as an error when I commented the #include line. I have no idea if it was actually dynamically linked.

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.

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.

The screen turns blue – yes, blue, not joking – for a brief moment, and the system reboots. :)

Is it 64-bit only? Which hardware are you using for this test?

EDIT:

I cannot reproduce on iPhone 5 which is NOT running any 64-bit kernel.

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.

Aha, interesting. Does the program crash or exit gracefully?

Debugging with lldb: no crash; Running from springboard: EXC_BAD_ACCESS (SIGKILL - CODESIGNING)

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.

It does not crashes iOS 8.3.

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.

No kernel panic, EXC_BAD_ACCESS in Debug/Release confs.

Possibly I have provided wrong prototypes, mach_vm is n/a in iOS: https://gist.github.com/cfr/425812debdb2a6d0449f

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

Yes, it crashes with kernel panic now.

Yay!

I set up a Xcode project to test it on iOS https://github.com/jdmoreira/KernelPanic-10LOC

It doesn't work on my device running iOS 8.1.2 Can someone confirm?

Edit: It works now!

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

I changed the code to https://gist.github.com/cfr/425812debdb2a6d0449f

It works now! Device restarts ;)

Excellent! :)

Hello I just checked out Frida (been meaning to just forgot the name)

I get a kernel panic in Mac OSX Mavericks (10.9.4) running this

import frida p = frida.attach("cat") print(p.enumerate_modules())

Not sure if this is a similar problem or not but doing print([x.name for x in p.enumerate_modules()]) instead works just fine.

Edit: Looks like the problem may be attaching to a program a second time. Not sure if I need to run some detach command or whatnot.

Hey,

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!

Cheers!

A very nice reminder that there's no such thing as code without bugs.

I see it as a reminder not to run software than you cannot patch yourself.

So unless you're a software developer don't use software?

Unless you're a software developer, don't call yourself a "hacker" and don't waste your time on Hacker News.

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

You're right. Now, if you'll excuse me, I'll go hack dinner.

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.

I just created the third, forth and fifth patches here to make vmware-modules compile and work on the 3.19.0 Linux kernel: https://bugs.gentoo.org/show_bug.cgi?id=539972

I write Python for a living.

Some projects also have terrible project layouts. I have to poke around for several minutes just to find the source folder.

> Unless you're a software developer, [...] don't waste your time on Hacker News.

That is both wrong and mean. Non-programmers are 100% welcome on Hacker News. The only criterion is willingness to follow the site guidelines.

The mandate of HN is "stories for the intellectually curious", not "exclusive programmer tribe".

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

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.

Well, on my rMBP I don't need to write a single line.

Neither should you have to: "It Just Works".

You probably have a hardware problem or kext. Haven't had a KP in years.

Take your laptop in and have it replaced.

Kernel panics don't just happen on OSX unless you have some third party driver that is misbehaving or far more commonly you have a hardware fault.

Damn.

Reply on news.ycombinator.com