Editing Talk:IDPS
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
<mysis> after model type....in short it was right-shift 10d / 0xA | |||
= IDPS Examples = | === IDPS Examples === | ||
The reason of why ordering the examples this way is because Product Code and Product Sub Code are known, and Chassis Check is the only thing left we can deduce from the examples... | The reason of why ordering the examples this way is because Product Code and Product Sub Code are known, and Chassis Check is the only thing left we can deduce from the examples... | ||
{| class="wikitable sortable" | {| class="wikitable sortable" | ||
! IDPS !! 6th<br />byte !! [[Product Code]] !! 8th<br />byte !! [[Product Sub Code]] !! Chassis Check !! Notes | ! IDPS !! 6th<br />byte !! [[Product Code]] !! 8th<br />byte !! [[SKU Models|Product Sub Code]] !! Chassis Check !! Notes | ||
|- bgcolor="#CCCCCC" | |- bgcolor="#CCCCCC" | ||
| <code>00 00 00 01 00 81 00 01 03 FF FF FF 18 43 C1 4D</code> || {{TID81}} || 0x01 || [[DECR-1000|DECR-1000(A/J)]] / [[DEH-Z1010]] ([[TMU-520]]) || 03 FF || Static Dummy IDPS | | <code>00 00 00 01 00 81 00 01 03 FF FF FF 18 43 C1 4D</code> || {{TID81}} || 0x01 || [[DECR-1000|DECR-1000(A/J)]] / [[DEH-Z1010]] ([[TMU-520]]) || 03 FF || Static Dummy IDPS | ||
|- | |- | ||
| <code>00 00 00 01 00 84 00 01 04 00 F3 44 AC 4F 8D 2F</code> || {{TID84}} || {{HWID01}} || 04 00 (1) || | | <code>00 00 00 01 00 84 00 01 04 00 F3 44 AC 4F 8D 2F</code> || {{TID84}} || {{HWID01}} || 04 00 (1) || | ||
Line 178: | Line 167: | ||
|- | |- | ||
| <code>00 00 00 01 00 89 00 0D 14 00 93 75 A9 00 4C 96</code> || {{TID89}} || {{HWID0D}} || 14 00 (5) || | | <code>00 00 00 01 00 89 00 0D 14 00 93 75 A9 00 4C 96</code> || {{TID89}} || {{HWID0D}} || 14 00 (5) || | ||
|- | |||
|} | |} | ||
*Chasis check speculation (bytes 9th and 10th): | |||
**9th byte (most common: 0x04, 0x10, 0x14, 0xF4), 0x03 in the "Dummy IDPS" | |||
***First [https://en.wikipedia.org/wiki/Nibble nibble] values: 0, 1, or F | |||
***Second [https://en.wikipedia.org/wiki/Nibble nibble] values: 0, or 4 (3 in the "Dummy IDPS") | |||
**10th byte (seems to be a counter, biggest value found 0x22), 0xFF in the "Dummy IDPS" | |||
***First [https://en.wikipedia.org/wiki/Nibble nibble] values: 0, 1, or 2 | |||
***Second [https://en.wikipedia.org/wiki/Nibble nibble] values: too random to find a pattern | |||
*Next 6 bytes speculation | |||
**11th and 12th: (FF in the "Dummy IDPS") | |||
**13th, 14th, 15th, 16th: per console identifyer ? a hash / encryption of previous bytes ? | |||
{| class="wikitable sortable" | {| class="wikitable sortable" | ||
! IDPS !! 6th<br />byte !! [[ | ! IDPS !! 6th<br />byte !! [[Target ID]] !! 8th<br />byte !! [[SKU Models|PS3 Model]] !! Notes | ||
|- | |- | ||
| <code>00 00 00 01 00 80 00 01 xx xx xx xx xx xx xx xx</code> || {{TID80}} || 0x01 || [[DECHSA00A/J]] ([[COK-00x#COK-001|COK-001]]) || - | | <code>00 00 00 01 00 80 00 01 xx xx xx xx xx xx xx xx</code> || {{TID80}} || 0x01 || [[DECHSA00A/J]] ([[COK-00x#COK-001|COK-001]]) || - | ||
Line 190: | Line 190: | ||
AV Testing Tool labeled as DECHSA00A<br /> | AV Testing Tool labeled as DECHSA00A<br /> | ||
Stock Firmware 2.41 (ros0), ros1 is empty<br /> | Stock Firmware 2.41 (ros0), ros1 is empty<br /> | ||
Target ID 82, installation of DEX PUPs still impossible.<br /> | |||
NAND patched with 3.55 downgrade file.<br /> | NAND patched with 3.55 downgrade file.<br /> | ||
Installation of CEX and DEX PUPs was successful after FSM. | Installation of CEX and DEX PUPs was successful after FSM. | ||
Line 209: | Line 209: | ||
|- | |- | ||
| <code>00 00 00 01 00 8F 00 0E xx xx xx xx xx xx xx xx</code> || {{TID8F}} || {{HWID0E}} || - | | <code>00 00 00 01 00 8F 00 0E xx xx xx xx xx xx xx xx</code> || {{TID8F}} || {{HWID0E}} || - | ||
|- | |||
|} | |} | ||
= | === Chassis Check === | ||
The Chassis Check seems to be still a secret, or at least it's not 100% clear what it represents. So my immediate question was of course: if it's not clear what this means, how does the scene even know that it's called "Chassis Check" at all? Where does this information come from? | |||
Answer: according to the analysis of many different models of PSP, PS3, PSVita and PS4, it is clear that the only possible values are 0x3, 0x4, 0xC, 0x10, 0x14 and 0xF4.<br /> | |||
*Doing [https://en.wikipedia.org/wiki/Arithmetic_shift right shift] by 2 results in: | |||
**0x3 >> 2 gives 0 | |||
**0x4 >> 2 gives 1 | |||
**0xC >> 2 gives 3 | |||
**0x10 >> 2 gives 4 | |||
**0x14 >> 2 gives 5 | |||
**the exception is 0xF4 >> 2 gives 61... | |||
We clearly see that most of models released at the same period have the same Chassis Check, and we can see that the more the console is released late, so more it has a high Chassis Check. | |||
And second: how is the current state (or former experience) with bruteforcing the IDPS from the IDPS hash of a PARAM.SFO file (second hash iirc). I mean most of the information is known so in the best case you chose your region and model and only have to bruteforce the last six bytes (if the Chassis Check was known better). | |||
if the scene could establish some kind of standard or BF blueprint, like a blank PARAM.SFO of the PS3 singstar app, which should look the same on every console, someone could even work on a rainbow table for IDPS.<br /> | |||
just some thoughts from someone who just entered the PS3 dev scene, so don't be too harsh please ;) | |||
* You can verify the IDPS of a PS3 console through 2 ways : param.sfo of savedata or HDD backup from PS3. | |||
** wasn't there also the possibility to read some deviceid file from the PS Store app (given you got root access to the hdd, thanks to ps3xploit) ? | |||
I | * the easiest would be of course param.sfo of savedata, by manually verifying a certain sha1-hmac made from the file PARAM.PFD with idps as key. you'd need to bruteforce at least 8 bytes (or almost 8 bytes, if you could take care of all the possibilities for Chassis Check) | ||
** exactly, i was just looking into that and did a small PoC in c#, which BFs my IDPS. But even with all optimizations (especially for C#) and running on all cores with parallelization it isn't really THAT fast. Moreover, I even cheated and only bruteforced the last six bytes of my (known) IDPS. It's currently still running xD. | |||
* using openCL would help, because graphic cards are naturally faster than CPUs | |||
** my idea, too. currently looking into that, but I never worked with openCL before and can't even find a hmac/sha1 kernel for openCL. like nobody every did that before ... ;) edit: https://searchcode.com/codesearch/view/45893397/ ? | |||
but surely someone from the scene was or is already working on something like that? i basically search for people to share experiences or even try to build something together. anyone, bueller? | |||
* nobody is working on it but I had the idea once. Btw, if you're thinking into profitting from this, I assure you I won't help you further xD. I guess you'll have to learn some openCL on the way :P | |||
** wanted to look into opencl for quite some time now, anyways. there were more than one or two occasions where it would've come in handy down the road. oh and i'm absolutely not planning on making profit in any way with this, honest! perhaps we could continue this discussion somewhere more fitting? another dev from the scene told me, that the efnet channel would be a good place? | |||
* i'm zecoxao on skype, notzecoxao on Twitter. Contact me if you wish :) | |||
* Is this something that's still being looked into? My old PS3 received the YLOD, however I have a hard drive backup of it, but not longer have the actual unit, but I do have a new PS3. I want to recover all my data to my new PS3, but need to be able to dump all the data from archive2.dat to create a fresh backup with all the data to restore to the new unit. Anyone have any suggestions or know of a way I could crack the IDPS used to encrypt my backup ? |