[TheEvolution_PT]

Also a 'hidden hint' at the top of here:
http://ps3devwiki.com/index.php?titl...318&oldid=6316

(you have all you need already ;-) just read carefully (compare option2 code with the kernel module code))

[EmBoLa.be]

Originally Posted by TheEvolution_PT Also a 'hidden hint' at the top of here: http://ps3devwiki.com/index.php?titl...318&oldid=6316 (you have all you need already ;-) just read carefully (compare option2 code with the kernel module code))

Ans did you get your per_console_key_0?

[TheEvolution_PT]

Originally Posted by EmBoLa.be Ans did you get your per_console_key_0?

No im just sayin

[georgeana100]

i think we are 100 miles away from a new cfw with no car and on a difficult road :S. no hopes for me yet!

[zecoxao]

I've been visiting the irc chans lately, and AFAIK, and what was told to me, is that there are two ways of getting cfw on the latest ofw:

One of the ways is by finding said key, the per_console_key_0. What we assume
is that per_console_key_1 derives from per_console_key_0, meaning that per_console_key_1 has a source on per_console_key_0, or in other words, the inverse of key_1 is key_0. Now, we don't know that for sure, we also don't know if there are further derivations of per_console_key_1, so it's a guessing game.

The second way, already achieved by one person, perhaps more, is pwning metldr. Many of you don't like the guy who has achieved that, but, truth be told, he has done it, and has inclusively given you hints on how to do it... His name is Mathieulh. If i'm not mistaken, the sum up of those hints is on ps3devwiki as well, under something entitled "Mathieulh Overflow Exploit". I suggest you take a good read at it...

Any corrections to what i've said would be apreciated and taken into account.
And don't forget twitter is a good place to collect info aswell.

[wikdclown]

IMO there should never be a cfw for the current ofw because you know it would only be a matter of time before someone released some sort of cheat software to absolutely ruin online games. If people want online they should really be on ofw.

All we need is some way to sign current and future games for 3.55 but i wish the devs who put their time into this the best of luck.

[georgeana100]

i totally agree that cheats on online sucks hard but in order to play for example 2 online games on ofw you need 100euros.too much for me

[shak360]

just some updates from the wiki

Boot Sequence

Power on : syscon boots from it's 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
+ syscon pulls the reset of Cell high -> Cell INIT
Cell INIT: CELL boots from it's internal ROM *2
+ Initialises I/O
+ fetches encrypted bootldr off NAND/NOR flash (at address 0xFC0000)
+ Initialises RAM
+ loads bootldr into Isolated SPU (SPE0)
+ Runtime Secure Boot decrypts and verifies bootldr and executes
+ 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.

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 which at this time has not been done.
************* [ - Post Merged - ] *************
Also if anyone has paid attention to the gitbrew - glevand has posted tons of documentation.

[TheEvolution_PT]

Originally Posted by shak360 just some updates from the wiki Boot Sequence Power on : syscon boots from it's 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 + syscon pulls the reset of Cell high -> Cell INIT Cell INIT: CELL boots from it's internal ROM *2 + Initialises I/O + fetches encrypted bootldr off NAND/NOR flash (at address 0xFC0000) + Initialises RAM + loads bootldr into Isolated SPU (SPE0) + Runtime Secure Boot decrypts and verifies bootldr and executes + 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. 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 which at this time has not been done. ************* [ - Post Merged - ] ************* Also if anyone has paid attention to the gitbrew - glevand has posted tons of documentation.

Thanks for the info, i pray for the lv0 get unlocked.

[defyboy]

Originally Posted by zecoxao The second way, already achieved by one person, perhaps more, is pwning metldr. Many of you don't like the guy who has achieved that, but, truth be told, he has done it, and has inclusively given you hints on how to do it... His name is Mathieulh. If i'm not mistaken, the sum up of those hints is on ps3devwiki as well, under something entitled "Mathieulh Overflow Exploit". I suggest you take a good read at it...

metldr has been dumped by a few people, we need to dump bootldr for the lv0 keys. This would enable us to decrypt all future firmware. The problem with dumping bootldr is that it is cleared very early in the boot process.

No matter the situation, you will not have a CFW that will install on 3.60+, you will still need a hardware flasher.