Editing Talk:Boot Order

=== IBM /Sony docs ===
Cell Broadband Engine™ CMOS SOI 65 nm Hardware Initialization Guide
* http://dl.dropbox.com/u/9694818/Bildschirmfoto%202011-06-01%20um%2000.13.58.png
* https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/BD3F1F4C3DB32C7487257142006131BC/$file/CellBE_HIG_90nm_v1.5_30Nov2007_pub.pdf
* https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/AF7832F379790768872572D10047E52B/$file/CellBE_HIG_65nm_v1.01_8Jun2007.pdf
* http://cell.scei.co.jp/e_download.html

===SPI traces/testpoints===
Does anybody have a picture of the SPI trace locations or even testpoints for them?

===PS3 Bootsequence:===

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.

==asecure loader==
How do isolated loaders work? Asecure_loaders in specific (metldr)? Well, metldr is a raw binary, not an ELF, and here are the segments of it I have figured out at least:

<pre>
 Name                   Start    End
 .local_storage_cleanup 00000400 00000860
 .text                  00000860 0000CB70
 .rodata                0000CB70 0000FCD0
 .data                  0000FCD0 0003E400
 .ram                   0003E400 00040000
</pre>

The entrypoint of metldr is at 0×400, and in essence it just does the following:
<pre>
    ULONG *pStart = (ULONG*)&start;
    (pStart)();
</pre>

The start routine prepares the DMA buffer, and essentially is crt0.c, branches to main, then exits. The main routine prepares the global isolated loader constructor (yes, this is C++ code), then branches to loader_start, which sets up the mailbox for recieving mail, and then loads the actual isolated module, after this, it sends back the mail twice, once normally, second with an interrupt. The actual loader decryption subroutine (load_isolated_loader) sets the prepares the SELF for decryption, verifies the header, then gets the program information headers, then verifies each segment. The code for verifying the header essentially sets up a buffer and then calls verify_header. Then metldr loads its AES decryption key, IV, ECDSA public key and curve type then calls verify_header again. Verify_header sets up the buffer manager, and eventually calls verify_signature after running aes_ctr and aes_decrypt. Verify_signature loads the digest, and performs the SHA1 hash checks. Then we verify the signature by using ECDSA signature algorithms. Verify_self_segment loads the elf segment after several buffers are initialized, then the necessary program structures needed for loader initialization are created then control is passed to the cleanup subroutine. This routine essentially zeroes out every register except $r3 (yes, $SP, $LR, $r0-r2, $r4-r127), and branches to the address in $r3. Ta-da! We have successfully decrypted a binary.

Source: http://rmscrypt.wordpress.com/2011/05/08/long-hiatus/

== What type of encryption? ==

The Boot Order table lists whether the various loaders and levels are encrypted, but doesn't say what type of encryption. Is this generally AES256?
-- 69.55.232.38 

^try reading the alinea just above^ where you posted this question ;) and ofcourse the [[SELF File Format and Decryption]] page is a good reference. :) [[User:Euss|Euss]]

