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

Other docs

Masking a hardware boot sequence (patent)

• https://www.google.com/patents/US8046573?dq=cell+broadband+engine+secure&hl=en&sa=X&ei=dfQCVM_hGpXh8AXm54D4Ag&ved=0CCMQ6AEwATgK

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 various loaders and levels in this page are encrypted as Certified Files.

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

CoreOS Contents Per Firmware

Generated with BwE Bulk Validator BETA 0.01 - Matched with valid ROS0/1 Extracts.

This list should have static MD5's (Meaning your files should not differ).

http://pastebin.com/mGNMZ1Nm

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.