Let’s start from the very beginning, Mach-O. In order to understand what are the differences introduced in Lion, we need to first give a look at a Mach-O built on two different OSes, we will take as a reference Snow Leopard. Let’s build this simple code for test:

If we compile that code on Lion, no specific option passed to gcc, we will notice a difference from the very same code compiled on Snow Leopard. The difference is the presence of the flag MH_PIE (Position Independent):

/usr/include/mach-o/loader.h

The MH_PIE flag has been sitting there since MacOS 10.5 and the linker on Lion is now defaulting to it.
The funny thing is that with MH_PIE enabled, the image base will always be at a fixed offset from dyld, 32bit or 64bit, no difference (just a bigger displacement).

Let’s give a look at the base addresses for the main executable and dyld on both cases [Lion, SL]:
NOTE: If you execute the binary through gdb you will have to set disable-aslr off (in gdb, before run) in order to enable dyld randomization, but even then you won’t have PIE enabled. That’s why I have added that otherwise inexplicable while (1) {}

Compiled on Lion (64bit), executed on Lion:

Compiled on SL (64bit), executed on Lion:

After hundreds of executions you can notice that dyld will always be at 0×1000 from the image base on 32bit, and 0×400000 on 64bit:

Since image bases are page aligned we can remove 1 byte and a nibble from the address, this leaves us with 2 bytes randomization on dyld (in this case 0xaf97). We’re actually working on 64bit! On 32bit we have, uhm, the incredible amount of 1 byte.

On Lion the userspace has been changed quite a bit, now there’s no big fat libSystem anymore (there still is but it’s not that fat ), instead there are several different libsystem_something located at /usr/lib/system. This ensures logical separation and randomization (libraries were already randomized in 10.5). Now there is also a libdyld.dylib which has a lot of symbols that were once in /usr/lib/dyld.

The problem with dyld was that it was loaded at a fixed address providing loads of go-go-gadgets for ROP exploitation. Now they say it’s randomized. And several different symbols have been moved to libdyld which is randomized.

Funny thing is that /usr/lib/dyld is still working as it was. dlsym() will resolve symbols in libdyld, but if you resolve symbols on the mapped dyld image (e.g. with your own implementation of dlsym()) you’ll see that everything works as it was in the past.

In conclusion, it looks like the big changes introduced in Lion (regarding dyld randomization) were actually a 2 bytes randomization on 64bit and 1 byte randomization on 32bit, always at a fixed offset from the main executable image base (with MH_PIE flag set).

Well, that’s it Hope you guys enjoyed and stay tuned!

I will make this the first place where I’ll post all the stuff I usually do – software engineering, reverse engineering, OS internals and everything else worth publishing here.

I think that’s all for now