littlelailo littlelailo

## blackbird.txt
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

## apollo.txt
This bug was also called moonshine in the beginning
Basically the following bug is present in all bootroms I have looked at:
1. When usb is started to get an image over dfu, dfu registers an interface to handle all the commands and allocates a buffer for input and output
2. if you send data to dfu the setup packet is handled by the main code which then calls out to the interface code
3. the interface code verifies that wLength is shorter than the input output buffer length and if that's the case it updates a pointer passed as an argument with a pointer to the input output buffer
4. it then returns wLength which is the length it wants to recieve into the buffer
5. the usb main code then updates a global var with the length and gets ready to recieve the data packages
6. if a data package is recieved it gets written to the input output buffer via the pointer which was passed as an argument and another global variable is used to keep track of how many bytes were recieved already
7. if all the data was recieved th
	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
	This bug was also called moonshine in the beginning
	Basically the following bug is present in all bootroms I have looked at:
	1. When usb is started to get an image over dfu, dfu registers an interface to handle all the commands and allocates a buffer for input and output
	2. if you send data to dfu the setup packet is handled by the main code which then calls out to the interface code
	3. the interface code verifies that wLength is shorter than the input output buffer length and if that's the case it updates a pointer passed as an argument with a pointer to the input output buffer
	4. it then returns wLength which is the length it wants to recieve into the buffer
	5. the usb main code then updates a global var with the length and gets ready to recieve the data packages
	6. if a data package is recieved it gets written to the input output buffer via the pointer which was passed as an argument and another global variable is used to keep track of how many bytes were recieved already
	7. if all the data was recieved th