Boot Order: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
(Created page with "This is my current understanding of the boot order: bootldr (Per-Console encrypted on flash, cannot be updated, has not yet been dumped) lv0 (Not per console encrypted, but we ...")
 
No edit summary
Line 1: Line 1:
This is my current understanding of the boot order:
== Boot Sequence ==
Power on : syscon boots from it's internal (non-encrypted / dual banked) ROM *1 *2
    + syscon powers up and configures Cell
    + syscon pulls the reset of Cell high -> Cell INIT
Cell INIT: CELL boots from it's internal ROM *2
    + Initialises RAM
    + fetches bootldr off NAND/NOR flash
    + loads bootldr into Isolated SPU (SPE0)
    + 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


bootldr (Per-Console encrypted on flash, cannot be updated, has not yet been dumped)
*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.


lv0 (Not per console encrypted, but we do not have the public or private encryption keys currently)
== Chain of Trust ==
{| class="wikitable"
|-
! Name
! Location
! Processor
! Encryption
! Updateable
! Revokable
! Usage
! Exploited
|-
| 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
|}


metldr (Per-Console encrypted on flash, cannot be updated, has been dumped)
== Changes in firmware 3.60 ==


loaders (lv1ldr, isoldr are passed from lv0 into metldr).
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.
 
From here the rest of the chain is loaded.
 
 
These are the points I understand about breaking the chain:
 
1) bootldr and metldr are stored in the asecure_loader region of the flash, is encrypted per console
 
2) bootldr and metldr, as far as we are aware, cannot be updated and never have been
 
3) 3.60 has changed lv0, since we cannot dump bootldr and get the private keys, we cannot decrypt the new lv0
 
4) now that all the loaders are packed within lv0, we cannot get the private keys to decrypt the rest of the firmware unless we dump lv0
 
5) Mathieulh has published a exploit for dual_nor and cell_reset that could possibly dump a large portion of the decrypted loaders
 
6) bootldr is run in a spu under isolation mode, aparently we are not able to run this more than once, this makes exploiting the bootldr process very difficult
 
 
Basically, to fully break the chain of trust, we need to exploit the bootldr process and dump it to get the public key for lv0. If we have the public key we could fully decrypt the firmware. If we are lucky, Sony will have used the sign fail on lv0, allowing us to also sign our own modified lv0, since bootldr is considered un-updateable, we would have completely broken current hardware.

Revision as of 02:27, 8 April 2011

Boot Sequence

Power on : syscon boots from it's internal (non-encrypted / dual banked) ROM *1 *2 

    + syscon powers up and configures Cell
    + syscon pulls the reset of Cell high -> Cell INIT

Cell INIT: CELL boots from it's internal ROM *2 

    + Initialises RAM
    + fetches bootldr off NAND/NOR flash
    + loads bootldr into Isolated SPU (SPE0)
    + 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
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

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.

Retrieved from "http://www.psdevwiki.com/ps3/index.php?title=Boot_Order&oldid=1251"