[raddog]

I recently bricked my console and got this idea wat if there was a custom recovery menu than would run no matter the nature of the brick,like for eg.instead of sony crap recovery menu where if ur ps3 bricked it wont go into rocovery most of the time cause its tied to the ps3 os,rather why not have a rcovery menu thats separate from the ps3 os and can be called despite the system gives u a black screen or ports are dead,and u can just recover from any brick without a e3 or prog.that would be amazing almost like android devices that has their own recovery menu some come preinstalled from factory and with custom rom.wat i realised is that my android phone revcovery menu is completely separated from the phone os it self thus i could recover from any bricks,so i cant see why this cant be done to some extent on our consoles,and ofcoruse we need a very skilful dev for this.and also i think android phones are way ahead of our consoles in terms of customisation why is this....maybe its a open source os?

SO wat do u guys think

[zecoxao]

nope. you'd need to get bootldr/syscon for that. after that, you could make one if you wished.

[sandungas]

The problem in few words is it needs to be placed in a early stage of the bootchain
The "factory/service mode" works by replacing lv2... instead of this we need to replace bootloader, but without knowing how it works we cant even be sure if is possible, also the syscon is the boss of the motherboard, this gives a few more options to play with

But without the keys involved there is no much hope for this to happen, maybe some day

[raddog]

Originally Posted by sandungas The problem in few words is it needs to be placed in a early stage of the bootchain The "factory/service mode" works by replacing lv2... instead of this we need to replace bootloader, but without knowing how it works we cant even be sure if is possible, also the syscon is the boss of the motherboard, this gives a few more options to play with But without the keys involved there is no much hope for this to happen, maybe some day

hmm then i see this needs alot of work....and the three main things are bootloader,syscon and keys but we already knw how two of those work right?,so bootloader is the only one left....still i would love to see this become a reality and i bet one of the devs already thpught of this!!

[playerkp420]

Would be cool. Like Bootmii for the Wii.

But even if you could get the keys, like bootmii does, it still might not work. Besides the keys you need an exploit.
With the older Wiiis there was a flaw that allowed bootmii to replace boot 1 with boot 2. So you could launch bootmii before bootloader. But even with the keys, you can not do this on newer Wiis.

[zecoxao]

well, as for syscon, the eid1 seeds naehrwert hinted a long time ago were found on sc_iso_factory self, so that means they have to do with syscon. maybe there's something on eid1 that points to the internal structure of syscon, who knows. you can know that by decrypting your own eid1 i guess. if you want i can provide a sample of my decrypted eid1.

edit: here it is http://dl.dropbox.com/u/35197530/eid1_dec

[cfwprpht]

For what i know syscon isn't encrypted on his chip and it hase a additional bank to boot.

But for bootloader i don't think that you could put it in there.

[sandungas]

Originally Posted by raddog ....and the three main things are bootloader,syscon and keys but we already knw how two of those work right?,so bootloader is the only one left....

This are the culpits, but is like the egg-chicken problem, we dont have the bootloader keys, and there is no full access to the syscon (there is some access because its needed to communicate with him, e.g: to turn on/off the ps3, to update his firmware... or to store the service mode flag)... but most areas are hidden (the important ones)
Is even more important than the bootloader because is working when the PS3 is in standby, when you turn on the PS3 it sends the "config ring" to the CPU... and the bootrom (inside CPU) is loaded, then the CPU starts working and the boot "jumps" to the bootloader (inside flash)

The 2 banks in syscon i heard are duplicated data. This maybe is speculation but has sense to me in the same way PC motherboards has 2 BIOS to avoid bricking when the BIOS is updated
Maybe by placing homebrew code in one of this banks we can have a dual-boot (or a normal boot + a new recovery)

So syscon is at the same time... a big problem... and a good target to find new features. Syscon and bootloader are so related that will be hacked together (or never)



Edit:
If there is some mistake in this start process i simplifyed on purpose (mostly because i ignore the details), please correct me

[tjhooker73]

What if We could make a custom bootldr and syscon On a Separate chip that could be soldered into place so it we brick we can just flip a switch and fix it.

[sandungas]

Originally Posted by sandungas So syscon is at the same time... a big problem... and a good target to find new features. Syscon and bootloader are so related that will be hacked together (or never)

Is funny few days after i wrote this, the bootloader was hacked (using an exploit in syscon)
Now we have all needed to make a good recovery/antibrick

Originally Posted by tjhooker73 What if We could make a custom bootldr and syscon On a Separate chip that could be soldered into place so it we brick we can just flip a switch and fix it.

The modchip juannadie was talking about was supposed to work in some way similar to what you said

For the exploit to work its needed to interfacte some output/input pins of syscon, to controll communications with CELL and to controll the areas used by syscon to store "temporal data"
This way you can "emulate" the syscon or make it work for you

The rest is a cake... having controll of the comunications with syscon means you have your root_key_0 (inside cell) and the rest of the bootchain stages is in flash (bootloader--->lv0-->etc, etc...), in other words... you can resign and regenerate all the contents in flash

To be able to write the flash (from a brick state)... maybe there are several ways... initially what writes the flash in a stock motherboard is the "southbridge"
Syscon has a connection with southbridge (or in other words... southbridge is an slave of syscon and does what the boss wants)
So maybe by sending commands from syscon to southbridge... we can write the flash !!! without a flasher !!!
Either way... if this idea of writing flash using southbridge doesnt works it makes no difference... this kind of modchip needs a way to write/read a 100% corrupted flash

To make a good recovery its needed to redirect the boot chain to another device (e.g: HDD or USB)... or as an alternative emulate the flash (a little eeprom in the modchip maybe is enought because we only need to load 1 stage more of the bootchain modifyed with a recovery menu)
Also the same idea can be used to make a multiboot with a selector menu (or a button)

It seems now is posible to make all this work, lest see what happens in next months, i would like to see a new generation of modchips, and probably i will buy one