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 examples are ordered based in priority: first "PS3 model" (byte 8), second "chassis check" (byte 9), and third "target id" (byte 6). | |||
The reason of why ordering the examples this way is because | The reason of why ordering the examples this way is because "PS3 model" is known, and "Chasis Check" is the only thing left we can deduce from the examples... | ||
{| class="wikitable sortable" | {| class="wikitable sortable" | ||
! IDPS !! 6th<br />byte !! [[ | ! IDPS !! 6th<br />byte !! [[Target ID]] !! 8th<br />byte !! [[SKU Models|PS3 Model]] !! 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 168: | ||
|- | |- | ||
| <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 191: | ||
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 210: | ||
|- | |- | ||
| <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}} || - | ||
|- | |||
|} | |} | ||
= | === IDPS Regex === | ||
0{7}10{2}8[456789ACE]000[6789ABCD][01F][04][0123][[0123456789ABCDEF]{13} | |||
Based on 300+ dumps | |||
=== IDPS rms blogtext === | |||
You’re probably wondering: “What the hell is this sequence of bytes?”. This is the IDPS, a sequence of bytes which is used as a unical per console ID. This structure is relatively undocumented until now, anyway. The IDPS is contained in EID0. EID0 is on the console internal flash as the file eEID and has multiple sections. I had made a splitter application to make your life easier a long time ago. Now, EID is decrypted by metldr, and is passed over to the isolated loader, which may pass it to a self. We can see this in graf_chokolo’s original payload. The IDPS is also used in various other parts of the system which could be of interest to you, but I will not discuss those right now. | |||
The IDPS contains the console's Target ID, motherboard revision and another chassis revision. The first IDPS shown at the beginning of this article is the dummy IDPS, the one that’s used when your IDPS fails to be decrypted. That IDPS belongs to a DECR-1000A. The one below belongs to a European PS3, and the one below that belongs to a Australian/NZ PS3. | |||
Source: http://rmscrypt.wordpress.com/2011/05/16/idps-what-the-hell-is-that-thing/ | |||
Note: The Reference Tool IDPS from above is static. aim_iso uses it. Retail/3.55 doesn't have it. | |||
===Change HWID=== | |||
Theory: If you give a slim console a fat IDPS, would that console have 3.15 OtherOS functionality? | |||
I would say it would, because most likely the check is done in firmware to either en/disable that option. However, it would still require a console that can be downgraded to that version (only CECH-20xx/DYN-001, because CECH-21xx/SUR-001 use different drivers for RSX). So classic OtherOS on a CellBE 45nm/RSX 40nm would be impossible (of course you can use OtherOS++). | I would say it would, because most likely the check is done in firmware to either en/disable that option. However, it would still require a console that can be downgraded to that version (only CECH-20xx/DYN-001, because CECH-21xx/SUR-001 use different drivers for RSX). So classic OtherOS on a CellBE 45nm/RSX 40nm would be impossible (of course you can use OtherOS++). | ||
=== [Homebrew-App] PS3 Model Detection === | |||
http://www.ps3hax.net/2011/01/homebrew-app-ps3-model-detection/ | |||
<pre>Dumping PS3 Model Data: | |||
- PS3 System Target ID: 0x85 (Retail - Europe) | |||
- PS3 Motherboard Revision: 0x0B (JTP-001 Motherboard, Revision 1) | |||
- PS3 BD-Laser Revision: 0x04 (KES-400, SACD supported) | |||
Probable Model: CECH-2504A | |||
Raw Model Data: | |||
Byte 0: 0x00 | |||
Byte 1: 0x01 | |||
Byte 2: 0x00 | |||
Byte 3: 0x85 | |||
Byte 4: 0x00 | |||
Byte 5: 0x0B | |||
Byte 6: 0x00 | |||
Byte 7: 0x04</pre> | |||
'''footnotes:''' | |||
* '7th byte of IDPS' is ''not'' [[Bluray Drive]] (it was misunderstood at that time). You can see it in the example where it names incorrectly a [[CECH-25xx]] as Super Audio CD compatible with a [[KES-400]] laserslide (which in real life has either [[KES-460A]] or [[KES-470A]] without daughterboard (swap can be done without remarry). | |||
* also, it named bytes 0-2 "Byte 0", byte 3 "Byte 1", byte 4 "Byte 2", byte 5 "Byte 3", byte 6 "Byte 4", byte 7 "Byte 5", byte 8 "Byte 6", byte 9 "Byte 7" etc. | |||
=== [Homebrew-App] IDPS Viewer === | |||
http://www.tortuga-cove.com/hacking/31-ps3/8396-released-idps-viewer | |||
* Displays the IDPS | |||
* Shows Target ID | |||
* Displays Motherboard revision | |||
* Save <abbr title="(NAND @ 0x80870 / NOR @ 0x2F070)">IDPS</abbr> (16 bytes from EID) in dev_hdd0/IDPS.bin file | |||
=== Structure === | |||
00 00 00 01 <- magic<br> | |||
00 89 <- Product Code<br> | |||
00 0B <- Product Sub Code<br> | |||
14 <- chassis check<br> | |||
00 <- unk0, FF in the dummy IDPS<br> | |||
EF DD <- unk1, FF FF in the dummy IDPS<br> | |||
CA 25 <- unk2<br> | |||
52 66 <- unk3<br> | |||
===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?<br /> | |||
answer: according to the analysis of many different models of PSP, PS3 and PS3, 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...<br /> | |||
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<br /> | |||
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) ? | |||
* 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 ? | |||
===PSP FallBack IDPS=== | |||
<pre>00000001008100010C4000B10E696978</pre> | |||
Found into the emulator_drm.sprx (iso self inside) | |||
===IDPS Generation on PSP=== | |||
* some PSP JigKick files contain information on how to (re)generate idstorage leaves | |||
* DespertarDelCementerio v7 also contains information about idstorage (re)generation. | |||
* the most significant module used by DCv7 used to do this is idsregeneration.prx<br /> | |||
(see DCv7 src code https://github.com/mathieulh/Despertar-Del-Cementerio/tree/master/idsregeneration). | |||
* you can see a plethora of "templates" which are used for the generation of the idstorage sections. | |||
* the idstorage regeneration requires 2, probably more parameters -> Region, MAC Address, and likely a timestamp of sorts. | |||
* on ps3 the generation method wasn't found on the JigKick firmware files (and selfs). however, it seems that factory still does this, but by accessing a server, so the information cannot be deduced anymore unless there's access to the server. | |||
* together with the idps (called PSID on PSP), the openPSID is also generated on PSP (written to IdStorage). | |||
* there are 12 sections on PSP, unlike the 11 ones on PS3 EID0. | |||
=== IDPS bytes 7-8 (Product Sub Code) and relationship with minimun firmware version === | |||
*Read the talk [http://www.psx-place.com/threads/where-is-stored-the-minimum-version-given-by-minverchk-pup.19393/page-3#post-134263 here]. | |||
*This table was originated from [[TemplateTest#Generic Tables]]. Sadly there is not enough info in wiki yet to know accurately which motherboard belongs to every PS3 superslim model. For more info about motherboard models see:[[Motherboard Revisions]]. | |||
*The PS3 model type value inside the superslim tables on [[SKU Models]] seems to be wrong and outdated !!! (but dont change it yet, lets take some time to review this before doing a change so important in wiki) | |||
{| border="1" cellspacing="0" cellpadding="5" border="#999" class="wikitable" style="border:1px solid #999; border-collapse: collapse; text-align:center; font-size:x-small;" | |||
|+ IDPS tests | |||
! rowspan="2" | [[SKU_Models|PS3 Model]] !! rowspan="2" | [[Motherboard_Revisions|Mother Board]] !! rowspan="2" | PS3 model type<br>(IDPS bytes 7 & 8) !! colspan="4" | Minimal firmware reported by minverchk.pup when changing IDPS bytes 7 & 8<br>in EID0 (spoofing LV2 has no influences) | |||
|- | |||
! CECHC04 4.82 !! CECHP04 4.82 !! CECH-2004B 3.55 !! CECH-2004B 4.82 | |||
|- | |||
! [[CECHAxx]] || rowspan="2" | [[COK-00x#COK-001|COK-001]] | |||
| 0x0001 || 1.00 || {{cellcolors|#eeee88}} 1.97 (mismatch) || {{cellcolors|#eeee88}} 1.97 (mismatch) || {{cellcolors|#eeee88}} 1.97 (mismatch) | |||
|- | |||
! [[CECHBxx]] | |||
| 0x0002 || 1.00 || {{cellcolors|#eeee88}} 1.97 (mismatch) || {{cellcolors|#eeee88}} 1.97 (mismatch) || {{cellcolors|#eeee88}} 1.97 (mismatch) | |||
|- | |||
! [[CECHCxx]] || rowspan="2" | [[COK-00x#COK-002|COK-002]] | |||
| 0x0003 || {{cellcolors|#8888ee}} 1.00 (original) || {{cellcolors|#eeee88}} 1.97 (mismatch) || {{cellcolors|#eeee88}} 1.97 (mismatch) || {{cellcolors|#eeee88}} 1.97 (mismatch) | |||
|- | |||
! [[CECHExx]] | |||
| 0x0004 || 1.00 || {{cellcolors|#eeee88}} 1.97 (mismatch) || {{cellcolors|#eeee88}} 1.97 (mismatch) || {{cellcolors|#eeee88}} 1.97 (mismatch) | |||
|- | |||
! [[CECHGxx]] || [[SEM-00x|SEM-001]] | |||
| 0x0005 || 1.90 || {{cellcolors|#eeee88}} 1.97 (mismatch) || {{cellcolors|#eeee88}} 1.97 (mismatch) || {{cellcolors|#eeee88}} 1.97 (mismatch) | |||
|- | |||
| colspan="7" {{cellcolors|lightblue}} | |||
|- | |||
! [[CECHHxx]] || [[DIA-00x#DIA-001|DIA-001]] | |||
| 0x0006 || 1.97 || 1.97 || 1.97 || 1.97 | |||
|- | |||
! [[CECHJxx]] || rowspan="2" | [[DIA-00x#DIA-002|DIA-002]] | |||
| rowspan="2" | 0x0007 || rowspan="2" | 2.16 || rowspan="2" | 2.16 || rowspan="2" | 2.16 || rowspan="2" | 2.16 | |||
|- | |||
! [[CECHKxx]] | |||
|- | |||
! [[CECHLxx]] || rowspan="4" | [[VER-00x|VER-001]] | |||
| rowspan="4" | 0x0008 || rowspan="4" | 2.45 || rowspan="4" {{cellcolors|#8888ee}} 2.45 (original) || rowspan="4" | 2.45 || rowspan="4" | 2.45 | |||
|- | |||
! [[CECHMxx]] | |||
|- | |||
! [[CECHPxx]] | |||
|- | |||
! [[CECHQxx]] | |||
|- | |||
| colspan="7" {{cellcolors|lightblue}} | |||
|- | |||
! [[CECH-20xx]]A/B || [[DYN-00x|DYN-001]] | |||
| 0x0009 || 2.70 || 2.70 || {{cellcolors|#8888ee}} 2.70 (original) || {{cellcolors|#8888ee}} 2.70 (original) | |||
|- | |||
! [[CECH-21xx]]A/B || [[SUR-00x|SUR-001]] | |||
| 0x000A || 3.20 || 3.20 || 3.20 || 3.20 | |||
|- | |||
! rowspan="2" | [[CECH-25xx]]A/B || [[JTP-00x|JTP-001]] | |||
| rowspan="2" | 0x000B || rowspan="2" | 3.40 || rowspan="2" | 3.40 || rowspan="2" | 3.40 || rowspan="2" | 3.40 | |||
|- | |||
! [[JSD-00x|JSD-001]] | |||
|- | |||
! [[CECH-30xx]]A/B || [[KTE-00x|KTE-001]] | |||
| 0x000C || 3.65 || 3.65 || {{cellcolors|#88ee88}} 3.55 (actual) || 3.65 | |||
|- | |||
| colspan="7" {{cellcolors|lightblue}} | |||
|- | |||
! [[CECH-40xx]]B/C v1 || ? | |||
| 0x000D || 4.15 || 4.15 || {{cellcolors|#88ee88}} 3.55 (actual) || 4.15 | |||
|- | |||
! [[CECH-40xx]]A v1 || ? | |||
| 0x000E || 4.20 || 4.20 || {{cellcolors|#88ee88}} 3.55 (actual) || 4.20 | |||
|- | |||
! [[CECH-40xx]]B/C v2 || ? | |||
| 0x000F || 4.20 || 4.20 || {{cellcolors|#88ee88}} 3.55 (actual) || 4.20 | |||
|- | |||
! [[CECH-40xx]]A v2 || ? | |||
| 0x0010 || 4.20 || 4.20 || {{cellcolors|#88ee88}} 3.55 (actual) || 4.20 | |||
|- | |||
! [[CECH-42xx]]B/C || ? | |||
| 0x0011 || 4.40 || 4.40 || {{cellcolors|#88ee88}} 3.55 (actual) || 4.40 | |||
|- | |||
! [[CECH-42xx]]A || ? | |||
| 0x0012 || 4.40 || 4.40 || {{cellcolors|#88ee88}} 3.55 (actual) || 4.40 | |||
|- | |||
! [[CECH-43xx]]B/C || ? | |||
| 0x0013 || 4.50 || 4.50 || {{cellcolors|#88ee88}} 3.55 (actual) || 4.50 | |||
|- | |||
! [[CECH-43xx]]A || ? | |||
| 0x0014 || 4.50 || 4.50 || {{cellcolors|#88ee88}} 3.55 (actual) || 4.50 | |||
|- | |||
! N/A || N/A | |||
| 0x0000<br>0x0015 to 0x0017<br>0x001F<br>0x00FF || {{cellcolors|#88ee88}} 4.82 (actual) || {{cellcolors|#88ee88}} 4.82 (actual) || {{cellcolors|#88ee88}} 3.55 (actual) || {{cellcolors|#88ee88}} 4.82 (actual) | |||
|- | |||
! N/A || N/A | |||
| 0x0018 to 0x001E<br>0x0020 to 0x008E<br>0x0091 to 0xAFFF<br>0xFFFF || untested || untested || untested || {{cellcolors|#88ee88}} 4.82 (actual) | |||
|- | |||
! N/A (arcade, unknown model) || N/A | |||
| 0x008F<br>0x0090 || untested || {{cellcolors|#ee8888}} 4.31 || untested || {{cellcolors|#ee8888}} 4.31 | |||
|- | |||
|} |