Boot Order: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
m (Text replacement - "color:red" to "color:red!important")
 
(34 intermediate revisions by 13 users not shown)
Line 1: Line 1:
[[Category:Software]]
== Boot Sequence ==
== Boot Sequence ==
Power on : syscon boots from it's internal (non-encrypted / dual banked) ROM *1 *2
Power on: syscon boots from its internal (non-encrypted / dual banked) ROM *1 *2
  + syscon powers up various power subsystems
  + syscon powers up various power subsystems
  + syscon powers up cell and checks status
  + syscon powers up cell and checks status
  + syscon sends Cell configuration ring to Cell
  + syscon sends Cell configuration ring to Cell. It is either sent during or before bootldr. The config ring is checked within bootldr (ch67).
  + syscon pulls the reset of Cell high -> Cell INIT
  + syscon pulls the reset of Cell high -> Cell INIT (Partially).
Cell INIT: CELL boots from it's internal ROM *2
Cell INIT: CELL boots from its internal ROM *2
+ Initialises I/O
  + fetches encrypted bootldr off NAND  (at address 0x000000) /NOR flash (at address 0xFC0000) and boots in isolated SPU.
  + fetches encrypted bootldr off NAND  (at address 0x000000) /NOR flash (at address 0xFC0000)
Bootldr Running: (Which SPU?)
  + Initialises RAM
  + Initialises I/O (IOIF0/IOIF1)
+ loads bootldr into Isolated SPU (SPE0)
  + Initialises XDR (And verifies with memtest elf - On SPU 0 - It's hardcoded to load there).
  + Runtime Secure Boot decrypts and verifies bootldr and executes
  + bootldr decrypts lv0 which runs on PPU -> loaders INIT
  + bootldr decrypts lv0 which runs on PPU -> loaders INIT
  NEW consoles only: metadata lv0.2 (signed with nonrandomfail key) is used to check lv0 integrity
LV0 Running:
+ LV0 boots frequency to 3GHz and does more HW init
loaders INIT: lv0 loads metldr (SPE2)
loaders INIT: lv0 loads metldr (SPE2)
  + passes lv1ldr (which loads lv1) to metldr
  + passes lv1ldr (which loads lv1) to metldr
Line 21: Line 22:


*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
*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
*2) {{CEX}} (+DEX?) consoles go to standby with red light. {{SHOP}} consoles 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
*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.
about the disabled SPE: syscon reads it’s internal (non-encrypted) eeprom @ 0x48C30 which is value 0×06 on all {{CEX}} 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. Config ring is checked against the known one in bootldr. If you were to modify syscon and the config ring, it still wouldn't boot and would panic as the config ring does not match the expected one.


=== References ===
=== References ===
* [http://ip.com/patapp/US20090055637 Secure power-on reset engine]
* [http://ip.com/patapp/US20090055637 Secure power-on reset engine]
** [http://www.ps3devwiki.com/files/documents/US7895426.pdf US7895426.pdf]
** [https://patentimages.storage.googleapis.com/f1/41/35/ebbd57077c21f9/US7895426.pdf US7895426.pdf]
** [http://www.ps3devwiki.com/files/documents/US20090055637.pdf US20090055637.pdf]
** [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/US20090055637.pdf US20090055637.pdf]
* [http://www.ps3devwiki.com/files/documents/-%20Cell%20BE/CellBE_Handbook_v1.12_3Apr09_pub.pdf CellBE_Handbook_v1.12_3Apr09_pub.pdf]
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/-%20Cell%20BE/CellBE_Handbook_v1.12_3Apr09_pub.pdf CellBE_Handbook_v1.12_3Apr09_pub.pdf]
* [http://www.ps3devwiki.com/files/documents/-%20Cell%20BE/Cell_Broadband_Engine_processor_vault_security_architecture.pdf Cell_Broadband_Engine_processor_vault_security_architecture.pdf]
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/-%20Cell%20BE/Cell_Broadband_Engine_processor_vault_security_architecture.pdf Cell_Broadband_Engine_processor_vault_security_architecture.pdf]
* [http://www.multiupload.com/7STWIQ8PBF CellBEBootprocess.pdf (177.69 KB)]) //  
* [http://www.multiupload.com/7STWIQ8PBF CellBEBootprocess.pdf (177.69 KB)]) (Mirror: [http://git.gitbrew.org/openclit/documentation/CellBEBootprocess.pdf GitBrew]) //  
* [http://www.ps3devwiki.com/files/documents/-%20CELL%20SDK%20Documentation/lib/CBE_Secure_SDK_Guide_v3.0.pdf CBE_Secure_SDK_Guide_v3.0.pdf]
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/-%20CELL%20SDK%20Documentation/lib/CBE_Secure_SDK_Guide_v3.0.pdf CBE_Secure_SDK_Guide_v3.0.pdf]
* [http://www.ps3devwiki.com/files/documents/-%20Cell%20BE/CellBE_HIG_65nm_v1.01_8Jun2007.pdf CellBE_HIG_65nm_v1.01_8Jun2007.pdf)]
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/-%20Cell%20BE/CellBE_HIG_65nm_v1.01_8Jun2007.pdf CellBE_HIG_65nm_v1.01_8Jun2007.pdf)]
* [http://www.ps3devwiki.com/files/documents/-%20Cell%20BE/CellBE_HIG_90nm_v1.5_30Nov2007_pub.pdf CellBE_HIG_90nm_v1.5_30Nov2007_pub.pdf])
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/-%20Cell%20BE/CellBE_HIG_90nm_v1.5_30Nov2007_pub.pdf CellBE_HIG_90nm_v1.5_30Nov2007_pub.pdf])
* [http://www.ps3devwiki.com/files/documents/-%20Cell%20BE/BE_Hardwar_Init_Guide_v1.3_31March2006.pdf BE_Hardwar_Init_Guide_v1.3_31March2006.pdf]
* [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/BE_Hardwar_Init_Guide_v1.3_31March2006.pdf BE_Hardwar_Init_Guide_v1.3_31March2006.pdf]


== Chain of Trust ==
== Chain of Trust ==
Line 62: Line 63:
| SPE(0)
| SPE(0)
| Per Console Encrypted at factory
| Per Console Encrypted at factory
| No <span style="color:red;">*</span>
| No <span style="color:red!important;">*</span>
| No
| Setup Primairy Hardware + load lv0
| No
| No
| Setup Primary Hardware + load lv0
| Yes
|-
|-
| lv0 (Level 0)
| lv0 (Level 0)
Line 74: Line 75:
| No
| No
| Setup Hardware
| Setup Hardware
| No
| Yes
|-
|-
| metldr (asecure_loader)
| metldr (asecure_loader)
Line 80: Line 81:
| SPE(2)
| SPE(2)
| Per&nbsp;Console&nbsp;Encrypted at&nbsp;factory
| Per&nbsp;Console&nbsp;Encrypted at&nbsp;factory
| No <span style="color:red;">*</span>
| No <span style="color:red!important;">*</span>
| No
| No
| load loaders (Meta Loader)
| Load loaders (Meta Loader)
| Yes
| Yes
|-
|-
Line 91: Line 92:
| Yes
| Yes
| No
| No
| Decrypt lv1 (Hypervisor)
| Decrypt lv1 (Hypervisor) + Initialize ATA/ENCDEC
| Yes
| Yes
|-
|-
Line 130: Line 131:
| Yes
| Yes
|}
|}
<span style="color:red;">*</span> : ofcourse with new hardware revisions, it is updated in factory. See [[Flash#new_metldr.2]]
<span style="color:red!important;">*</span> : ofcourse with new hardware revisions, it is updated in factory. See [[Flash#new_metldr.2]]


== Chain of trust Diagram ==
== Chain of trust Diagram ==
Line 139: Line 140:


* http://www.ibm.com/developerworks/power/library/pa-cellsecurity/
* http://www.ibm.com/developerworks/power/library/pa-cellsecurity/
== Changes in firmware 3.56 ==
[[spkg_hdr.tar]] and [[ps3swu2.self]] in [[Playstation Update Package (PUP)]] root added


== Changes in firmware 3.60 ==
== Changes in firmware 3.60 ==
Lv0 has now been changed, LV0 now appears to encapsulate all of the [[Loaders]] (appldr, isoldr, lv1ldr, lv2ldr). Now in order to break the chain of trust we need to be able to decrypt/exploit LV0 (or bootldr which loads LV0).
Lv0 has now been changed, LV0 now appears to encapsulate all of the [[Loaders]] (appldr, isoldr, lv1ldr, lv2ldr). Now in order to break the chain of trust we need to be able to decrypt/exploit LV0 (or bootldr which loads LV0) and reverse the obfuscation in the loaders -> done! see http://www.psdevwiki.com/ps3/Keys#Key_Scrambling


=== Chain of trust Diagram 3.60++ ===
=== Chain of trust Diagram 3.60++ ===
<table width="100%" align="left"><tr><td align="left">[[File:Ps3-cryptochain-360.png|800px|thumb|left|LV0 with encapsulated loaders (appldr, isoldr, lv1ldr, lv2ldr).)]]</tr></tr></table><br />
<table width="100%" align="left"><tr><td align="left">[[File:Ps3-cryptochain-360.png|800px|thumb|left|LV0 with encapsulated loaders (appldr, isoldr, lv1ldr, lv2ldr).)]]</tr></table>
not in this diagram: the added .2 metadata<br />
 
== PPU Boot Order ==
 
lv0 -> lv1.self -> lv2_kernel.self -> sys_init_osd.self -> vsh.self
 
{{Reverse engineering}}<noinclude>[[Category:Main]]</noinclude>

Latest revision as of 03:44, 1 July 2023

Boot Sequence[edit | edit source]

Power on: syscon boots from its 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. It is either sent during or before bootldr. The config ring is checked within bootldr (ch67).
+ syscon pulls the reset of Cell high -> Cell INIT (Partially).

Cell INIT: CELL boots from its internal ROM *2

+ fetches encrypted bootldr off NAND  (at address 0x000000) /NOR flash (at address 0xFC0000) and boots in isolated SPU.

Bootldr Running: (Which SPU?)

+ Initialises I/O (IOIF0/IOIF1)
+ Initialises XDR (And verifies with memtest elf - On SPU 0 - It's hardcoded to load there).
+ bootldr decrypts lv0 which runs on PPU -> loaders INIT
  NEW consoles only: metadata lv0.2 (signed with nonrandomfail key) is used to check lv0 integrity

LV0 Running:

+ LV0 boots frequency to 3GHz and does more HW 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  (+DEX?) consoles go to standby with red light.  SHOP  consoles 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  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. Config ring is checked against the known one in bootldr. If you were to modify syscon and the config ring, it still wouldn't boot and would panic as the config ring does not match the expected one.

References[edit | edit source]

Chain of Trust[edit | edit source]

Name Location Processor Encryption Updateable Revokable Usage Exploited
Runtime Secure Boot Hardware based Cell Hardware Based no no Verification of images loaded into isolated SPE no
bootldr (Boot Loader) NAND (0x000000) / NOR (0xFC0000) SPE(0) Per Console Encrypted at factory No * No Setup Primary Hardware + load lv0 Yes
lv0 (Level 0) NAND/NOR (COREOS) PPU Static Encryption / Signed Yes No Setup Hardware Yes
metldr (asecure_loader) NAND (0x0040810) / NOR (0x000810) SPE(2) Per Console Encrypted at factory No * No Load loaders (Meta Loader) Yes
lv1ldr (Level 1 (Hypervisor) Loader) NAND/NOR (COREOS) SPE(2) Static Encryption / Signed Yes No Decrypt lv1 (Hypervisor) + Initialize ATA/ENCDEC 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) (Discarded after 0.8) NAND/NOR (COREOS) SPE(2) Static Encryption / Signed Yes No Decrypt revoke list Yes

* : ofcourse with new hardware revisions, it is updated in factory. See Flash#new_metldr.2

Chain of trust Diagram[edit | edit source]

Ps3-cryptochain.png

Runtime Secure[edit | edit source]

This runtime secure boot, in fact, is tightly coupled with an SPE entering isolation mode. An application must go through the hardware authentication step before it can execute on an isolated SPE. When isolation mode is requested, first, the previous thread is stopped and cancelled. Then, the hardware will automatically start fetching the application into the LS, and the hardware will verify the integrity of the application. If the integrity check fails, the application will not be executed. The check can fail for one of two reasons. The application might have been modified within memory or storage. Then, the assumption is that the functionality might have changed and it cannot be trusted anymore. Or, the writer of the application does not know the cryptographic secret that is needed for a successful authentication. Otherwise, if the authentication check is successful, the hardware will automatically kick-start the application's execution in isolation mode. Because the hardware controls all of these steps, the verification of the application's integrity cannot be skipped or manipulated and will happen consistently and correctly.

Changes in firmware 3.56[edit | edit source]

spkg_hdr.tar and ps3swu2.self in Playstation Update Package (PUP) root added

Changes in firmware 3.60[edit | edit source]

Lv0 has now been changed, LV0 now appears to encapsulate all of the Loaders (appldr, isoldr, lv1ldr, lv2ldr). Now in order to break the chain of trust we need to be able to decrypt/exploit LV0 (or bootldr which loads LV0) and reverse the obfuscation in the loaders -> done! see http://www.psdevwiki.com/ps3/Keys#Key_Scrambling

Chain of trust Diagram 3.60++[edit | edit source]

LV0 with encapsulated loaders (appldr, isoldr, lv1ldr, lv2ldr).)

not in this diagram: the added .2 metadata

PPU Boot Order[edit | edit source]

lv0 -> lv1.self -> lv2_kernel.self -> sys_init_osd.self -> vsh.self