== LV0 ==
* 0.84 ebootbin : Boot Loader SE Version 0.8.4 (Build ID: 822,8517, Build Data: 2006-05-16_17:50:21)
* 3.66 DEX : Boot Loader SE Version 3.6.6 (Build ID: 4534,47762, Build Date: 2011-06-16_13:24:46)
* 3.73 DEX : Boot Loader SE Version 3.7.3 (Build ID: 4611,48369, Build Date: 2011-10-12_12:31:19)
<!--// "Boot Loader SE Version  (Build ID: security$,system$ Build Date: tardate$)" //-->
<small>(You can get these strings via tty on a [[SKU_Models#Reference_Tool_.28Tool.2FDECR.29|DECR]], so its not a proof of decryption :P)</small>

== old and new metldr handle CoreOS/flash the same ==

=== 4.0 PUP and 4.0 Flash comparison (all metldr) ===
{| class="wikitable sortable"
|-
! PUP file !! PUP SHA1 !! Flash SHA1 !! Flash region !! Notes
|-
| aim_spu_module.self || 2d58907eb6e49b6504154254d5b2d29aea533fa2 || 2d58907eb6e49b6504154254d5b2d29aea533fa2 || 0x083FFFC ||
|-
| creserved_0 || 1e4903cd5f594c13dad2fd74666ba35c62550044 || 1e4903cd5f594c13dad2fd74666ba35c62550044 || 0x07C04D0 ||
|-
| default.spp || 657b3bf16cf47e57560e1a7ef320c6c028685a0f || 657b3bf16cf47e57560e1a7ef320c6c028685a0f || 0x0888BA0 ||
|-
| emer_init.self || cc81212fdf17f6aaa41b784a878f5edc09d16955 || cc81212fdf17f6aaa41b784a878f5edc09d16955 || 0x0C9347C ||
|-
| eurus_fw.bin || f7b44127177a9d877bc477895ab25008262c17d6 || f7b44127177a9d877bc477895ab25008262c17d6 || 0x0C224E8 ||
|-
| hdd_copy.self || 7a6ee4186e40ced25ed24cf95499b27de0fb6c20 || 7a6ee4186e40ced25ed24cf95499b27de0fb6c20 || 0x0D10A4C ||
|-
| lv0 || 4e2122393939096e4dacd5fe302d276ff1b58ab0 || 4e2122393939096e4dacd5fe302d276ff1b58ab0 || 0x09BEB90 ||
|-
| lv0.2 || 21ff7f626fae073184084192dc93bb18b7eceaa8 || 21ff7f626fae073184084192dc93bb18b7eceaa8 || 0x0AA6710 ||
|-
| lv1.self || 16397b22cbcd51367e4ad78db95cae8215a08822 || 16397b22cbcd51367e4ad78db95cae8215a08822 || 0x088B310 ||
|-
| lv2_kernel.self || 3c64895ee9cb27fc81429704791280851fc67e03 || 3c64895ee9cb27fc81429704791280851fc67e03 || 0x0AA6C10 ||
|-
| manu_info_spu_module.self || 92eae56efdf632e2d331129a90126b0464b73e93 || 92eae56efdf632e2d331129a90126b0464b73e93 || 0x0D71DA4 ||
|-
| mc_iso_spu_module.self || 9879237f711428dab952f3e342543a75f1352624 || 9879237f711428dab952f3e342543a75f1352624 || 0x0851A84 ||
|-
| me_iso_for_ps2emu.self || f6374166d356fc6a9370b76b43678e9bc526a719 || f6374166d356fc6a9370b76b43678e9bc526a719 || 0x0874320 ||
|-
| me_iso_spu_module.self || a22a53ba40ea55667db3cf7e57690139346780d9 || a22a53ba40ea55667db3cf7e57690139346780d9 || 0x0859B10 ||
|-
| pkg.srvk || 5a35c13191ca51c47140f8128884be9629e4a09c || 5a35c13191ca51c47140f8128884be9629e4a09c || 0x0D7332C ||
|-
| prog.srvk || 1166b9cb203d7bb5bdea61bd1fca15fea0aff9ab || 1166b9cb203d7bb5bdea61bd1fca15fea0aff9ab || 0x0D7304C ||
|-
| sb_iso_spu_module.self || e5d5b2b9d59303892a633e5fdfbdd7d36fe654a6 || e5d5b2b9d59303892a633e5fdfbdd7d36fe654a6 || 0x086E3A0 ||
|-
| sc_iso.self || 2cabe7da48f7aa8289eb7922ca7c672885dff848 || 2cabe7da48f7aa8289eb7922ca7c672885dff848 || 0x0822D24 ||
|-
| sdk_version || 3adfabf1760cd5234166c1e41f24a82a6516d18c || 3adfabf1760cd5234166c1e41f24a82a6516d18c || 0x08004D0 ||
|-
| spp_verifier.self || ff902bca2f76067eb9203802a8189d075b47d9dd || ff902bca2f76067eb9203802a8189d075b47d9dd || 0x08444B4 ||
|-
| spu_pkg_rvk_verifier.self || 0d56f1f1ba3464fe3a45024cd7006a3151984869 || 0d56f1f1ba3464fe3a45024cd7006a3151984869 || 0x08004D8 ||
|-
| spu_token_processor.self || e82c8a1ecebd4342089bceacef47d48779d95881 || e82c8a1ecebd4342089bceacef47d48779d95881 || 0x0810024 ||
|-
| spu_utoken_processor.self || 4e9093314a85fd0c3ce9df940f0084b640282502 || 4e9093314a85fd0c3ce9df940f0084b640282502 || 0x081C954 ||
|-
| sv_iso_for_ps2emu.self || cd7d2aeb07b21ad72966cc30b31f9bc69d6158eb || cd7d2aeb07b21ad72966cc30b31f9bc69d6158eb || 0x087CBB0 ||
|-
| sv_iso_spu_module.self || 02dcd8c8f941b172f4164305c73d890612f14386 || 02dcd8c8f941b172f4164305c73d890612f14386 || 0x08623A0 || 
|-
| colspan="5" | 
|-
|-
| RL_FOR_PACKAGE.img || 912ba545f5950f7db5ca2df463867f3b9892f101 || - || - ||
|-
| RL_FOR_PROGRAM.img || 521704c06a55114ffa2de539cde12d6cec0c8b12 || - || - ||
|-
| - || - || 301006d38f7a8ece75fa1644b3ad02b17f10f035 || 0x0080000 || trvk_pkg0
|-
| - || - || 301006d38f7a8ece75fa1644b3ad02b17f10f035 || 0x00A0000 || trvk_pkg1
|-
| - || - || 5e6a48aa58e70f92ba1152d6e1a7dd8343bb6b72 || 0x0040000 || trvk_prg0
|-
| - || - || 5e6a48aa58e70f92ba1152d6e1a7dd8343bb6b72 || 0x0060000 || trvk_prg1
|-
|}

=== 3.60 PUP and 3.60 Flash comparison (sanity crosscheck 'metldr.2') ===
{| class="wikitable sortable"
|-
! PUP file !! PUP SHA1 !! Flash SHA1 !! Flash region !! Notes
|-
| aim_spu_module.self || 9283d37bd2fdd5fda03fc14e725e717904840633 || 9283d37bd2fdd5fda03fc14e725e717904840633 || 0x083FF9C || 
|-
| creserved_0 || 1e4903cd5f594c13dad2fd74666ba35c62550044 || 1e4903cd5f594c13dad2fd74666ba35c62550044 || 0x07C0470 || 
|-
| default.spp || 6610b4c76d069919d54818fe959e722a764c7ed2 || 6610b4c76d069919d54818fe959e722a764c7ed2 || 0x0874190 || 
|-
| emer_init.self || fcc019cc046ba8e3e6b64c86c3d72b75d8ddbe39 || fcc019cc046ba8e3e6b64c86c3d72b75d8ddbe39 || 0x0C3B67C || 
|-
| eurus_fw.bin || f7b44127177a9d877bc477895ab25008262c17d6 || f7b44127177a9d877bc477895ab25008262c17d6 || 0x0BCA6E8 || 
|-
| hdd_copy.self || b2b787e93a44ae66350e00ad416d317c30a36cf4 || b2b787e93a44ae66350e00ad416d317c30a36cf4 || 0x0CB98E4 || 
|-
| lv0 || 4d916dd40f594515a080fb1a5e9217b720d0adff || 4d916dd40f594515a080fb1a5e9217b720d0adff || 0x099C390 || 
|-
| lv0.2 || f0350d02bb9df3322e4a8f7e3a0527f379807891 || f0350d02bb9df3322e4a8f7e3a0527f379807891 || 0x0A51890 || 
|-
| lv1.self || 3fe00a9a76a7af93854537e48bd96dc6fe49e9cd || 3fe00a9a76a7af93854537e48bd96dc6fe49e9cd || 0x0876490 || 
|-
| lv2_kernel.self || 26791e398a6d73092f2e92692b2572b122751844 || 26791e398a6d73092f2e92692b2572b122751844 || 0x0A51D90 || 
|-
| manu_info_spu_module.self || 30d85dd537609ea6d407ce0d4a70a644d8321b68 || 30d85dd537609ea6d407ce0d4a70a644d8321b68 || 0x0D1B0FC || 
|-
| mc_iso_spu_module.self || 1802405dc3c05b45cb9324a25942487757066ef6 || 1802405dc3c05b45cb9324a25942487757066ef6 || 0x0851A24 || 
|-
| me_iso_spu_module.self || 2d30fe7f78fd667d82faae775fed0fd6ee807de4 || 2d30fe7f78fd667d82faae775fed0fd6ee807de4 || 0x0859AB0 || 
|-
| pkg.srvk || bc90ec2cca61363916581429588d762acc91b5d3 || bc90ec2cca61363916581429588d762acc91b5d3 || 0x0D1C3A4 || 
|-
| prog.srvk || 4939c2c67a4c042892f3d41d053c5df0300b6fe1 || 4939c2c67a4c042892f3d41d053c5df0300b6fe1 || 0x0D1C684 || 
|-
| sb_iso_spu_module.self || ebc24d11e949a89f133faf5af8b65ab0bdd48a5b || ebc24d11e949a89f133faf5af8b65ab0bdd48a5b || 0x086E3E0 || 
|-
| sc_iso.self || f88da181630e9b18906a2422eef84d9031389a0d || f88da181630e9b18906a2422eef84d9031389a0d || 0x0822CC4 || 
|-
| sdk_version || b3811e02d05e465b40fb97c90bdf6555f57c2bc1 || b3811e02d05e465b40fb97c90bdf6555f57c2bc1 || 0x0800470 || 
|-
| spp_verifier.self || c229c969c86aaaf6fcb8a6c934efc4c89cade331 || c229c969c86aaaf6fcb8a6c934efc4c89cade331 || 0x0844234 || 
|-
| spu_pkg_rvk_verifier.self || a65bc5d877975c8d6b9f32871cd0f72623437179 || a65bc5d877975c8d6b9f32871cd0f72623437179 || 0x0800478 || 
|-
| spu_token_processor.self || 24ca3d547c96a273e0ca6e7a04950da479c37240 || 24ca3d547c96a273e0ca6e7a04950da479c37240 || 0x080FFC4 || 
|-
| spu_utoken_processor.self || 2fb6594a089fd2a979ee135aaf563813eb9af3e2 || 2fb6594a089fd2a979ee135aaf563813eb9af3e2 || 0x081C8F4 || 
|-
| sv_iso_spu_module.self || bd95da672a720e2db8129949834c8b37b116f4f5 || bd95da672a720e2db8129949834c8b37b116f4f5 || 0x0862368 || 
|-
| colspan="5" | 
|-
|-
| RL_FOR_PACKAGE.img || a1859315621737a6a231d2b5939acf25a8bd6498 || - || - || 
|-
| RL_FOR_PROGRAM.img || b747d015488762163ae60bce82541cd36351151c || - || - || 
|-
| - || - || 1b65641edaa9c53cb33d1d7cb4c15e5417917a33 || 0x0080000 || trvk_pkg0
|-
| - || - || 1b65641edaa9c53cb33d1d7cb4c15e5417917a33 || 0x00A0000 || trvk_pkg1
|-
| - || - || da1721aa1a8e0626ab916299562fb0f517c7da52 || 0x0040000 || trvk_prg0
|-
| - || - || da1721aa1a8e0626ab916299562fb0f517c7da52 || 0x0060000 || trvk_prg1
|-
|}
== CoreOS Contents Per Firmware ==

Note: the different MD5 obtained from the /same/ versions, suggest something is wrong...

http://pastebin.com/1BuQbPVE  (moved to pastebin to reduce page size and above dubiousness)
 
 

== CEB Units ==

* On CEB units the Boot order is different: 
- There is no metldr, all loaders are Secure Isolated Loader (Not Secure Loader Applications) and load as metldr would, they are 00 paired and as such can be updated/overwritten
* 1. lv0ldr (the file is actually called this way on NOR) starts, if DIP SW is set to normal position it starts lv0 from lv0_bank0; if lv0_bank0 is missing, corrupt or blank, it starts from lv0_bank1 if none are present, it fails
 If DIP SW is set to update mode, then it starts "updater" instead of lv0_bank0.
* 2. updater is a slightly modified lv0, it will load isoldr and use it to decrypt ebootroms (old ebootroms are encrypted with AES128CTR), old Ebootroms only contained a NOR image.
* 3. If DIP SW is set to normal, lv0_bank0 is loaded and will start rvkldr which will verify revocation using RL_FOR_PROGRAM.img for lv1.self then lv1ldr, which will decrypt and start lv1.self
* 4. Lv1 will start rvkldr to verify lv2_kernel.self revocation using RL_FOR_PROGRAM.img, if the check passes it will load lv2ldr and lv2_Kernel.self will start
* 5. sys_init_ios.self is decrypted by lv2ldr and started. (There is no appldr)
* 6. sys_init_app.self is decrypted by lv2ldr and started. (There is no appldr)



* Note 1 : updater, lv0_bank0 and lv1.self share the same keyset (even though lv1ldr is exclusively used to decrypt lv1.self)
* Note 2 : There is no isolated module that I know of that isoldr decrypts (even though it does handle the feature), isoldr is used for updating purposes back then on the CEB units
* Note 3 : Self Applications are all decrypted by lv2ldr (only sys_init_app.self and sys_init_ios.self exist in self format, all other applications are in .elf format and started directly by sys_init_app)
* Note 4 : There is no CBC Step in the self decryption ! Even if you can't dump/decrypt loaders it is still possible to decrypt self by xoring their metadatas together for those using the same keysets (AES128CTR using the same key and iv)
* Note 5 : A 00 paired Secure Isolated Loader can be identified by the fact that the per console key in the header located at 0x14 of size 0x0C is filled with 0x00. These loaders do not decrypt/load on regular consoles because the per console key is forced in the decryption step if set.