Skip to content

Instantly share code, notes, and snippets.

Created August 21, 2020 11:41
  • Star 5 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
Star You must be signed in to star a gist
What would you like to do?
Prove that I had blackbird :)
There is a bug in SEPROM, at least up to A10 (the one I reversed), in the trustzone bounds checks.
The trustzone is setup by the main AP in an early boot stage and because of that SEPROM has to verify that it's setup correctly before continuing to boot SEPOS.
Otherwise the AP could write to SEPOS RAM and with that it might be able to get code execution on the SEP.
The verification is done by first checking if the trustzone values are locked and then if they are correct.
Those values are stored in hardware registers that both processors share.
The registers are 32 bit tho and because of that apple decided to shift the address down by 12 bits before putting it into the registers.
This means that if you want to lock down 0x1000000 to 0x2000000 you will actually write 0x1000 and 0x2000 to the registers.
On the other side SEPROM loads these values from the hardware registers again.
But instead of just comparing them against some constant it shifts up all of those values by 12 bits again before doing any check on them.
This is a major flaw because SEP is only 32 bit so shifting the value by 12 bits will move bit 20 and the upper ones out of the register.
So you can bypass the trustzone checks by setting for example bit 20 in the register and SEP won't complain.
This bug is called blackbird because the jet was build to fly so high nobody could see it :D
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment