Editing Boot Order

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
== Boot Sequence ==
This is my current understanding of the boot order:
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
bootldr (Per-Console encrypted on flash, cannot be updated, has not yet been dumped)
*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 ===
lv0 (Not per console encrypted, but we do not have the public or private encryption keys currently)
* [http://ip.com/patapp/US20090055637 Secure power-on reset engine]
** [https://patentimages.storage.googleapis.com/f1/41/35/ebbd57077c21f9/US7895426.pdf US7895426.pdf]
** [https://web.archive.org/web/*/http://ps3devwiki.com/files/documents/US20090055637.pdf US20090055637.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]
* [[:File: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)]) (Mirror: [http://git.gitbrew.org/openclit/documentation/CellBEBootprocess.pdf GitBrew]) //
* [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]
* [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)]
* [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])
* [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 ==
metldr (Per-Console encrypted on flash, cannot be updated, has been dumped)
{| class="wikitable"
|-
! 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)
| [[Flash|NAND (0x000000) / NOR (0xFC0000)]]
| SPE(0)
| Per Console Encrypted at factory
| No <span style="color:red!important;">*</span>
| No
| Setup Primary Hardware + load lv0
| Yes
|-
| lv0 (Level 0)
| [[Flash|NAND/NOR (COREOS)]]
| PPU
| Static&nbsp;Encryption / Signed
| Yes
| No
| Setup Hardware
| Yes
|-
| metldr (asecure_loader)
| [[Flash|NAND&nbsp;(0x0040810) / NOR&nbsp;(0x000810)]]
| SPE(2)
| Per&nbsp;Console&nbsp;Encrypted at&nbsp;factory
| No <span style="color:red!important;">*</span>
| No
| Load loaders (Meta Loader)
| Yes
|-
| lv1ldr (Level 1 (Hypervisor) Loader)
| [[Flash|NAND/NOR (COREOS)]]
| SPE(2)
| Static&nbsp;Encryption / Signed
| Yes
| No
| Decrypt lv1 (Hypervisor) + Initialize ATA/ENCDEC
| Yes
|-
| lv2ldr (Level 2 (GameOS) Loader)
| [[Flash|NAND/NOR (COREOS)]]
| SPE(2)
| Static&nbsp;Encryption / Signed
| Yes
| No
| Decrypt lv2 (GameOS)
| Yes
|-
| appldr (Application Loader)
| [[Flash|NAND/NOR (COREOS)]]
| SPE(2)
| Static&nbsp;Encryption / Signed
| Yes
| Yes
| Decrypt games
| Yes
|-
| isoldr (Isolation Loader)
| [[Flash|NAND/NOR (COREOS)]]
| SPE(2)
| Static&nbsp;Encryption / Signed
| Yes
| No
| Decrypt modules
| Yes
|-
| rvkldr (Revokation Loader) (Discarded after 0.8)
| [[Flash|NAND/NOR (COREOS)]]
| SPE(2)
| Static&nbsp;Encryption / Signed
| Yes
| No
| Decrypt revoke list
| Yes
|}
<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 ==
loaders (lv1ldr, isoldr are passed from lv0 into metldr).
[[File:Ps3-cryptochain.png]]


== Runtime Secure ==
From here the rest of the chain is loaded.
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.


* http://www.ibm.com/developerworks/power/library/pa-cellsecurity/


== Changes in firmware 3.56 ==
These are the points I understand about breaking the chain:
[[spkg_hdr.tar]] and [[ps3swu2.self]] in [[Playstation Update Package (PUP)]] root added


== Changes in firmware 3.60 ==
1) bootldr and metldr are stored in the asecure_loader region of the flash, is encrypted per console
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++ ===
2) bootldr and metldr, as far as we are aware, cannot be updated and never have been
<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 ==
3) 3.60 has changed lv0, since we cannot dump bootldr and get the private keys, we cannot decrypt the new lv0


lv0 -> lv1.self -> lv2_kernel.self -> sys_init_osd.self -> vsh.self
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


{{Reverse engineering}}<noinclude>[[Category:Main]]</noinclude>
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.
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps3/Boot_Order"