Talk:Boot Order

From PS3 Developer wiki
Revision as of 19:03, 17 December 2012 by Mathieulh (talk | contribs) (→‎CEB Units: new section)
Jump to navigation Jump to search

IBM /Sony docs

Cell Broadband Engine™ CMOS SOI 65 nm Hardware Initialization Guide

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: 

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

The entrypoint of metldr is at 0×400, and in essence it just does the following: 

    ULONG *pStart = (ULONG*)&start;
    (pStart)();

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. :) 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)

(You can get these strings via tty on a DECR, so its not a proof of decryption :P)

old and new metldr handle CoreOS/flash the same

4.0 PUP and 4.0 Flash comparison (all metldr)

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
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')

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
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

CEB Units

  • On CEB units the Boot order is different:

- There is no metldr, all loaders are Isolated Secure 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 modifier 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)
Retrieved from "http://www.psdevwiki.com/ps3/index.php?title=Talk:Boot_Order&oldid=18171"