10-03-2008 #21NDT Guest
Hi law, message me on efnet, my nick is: _N_D_T_
10-03-2008 #22pompomgirl Guest
Congrats NDT and RPS!
As seen in another thread, be aware that impossible to pass barriers exist.
2.10 is confirmed to be the first one it seems. We have to assume an efuse (or something similar) is blown up.
So if your fw is under 2.10 (and also below 2.01) you will be able to play a lot with dump/reflash and the satety of rebuilder 3.50 by upgrading a bit (not to 2.10 or above!) and downgrading to your previous dumped older fw...
Once you got fw at 2.10 or above, it's over for older fw<2.10 (until cfw's appear). But it's possible other barriers exists above 2.10 that will make your older dumps fail.
Be sure to let us know if you detect such new barriers (it will give hints about stuffed holes Sony doesn't want people to go explore back in older fw's...).
10-03-2008 #23Tidusnake666 Guest
10-03-2008 #24sphinx1267 Guest
10-03-2008 #25Tidusnake666 Guest
10-03-2008 #26NDT Guest
Hmmm i think there is a missunderstanding.
When the devs say that 2.10 is ok to downgrade they say that it's ok using the sdkversion downgrade procedure and NOT restoring the previous dump with infectus.
It was one of the first hack attempt ggparallel tried, he downgraded just the sdk version in the dump then he tried a fake upgrade to a lower fw version and it worked.
I never tried this hack on my console because i had already updated it when i knew bout it
10-03-2008 #27djakobino2008 Guest
guys its great release so how to install ? this will work on 2.43 firmware guys?
10-04-2008 #28d4ny Guest
So NDT, your clarification, makes me wonder about that:
1. 2.10 (or maybe even below but I can't confirm that) introduces some kind of security that prevents flashing untouched previous dump
2. 2.10 can be downgraded by sdk version modification and fake upgrade to a lower fw
3. 2.17 can't be downgraded by sdk version modification and fake upgrade to a lower fw
It looks like after upgrade to 2.10 some kind of hash of system files is made and its written somewhere (but not in the NAND). When console boots, calculates such hash again and compares it with the saved one. If calculated one is different that saved one, console turns in panic mode. It prevents from flashing previous dump because hash of system files of lower fw is different that saved one calculated on 2.10.
But in 2.10 this hash calculation does not include the sdk version file, so it allows downgrade by modification of its contents. 2.17 includes sdk version file in hash calculation, so it prevents both of downgrade methods.
I think this aproach is more secure than saving only version of installed firmware. I also agree that calculated hash saving could be made by blowing an efuse.
It's only theory and needs more testing, but it looks logically consistent
07-01-2009 #29RexVF5 Guest
Idea struck me now when replying post in other section: this tool was able to recover part of the flash's filesystem. The other part remained encrypted and was resisting attempts to break in. The question is: now when we have a way to decrypt the HDD - has anyone tried to decrypt that encrypted flash partition as if it was part of the HDD? I know chances are slim the same encryption is used for both HDD and flash but what if ...???
07-01-2009 #30CJPC Guest
Well, the encrypted filesystem part of the flash is, in the PS3, labeled as /dev_flash , /dev_flash2 , /dev_flash3 (assumption on 2/3)
Now, in an older ps3, all of the dev_flash was actually, on the flash (it was big enough)
However, on the NEW PS3's, that only have 16MB of Flash, 90% of that data is stored right on the HDD, so we can access it.
However (again), we have already accessed most (/dev_flash) of this data, with a TEST. It may help to compare Test->Retail differences, but that is about it.
The "Goodies" come in at dev_flash 2/3. But, since there is still 16MB of data on the flash (holding the bootloader, etc), the 2/3 of dev flash could just be reserved space for that - its all mostly speculation.