Brandon Azad

I’m really excited for us to shed light on some really cool work we’ve been doing to harden the XNU allocator! This has been a huge effort by so many people, and I’m very proud of the direction:

It's with both bittersweet sadness and excitement that I say goodbye to Project Zero, as I'll be joining Apple next week to continue my work improving Apple device security. My time at Project Zero has been amazing, and it's been an honor to share in this wonderful mission.

My teammates at Project Zero have been among the kindest and smartest people I've met, and I've learned so much from them. I'll really miss working alongside everyone on the team. Thank you all for these wonderful experiences, and keep on hacking!

From A13 SecureROM. This isn't a security issue, since this particular bzero is only used to initialize the boot trampoline in SRAM. Even so, Apple appears to have addressed this in iBoot, hence the credit in the iOS 14 release notes. Always worth checking hand-rolled assembly.

Here are the slides from my BlackHat talk "iOS Kernel PAC, One Year Later", in which I consider how kernel PAC CFI has changed since its introduction in iOS 12 and examine 5 ways to bypass it in iOS 13:

The core of Apple is PPL: Attacking the XNU kernel's kernel. How to use an out-of-bounds read in PPL (Apple's kernel-within-the-kernel) to get a stale TLB entry for a page, allowing you to bypass PPL and map arbitrary physical addresses accessible at EL0.

You can find the full PPL bypass at

One Byte to Rule Them All: An iOS 13 exploit technique that turns a one-byte kernel heap overflow into an arbitrary physical address mapping primitive, all while avoiding the kernel task port and sidestepping mitigations like PAC, KASLR, and zone_require.

I'm excited to be sharing my latest research on iOS kernel Pointer Authentication at Black Hat USA 2020! One year ago, I published 5 ways to bypass iOS 12 kernel PAC. This year, we'll take a look at what's changed in iOS 13, once again concluding with 5 new ways to bypass PAC.

iOS Kernel Pac, One Year Later

Looks like iOS Pointer Authentication is getting per-process A keys.

New blog post on how I was able to find the 0-day used in unc0ver just 4 hours after it was released: Key takeaways: 1. Obfuscating an exploit doesn't hide the bugs. 2. Like SockPuppet, this bug could have been identified with simple regression tests.

I've compiled a summary of every original public iOS kernel exploit from app context since iOS 10, describing the high-level exploit flow to get stable kernel read/write. The trends of how these exploits have evolved over time are quite interesting:

Thanks to everyone for suggesting exploits missed in my initial survey! I updated the blog post to add an exploit for iOS 12.4.1, swap an exploit for iOS 12.1.2, and clarify the wording of some of the mitigations. Please do reach out with any more suggestions!

KTRW now has proper support for kernel debugging iOS 13. It uses checkra1n to insert an XNU kernel extension into the kernelcache before boot.

IDA 7.5 improves support for iPhone kernel debugging using KTRW! Breakpoints now work very nicely out of the box. Also, KTRW's iOS 13 support is in the works.

Here are slides and recordings from 36C3 and OBTS. 36C3 slides: video: OBTS slides: day 2 stream: In the OBTS live demo I showed how I used KTRW to discover the oob_timestamp bug.

Unfortunately due to a recent injury I won’t be able to attend @nullcon. I’m hoping to still make it to #OBTS.

I'm excited to be presenting at both @nullcon and #OBTS this March. Come learn how I built KTRW, an iOS kernel debugger for production A11 iPhones, and how I used it to expose attack surface that led to the discovery of the oob_timestamp vulnerability.

For those interested in low-level analysis of Apple's A13 and associated kernel mitigations, here's a version of oob_timestamp with a PAC bypass for iOS 13.3.