Retail 2 Dev

[AbdouRetro]

I've had this concept for a very long time but i always thought if it was possible it should've been done already. until somebody brought it up on #fw.

i remember reading that dev and retail hardware are the same. so i thought if NDT reversed the ECC algorithm in the NAND and is now able to read and write properly from any NAND and actually he released his tool "NAND flow rebuilder" i think.
so why can't somebody just use a dev dump to get the files then use the tool to swap them with the one in his own dump, shouldn't this work??
i see that if the NAND can be modified without producing any errors as claimed on ps3news, then this concept should be possible.

[jelle2503]

good idea 

[AbdouRetro]

am pleased to see that
i think Hacked2132 had a few ps3's with infectus, ama ask him bout that
who are the other devs you think are capable

[bowser222]

i got a demo unit here i dunno if anyones ever tried that tho.i have an infectus too

[AbdouRetro]

bowser222

i am so happy you paid me some attention
do you have good soldering skills
i mean you can solder the infectus to the flash or remove the flash and put it in a NAND reader and put it back no problem??

if you can do so or have already done, the first step towards this would be you giving me a dump of your NAND chips and i'll run over to other PS3 sites and find more dumps

if i can't find dev dumps, we'll go with retail ones so we can make a PoC
so make a proper dump of the NAND and we'll be waiting here

p.s which firmware does the demo unit have

[lordmash]

sounds like a great idea,good luck and hope it works

[AbdouRetro]

unfortunately the only forum with public good data is ps3news
so i went there

and adding to this project this info:

 (*) xvistaman's method of partially installing the debug firmware didn't properly due to missing files:
so how about this--> doing that then adding those files --- i will pursue this concept starting at ps3news as thats where xvistaman and this originated
 -will update if i learn anymore

[AbdouRetro]

Am on the look out for proper NAND dumps as well as bios dumps and info about the ps3 bios chip as i've been informed by some devs that it might have a key role in this project

NAND retail or Debug ---> just point me to a rapidshare or torrent link in PM

[AbdouRetro]

Somebody over at PS3Hax told me that the most significant barrier to this process is the EID, which i am awaiting feedback on the location of such data NAND/BIOS/WHAT.DA.HELL

its also good to note that as i said in my previous post, i was informed by a ps3news dev that the barrier was the bios chip. but is it possible that the bios holds blu-ray keys(check below), which makes me doubt the credibility of this piece of information, especially when i know for a fact that blu-ray drives of the same revision can be swapped, meaning no unique keys.

The EID is a specific area on your ps3 which is signed per ps3 and contains "keys" (more like certificates in fact) generated (and signed) by sony which contain specific informations such as the target id/region, the bluray keys etc etc

What you would like to change is the target id which is as follow: 81 = reference tool, 82 = debugging station, 83 = japan, 84 = USA, 85 = Europe, 86 = Korea, 87 = UK, 88 = Mexico, 89 = Australia/New Zealand, 8A = South Asia (Asia except China, Japan and Taiwan), 8B = Taiwan, 8C = Russia, 8D= China.

Anything from 84 and onward is retail (or demo/shop unit since they share the same target ids as the retail units, only the vsh and its modules change)

The kernel checks the target id to see if your unit is debug or not and if not it disables all the fancy things such as running unsigned code. So what you want to do is to change 8x into 81 or 82 but this implies resigning the EID section (or at least decrypting the per ps3 encryption from a debug EID target key and reaplying onto a retail)

so this leaves me to :
1- properly reconstruct a dump with proper dev files <------- do-able
2- downgrade dev machine to 1.0 using special PUP already available to go up again thus rebuilding the whole firmware flash(more on this if requested) <----do-able
3- EIDs<----what the hell are we going to do about this??. but let's not judge until i get more info on this

am also speculating that doing xvistaman's dev firmware hack makes alot of steps unnecessary
will update when more info is learned

bowser222 ---> you still got time for our project???

[McLaren2]

***********

PS3 retail dump, don't know what version exactly

[Arakon]

That's copyrighted material and may not be linked to here.

[mathieulh]

Somebody over at PS3Hax told me that the most significant barrier to this process is the EID, which i am awaiting feedback on the location of such data NAND/BIOS/WHAT.DA.HELL

its also good to note that as i said in my previous post, i was informed by a ps3news dev that the barrier was the bios chip. but is it possible that the bios holds blu-ray keys(check below), which makes me doubt the credibility of this piece of information, especially when i know for a fact that blu-ray drives of the same revision can be swapped, meaning no unique keys.

The EID is a specific area on your ps3 which is signed per ps3 and contains "keys" (more like certificates in fact) generated (and signed) by sony which contain specific informations such as the target id/region, the bluray keys etc etc

What you would like to change is the target id which is as follow: 81 = reference tool, 82 = debugging station, 83 = japan, 84 = USA, 85 = Europe, 86 = Korea, 87 = UK, 88 = Mexico, 89 = Australia/New Zealand, 8A = South Asia (Asia except China, Japan and Taiwan), 8B = Taiwan, 8C = Russia, 8D= China.

Anything from 84 and onward is retail (or demo/shop unit since they share the same target ids as the retail units, only the vsh and its modules change)

The kernel checks the target id to see if your unit is debug or not and if not it disables all the fancy things such as running unsigned code. So what you want to do is to change 8x into 81 or 82 but this implies resigning the EID section (or at least decrypting the per ps3 encryption from a debug EID target key and reaplying onto a retail)

so this leaves me to :
1- properly reconstruct a dump with proper dev files <------- do-able
2- downgrade dev machine to 1.0 using special PUP already available to go up again thus rebuilding the whole firmware flash(more on this if requested) <----do-able
3- EIDs<----what the hell are we going to do about this??. but let's not judge until i get more info on this

am also speculating that doing xvistaman's dev firmware hack makes alot of steps unnecessary
will update when more info is learned

bowser222 ---> you still got time for our project???

Thanks for quoting my post without giving the source....

Changing the EID is the only thing necessary considering this is also what the updater's self check, in otherword you "just need" to set the target id to 82 and then get a debugging station update that is an higher version than your current firmwares (because of the vsh version checks) and it will flash flawlessly just as it would on a normal debugging station. The problem is that changing the target id requires to resign the EID and doing so without the keys or algorithms which sony use is impossible, in otherword with our current level of knownledge resigning the EID is as "easy" as signing your own self. Considering that the whole debugging station detection checks rely on the EID's target id, it is doubtless to mention that sony consider the EID as safe from any form of tampering.