Information Leaks & KASLR Bypass

Before reading/writing kernel memory, you need to know where the kernel is loaded. KASLR (Kernel Address Space Layout Randomization) randomizes the kernel base address each boot. An info leak = step 1.

KASLR on iOS

Kernel base address = fixed_base + random_slide
  fixed_base: 0xFFFFFE0007004000 (varies by device/iOS version)
  random_slide: random value, aligned to 2MB boundary
  → Actual base: 0xFFFFFE0007004000 + 0x000000XXXX000000

If you know the slide, you can compute the address of every kernel symbol:

symbol_runtime_addr = symbol_static_addr + slide

Leak Techniques

1. IOKit Property Leaks

Some IOKit drivers return kernel addresses in properties:

io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, ...);
CFTypeRef prop = IORegistryEntryCreateCFProperty(service, CFSTR("some-property"), ...);
// prop may contain a kernel pointer → leak!

2. Uninitialized Heap Data

1. Trigger allocation from a zone containing stale data
2. Read back data → may contain kernel pointers from a previous object
3. Calculate slide from the leaked pointer

3. Timing Side Channels

  • Measure access time for different kernel addresses
  • Mapped vs unmapped addresses have timing differences
  • Used to brute-force the KASLR slide

4. Via the Vulnerability Itself

Many vulnerabilities provide both an info leak + write primitive:

Heap overflow → overread adjacent object → leak pointer
                → overwrite adjacent object → write primitive

5. proc_info / sysctl Leaks

Historically, some syscalls leaked kernel addresses:

  • proc_info(PROC_PIDINFO, ...) once leaked kqueue kernel addresses
  • sysctl kern.* nodes once leaked kernel pointers

When KASLR Bypass Is Not Needed

  • checkm8/palera1n: Bootrom exploit runs before KASLR – fixed layout is known
  • Deterministic exploits: Some exploits do not need exact addresses
  • Relative exploits: Only relative offsets between objects are needed