ASLR

ASLR (Address Space Layout Randomization) is a form of data security used to randomize data on the RAM to help prevent exploits from taking control of the system. It first appeared in iOS 4.3.

Program and dyld

 * On program load, the address space offset of the program is randomized between 0x0 and 0x100000
 * Deployment target must be iOS 4.3 or higher
 * It always falls on a 0x1000 page boundary
 * 0x100 possible pages
 * dyld is included in this sliding section

Changes in iOS 5
In iOS 5, Apple fixed a major weakness in dyld: All dynamic libraries are "slid" around in memory on load regardless of the main binary's deployment target. However, the dylib is slid the same amount as the main binary. To exploit this, the use of only 256 possible pages to be loaded on was used. A simple loop looking for an info leak was used.

Kernel space ASLR
Mountain Lion boasts a xnu 2150 kernel, which includes, for the first time, ASLR in kernel space. Because OS X and iOS are so closely tied together, as previously surmised here, iOS 6.0 beta 1 (XNU 2107.1.78) indeed includes ASLR. This is the lowdown of ASLR:


 * When the kernel boots, i386_vm_init (iOS: arm_vm_init) initializes the value of vm_kernel_slide
 * The kernel supports a new system call (#439 on Mountain Lion, likely #440 on iOS 6), called kas_info. This will return the value of vm_kernel_slide, but only for a privileged process. Update for beta 3: Apple probably realized how stupid this is, and so the syscall (at 0x8021C9E8 on 6.0 beta 3, N81AP) returns 0x2D (ENOTSUP).
 * kld is updated to reflect the slide in symbols. Likewise OSKext::LoadExecutable and friends
 * stackshot and other kernel functions take the vm_kernel_slide into consideration and subtract it from the actual positions of functions/symbols.
 * Disassembly is somewhat harder. Rather than store addresses of symbols and strings at the end of each function (DCD), the symbols/string offsets with respect to PC are now hardcoded in the instructions themselves, and need to be calculated.

An upcoming book on OS X/iOS internals discusses this in detail.

dyld_shared_cache

 * The system libraries are now stored in a big cache file
 * This address randomized at boot time, in many possible places, higher in the address space than the program
 * The functions retain a fixed offset to each other