Boot Order
Boot Sequence
Power on : syscon boots from it's internal (non-encrypted / dual banked) ROM *1 *2
+ syscon powers up various power subsystems + syscon powers up cell and checks status + syscon sends Cell configuration ring to Cell + syscon pulls the reset of Cell high -> Cell INIT
Cell INIT: CELL boots from it's internal ROM *2
+ Initialises RAM & I/O + fetches encrypted bootldr off NAND/NOR flash (at address 0xF00000) + loads bootldr into Isolated SPU (SPE0) + Isolated SPU decrypts bootldr + bootldr decrypts lv0 which runs on PPU -> loaders INIT
loaders INIT: lv0 loads metldr (SPE2)
+ passes lv1ldr (which loads lv1) to metldr + passes lv2ldr (which loads lv2) to metldr + passes appldr (which loads vsh) to metldr + passes isoldr (which loads *.iso_spu_module) to metldr + passes rvkldr (which loads rvkprg / rvklist) to metldr
- 1) Read/Writeable with undocumented / should also be read/writeable through serial port and possible to switch it to the backup bank1 with backup_mode pulled high
- 2) CEX/Retail consoles go to standby with red light. SEX/SHOP/SECH will not standby, but instead boot through without waiting for powerbutton. Also check is done on all models if update is flagged to set it into firmware updating procedure
- 3) Partialy Read/Writeable
about the disabled SPE: syscon reads it’s internal (non-encrypted) eeprom @ 0x48C30 which is value 0×06 on all CEX/Retail consoles and will set the cell config ring accordingly for 7 SPE’s. SPE0 and SPE2 are reserved for bootldr and metldr for isolation respectively. Setting the value to a nonworking state (e.g. 0×00, 0xFF, enabling a defective SPE or disabling a needed SPE for proper boot) might brick the console, locking you out from restoring the correct value to the syscon eeprom.
Chain of Trust
| Name | Location | Processor | Encryption | Updateable | Revokable | Usage | Exploited |
|---|---|---|---|---|---|---|---|
| Cell ROM | Cell ROM | PPU | None | No | No | Initialise SPR, SPI, Isolation | No |
| bootldr (Boot Loader) | NAND/NOR (asecure_loader) | SPE(0) | Per Console Encrypted at factory | No | No | Boot lv0 | No |
| lv0 (Level 0) | NAND/NOR (COREOS) | PPU | Static Encryption / Signed | Yes | No | Setup Hardware | No |
| metldr (Meta Loader) | NAND/NOR (asecure_loader) | SPE(2) | Per Console Encrypted at factory | No | No | Run loaders | Yes |
| lv1ldr (Level 1 (Hypervisor) Loader) | NAND/NOR (COREOS) | SPE(2) | Static Encryption / Signed | Yes | No | Decrypt lv1 (Hypervisor) | Yes |
| lv2ldr (Level 2 (GameOS) Loader) | NAND/NOR (COREOS) | SPE(2) | Static Encryption / Signed | Yes | No | Decrypt lv2 (GameOS) | Yes |
| appldr (Application Loader) | NAND/NOR (COREOS) | SPE(2) | Static Encryption / Signed | Yes | Yes | Decrypt games | Yes |
| isoldr (Isolation Loader) | NAND/NOR (COREOS) | SPE(2) | Static Encryption / Signed | Yes | No | Decrypt modules | Yes |
| rvkldr (Revokation Loader) | NAND/NOR (COREOS) | SPE(2) | Static Encryption / Signed | Yes | No | decrypt revoke list | Yes |
Chain of trust Diagram
Changes in firmware 3.60
Lv0 has now been changed, LV0 now appears to encapsulate all of the loaders (lv1ldr, lv2ldr, appldr, isoldr, rvkldr). Now in order to break the chain of trust we need to be able to decrypt/exploit LV0 which at this time has not been done.