Kernel module for syscall interception and fixing ptrace

Landon Fuller (http://landonf.bikemonkey.org/code/macosx) created a kernel module to bypass the PTRACE_DENY_ATTACH “anti-debug” feature of Mac OS X. For the Tiger version he used a deprecated API, removed on Leopard. For Leopard he re-routes the ptrace syscall to his own version by patching the syscall table. Since the Leopard version is much more interesting because we can use it to re-route other interesting syscalls (for cases where DYLD_INSERT_LIBRARIES trick isn’t interesting to use), I fixed his great code to be used for Tiger.

I added the open() syscall, and if you want to use it you should uncomment the code for it (check the source code, it’s there.

If you are using other version than 10.4.11, you should edit the Info.plist file and replace the com.apple.kernel string for the correct one (hint: use uname -a to get it).
Grab the code here:

pt_deny_attach-201-tiger.tar.gz

As usual, have fun 🙂

11 thoughts on “Kernel module for syscall interception and fixing ptrace

  1. That’s interesting stuff! Such a few line of code to do this kind of tricks… I must study XNU (in particular, the Mach and it’s IPC)! 🙂

  2. Yes it is 🙂 Check the paper from Blackhat USA 2008 about rootkits ! Worth the read if you are interested in this kind of stuff…

    The DYLD_INSERT_LIBRARIES trick might be useful too ! I have to post the code I was playing with (need to update all the links related to this stuff!)

  3. Hi, congrats for your site. It’s a great source of learning, I’ve been interested in ASM since I was 15 and programmed a motorola 68k microontroler for the first time.

    I’ve a question about this anti-anti-debug method, this solves the problem with programs like itunes exiting on gdb with 055 status, but I’m now looking at others programs that call sysctl() and they exit with status 146 when they’re run in gdb.

    I’ve found an article at apple talking about detecting the debugger using sysctl(), but I don’t know if it’s safe to NOP every call or how to detect the “bad one”.

    Got any hints?

    Thanks for sharing the knowledge and keep up the good work.

  4. Hello,

    Could you please tell me where to find such program using that sysctl() trick and the url for the Apple article ? I would love to give a look at such thing 🙂
    There are a few articles about fooling GDB under Linux but I doubt Apple would use such tricks.

    Thanks,
    fG!

  5. Just gave a very quick look and I think you can patch those calls (or convert those JE to a JMP). Only thing they are doing is calling exit if the program is being debugged. If you are using Leopard don’t forget you need to resign the binary since it’s “protected” by code signing.

    I will give this one a deeper look (bit busy at the moment 🙁 ) since it seems to have interesting tricks. I’m very curious why there are so many calls to _rand before a few of those sysctl routines. Or OTX can’t disassemble them correctly or maybe there’s some code crypted or something !

    Thanks for this nice target !

  6. Yes, I found that really large series of _rand strange too, maybe they’re trying to put a delay or just writing random values in the registers to distract your attention.

  7. I just hacked around a kernel module to bypass that protection.

    Example:
    $ ./antidebug
    Antidebug test…
    NO DEBUGGER FOUND
    End…

    Antidebug uses the same code from that Apple Technical Bulletin. With the module that sysctl protection is bypassed 🙂

    Let me polish the code and I will publish it 🙂 No need to patch the binaries !!!

Comments are closed.