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. bugs.chromium.org/p/project-zero…

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.

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

Here are slides and recordings from 36C3 and OBTS. 36C3 slides: bazad.github.io/presentations/… video: media.ccc.de/v/36c3-10806-k… OBTS slides: bazad.github.io/presentations/… day 2 stream: youtube.com/watch?v=ZDJsag… In the OBTS live demo I showed how I used KTRW to discover the oob_timestamp bug.

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.

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

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

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

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. googleprojectzero.blogspot.com/2020/07/one-by…

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: bazad.github.io/presentations/…

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.

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: security.apple.com/blog/towards-t…