kozarovv
Developer
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.
PS3 PS3DumpChecker
- Thread starter littlebalup
- Start date
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.
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.
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
Regards
Everything is working perfect after i re-install a second time the OFW4.78 and then dumped the files , thank u for the help
[email protected]
Member
nice job thanks
thanks very much
:
thanks very much
:
Last edited by a moderator:
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.
Last edited:
baileyscream
Member
You just quoted the answer to your own question
Sent from my hand using Tapatalk and magic
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:
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.
Build 489 released with 4.81 "patch".
Once again, thx @Alexander
Once again, thx @Alexander
Alexander
Developer
ooooh thank you @littlebalup ^^
sandungas
Developer
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"
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:
@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).
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).
sandungas
Developer
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
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
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.
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.
sandungas
Developer
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)
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:
sandungas
Developer
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
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:
playerkp420
Developer
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.
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.
Similar threads
-
-
PS3 BadWDSD HW Exploit - With new powerful qCFW for PS3 Slim & SuperSlim NOR models on the horizon- Started by STLcardsWS
- Replies: 141
-
PS2 [POC/Outdated] unofficial Open PS2 Loader (uOPL)- Started by Ripto
- Replies: 58
-
PS3 4.92 Evilnat Custom Firmware (w/ Cobra v8.5) Released - CEX,PEX,D-PEX,DEX builds
- Started by STLcardsWS
- Replies: 41