Patching the Mach-o Format the Simple and Easy Way

This is a strange post for me.

I'm relatively new to mac research.  So when I find something new, that seems cutting edge, but relatively simple I question it. Has anyone else done this before? Is this in the public domain? Is this in the academic domain that I have no way of researching?

I google like hell.

I question myself (for a short period of time).

I write my congressman.

I wait.

I try to contact people in the know without letting them know to much.

Then I'm afraid I've said too much.

So here we are.

Thank's to the guys in #osxre (fg!) for telling what would work and not work.

This is my 'new' method for patching the mach-o format.

The macho format is simply nested segments in a very straight forward waterfall format that IMHO is much more simple than the PE and ELF formats.

As you have seen many times, this is the format, no seriously, this is it:

From: https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html

What is so special about this format?

It is very hackable easy to modify, far easier than ELF and PE formats.

There are not many code caves in a mach-o executable:
$ file ls.mach-o
ls.mach-o: Mach-O 64-bit executable x86_64

$ python ./find_caves.py ls.mach-o
[*] Looking in ls.mach-o for caves
[*] Looking for caves of 50 byes in size
No section
->Begin Cave 0x736
->End of Cave 0x10f8      # <--- Remember this one
Size of Cave (int) 2498
**************************************************
No section
->Begin Cave 0x4ff6
->End of Cave 0x5038
Size of Cave (int) 66
**************************************************
No section
->Begin Cave 0x54d1
->End of Cave 0x6000
Size of Cave (int) 2863
**************************************************
[*] Total of 3 caves found

The caves are large, but they are not in a section that includes read/execute attributes.

But let's look at the beginning of the __TEXT/_text segment/section:

Let's look at lower address space, what's going on?

Continuing:

Continuing:

You get the idea.  Many zeros. Much waste. Wow.

But that looks like enough room for shellcode, right? (The answer is yes).

How do we make that part of the __TEXT,__text segment/section?

Easy:

1. Change the __text section Address and Offset to the beginning of your shellcode and Size to accommodate your new shellcode.

Update 1/28/2014: This step is not necessary. Greetz to fG!: https://reverse.put.as/2012/02/02/anti-disassembly-obfuscation-1-apple-doesnt-follow-their-own-mach-o-specifications/

Before:

After:

2. Change LC_Main to point to the __text Offset or if a LC_UNIXTHREAD binary make sure [eip|rip] points to the new __text Address.

Before:











After:



3. You need to fork() your shellcode so that it continues after the parent has completed and you need to make sure that what LC_MAIN/LC_UNIXTHREAD was pointing to originally is the first thing that is executed whether a dyld or the __text section. Here I have the shellcode that I use in my POC.

And that's it. No really. That's it.

Here's the beginning of the __TEXT Segment after:

As you may have already figured out, this method works on both LC_MAIN and LC_UNIXTHREAD binaries. Also, this will work from within Fat binaries.

Proof:

Top window: netcat listener
Bottom window: Executing the patched ls.macho showing all the other successfully patched bins with my POC.

I've already automated the i386/x64 intel chipset mach-o patching, expect an update in BDF supporting these chipsets and Fat binaries containing these mach-o formats.

Cheers,
Midnite_runr