Onyx The Black Cat v0.1 – Anti Anti-debug kernel module

Here it is, my crazy idea to create an anti anti-debug kernel module so reversing efforts get a little easier and faster against “hostile” code.

This module will protect you against the classic PT_DENY_ATTACH trick and the sysctl debugger detection trick (http://developer.apple.com/qa/qa2004/qa1361.html).

For now it’s only compatible with Mac OS X Tiger v10.4.11. Soon I will make it compatible with Leopard.

Grab the binaries here: onyx-the-black-cat.kext.v0.1.tgz

This is a small program to test the sysctl trick: antidebug.c

XCode Project source code here: onyx-the-black-cat.src.tgz

More updates very soon. Meanwhile enjoy this 🙂

fG!

Some good reading:
Attacking FreeBSD with Kernel Modules by pragmatic / THC <http://packetstormsecurity.org/papers/unix/bsdkern.htm>

Fun and Games with FreeBSD Kernel Modules by Stephanie Wehner <http://www.r4k.net/mod/fbsdfun.html>

Designing BSD Rootkits: An Introduction to Kernel Hacking by Joseph Kong, No Starch Press

12 thoughts on “Onyx The Black Cat v0.1 – Anti Anti-debug kernel module

  1. Excellent!
    Hope to see the leopard version soon, gonna check this one on my other machine tomorrow.

    Thanks!

  2. I will compile and test a Leopard version this weekend. There should be no big problem since Landon Fuller’s original code was for Leopard. I will post it when it’s ready.

    I have been using this module to reverse Remote Buddy and gave me no problems 🙂 I have another trick to add it since Remote Buddy is using something I wasn’t expecting to hide his trial date.

  3. Well, last night I’ve been playing around with the latest version of Remote Buddy, I remember you tell me to sing the app after any modification but it was late (4.30 AM in the morning so I only have 2 hours to sleep and go to work) I patched 3 _ptrace calls in the main binary, forget to re sign it but it wss runnig perfectly when I leave home this morning.
    It keeps quitting under GDB with Error Code 146, I can debug up to one of this calls:
    [CODE] 171 +186 000033b8 e8b7041a00 calll 0x001a3874 _NSLog[/CODE]
    [CODE] 177 +204 000033ca e878041a00 calll 0x001a3847 _NSApplicationMain[/CODE]

    It loads some resources (images for what I understand) but it never reachs the return of that code section at 0x000033d5.

    Looking forward to see what you found, I’m still intrigued by that large series of _rand calls…

    Also, I found an interesting link about GDB here: http://www-128.ibm.com/developerworks/aix/library/au-gdb.html
    I searched for the Mammon gdbinit file but the ones I found have a couple of errors in them, I think they may have been “updated” by someone else.

    Did you ever check some info about the old macsbug back in the days of OS 9? It’s of no use now but it was great, you could jump to it at anytime with the programmers button in every mac and there was all the info you need instantly: PPC registers, a backtrace, etc.

  4. Well, I forget to add this in the previous comment, sorry.
    I fired up fseventer during the first run of file buddy and find some pretty interesting things, a lot of files and folders (the Users home for example) where left wit a special attribute, you can see an “@” if you do a ls -la.

  5. That’s why the module is nice, because I don’t need to patch anything and don’t need to worry anymore with those calls 🙂

    Grab my gdbinit here: http://reverse.put.as/gdbinit

    It’s Mammon’s one but with some stuff (the one that gives errors). It’s in the TODO list to make theat gdbinit more Mac friendly.

    Yeap, you discovered the same thing I did 🙂 Remote buddy stores encrypted information in the extra attributes space, more specific at /Users/username dir.
    In Tiger there’s no utility to read this attribute (some article talks about exttra.zip, but the file isn’t available anywhere) and “ls -la” doesn’t show anything. I’m finishing a small perl program to read that stuff (there is a nice perl module called File-ExtAttr-1.08).
    There are other two files where it stores information (/Users/username/Desktop/.DS_Store and /Users/username/Documents/.DS_Store). Those files have spaces at the end of their names! Then it stores an encrypted field in the GlobalPreferences.plist file.

    I already knew the extended attributes trick to store information (from rootkits) but got me by surprise here. I will update Onyx to monitor these kind of calls, because they can be easily lost on “fs_usage” traces.

    I will write something more complete and publish the perl util as soon as I finish it.

  6. Ah… about the _rand calls… They seem to be there just to bother and fill up cpu cycles. There is lot of cpu cycles waste there, for example, to “obsfucate” the fact that is going to read .GlobalPreferences.plist file it takes like 200 lines of code to do that 🙂

  7. About the extended attributes, check the software for Rixstep, those guys are great developers, they really care about the quality of their code.
    http://rixstep.com/4/0/
    You may be interested in Xattr and Xattrib, they’re part of a bigger suite called ACP (Apple Core Project). I actually own this software because I found it to be a real life saver.
    http://rixstep.com/4/0/td.shtml
    They also have some excellent articles on Acces Control List, Extended Attributes and HFS+ (Hopeless File System 🙂 ) , metadata, exploits, bugs and lots of thing someone working on software development should care.
    I know it, those _rand where just waisting time, its like when I was 15 and needed to do a timer with a Motorola 68k J1 microprocessor.
    So a jump to skip all that lines straight to the end should make the app go faster and waste less cpu power. Thats an optimization.

  8. Hummmm appears to be really nice software there !! And the articles look nice too ! Thanks for the link 🙂

    That’s a good idea to patch the program, bypass those rands. Now I need to give a look at the decrypt routine.

    You should already know where the fun starts: -(id)[CopyCore init]

    The decrypted dictionary is like this:
    {
    M = 0;
    F = 2008-10-01 18:02:36 +0100;
    C = 45;
    Z = 20;
    L = 2008-11-06 14:47:05 +0000;
    E = 1;
    }

    After encryption is defeated, it’s easy to extend trial forever. To remove the initial nag should be easy too 🙂

  9. I’m shure you realized this before than I but I’m slowly learning how this program works. It is always the same routine, it gets the process id, then the _sysctl cal, then a conditional jump and then “~” and exit, so there is where I’m getting my code 146 from…
    I’ve already jumped out those rands, is always the same offset 0x3ae8, 15.080 lines of useless code, and I think I patched like 10 of those jumps.
    On the other hand I checked with Xscan and found 40772 items with extended attributes, a lot of them from the Office 2008 and the Adobe CS3 installation, I’m thinking if it is a good idea to clean them all and see what happens, maybe there are other programs besides this one and the Finder using them.
    So, the CodeResources files only holds sha1 checksums for the files in the Resources Folder, and the lproj are marked optional because some people like me likes to clean unused languages to save disk space, but there is no checksum for the binary, nor integrity checks in the binary itself.
    I’m still looking at your previous writings trying to understand all those encryption function calls and such, it will be a long night.

  10. That routine you are talking about is the routine from the link you gave me (http://developer.apple.com/qa/qa2004/qa1361.html).

    This post (http://reverse.put.as/2008/09/10/pthpasteboard-440-generic-mac-os-x-protector-is-found/) has some discussion in the comments about Leopard code signing. It’s very easy to bypass so it’s not a big problem for you 🙂

    The decryption routines are located at:
    +(id)[NSDictionary(Crypt) decrypt:]
    and
    +(id)[NSDictionary(Crypt) decrypt:withUnarchiver:]

    These are the ones called when the program is started and that result in the decrypted dictionary I pasted in my previous reply 🙂

Comments are closed.