Why is GID-based AES inaccessible post-iBoot?

Questions and Answers about all things *OS (macOS, iOS, tvOS, watchOS)

Why is GID-based AES inaccessible post-iBoot?

Postby Siguza » Thu Jul 21, 2016 10:48 pm

Hi J

From your comments on taking apart OTAs and the general unavailability of firmware keys for newer devices, it becomes clear that AES operations involving the GID cannot be done once iOS has fully booted (on a non-compromised boot chain).
But why is that, exactly?

Here's what I've gathered from the iPhone wiki and from the iOS Security Guide:

  • 32-bit devices have an AES coprocessor that handles GID-based operations. On 64-bit devices, that duty is taken on by the secure enclave.
  • The AES engine is available to everything that loads before and including iBoot, and unavailable to everything that loads after it.
  • The boot chain runs in EL3, the kernel in EL1 and userland in EL0.
Is that all correct?
If so, there are two ways I could think of to block access to the AES engine:

  • Either it is only accessible in EL3
  • Or it is sent some kind of shutdown signal during the boot sequence after the kernel has been decrypted, either by iBoot or the kernel.
Now another page on the iPhone wiki mentions XPwn's crypto bundle as a means of making the engine available to userland, noting that it requires a kernel patch (ofc requiring a bootchain exploit).
This would suggest the shutdown signal method, and that the code for that resides in the kernel.
Or at least, that's how it was 8 years ago.
Is that still how it is today or have things changed? Or is there more to it?
I'd appreciate if you could shed some light on this. :)

Thanks
- Siguza
User avatar
Siguza
Unicorn
 
Posts: 159
Joined: Thu Jan 28, 2016 10:38 am

Re: Why is GID-based AES inaccessible post-iBoot?

Postby morpheus » Fri Jul 22, 2016 1:34 am

Short answer: iBoot explicitly disables it before booting any other IMG3/IMG4 (e.g. Diags, or the kernel). You can see that because trying to invoke the AES routines from a pwned iBoot (using winocm's kexec, with Odysseus) fails miserably. You have to reboot the device for AES to be reactivated. Xerub, sn0w and others have access to an iBoot-level exploit, which is why they get code exec prior to that shutdown, and can use it to get decrypted firmware keys.

For 64-bit, indeed EL3 is used for iLLB/iBoot, but from what I understand (caveat: speculating, haven't been privy to an iBoot 10 64 dump!) it's the same sequence.

Long answer: I had the instruction pointed in older iBoot dumps. Now that we have iBoot 32xx for iOS10 in the clear, I intend to include that in the upcoming Vol III (Which discusses the boot sequence).
morpheus
Site Admin
 
Posts: 532
Joined: Thu Apr 11, 2013 6:24 pm

Re: Why is GID-based AES inaccessible post-iBoot?

Postby Siguza » Fri Jul 22, 2016 1:57 am

Oh wait, the boot sequence is part of vol III? I somehow thought that would be in vol II...
But that's awesome. Looking forward to vol III even more now.

And thanks for explaining that. :)
User avatar
Siguza
Unicorn
 
Posts: 159
Joined: Thu Jan 28, 2016 10:38 am

Re: Why is GID-based AES inaccessible post-iBoot?

Postby morpheus » Fri Jul 22, 2016 2:06 am

I thought so too. Till AAPL gave me KPP (for iOS 9) and iBoot on a silver platter. And since iOS security hinges on it, it made sense to include :-)

A lot of stuff never before documented. It'll be worth the wait. Promise.

J
morpheus
Site Admin
 
Posts: 532
Joined: Thu Apr 11, 2013 6:24 pm


Return to Questions and Answers

Who is online

Users browsing this forum: No registered users and 1 guest