PS3DumpChecker

Discussion in 'Downgrading' started by littlebalup, Oct 16, 2014.

  1. 7,605
    5,753
    872
    kozarovv

    kozarovv Super Moderator

    Joined:
    Nov 8, 2014
    Messages:
    7,605
    Likes Received:
    5,753
    Trophy Points:
    872
    Home Page:
    Is probably because ros1 is 4.76 cfw so MD5 is not MD5 from OFW. But is only my sugestion, wait for someone smarter than me in downgrade things.
     
  2. 1,189
    1,201
    272
    littlebalup

    littlebalup Developer PSX-Place Supporter

    Joined:
    Oct 16, 2014
    Messages:
    1,189
    Likes Received:
    1,201
    Trophy Points:
    272
    Location:
    43°36'16.0"N 1°26'36.1"E
    ROS1 header issue is due to the use of a coreOS firmware region size (decripted coreOS size) wich is not as it should...
    The bad hash is due to the CFW that was installed before the OFW update.

    There is an option in PS3dumpchecker to restore it. To be used with the "force patch" function that will solve your hash issue as well.
    Another safer procedure is to re-install a second time the OFW4.78, then dump again, and everything should be OK with the new dump.
     
  3. 3
    0
    0
    miro_vampiro

    miro_vampiro

    Joined:
    Jan 26, 2016
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    0
    kozarovv and littlebalup , thank u both for the fast reply and for the great help, i will do that tomorrow and i believe everything will be ok
    Regards
     
  4. 3
    0
    0
    miro_vampiro

    miro_vampiro

    Joined:
    Jan 26, 2016
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    0
    Everything is working perfect after i re-install a second time the OFW4.78 and then dumped the files , thank u for the help
     
  5. 10
    0
    0
    kam2010

    kam2010

    Joined:
    Jan 30, 2016
    Messages:
    10
    Likes Received:
    0
    Trophy Points:
    0
    thnak you :but start:
     
  6. 1
    0
    0
    beats.drum@yahoo.ie

    [email protected]

    Joined:
    Feb 13, 2016
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    0
    nice job thanks

    thanks very much:but x:::dir down::but r1::but start:
     
    Last edited by a moderator: Feb 14, 2016
  7. 24
    8
    32
    oceansoul

    oceansoul Member

    Joined:
    Mar 2, 2015
    Messages:
    24
    Likes Received:
    8
    Trophy Points:
    32
    Code:
    Build 487 2016-01-24:
    Changed: The embedded 4.76 patch replaced by a 4.78 patch build from the FERROX 4.78 CEX custom firmware CoreOS.
    Added: OFW and Patched 4.78 ROS hashs.
    Added cisd2 no-wifi entry and one CECHB SKU ID data.
    
    Latest this just check ofw 4.78 not patch tham ?
     
    Last edited: Feb 15, 2016
  8. 309
    302
    97
    baileyscream

    baileyscream Member

    Joined:
    May 5, 2015
    Messages:
    309
    Likes Received:
    302
    Trophy Points:
    97
    You just quoted the answer to your own question


    Sent from my hand using Tapatalk and magic
     
  9. 1
    0
    0
    ddubz

    ddubz

    Joined:
    Feb 19, 2016
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    0
    I have ps3 slim cech2001a on 4.78 ofw i have used e3 flasher to dump nor and have gotten passes in nor inspector and dump checker for my backups. I have tried to use ps3 dump checker to patch dump and reflash. the ps3 will boot as normal but when trying to install rogero downgrader 3.55 it says update data is not supported by this system. So I have tried a couple of programs one is norpatch.exe and that didn't boot and in service menu it never found and update data on my usb just stuck on searching for 30 minutes before i shut it off, also tried nor and nand auto patcher and it did the same as norpatch i dont know what else to do please help i was using the 487 version of ps3dumpchecker. Do you need patch.bin files or is just .exe needed i tried both. pc is on windows 10. It seems to me that the nor dump is not being patched for some reason.
     
    Last edited: Feb 19, 2016
  10. 1,189
    1,201
    272
    littlebalup

    littlebalup Developer PSX-Place Supporter

    Joined:
    Oct 16, 2014
    Messages:
    1,189
    Likes Received:
    1,201
    Trophy Points:
    272
    Location:
    43°36'16.0"N 1°26'36.1"E
    I checked your dump. Seems correct.
    - Console was already jailbroken before? If so, what CFW? Any spoof?
    - Did you tried with another USB stick?
    - Try to install Rebug REX 4.78, then toggle QA via toolbox, then install rogero downgrader 3.55, then install OFW3.55 both time. Do each update via recovery mode.
     
    T.A.U likes this.
  11. 10
    0
    5
    reneperez

    reneperez Forum Noob

    Joined:
    Mar 2, 2015
    Messages:
    10
    Likes Received:
    0
    Trophy Points:
    5
    Gracias por el aporte!!
     
  12. 1,189
    1,201
    272
    littlebalup

    littlebalup Developer PSX-Place Supporter

    Joined:
    Oct 16, 2014
    Messages:
    1,189
    Likes Received:
    1,201
    Trophy Points:
    272
    Location:
    43°36'16.0"N 1°26'36.1"E
    Build 489 released with 4.81 "patch".
    Once again, thx @Alexander
     
    T.A.U, STLcardsWS and Alexander like this.
  13. 453
    302
    97
    Alexander

    Alexander Developer

    Joined:
    Oct 17, 2014
    Messages:
    453
    Likes Received:
    302
    Trophy Points:
    97
    ooooh thank you @littlebalup ^^
     
  14. 5,915
    5,592
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,915
    Likes Received:
    5,592
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    I had a talk with judges yesterday and while brainstorming a bit appeared a couple of ideas, im going to try explain them here for the record
    One is a "shorcut auto-diagnosis test" for the teensy firmware itself (norway or nandway) or to be used in norpy incase someone is interested in improving them
    The other is a "data auto-diagnosis test" that needs to be performed after ps3dumpchecker

    The reason why i was talking with judges about norway is because i did read in other forum someone that was having problems when analyzing the dump in ps3dumpchecker, it was returning error in ROS0, ROS1, and cvtrm
    After some struggling he realized he had the b3 and b4 wires touching each other (spoiler... both are "address" lines)
    When looking at the dump in a hexeditor it seems that there was areas with dumplicated data

    So i was wondering.... there is some way to identify this problem automatically by software ?
    If we know wich offsets and lenghts from the dump are affected by each wire... then we could make a bynary comparison of two areas and if the comparison succeeds then we have a problem
    The theory is ok... but the problem is this could only identify problems in very specific scenarios (when adress lines are crossed and touching other address line) so is not very usefull

    Judges pointed to a better way to make this test "by hardware"... the idea is to pull up one of the adress lines and meassure volts in the other adress lines... if any of the others has volts then we have a problem
    But pimping this idea a bit more... this could be made by teensy itself... as a "sanity check" when the atmel chip boots... it can even be made with other wires
    This feature could be part of the teensy firmware or the python client i think, judges doesnt plans in updating them btw, im just throwing the idea here if someone likes it

    ---------------------------------
    Based partially in what i wrote before... there is a way to know wich areas of the dump belongs to each address and data wires
    Is a math calculation, i dont know the formula right not, but flash works like a matrix
    By analizing the data to find "error patterns" is posible to identify if there is a wire wrong and to know which one is it
    Is like searching for "chessboard" patterns filled with error bytes

    This kind of checks by software are better to be made in pc, fits fine with a program like dumpchecker, if something bad is detected after the check it could show a warning like this:
    "the errors you got matches with a pattern and could be caused by wire X and wire Y... please verify that connections"
     
    Last edited: Mar 24, 2017
    playerkp420, Sdw100 and littlebalup like this.
  15. 1,189
    1,201
    272
    littlebalup

    littlebalup Developer PSX-Place Supporter

    Joined:
    Oct 16, 2014
    Messages:
    1,189
    Likes Received:
    1,201
    Trophy Points:
    272
    Location:
    43°36'16.0"N 1°26'36.1"E
    @sandungas
    For the shortcut test, I agreee it is definitely better to do it via hardware as judges stated.
    For the data test, we could assign the address line number to each check. But I'm not sure it can be very usefull as both ROS's are 90% in size of a NOR dump. Any bad address will make an ROS error, then the checker will list all the address that can cause the error (so, many address).
     
  16. 5,915
    5,592
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,915
    Likes Received:
    5,592
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Im thinking it could be an extended test, after the actual ps3dumpchecker tests
    If something goes wrong in the actual checks it could appear an option "do you want to make an indepth address test?"

    By now i dont get how the address are "mapped" to flash, but it looks like it can be made with a double nested "for" loop
    In the loop at top you check for an adress bit, and in the internal loop you check for the other bits
    It could take several minutes to complete... but imo the time doesnt matters, if you are using this is because there are serious problems, heheh, so is worthy to wait and see if dumpchecker finds some error pattern

    The offsets where the errors could start appearing are always located in the same postions (should match with the block size i think)
    To target a bit the search... it could start at the offsets of the areas that was reported with errors in the first dumchecker pass (at ROS0 in our example)

    Also, the comparison could be made initially only with the first few bytes (one, or a couple) to speed it up... and only incase the first byte matches it should compare seconds byte... and so on

    Dunno, are just ideas, found this that explains it a bit
    http://www.psdevwiki.com/ps3/Validating_flash_dumps#Repetitions
     
  17. 1,189
    1,201
    272
    littlebalup

    littlebalup Developer PSX-Place Supporter

    Joined:
    Oct 16, 2014
    Messages:
    1,189
    Likes Received:
    1,201
    Trophy Points:
    272
    Location:
    43°36'16.0"N 1°26'36.1"E
    Understand how we can check repetition/swap of data, etc.
    But what I'm trying to say is, before that, we need to find where are the error(s) in the ROS.
    Today we are just checking the MD5 vs a CoreOS hash list. To determine exactly what is wrong, the ROS data must be compared to the equivalent CoreOS data and not only checksum.
    Means:
    - need to know what are the ROS versions of the dump before to be able to check it. Can be difficult if totaly corrupted or if CFW.
    - add all the CoreOS versions to the checker (huge) or make them available online or whatever.

    So, it's not so easy.
     
  18. 5,915
    5,592
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,915
    Likes Received:
    5,592
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Hmmm what im thinking is different, doesnt compares data against a "database" but against another potential offsets where that adress wire could have created the same pattern
    The comparisons are made in the offsets that matches with the address wires to check any data on them (byte by byte... or 2 bytes because teensy uses 16 wires for data that makes 16 bits), comparing up to 16 bytes incase all previous 15 was successfull

    If the address wire is not connected the data should be 0x00, right ? (or 0xFF ? not sure about this)
    Then continue comparing more bytes from it against the other offsets where that address wires was used
    If there are several areas with the same 16 bytes and all them are 0x00 (or 0xFF ? not sure about this) then the wire is not connected (teensy is reading garbage in a chessboard pattern)
    If there are several areas with the same 16 bytes and but none of them is 0x00 (or 0xFF ? not sure about this) then the address wire is touching another address wire (the data is real but is duplicated)
     
    Last edited: Mar 24, 2017
  19. 5,915
    5,592
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    5,915
    Likes Received:
    5,592
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    Sorry, with my english is hard to explain what i have in mind, specially because im not so sure how to limit the amount of interesting target addresses to check
    The whole NOR map is made of 2^23 address, this makes a total of 8.388.603 addresses (and every one of them has 2 bytes of data)
    When there is an error in one of the address wires... the "garbage" data patterns are going to be distributed very preciselly, like a checkered flag
    By now im trying to imagine a way to represent this visually... with a wiki table i guess

    But the problem i have to represent the whole NOR map in a wiki table is the same an app could have to perform checks in it... the amount of addresses is huge (near 8.4 millions of cells to make a very accurate table) XD
    Point is... we dont need to look at all that addresses, but only to the representative ones
    By grouping the addresses we reduce the number... then we check at the first address of the groups (initially only the first address for performance... checks to the next addresses are optional if needed)

    There are several ways to group them, but not sure which is the best one
    -One is to pick 8 consecutive addresses... this way we have groups of 16 bytes (total groups 1.048.576)
    -Other way is by using groups of 23 address each, because teensy has 23 address wires (total groups 364.722)
    -Other way is by using "block access" (512 bytes... so 32 addresses by block)... PS3 accesses data in NOR this way (total blocks 16.384)
    -Another more weird way is grouping addresses that are affected ONLY by an specific wire... this is another thing i dont have the picture in mind... the problem is could not be consecutive

    So dont know... but it could be nice to have a table in wiki with the whole NOR map (using some grouping, im not going to make a table with 8.4 millions of cells :P)
    After having the table is posible to add different colors to some cells (for specific parts of the firmware), and most important i hope it will be easyer to figure a way to identify the posible error patterns visually
     
    Last edited: Mar 25, 2017
    Death_Dealer likes this.
  20. 249
    189
    72
    playerkp420

    playerkp420 Moderator Developer

    Joined:
    Feb 24, 2015
    Messages:
    249
    Likes Received:
    189
    Trophy Points:
    72
    I think it would be more important to do that for NAND dumps. Since NOR dumps are pretty easy to validate.

    But I get what you are saying, and I think it is a great idea if it can be done. Would be great for someone to know exactly which line(s), were the cause of their bad dumps. Would make fixing their setup a lot easier.
     

Share This Page