Hey there.

So... you use an ad blocker. That's cool. Sometimes we do too.


But without ad revenue, we wouldn't even be here. And we might not be here much longer.

Please disable your ad blocker and click to continue.

Page 3 of 4 First ... 234 Last
  1. #21
    NDT Guest
    Hi law, message me on efnet, my nick is: _N_D_T_

  2. #22
    pompomgirl 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...).

  3. #23
    Tidusnake666 Guest
    Quote Originally Posted by pompomgirl View Post
    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.
    Which thread? any links?

  4. #24
    sphinx1267 Guest
    idone & D4ny have confirmed in this thread that flashing a previous dump to a 2.10 fw console boot will fail

    http://www.ps4news.com/forums/playst...old-98097.html

  5. #25
    Tidusnake666 Guest
    Quote Originally Posted by sphinx1267 View Post
    idone & D4ny have confirmed in this thread that flashing a previous dump to a 2.10 fw console boot will fail

    http://www.ps4news.com/forums/playst...old-98097.html
    Oh, I get it. It's not cool at all.

    I guess this applies to flashing modified dumps, not only downgrading?

  6. #26
    NDT 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

  7. #27
    djakobino2008 Guest
    guys its great release so how to install ? this will work on 2.43 firmware guys?

  8. #28
    d4ny 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

  9. #29
    RexVF5 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 ...???

  10. #30
    CJPC 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.

Page 3 of 4 First ... 234 Last

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in