User talk:Masterzorag: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
 
(41 intermediate revisions by 3 users not shown)
Line 106: Line 106:
00000400
00000400
</pre>
</pre>
Another test on a different, not hacked PS3, running GameOS 4.11
ST96812AS is a 117210240 sectors of 512 bytes each, original PS3 60Gb HDD: here I've limited to 1/10, but I can force every size.
[[File:Smaller hdd.jpg|200px|thumb|6Gb]] [[File:Smaller hdd 2.jpg|200px|thumb|60Gb]]
GameOS (must) accept it.<br />


=ps3vuart-tools=
=ps3vuart-tools=
Line 125: Line 131:


=UPL.xml.pkg=
=UPL.xml.pkg=
Into
<pre>
<pre>
tar -t -f update_files.tar
tar -t -f update_files.tar
Line 170: Line 175:
002 00000300 0000016B 03  03    [YES]  0C  [YES]    12  13 [YES]
002 00000300 0000016B 03  03    [YES]  0C  [YES]    12  13 [YES]
[*] SCE File Keys: n 14
[*] SCE File Keys: n 14
</pre>Signature Input Length 0x0000000000000250<pre>
00000020  25 b7 b7 25 8f 96 e9 7c  29 ee 2d 51 51 04 f4 da  |%..%...|).-QQ...|
00000030  29 ea 39 dc 81 1a 66 65  fd 5d 22 46 17 e5 9b ee  |).9...fe.]"F....|
00000040  64 e6 cd 3f bf de e7 17  ed 2d 00 f3 6f 03 59 88  |d..?.....-..o.Y.|
00000050  78 b9 6e bc 14 21 a0 99  19 1d 64 23 fb 49 8e c6  |x.n..!....d#.I..|
00000060  da 4d 44 bf 40 ac 25 16  98 58 6f ba bc dc 78 d0  |.MD.@.%..Xo...x.|
00000070  f9 f5 eb 7f 4e 02 c6 c8  41 ab b9 25 51 08 fb 98  |....N...A..%Q...|
00000080  87 e4 6b 15 b2 8e fc 30  11 a3 a3 3c 63 e7 e0 0a  |..k....0...<c...|
00000090  d6 0a 5c 0f 35 5a 14 ed  63 49 ec 7e 4c b2 bb be  |..\.5Z..cI.~L...|
000000a0  ce aa 0e 0f c4 30 e5 e2  fd d0 4d 7e 6f 49 c8 b7  |.....0....M~oI..|
000000b0  1d 93 d1 bb 8e 59 73 cd  35 e3 08 31 e7 14 96 64  |.....Ys.5..1...d|
000000c0  da da 2a 1d 6a e5 7d b9  19 0c ef d2 20 57 cc bb  |..*.j.}..... W..|
000000d0  70 22 4a 47 f9 11 ec dc  96 dd e9 47 aa 06 56 18  |p"JG.......G..V.|
000000e0  39 b5 98 cd 36 08 33 3f  fa e7 fd fc bf 61 a1 f0  |9...6.3?.....a..|
000000f0  f4 d4 b7 f5 14 7b 37 d2  9f aa 16 9c de f2 64 79  |.....{7.......dy|
00000100  e9 e0 a8 e9 6d 07 f7 fa  da 61 8d ca 97 2c f9 10  |....m....a...,..|
00000110  0c 2f af bc 96 f8 00 2e  47 08 5d 15 53 7f 97 c8  |./......G.].S...|
00000120  58 a5 66 39 85 62 1d 1d  0b fc 8a 43 e1 d5 dc 08  |X.f9.b.....C....|
00000130  b5 67 aa 56 74 3b d7 fb  3a 6e 93 9b d5 eb c0 90  |.g.Vt;..:n......|
00000140  ae 97 3f af 33 4b 92 87  13 fe 8f 3c 61 28 9b 91  |..?.3K.....<a(..|
00000150  14 f7 13 fd 20 d3 b4 3a  91 d5 9e bc 9a 99 da d5  |.... ..:........|
00000160  fd 6f 89 55 ef ab f4 8b  5a 5b 79 8d e6 4f 0c 51  |.o.U....Z[y..O.Q|
00000170  6f be 61 1a 8d b4 45 f7  ab c9 d7 69 35 68 0e 57  |o.a...E....i5h.W|
00000180  83 2d b9 6c b4 45 a2 31  5b 0a 70 c9 4e 09 48 a1  |.-.l.E.1[.p.N.H.|
00000190  7c b4 b8 93 91 6c f4 ad  ec 5c 4a f3 66 5b 18 94  ||....l...\J.f[..|
000001a0  bb b5 1a 59 4f 90 fe c3  eb 10 fe 57 22 45 51 e7  |...YO......W"EQ.|
000001b0  1c 2e 55 87 6a d8 0b 0f  80 40 a7 aa 6f cc 47 0c  |[email protected].|
000001c0  ff 41 b4 6a bf 08 94 5b  bd 32 60 12 d2 f3 25 c0  |.A.j...[.2`...%.|
000001d0  62 29 c3 76 78 f0 dc b3  85 d7 91 98 36 24 f6 f6  |b).vx.......6$..|
000001e0  33 3a 35 b0 e9 d1 b6 05  31 65 7a f5 05 2d f2 3c  |3:5.....1ez..-.<|
000001f0  a5 90 de c9 74 94 e1 47  96 ec b8 e2 a7 29 18 ba  |....t..G.....)..|
00000200  12 a8 54 81 98 3c 0a e2  b2 42 4c 1d 75 03 c3 86  |..T..<...BL.u...|
00000210  29 27 34 9c 83 d9 01 34  8e c6 ca e7 a6 c0 c8 ef  |)'4....4........|
00000220  25 b2 43 8e e8 b1 77 5c  c0 e8 02 44 6a 92 f1 17  |%.C...w\...Dj...|
00000230  7c 7c c4 a1 1e 75 13 42  99 8c c2 7d 7b 85 56 87  |||...u.B...}{.V.|
00000240  e2 b3 0e e3 05 bf 19 7d  70 83 d5 c2 00 e4 5b 47  |.......}p.....[G|
00000250  1e af b4 96 f3 9e 3b ec  c4 85 29 50 13 79 55 f1  |......;...)P.yU.|
00000260  ab bb a2 c2 12 f8 d0 60  1d 8a 08 16 8f a5 bd 08  |.......`........|
00000270  ed b6 f0 a7 11 21 92 b5  ce 11 dd 13 4e 80 60 3d  |.....!......N.`=|
</pre>
hexdump -C UPL.xml.pkg.spkg_hdr.1
<pre>
00000020  7b be 81 a6 f2 8d 41 3e  cf 59 63 bc 22 03 54 44  |{.....A>.Yc.".TD|
00000030  3d 17 d9 a3 ee 72 21 c4  38 21 fe 81 79 52 b2 29  |=....r!.8!..yR.)|
00000040  a9 dc ea 8c 91 5b 45 81  3d ee f3 e0 04 bd 2e 74  |.....[E.=......t|
00000050  d5 1e 11 23 86 f2 29 a2  df f1 64 94 a0 1f 7d de  |...#..)...d...}.|
00000060  68 4e 60 50 85 ea 64 bd  c8 df 6d 94 f1 db ff 65  |hN`P..d...m....e|
00000070  31 e7 62 09 f5 dc 63 d4  53 3c 25 06 f6 60 64 19  |1.b...c.S<%..`d.|
00000080  40 89 05 1e e2 30 5e 10  9d ec 0f ad 04 6d a5 ef  |@....0^......m..|
00000090  1b 90 10 8f 8e d8 a7 04  8f 9f a5 19 d5 89 d7 c3  |................|
000000a0  07 92 19 52 b7 1e 61 cb  af 93 71 b7 fd 55 02 67  |...R..a...q..U.g|
000000b0  97 98 0f 72 0c 20 e9 45  11 78 9d fd d7 1b 54 68  |...r. .E.x....Th|
000000c0  d3 26 91 58 9e 02 5f dc  72 67 3b 16 9c 84 ce 96  |.&.X.._.rg;.....|
000000d0  70 d8 af d8 72 79 a0 f6  5a 9d 12 69 49 aa 6a 4a  |p...ry..Z..iI.jJ|
000000e0  39 9a 8c 21 b0 d0 34 08  46 52 0a 62 07 cc 9b dd  |9..!..4.FR.b....|
000000f0  de 39 62 85 07 19 1a 40  67 14 c8 60 26 bf 6a 90  |.9b....@g..`&.j.|
00000100  8d 85 4a 12 d4 56 69 b5  01 a1 32 ad 3e 23 ae 36  |..J..Vi...2.>#.6|
00000110  41 fc f4 c2 f7 0e 64 88  f1 51 0a 6f af 87 e5 4f  |A.....d..Q.o...O|
00000120  8a 33 f7 d8 3d 11 76 98  e3 72 ac fb 3a 12 64 6d  |.3..=.v..r..:.dm|
00000130  fc 06 06 9d 69 c1 1d 50  9c cb 50 72 a4 6e ff d1  |....i..P..Pr.n..|
00000140  1e cc 14 13 d4 19 c9 15  f0 8c ad 35 19 46 e6 aa  |...........5.F..|
00000150  bb e0 0f d1 9a b7 5b 4f  98 1f f0 28 89 ab 31 db  |......[O...(..1.|
00000160  0a ef e2 3a 14 a6 7d 3b  2f 9f 9d d1 30 9c aa a9  |...:..};/...0...|
00000170  f3 6f 48 fb 18 93 82 bc  6c 57 e6 3d 93 db 8d 76  |.oH.....lW.=...v|
00000180  4a e0 01 1a 5c dd d7 74  08 54 03 d5 83 75 db 60  |J...\..t.T...u.`|
00000190  4a b8 21 3d 8c 83 e2 b0  ac 5d 7e e5 df 4f 27 8b  |J.!=.....]~..O'.|
000001a0  62 e1 7d 38 14 f5 1b 1c  bb 90 8a 39 15 45 33 4f  |b.}8.......9.E3O|
000001b0  a2 d7 e2 24 55 12 f2 27  71 a6 ee 55 aa b2 01 d1  |...$U..'q..U....|
000001c0  4c ba 77 82 41 17 05 da  0f d7 06 06 20 1c 96 eb  |L.w.A....... ...|
000001d0  10 e5 60 46 f6 02 5a 40  2a 48 07 6a ce 0a fd 3b  |..`F..Z@*H.j...;|
000001e0  06 e4 99 dc 4e b4 7f f8  08 94 7d b3 0a 33 04 2d  |....N.....}..3.-|
000001f0  e8 20 0f 31 9a c2 9c b3  b1 9a ad 0d 82 5d bd 43  |. .1.........].C|
00000200  d7 41 90 2c 33 aa 57 5b  01 97 f9 8b 1b 80 2b f4  |.A.,3.W[......+.|
00000210  03 21 31 58 16 0a ba a0  bb 62 20 d4 5e c6 a6 78  |.!1X.....b .^..x|
00000220  69 22 71 e7 b0 af 76 c8  c0 7e 6d e1 cc 87 7d 67  |i"q...v..~m...}g|
00000230  7a fe 9d 24 18 0e 16 90  c2 b1 79 49 28 9b 04 9d  |z..$......yI(...|
00000240  18 0d fd 51 93 c0 60 83  59 e2 9c 5e 80 1a cd ae  |...Q..`.Y..^....|
00000250  1a d4 d3 41 0a 74 fd 79  c0 be 15 0d 1c 0a e0 15  |...A.t.y........|
00000260  fe d6 14 69 9a 16 41 2b  d5 4d 32 f3 69 14 48 6f  |...i..A+.M2.i.Ho|
00000270  49 81 92 4c e2 04 ec 05  8b d8 a0 88 6e 19 50 ea  |I..L........n.P.|
</pre>
</pre>
hexdump -C UPL.xml.pkg
hexdump -C UPL.xml.pkg
<pre>
<pre>
00000280  00 00 00 03 00 00 00 04  00 00 00 00 00 00 00 0a  |................|
00000280  00 00 00 03 00 00 00 04  00 00 00 00 00 00 00 0a  |................|
00000290  20 14 06 19 01 15 45 00  00 00 00 00 00 00 0b 1d  | .....E.........|
00000290  20 14 06 19 01 15 45 00  00 00 00 00 00 00 0b 1d  | .....E.........|
Line 269: Line 189:


We got info0 + info1, 64bytes each
We got info0 + info1, 64bytes each
content is 2845bytes, total is data lenght 2973
content is 2845bytes, total is data length 2973
info0, info1 are not encrypted
info0, info1 are not encrypted
</pre>
</pre>


UPL.xml.pkg is decrypted using pkg keyset [0x0000 03.55], UPL.xml.pkg.spkg_hdr.1 is decrypted using spkg keyset for > 3.55: only Metadata Info changes.
UPL.xml.pkg is decrypted using pkg keyset [0x0000 03.55], UPL.xml.pkg.spkg_hdr.1 is decrypted using spkg keyset for > 3.55: only Metadata Info and Signature changes.
<pre>
 
[*] Metadata Info:                                              [*] Metadata Info:
Key 87 EE 46 44 60 DA DA EA 49 74 58 F9 02 1D 6D 11            Key E0 12 4D EC 48 3A 52 0E BE 4C C1 4A A6 E3 20 D8
IV  F4 9F 43 D8 D0 6A F0 FC 33 AF 5E 6E CF 2F 30 1E            IV  93 92 A9 38 8D B7 2B 8F 43 0E 0B 97 3D 45 9A 74
</pre>
I think that on 3.55 all .spkg_hdr.1 files are not involved in updating, on 3.56 all of them are used as in overlayfs, so all .spkg_hdr.1 files are readed as metadata headers, decrypted by newer spkg keyset to get the same SCE keys to get rest of data decrypted.
I think that on 3.55 all .spkg_hdr.1 files are not involved in updating, on 3.56 all of them are used as in overlayfs, so all .spkg_hdr.1 files are readed as metadata headers, decrypted by newer spkg keyset to get the same SCE keys to get rest of data decrypted.
*https://www.certicom.com/index.php/20-elliptic-curve-groups-over-real-numbers
*http://csrc.nist.gov/groups/ST/key_mgmt/documents/June09_Presentations/rene.struik.KMWJune09_5Min.pdf
*http://cacr.uwaterloo.ca/techreports/2005/cacr2005-28.pdf
*http://stackoverflow.com/questions/20266368/ecdsa-signature-size-too-long
=.spkg_hdr.1 decryption=
Verifing decryption of signed pkg headers with openssl:
*strip metadata info
# dd if=CORE_OS_PACKAGE.pkg.spkg_hdr.1 of=metainfo.crypt skip=32 count=64 bs=1
64+0 records in
64+0 records out
64 bytes (64 B) copied, 0.0021009 s, 30.5 kB/s
# hexdump -C metainfo.crypt
00000000  d7 f9 82 9e 75 0a 3f 20  8b 6f e7 41 b1 bb 52 15  |....u.? .o.A..R.|
00000010  e1 8f d2 86 43 b5 4f 56  4c 42 a0 10 e1 1a 25 38  |....C.OVLB....%8|
00000020  9c 28 c7 fd 38 31 24 3b  1b 2b 9f 3f dc 72 4f c4  |.(..81$;.+.?.rO.|
00000030  95 34 b8 0a af 25 a1 05  b6 8f ce 2c 88 e9 2b 7b  |.4...%.....,..+{|
*verify metadata info decryption with standard tool
# openssl enc -d -aes-256-cbc -in metainfo.crypt -K erk -iv riv | hexdump -C
00000000  7c f2 9a 4b 96 de 5f 75  a1 32 87 c0 42 ec 8f cf  ||..K.._u.2..B...|  Key
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  6f 85 6a 60 2a 8d b4 3f  2a 81 1b 1a 9c a3 02 f6  |o.j`*..?*.......|  IV
00000030
*strip rest of crypted metadata
# dd if=CORE_OS_PACKAGE.pkg.spkg_hdr.1 of=metarest.crypt skip=96 bs=1
544+0 records in
544+0 records out
544 bytes (544 B) copied, 0.00626423 s, 86.8 kB/s
*decrypt rest of metadata
# openssl enc -d -aes-128-ctr -in metarest.crypt -K Key -iv IV | hexdump -C
00000000  00 00 00 00 00 00 <span style="background-color:#B5E61D;">02 50</span>  00 00 00 01 00 00 00 <span style="background-color:#fff200;">03</span>  |.......P........| mh
00000010  00 00 00 <span style="background-color:#808000;">14</span> 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 02 80  00 00 00 00 00 00 00 40  |...............@| m_sh<span style="background-color:#fff200;">0</span>
00000030  00 00 00 01 00 00 00 01  00 00 00 02 00 00 00 00  |................|
00000040  00 00 00 01 ff ff ff <span style="background-color:#000000; color:#ffffff;">ff</span>  ff ff ff <span style="background-color:#000000; color:#ffffff;">ff</span> 00 00 00 01  |................|
00000050  00 00 00 00 00 00 02 c0  00 00 00 00 00 00 00 40  |...............@| m_sh<span style="background-color:#fff200;">1</span>
00000060  00 00 00 02 00 00 00 02  00 00 00 02 00 00 00 06  |................|
00000070  00 00 00 01 ff ff ff <span style="background-color:#000000; color:#ffffff;">ff</span>  ff ff ff <span style="background-color:#000000; color:#ffffff;">ff</span> 00 00 00 01  |................|
00000080  00 00 00 00 00 00 03 00  00 00 00 00 00 5a 01 74  |.............Z.t| m_sh<span style="background-color:#fff200;">2</span>
00000090  00 00 00 03 00 00 00 03  00 00 00 02 00 00 00 0c  |................|
000000a0  00 00 00 03 00 00 00 <span style="background-color:#ff0000;">12</span>  00 00 00 <span style="background-color:#d52bd0;">13</span> 00 00 00 02  |................|
<span style="background-color:#808000;">0</span>00000b0  fd 5e fe 3f a0 42 fe 31  d6 61 83 26 98 07 ce e8  |.^.?.B.1.a.&....| h0 0x20, HMAC-SHA1
<span style="background-color:#808000;">0</span>00000c0  09 a7 65 7a 00 00 00 00  00 00 00 00 00 00 00 00  |..ez............|
<span style="background-color:#808000;">0</span>00000d0  6a 49 08 b2 87 ee 02 65  8c 73 5a 4c 54 f8 bf 5d  |jI.....e.sZLT..]| k0 0x40, HMAC key
<span style="background-color:#808000;">0</span>00000e0  b6 3a d4 ef d3 94 74 f5  f3 a3 f2 ad af 1c 45 4e  |.:....t.......EN|
<span style="background-color:#808000;">0</span>00000f0  08 aa 2b 61 fb 91 52 9d  69 a8 44 b0 a0 dd 39 1c  |..+a..R.i.D...9.|
<span style="background-color:#808000;">0</span>0000100  bc 4d a0 51 ed f5 30 16  d1 35 8c b1 d1 09 54 d0  |.M.Q..0..5....T.|
<span style="background-color:#808000;">0</span>0000110  60 32 ff 1c 3d 1a 9d 03  61 28 d8 ad 1f dc 34 57  |`2..=...a(....4W| h1 0x20, HMAC-SHA1
<span style="background-color:#808000;">0</span>0000120  05 2a 1e f6 00 00 00 00  00 00 00 00 00 00 00 00  |.*..............|
<span style="background-color:#808000;">0</span>0000130  6a 49 08 b2 87 ee 02 65  8c 73 5a 4c 54 f8 bf 5d  |jI.....e.sZLT..]| k1 0x40, HMAC key
<span style="background-color:#808000;">0</span>0000140  b6 3a d4 ef d3 94 74 f5  f3 a3 f2 ad af 1c 45 4e  |.:....t.......EN|
<span style="background-color:#808000;">0</span>0000150  08 aa 2b 61 fb 91 52 9d  69 a8 44 b0 a0 dd 39 1c  |..+a..R.i.D...9.|
<span style="background-color:#808000;">0</span>0000160  bc 4d a0 51 ed f5 30 16  d1 35 8c b1 d1 09 54 d0  |.M.Q..0..5....T.|
<span style="background-color:#808000;">0</span>0000170  3c 37 73 07 73 d5 69 69  52 67 97 3b e9 20 70 a9  |<7s.s.iiRg.;. p.| h2 0x20, HMAC-SHA1
<span style="background-color:#808000;">0</span>0000180  53 a7 11 6d 00 00 00 00  00 00 00 00 00 00 00 00  |S..m............|
<span style="background-color:#808000;">0</span>0000190  6a 49 08 b2 87 ee 02 65  8c 73 5a 4c 54 f8 bf 5d  |jI.....e.sZLT..]| k2 0x40, HMAC key
<span style="background-color:#808000;">0</span>00001a0  b6 3a d4 ef d3 94 74 f5  f3 a3 f2 ad af 1c 45 4e  |.:....t.......EN|
<span style="background-color:#808000;">0</span>00001b0  08 aa 2b 61 fb 91 52 9d  69 a8 44 b0 a0 dd 39 1c  |..+a..R.i.D...9.|
<span style="background-color:#808000;">0</span>00001c0  bc 4d a0 51 ed f5 30 16  d1 35 8c b1 d1 09 54 d0  |.M.Q..0..5....T.|
<span style="background-color:#808000;">0</span>00001d0  <span style="background-color:#ff0000;">35 53 b4 b5 44 28 fe 09  5a 04 e5 38 e8 38 f4 a6</span>  |5S..D(..Z..8.8..| Key
<span style="background-color:#808000;">0</span>00001e0  <span style="background-color:#d52bd0;">5d 24 fa b1 e0 55 f4 58  15 22 c2 73 00 00 00 00</span>  |]$...U.X.".s....| IV
<span style="background-color:#B5E61D;">0</span>00001f0  00 c9 57 08 f1 6f e6 75  39 6f 2a 12 51 48 5f 8c  |..W..o.u9o*.QH_.| r, s
00000200  97 53 e3 e2 a7 00 b7 47  fa c2 0b 01 2b df 5a 34  |.S.....G....+.Z4|
00000210  f7 a8 d0 21 d2 f8 94 4b  6e 30 00 00 00 00 00 00  |...!...Kn0......|
=verify ecdsa signatures=
*get signature
*join sceh + decrypted metadata info + decrypted rest of metadata until signature
# ls -l metadata.bin
-rw-r--r-- 1 root root 592 Jul 11  metadata.bin
*compute digest of the whole decrypted metadata until signature
# sha1sum metadata.bin
70942107d35df85091bf4949d7fa46421e27d056  metadata.bin
*verify signature against computed digest
ecdsa_verify(digest, r, s) == 1
=collecting spkg_hdr.1 signatures=
I've started collecting into an SQLite database all publicily available ECDSA signatures from spkg.hdr.1 files, to research.<br />
Note that here I've named 3.57 the 3.56#2 one! I know, 3.57 doesn't exist.
*get spkg_hdr.tar file from PS3UPDAT.PUP, here I've just added an argument to pupunpack to extract only the needed section:
ps3tools # ./pupunpack ../PS3\ 3.56\ OFW/PS3UPDAT.PUP ../PS3\ 3.56\ OFW/unpacked 7
sections:    9
hdr size:    00000000_00000290
data size:  00000000_0b0f3d3d
header hmac: OK
extracting only section 7
section 7: unpacking spkg_hdr.tar      (00000000_00011800 bytes; hmac: OK)...
*untar spkg.hdr.1 files
# cd ../PS3\ 3.56\ OFW/unpacked/
unpacked # tar -xf spkg_hdr.tar
*strip signature data off spkg.hdr.1 files into spkg.hdr.1_sigdata files, here I've added a function to sceverify
unpacked # for file in *hdr.1; do ../../ps3tools/sceverify $file; done
...
hash:  c72f26e67e03b743a8c830a541e82bfb2e9f6c19
r:      0056af2dad5647288c75e76dc92ed875de86876d7e
s:      00d7de25130de0f6dc0602e590b42bc5f21ab2a3e6
Signature: ecdsa_verify(hash, r, s) : OK
Collecting digest + signature for file: UPL.xml.pkg.spkg_hdr.1
exported: UPL.xml.pkg.spkg_hdr.1_sigdata, recheck ecdsa signature: OK
unpacked # for file in *1_sigdata; do ls -h $file; done
BDIT_FIRMWARE_PACKAGE.pkg.spkg_hdr.1_sigdata
BDPT_FIRMWARE_PACKAGE_301R.pkg.spkg_hdr.1_sigdata
BDPT_FIRMWARE_PACKAGE_302R.pkg.spkg_hdr.1_sigdata
...
*collect sigdata into an sqlite database, I've coded an app to do the job:
unpacked # for file in *1_sigdata; do ../../ps3tools/collector 1 $file 3.56; done
Connection successful
BDIT_FIRMWARE_PACKAGE.pkg.spkg_hdr.1_sigdata
BDIT_FIRMWARE_PACKAGE.pkg.spkg_hdr.1 3.56
dig = 749e7ba6fba9ff4c8ad83d1fd62feec4ea9ad3f2
sig = 00574c57e9ceaac1285b3f6d7b06feaa7daa180edf002b0cc8548f42c523afa39c6984e4b67b9639afbc
...
BDPT_FIRMWARE_PACKAGE_301R.pkg.spkg_hdr.1_sigdata
BDPT_FIRMWARE_PACKAGE_301R.pkg.spkg_hdr.1 3.56
dig = cee76eb85bf899952acc8723ef3e35fdc9b0da23
sig = 0001bd4af80d5e8f190baea58e6613e5672d1c29a8000dcfad27f4edcef9f0b9f000759d89ebb050d871
...
*since collector can also export to STDOUT, we can already filter, sort...
# ./ps3tools/collector 2 | head -12
Connection successful
Export to STDOUT
BDIT_FIRMWARE_PACKAGE.pkg.spkg_hdr.1 3.57
dig = fcde1eaf97e24c9d0a5fe2af312e5b1ce1e6ab14
r = 003798ace6c2097c02e2f9214bfc2bbf5c7bd347ae
s = 002b1a77b56e0995f80761fa779db5b09e269ebf96
BDPT_FIRMWARE_PACKAGE_301R.pkg.spkg_hdr.1 3.57
dig = 0d953e1f78195b960a145a0c20753269a2352204
r = 00b2a103abbf09db35eb5a2580554446255fee4504
s = 0061292680dccc79e92373f002e669cf238c520a70
# ./ps3tools/collector 2 | grep "r =" | sort | head
r = 000119f11cc9076d039c1c0a625afe3dc5f9e38af9
r = 000171cfd17643b35e3f7a9fa1d64398413c35a949
r = 0001bd4af80d5e8f190baea58e6613e5672d1c29a8
r = 00023c6b278121e57ae6c836c0a188344dc676f9b7
r = 0003c42810e1b9f3cc4a93e71b101359116c06e68a
r = 000418380d9e2d2f4a11e88bcb42af8f17b042cd31
r = 00049a30c5e2d38ad19765e6c02e94377bf93444f9
r = 0004fa6eb1641706c20a14ede5dc0fe497b01f4dee
r = 00051b73b3eea4904f899ffc10f445ee080f2f3912
r = 0005639f0f3dd5585ed5e64df0421b274e842a2a2f
*check for the same r (they just failed in this, but watch how is simple!)
# ./ps3tools/collector 2 | grep "r =" | sort | wc -l
298 lines
# ./ps3tools/collector 2 | grep "r =" | sort | uniq | wc -l
298 lines (no same r!)
*database can be accessed via SQL query too, it contains binary blobs
# sqlite3 /tmp/collector_db.sqlite3
SQLite version 3.8.5 2014-06-04 14:06:34
Enter ".help" for usage hints.
sqlite> SELECT HEX(dig) FROM spkg_hdr WHERE name = "SYS_CON_FIRMWARE_01010303.pkg.spkg_hdr.1 3.70";
7215D87859A31889F5FB931BDED988A95AF6A38E
*we can just use a browser plugin to deal with database
[[File:Collector.png|200px|thumb|spkg_hdr SQLite table]]
=questions=
'''z'''<br />
why you collect these hashes and signatures?<br />
Now if 2 digests are different then R signatures would be diffenet too. Pseudo Random number (that used to creating signature) now is F(digest);<br />
If digests are same then Pseudo Random numbers are same too ->> R sigs would be same and S sigs would be same.<br />
For every digest, we have 1 and only 1 signature (R,S). If you want obtain private key, you need to find an algorithm for generating pseudo random number from the digest.<br />
<br />
'''m'''<br />
ECDSA signature is the (r, s) keypair:<br />
http://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm
*first part, r
to compute r you have to (3) select a random integer, (4) calculate the curve point first, to finally (5) take the x coordinate mod n.
*the random integer
that random integer in signature generation is equal to select the random integer in the priv/pub keypair generation.<br />
that number is the temporary or ephemeral key.<br />
for every signature the algorithm needs one random integer, that must be never reselected, else epic fail.<br />
*digest
hash function is SHA1, you know, collision resistant: we can "never" have two different messages that produces the same sha1sum, else a collision.<br />
they also uses metadata info to change the message to sign from .pkg to .spgk_hdr.1 files, else they signs the same digest with different curve. (who other noticed/know this?)
*second part, s
s is computed from the digest and the latter r.
*why
suppose that you are doing trial point multiplication (x) computing: p = k x G to guess for the correct k that had produced our public point p.<br />
instead of checking only for exactly p, the pub, now you can consider that you have some hundreds of correct/public x coordinate mod n to check/guess for.<br />
or, in other words: I can luckily select an integer that, even isn't the priv, is the ephemeral key that had produced a valid signature.<br />
what could happen if I get an ephemeral key?
*those two needs investigation
{|
| 1. "''For every digest, we have 1 and only 1 signature (R,S).''"<br />Sorry, but don't think so, because as you can have read, r comes from a random number.<br />2. "''Pseudo Random number (that used to creating signature) now is F(digest);''"<br />They can't be so idiots, since digest is ever known...<br /> || [[File:Signing with my keypair.png|100px|thumbnail]]
|}
*example of different signatures from custom keypair to test for dig: da39a3ee5e6b4b0d3255bfef95601890afd80709<br />
pub: df4222f3bff899845d203cd9373358ff7a0752f501c7f378195c0ac7e157f61e14ff231d73a0137f<br />
sig0: 008e8eaee8452d2915ef2186358079ee82a7c90d410063de8d98f012778596c14eb0df17f7464da65a02<br />
sig1: 00fdb20299e37c4a23a6cdc07ee0e91539e58ae62b00fc8ec36e79d2de33b4569f7968ea2211a4a92bef<br />
sig2: 0067af6858bf5bc2eb239dfcb997bc0c21fbaf16dc002f1c4cd4dcc5d71037d65caf05bbbccfce4f7fc1<br />
=playing on the vsh curve=
{| class="wikitable"
|-
|'''z'''<br />
So I will show for you that R = Function(digest) and what this fail is not so critical.
I was interested for edat algorithm and figured out how edats (and sdat) files are signed.<br />
It contains 2 non-randomfailed ecdsa signatures. http://www.psdevwiki.com/ps3/EDAT_files#Structure_.28Encrypted_Format.29<br />
first one is metadata signature and the second one is header signature. There are some edat files created from data files with 0 byte length, that contains metadata with 0 byte length.<br />
There are examples: original pkg links: http://is.gd/naLaxh , http://is.gd/IFtWmq it contains destiny.edat and hdd_package_key.edat , both files have metadata with 0 byte length.<br />
Hex code of the edats: http://pastie.org/private/ejoloa5qjjy8wlkezadga , http://pastie.org/private/fbr9uphpjzm0xd4gqfuyg .<br />
So Both edats have metadata digiest = DA39A3EE5E6B4B0D3255BFEF95601890AFD80709 , R = A2732E0161E20C290108FDD0B567120C42AAB3D2 , S = B894E8775AFF90A3CBB6CC08BC918C14F759D439<br />
So if digests are same then pseudo_random_numbers are same and signatures are same.<br />
Please make your conclusions.<br />
|}
{| class="wikitable"
|-
|'''m'''<br />You have already seen differences between two files, but maybe some other not. Here a png.<br />Page is telling me that at 0xB0 there is an ECDSA signature, and you are pointing out that we have the same (ECDSA) signature on two different files !?!<br />1. I see your "same signature", but how do you get "metadata digest = DA39A3EE5E6B4B0D3255BFEF95601890AFD80709" from both?<br />2. Conclusion to me are that at 0xB0 there is not an ECDSA signature, so: have you checked? Have you validated? Have you proven that r, s is the valid signature for the digest?<br />3. There is also another aspect to not forget: alignment (%16 = 0), so there is an ECDSA signature in 40 bytes? does not sound good to me...<br />4. SHA-1 produces a fixed length of 20 bytes: at wiki page I read "''0x40 QA digest, size 0x10 (seems like to be a SHA-1 hash of the non-finalized file) ... Can be ... zeroed on forged file.''" !?!<br />5. There are two ECDSA signatures on an EDAT file and only one to protect CORE_OS_PACKAGE.pkg from alteration !?!?! || [[File:EDATs diff.png|thumbnail|100px]]
|}
<br />
{| class="wikitable"
|-
|'''z'''<br />
1. metadata length = 0 bytes for both files, so digest for empty message is DA39A3EE5E6B4B0D3255BFEF95601890AFD80709.<br />
2. r,s validated and valid of course. so you can use make_npdata the newest version for validate signatures into edats. there are no mistakes, it is realy ecdsa sig.<br />
3. Both signatures has 40 bytes, first 20 bytes is R , second 20 bytes is S.<br />
4. Sony used full 20 bytes length sha1 hash for validate ECDSA signatures.<br />
5. Correct info. SCE pkg file have only header signature. edat have metadata sig and header sig.<br />
|}
{| class="wikitable"
|-
|'''m'''<br />You are right, I've verified all, as you can see in my shots.<br />I've also noticed one thing that explain something: with zeroed ECDSA signature every digest results in a valid signature!<br />Why?<br />Because the signature becomes the point at infinity!<br />That's because on signature generation when r = 0 you have to select another random integer, as 0 < rand < n! And the same applies for s.<br />But really cool stuff can happen exacly with this kind of crazyness!||[[File:EDAT signatures on vsh curve 1.png|thumbnail|100px]] || [[File:EDAT signatures on vsh curve 2.png|thumbnail|100px]]
|}
<br />
{| class="wikitable"
|-
|'''z'''<br />Im verified metadata and header signatures for both edat files. Check my screenshotes please. || [[File:Hdd_package_key.edat_ECDSA_validation.jpg|thumbnail|100px]] || [[File:Destiny.edat_ECDSA_validation.jpg|thumbnail|100px]]
|}
{| class="wikitable"
|-
|'''m'''<br />
Checked your data, validated the same:
r =    00a2732e0161e20c290108fdd0b567120c42aab3d2
s =    00b894e8775aff90a3cbb6cc08bc918c14f759d439
hash =  da39a3ee5e6b4b0d3255bfef95601890afd80709 < zerolength metadata digest
call to check_ecdsa return 1, signature is VALID!
r =    00ff83adbd03d9ba619f3a6d80efef6408561f08d2
s =    009c3102a2852cdda21648014c4d0a1471bd6512fc
hash =  c9210133558bedda8981e5e06d6189be0dee84f3
call to check_ecdsa return 1, signature is VALID!
r =    0011f2e3ded044e3ace8e4513306a81ee124356e7a
s =    00ac9e20528900839f7a577c4b84e026539b89425e
hash =  6db5d204d7f9fa19442209a27647c3973a7e7232
call to check_ecdsa return 1, signature is VALID!
||
I can confirm your two signatures EDATs, when metadata length is zero the signature is valid as you told me and verified.<br />
could you try to validate a zeroed signature on two random hash with your implementation?<br />
f0f's one (and derived make_npdata) does not check for 1 < (r, s) < N - 1 as stated in signature verification algorithm, so a zeroed sig is valid for us!!<br />
|}
<br />
{| class="wikitable"
|-
|'''z'''<br />Im tryed to validate a zeroed signature on two random hashes. Check my screenshot please. My Conclusion. Signatures R would be same only when random numbers are same. -->> Random numbers are not random again! So you can find another examples with another same digests and same signatures(R,S) -->> Random number are depends of digest. If we find algorithm how the "Random" numbers depends of the digests , we can calculate the "Random" number itself and obtain the private key.|| [[File:Zeroed_signature_validation.jpg|thumbnail|100px]]
|}
*conclusion<br />
when you EDAT have your famous zero metadata length, so the same digest, they MUST use EVER the same signature, else they let us solve the math!<br />
that's the real reason that explain also your wrong think about "''there is only one signature''" for a digest.
* [https://www.youtube.com/watch?v=9UbTT_2yxeM sample psl1ght app: ec_gmp]
[https://github.com/andoma/ps3toolchain ps3toolchain and psl1ght from andoma], [https://gmplib.org gmplib] port, [https://github.com/masterzorag/xbm_tools xbm font] in [https://scognito.wordpress.com/2010/11/07/sconsole-a-simple-function-for-printing-strings-on-ps3 sconsole]: compute P = kG to eternity
=Petitboot NAND/NOR precompiled images=
* Not sure what is happening with you right now, but do you have some petitboot precompiled images? That'd be nice contribution for the wiki. Thanks :)

Latest revision as of 18:37, 31 January 2022

SPU Problems on Linux > 3.2, OpenCL related[edit source]

As far as I know, I'm the only coding OpenCL on the Cell here, if someone want to test something be warned that due some spufs changes that ppc-kernel-devs are (maybe) trying to fix, latest 3.3/3.4/3.5 branches falls into 'possible circular locking dependency detected' and slowdown runtime.

  • It's stable until 3.2 branch.
  • Even disabling lock debugging it slowdowns without warnings, it happens even with OpenCL samples from IBM.

http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/50547

Latest tested kernels:

  • 3.2.55 works fine
# ./perlin
OpenCL took 22.496168 seconds to compute 1000 frames. Pixel Rate = 46.611316 Mpixels/sec, Frame Rate = 44.452015 frames/sec
Host code took 12.620616 seconds to compute 10 frames. Pixel Rate = 0.830844 Mpixels/sec, Frame Rate = 0.792354 frames/sec
OpenCL provided a 56.101182 speedup
  • 3.3.3/3.4.6/3.5.3 falls into 'possible circular locking dependency detected' and slowdown runtime

Here the slowdown effect: 

# ./perlin
OpenCL took 93.280273 seconds to compute 1000 frames. Pixel Rate = 11.241133 Mpixels/sec, Frame Rate = 10.720380 frames/sec
Host code took 12.948244 seconds to compute 10 frames. Pixel Rate = 0.809821 Mpixels/sec, Frame Rate = 0.772305 frames/sec
OpenCL provided a 13.881010 speedup

In this specific case time spent is 4x to do the same thing!
When program runs something is going weird, e.g. in my program I'm used to query an OpenCL builtin function to tell me how many available SPEs there are, and its reply 8.
Using spu_base.enum_shared=1 parameter it should reply 7, so seems that the issue is OpenCL related.

OtherOS region[edit source]

OtherOS/OtherOS++ region is on HDD (ps3dd), we have new linux tools (ps3sed) and drivers.
To resize ps3da I've tried new ps3sed (manually), unsuccesfully: GameOS always detect corruption and redo its own things.

I've found a way to force resize on 4.46, no emer_init patch, no downgrading: GameOS respect standards.
I can now resize ps3da at arbitrary size.
Swapping HDD on pc is necessary to me to send a couple to SET MAX ADDRESS ata commands to get the job done: set the limit, left GameOS (partition and) format, then reset size back the same way.
On boot all regions are fine, plus empty space as tail, nice to fit a fouth region.

Here I've forced ps3da to use 1216709344 sectors, this left me about 16G for ps3dd.
After that GameOS do it own things, I've resetted ps3da to its real geometry (1250263728) and booted a new petitboot. 

root@ps3-linux:~# dmesg | grep ps3disk
[    3.220526] ps3disk_init:601: registered block device major 254
[    3.220549] ps3_system_bus_match:369: dev=6.0(sb_04), drv=6.0(ps3disk): match
[    3.220856] ps3disk sb_04: accessible region 0 start 0 size 1250263728
[    3.220952] ps3disk sb_04: accessible region 1 start 32 size 1212515008
[    3.221045] ps3disk sb_04: accessible region 2 start 1212515040 size 4194296
[    3.221051] ps3disk sb_04: ps3stor_probe_access:133: 3 accessible regions found
[    3.227341] ps3disk sb_04: ps3da is a SAMSUNG HM641JI (610480 MiB total, 610480 MiB region)
[    3.229035] ps3disk sb_04: ps3db is a SAMSUNG HM641JI (610480 MiB total, 592048 MiB region)
[    3.230008] ps3disk sb_04: ps3dc is a SAMSUNG HM641JI (610480 MiB total, 2047 MiB region)

root@ps3-linux:~# ps3sed print_region 3
   0                0       1250263728    1
   1               32       1212515008    8
   2       1212515040          4194296    8

root@ps3-linux:~# create_hdd_region.sh
INFO: device id 3
INFO: number of regions 3
INFO: total number of blocks 1250263728
INFO: last region start block 1212515040
INFO: last region number of blocks 4194296
INFO: new region start block 1216709344
INFO: new region number of blocks 33554376
INFO: new region id 3

root@ps3-linux:~# ps3sed print_region 3
   0                0       1250263728    1
   1               32       1212515008    8
   2       1212515040          4194296    8
   3       1216709344         33554376    1

root@ps3-linux:~# reboot && exit

Last number 1 is wrong, it says that last region has only one acl entry, we need to fix it at 8 entries:

  • manually with ps3sed
  • rebooting

Petitboot finally detect a new ps3dd device, the fourth region, of (33554376 * 512 =) 17179840512 bytes.
All of this with a 3.10.26 kernel and new tools: no vflash hacking involved, linux on vflash7 is deprecated.

Sometimes HDD is reported as second device (something buggy in my kernel?): 

root@ps3-linux:~# ps3sed print_device
     flash    1      512           491008        7
     cdrom    3     2048       2147483647        1
      disk    2      512       1250263728        4

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 0f ac e0 ff  00 00 00 00 de ad fa ce  |................|
00000020  00 00 00 00 00 00 00 03  00 00 00 00 00 00 00 02  |................|
00000030  00 00 00 00 00 00 00 20  00 00 00 00 48 45 82 c0  |....... ....HE..|
00000040  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000050  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000060  10 20 00 00 03 00 00 01  00 00 00 00 00 00 00 03  |. ..............|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000c0  00 00 00 00 48 45 82 e0  00 00 00 00 00 3f ff f8  |....HE.......?..|
000000d0  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
000000e0  10 70 00 00 01 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000150  00 00 00 00 48 85 82 e0  00 00 00 00 01 ff ff c8  |....H...........|
00000160  10 70 00 00 02 00 00 01  00 00 00 00 00 00 00 03  |.p..............|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400

Another test on a different, not hacked PS3, running GameOS 4.11

ST96812AS is a 117210240 sectors of 512 bytes each, original PS3 60Gb HDD: here I've limited to 1/10, but I can force every size.

6Gb
60Gb

GameOS (must) accept it.

ps3vuart-tools[edit source]

We miss some stuff from old ps3sm-utils, looking to port: temperature, get_fan_policy and set_fan_policy to new ps3vuart-tools.
We need to enable some sort of fan control on petitboot now. 

root@fedora_clone ~]# /home/ps3vuart-tools-2012-09-01/ps3sm/ps3sm get_fan_policy 0
0x01 0x01 0x48 0x00

[root@fedora_clone ~]# /home/ps3vuart-tools-2012-09-01/ps3sm/ps3sm temperature 0
01 00 00 00 3f 49 00 00

Updating the Real Time Clock with hwclock results in error: 

Mar 31 18:09:18 fedora_clone kernel: os_area_queue_work_handler: Could not update FLASH ROM

UPL.xml.pkg[edit source]

tar -t -f update_files.tar

ls UPL.xml.unpkg/
-rw-r--r-- 1 0 0 2.8K Jun 27 13:40 content
-rw-r--r-- 1 0 0   64 Jun 27 13:40 info0
-rw-r--r-- 1 0 0   64 Jun 27 13:40 info1
...
-rwxr-xr-x 1 0 0  640 Jun 27 15:20 UPL.xml.pkg.spkg_hdr.1

UPL.xml.unpkg/content:                XML document text
UPL.xml.unpkg/info0:                  data
UPL.xml.unpkg/info1:                  data
UPL.xml.unpkg/UPL.xml.pkg.spkg_hdr.1: data

scetool -v -i update_files.untar/UPL.xml.pkg
[*] Using keyset [pkg 0x0000 03.55]
[*] Header decrypted.
[*] Data decrypted.
[*] SCE Header:
Magic           0x53434500 [OK]
Version         0x00000002
Key Revision    0x0000
Header Type     [PKG]
Metadata Offset 0x00000000
Header Length   0x0000000000000280
Data Length     0x0000000000000B9D  // 2973 bytes, content + info0 + info1
[*] Metadata Info:
Key 87 EE 46 44 60 DA DA EA 49 74 58 F9 02 1D 6D 11
IV  F4 9F 43 D8 D0 6A F0 FC 33 AF 5E 6E CF 2F 30 1E
[*] Metadata Header:
Signature Input Length 0x0000000000000250
unknown_0              0x00000001
Section Count          0x00000003
Key Count              0x00000014
Optional Header Size   0x00000000
unknown_1              0x00000000
unknown_2              0x00000000
[*] Metadata Section Headers:
Idx Offset   Size     Type Index Hashed SHA1 Encrypted Key IV Compressed
000 00000280 00000040 01   01    [YES]  00   [NO ]     --  -- [NO ]
001 000002C0 00000040 02   02    [YES]  06   [NO ]     --  -- [NO ]
002 00000300 0000016B 03   03    [YES]  0C   [YES]     12  13 [YES]
[*] SCE File Keys: n 14

hexdump -C UPL.xml.pkg 

00000280  00 00 00 03 00 00 00 04  00 00 00 00 00 00 00 0a  |................|
00000290  20 14 06 19 01 15 45 00  00 00 00 00 00 00 0b 1d  | .....E.........|
000002a0  00 00 00 00 00 00 01 6b  00 00 00 00 00 00 00 00  |.......k........|
000002b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

000002c0  00 00 00 00 00 00 00 03  00 00 00 00 00 00 00 40  |...............@|
000002d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 0b 1d  |................|
000002e0  00 00 00 00 00 00 00 01  00 00 00 00 00 00 00 01  |................|
000002f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

We got info0 + info1, 64bytes each
content is 2845bytes, total is data length 2973
info0, info1 are not encrypted

UPL.xml.pkg is decrypted using pkg keyset [0x0000 03.55], UPL.xml.pkg.spkg_hdr.1 is decrypted using spkg keyset for > 3.55: only Metadata Info and Signature changes.

I think that on 3.55 all .spkg_hdr.1 files are not involved in updating, on 3.56 all of them are used as in overlayfs, so all .spkg_hdr.1 files are readed as metadata headers, decrypted by newer spkg keyset to get the same SCE keys to get rest of data decrypted.

.spkg_hdr.1 decryption[edit source]

Verifing decryption of signed pkg headers with openssl:

  • strip metadata info
# dd if=CORE_OS_PACKAGE.pkg.spkg_hdr.1 of=metainfo.crypt skip=32 count=64 bs=1 
64+0 records in
64+0 records out
64 bytes (64 B) copied, 0.0021009 s, 30.5 kB/s
# hexdump -C metainfo.crypt 
00000000  d7 f9 82 9e 75 0a 3f 20  8b 6f e7 41 b1 bb 52 15  |....u.? .o.A..R.|
00000010  e1 8f d2 86 43 b5 4f 56  4c 42 a0 10 e1 1a 25 38  |....C.OVLB....%8|
00000020  9c 28 c7 fd 38 31 24 3b  1b 2b 9f 3f dc 72 4f c4  |.(..81$;.+.?.rO.|
00000030  95 34 b8 0a af 25 a1 05  b6 8f ce 2c 88 e9 2b 7b  |.4...%.....,..+{|
  • verify metadata info decryption with standard tool
# openssl enc -d -aes-256-cbc -in metainfo.crypt -K erk -iv riv | hexdump -C
00000000  7c f2 9a 4b 96 de 5f 75  a1 32 87 c0 42 ec 8f cf  ||..K.._u.2..B...|   Key
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  6f 85 6a 60 2a 8d b4 3f  2a 81 1b 1a 9c a3 02 f6  |o.j`*..?*.......|   IV
00000030
  • strip rest of crypted metadata
# dd if=CORE_OS_PACKAGE.pkg.spkg_hdr.1 of=metarest.crypt skip=96 bs=1
544+0 records in
544+0 records out
544 bytes (544 B) copied, 0.00626423 s, 86.8 kB/s
  • decrypt rest of metadata
# openssl enc -d -aes-128-ctr -in metarest.crypt -K Key -iv IV | hexdump -C
00000000  00 00 00 00 00 00 02 50  00 00 00 01 00 00 00 03  |.......P........| mh
00000010  00 00 00 14 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00000020  00 00 00 00 00 00 02 80  00 00 00 00 00 00 00 40  |...............@| m_sh0
00000030  00 00 00 01 00 00 00 01  00 00 00 02 00 00 00 00  |................|
00000040  00 00 00 01 ff ff ff ff  ff ff ff ff 00 00 00 01  |................|

00000050  00 00 00 00 00 00 02 c0  00 00 00 00 00 00 00 40  |...............@| m_sh1
00000060  00 00 00 02 00 00 00 02  00 00 00 02 00 00 00 06  |................|
00000070  00 00 00 01 ff ff ff ff  ff ff ff ff 00 00 00 01  |................|

00000080  00 00 00 00 00 00 03 00  00 00 00 00 00 5a 01 74  |.............Z.t| m_sh2
00000090  00 00 00 03 00 00 00 03  00 00 00 02 00 00 00 0c  |................|
000000a0  00 00 00 03 00 00 00 12  00 00 00 13 00 00 00 02  |................|

000000b0  fd 5e fe 3f a0 42 fe 31  d6 61 83 26 98 07 ce e8  |.^.?.B.1.a.&....| h0 0x20, HMAC-SHA1
000000c0  09 a7 65 7a 00 00 00 00  00 00 00 00 00 00 00 00  |..ez............|
000000d0  6a 49 08 b2 87 ee 02 65  8c 73 5a 4c 54 f8 bf 5d  |jI.....e.sZLT..]| k0 0x40, HMAC key
000000e0  b6 3a d4 ef d3 94 74 f5  f3 a3 f2 ad af 1c 45 4e  |.:....t.......EN|
000000f0  08 aa 2b 61 fb 91 52 9d  69 a8 44 b0 a0 dd 39 1c  |..+a..R.i.D...9.|
00000100  bc 4d a0 51 ed f5 30 16  d1 35 8c b1 d1 09 54 d0  |.M.Q..0..5....T.|
00000110  60 32 ff 1c 3d 1a 9d 03  61 28 d8 ad 1f dc 34 57  |`2..=...a(....4W| h1 0x20, HMAC-SHA1
00000120  05 2a 1e f6 00 00 00 00  00 00 00 00 00 00 00 00  |.*..............|
00000130  6a 49 08 b2 87 ee 02 65  8c 73 5a 4c 54 f8 bf 5d  |jI.....e.sZLT..]| k1 0x40, HMAC key
00000140  b6 3a d4 ef d3 94 74 f5  f3 a3 f2 ad af 1c 45 4e  |.:....t.......EN|
00000150  08 aa 2b 61 fb 91 52 9d  69 a8 44 b0 a0 dd 39 1c  |..+a..R.i.D...9.|
00000160  bc 4d a0 51 ed f5 30 16  d1 35 8c b1 d1 09 54 d0  |.M.Q..0..5....T.|
00000170  3c 37 73 07 73 d5 69 69  52 67 97 3b e9 20 70 a9  |<7s.s.iiRg.;. p.| h2 0x20, HMAC-SHA1
00000180  53 a7 11 6d 00 00 00 00  00 00 00 00 00 00 00 00  |S..m............|
00000190  6a 49 08 b2 87 ee 02 65  8c 73 5a 4c 54 f8 bf 5d  |jI.....e.sZLT..]| k2 0x40, HMAC key
000001a0  b6 3a d4 ef d3 94 74 f5  f3 a3 f2 ad af 1c 45 4e  |.:....t.......EN|
000001b0  08 aa 2b 61 fb 91 52 9d  69 a8 44 b0 a0 dd 39 1c  |..+a..R.i.D...9.|
000001c0  bc 4d a0 51 ed f5 30 16  d1 35 8c b1 d1 09 54 d0  |.M.Q..0..5....T.|
000001d0  35 53 b4 b5 44 28 fe 09  5a 04 e5 38 e8 38 f4 a6  |5S..D(..Z..8.8..| Key
000001e0  5d 24 fa b1 e0 55 f4 58  15 22 c2 73 00 00 00 00  |]$...U.X.".s....| IV

000001f0  00 c9 57 08 f1 6f e6 75  39 6f 2a 12 51 48 5f 8c  |..W..o.u9o*.QH_.| r, s
00000200  97 53 e3 e2 a7 00 b7 47  fa c2 0b 01 2b df 5a 34  |.S.....G....+.Z4|
00000210  f7 a8 d0 21 d2 f8 94 4b  6e 30 00 00 00 00 00 00  |...!...Kn0......|

verify ecdsa signatures[edit source]

  • get signature
  • join sceh + decrypted metadata info + decrypted rest of metadata until signature
# ls -l metadata.bin
-rw-r--r-- 1 root root 592 Jul 11  metadata.bin
  • compute digest of the whole decrypted metadata until signature
# sha1sum metadata.bin 
70942107d35df85091bf4949d7fa46421e27d056  metadata.bin
  • verify signature against computed digest
ecdsa_verify(digest, r, s) == 1

collecting spkg_hdr.1 signatures[edit source]

I've started collecting into an SQLite database all publicily available ECDSA signatures from spkg.hdr.1 files, to research.
Note that here I've named 3.57 the 3.56#2 one! I know, 3.57 doesn't exist.

  • get spkg_hdr.tar file from PS3UPDAT.PUP, here I've just added an argument to pupunpack to extract only the needed section:
ps3tools # ./pupunpack ../PS3\ 3.56\ OFW/PS3UPDAT.PUP ../PS3\ 3.56\ OFW/unpacked 7
sections:    9
hdr size:    00000000_00000290
data size:   00000000_0b0f3d3d
header hmac: OK
extracting only section 7
section 7: unpacking spkg_hdr.tar       (00000000_00011800 bytes; hmac: OK)...
  • untar spkg.hdr.1 files
# cd ../PS3\ 3.56\ OFW/unpacked/
unpacked # tar -xf spkg_hdr.tar
  • strip signature data off spkg.hdr.1 files into spkg.hdr.1_sigdata files, here I've added a function to sceverify
unpacked # for file in *hdr.1; do ../../ps3tools/sceverify $file; done
...
hash:   c72f26e67e03b743a8c830a541e82bfb2e9f6c19
r:      0056af2dad5647288c75e76dc92ed875de86876d7e
s:      00d7de25130de0f6dc0602e590b42bc5f21ab2a3e6
Signature: ecdsa_verify(hash, r, s) : OK
Collecting digest + signature for file: UPL.xml.pkg.spkg_hdr.1
exported: UPL.xml.pkg.spkg_hdr.1_sigdata, recheck ecdsa signature: OK

unpacked # for file in *1_sigdata; do ls -h $file; done
BDIT_FIRMWARE_PACKAGE.pkg.spkg_hdr.1_sigdata
BDPT_FIRMWARE_PACKAGE_301R.pkg.spkg_hdr.1_sigdata
BDPT_FIRMWARE_PACKAGE_302R.pkg.spkg_hdr.1_sigdata
...
  • collect sigdata into an sqlite database, I've coded an app to do the job:
unpacked # for file in *1_sigdata; do ../../ps3tools/collector 1 $file 3.56; done
Connection successful
BDIT_FIRMWARE_PACKAGE.pkg.spkg_hdr.1_sigdata
BDIT_FIRMWARE_PACKAGE.pkg.spkg_hdr.1 3.56
dig = 749e7ba6fba9ff4c8ad83d1fd62feec4ea9ad3f2
sig = 00574c57e9ceaac1285b3f6d7b06feaa7daa180edf002b0cc8548f42c523afa39c6984e4b67b9639afbc
...
BDPT_FIRMWARE_PACKAGE_301R.pkg.spkg_hdr.1_sigdata
BDPT_FIRMWARE_PACKAGE_301R.pkg.spkg_hdr.1 3.56
dig = cee76eb85bf899952acc8723ef3e35fdc9b0da23
sig = 0001bd4af80d5e8f190baea58e6613e5672d1c29a8000dcfad27f4edcef9f0b9f000759d89ebb050d871
...
  • since collector can also export to STDOUT, we can already filter, sort...
# ./ps3tools/collector 2 | head -12
Connection successful
Export to STDOUT
BDIT_FIRMWARE_PACKAGE.pkg.spkg_hdr.1 3.57
dig = fcde1eaf97e24c9d0a5fe2af312e5b1ce1e6ab14
r = 003798ace6c2097c02e2f9214bfc2bbf5c7bd347ae
s = 002b1a77b56e0995f80761fa779db5b09e269ebf96
BDPT_FIRMWARE_PACKAGE_301R.pkg.spkg_hdr.1 3.57
dig = 0d953e1f78195b960a145a0c20753269a2352204
r = 00b2a103abbf09db35eb5a2580554446255fee4504
s = 0061292680dccc79e92373f002e669cf238c520a70

# ./ps3tools/collector 2 | grep "r =" | sort | head
r = 000119f11cc9076d039c1c0a625afe3dc5f9e38af9
r = 000171cfd17643b35e3f7a9fa1d64398413c35a949
r = 0001bd4af80d5e8f190baea58e6613e5672d1c29a8
r = 00023c6b278121e57ae6c836c0a188344dc676f9b7
r = 0003c42810e1b9f3cc4a93e71b101359116c06e68a
r = 000418380d9e2d2f4a11e88bcb42af8f17b042cd31
r = 00049a30c5e2d38ad19765e6c02e94377bf93444f9
r = 0004fa6eb1641706c20a14ede5dc0fe497b01f4dee
r = 00051b73b3eea4904f899ffc10f445ee080f2f3912
r = 0005639f0f3dd5585ed5e64df0421b274e842a2a2f
  • check for the same r (they just failed in this, but watch how is simple!)
# ./ps3tools/collector 2 | grep "r =" | sort | wc -l
298 lines
# ./ps3tools/collector 2 | grep "r =" | sort | uniq | wc -l
298 lines (no same r!)
  • database can be accessed via SQL query too, it contains binary blobs
# sqlite3 /tmp/collector_db.sqlite3
SQLite version 3.8.5 2014-06-04 14:06:34
Enter ".help" for usage hints.
sqlite> SELECT HEX(dig) FROM spkg_hdr WHERE name = "SYS_CON_FIRMWARE_01010303.pkg.spkg_hdr.1 3.70";
7215D87859A31889F5FB931BDED988A95AF6A38E
  • we can just use a browser plugin to deal with database
spkg_hdr SQLite table

questions[edit source]

z
why you collect these hashes and signatures?
Now if 2 digests are different then R signatures would be diffenet too. Pseudo Random number (that used to creating signature) now is F(digest);
If digests are same then Pseudo Random numbers are same too ->> R sigs would be same and S sigs would be same.
For every digest, we have 1 and only 1 signature (R,S). If you want obtain private key, you need to find an algorithm for generating pseudo random number from the digest.

m
ECDSA signature is the (r, s) keypair:
http://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm

  • first part, r

to compute r you have to (3) select a random integer, (4) calculate the curve point first, to finally (5) take the x coordinate mod n.

  • the random integer

that random integer in signature generation is equal to select the random integer in the priv/pub keypair generation.
that number is the temporary or ephemeral key.
for every signature the algorithm needs one random integer, that must be never reselected, else epic fail.

  • digest

hash function is SHA1, you know, collision resistant: we can "never" have two different messages that produces the same sha1sum, else a collision.
they also uses metadata info to change the message to sign from .pkg to .spgk_hdr.1 files, else they signs the same digest with different curve. (who other noticed/know this?)

  • second part, s

s is computed from the digest and the latter r.

  • why

suppose that you are doing trial point multiplication (x) computing: p = k x G to guess for the correct k that had produced our public point p.
instead of checking only for exactly p, the pub, now you can consider that you have some hundreds of correct/public x coordinate mod n to check/guess for.
or, in other words: I can luckily select an integer that, even isn't the priv, is the ephemeral key that had produced a valid signature.
what could happen if I get an ephemeral key?

  • those two needs investigation
1. "For every digest, we have 1 and only 1 signature (R,S)."
Sorry, but don't think so, because as you can have read, r comes from a random number.
2. "Pseudo Random number (that used to creating signature) now is F(digest);"
They can't be so idiots, since digest is ever known...
Signing with my keypair.png
  • example of different signatures from custom keypair to test for dig: da39a3ee5e6b4b0d3255bfef95601890afd80709

pub: df4222f3bff899845d203cd9373358ff7a0752f501c7f378195c0ac7e157f61e14ff231d73a0137f
sig0: 008e8eaee8452d2915ef2186358079ee82a7c90d410063de8d98f012778596c14eb0df17f7464da65a02
sig1: 00fdb20299e37c4a23a6cdc07ee0e91539e58ae62b00fc8ec36e79d2de33b4569f7968ea2211a4a92bef
sig2: 0067af6858bf5bc2eb239dfcb997bc0c21fbaf16dc002f1c4cd4dcc5d71037d65caf05bbbccfce4f7fc1

playing on the vsh curve[edit source]

z

So I will show for you that R = Function(digest) and what this fail is not so critical. I was interested for edat algorithm and figured out how edats (and sdat) files are signed.
It contains 2 non-randomfailed ecdsa signatures. http://www.psdevwiki.com/ps3/EDAT_files#Structure_.28Encrypted_Format.29
first one is metadata signature and the second one is header signature. There are some edat files created from data files with 0 byte length, that contains metadata with 0 byte length.
There are examples: original pkg links: http://is.gd/naLaxh , http://is.gd/IFtWmq it contains destiny.edat and hdd_package_key.edat , both files have metadata with 0 byte length.
Hex code of the edats: http://pastie.org/private/ejoloa5qjjy8wlkezadga , http://pastie.org/private/fbr9uphpjzm0xd4gqfuyg .
So Both edats have metadata digiest = DA39A3EE5E6B4B0D3255BFEF95601890AFD80709 , R = A2732E0161E20C290108FDD0B567120C42AAB3D2 , S = B894E8775AFF90A3CBB6CC08BC918C14F759D439
So if digests are same then pseudo_random_numbers are same and signatures are same.
Please make your conclusions.

m
You have already seen differences between two files, but maybe some other not. Here a png.
Page is telling me that at 0xB0 there is an ECDSA signature, and you are pointing out that we have the same (ECDSA) signature on two different files !?!
1. I see your "same signature", but how do you get "metadata digest = DA39A3EE5E6B4B0D3255BFEF95601890AFD80709" from both?
2. Conclusion to me are that at 0xB0 there is not an ECDSA signature, so: have you checked? Have you validated? Have you proven that r, s is the valid signature for the digest?
3. There is also another aspect to not forget: alignment (%16 = 0), so there is an ECDSA signature in 40 bytes? does not sound good to me...
4. SHA-1 produces a fixed length of 20 bytes: at wiki page I read "0x40 QA digest, size 0x10 (seems like to be a SHA-1 hash of the non-finalized file) ... Can be ... zeroed on forged file." !?!
5. There are two ECDSA signatures on an EDAT file and only one to protect CORE_OS_PACKAGE.pkg from alteration !?!?!
EDATs diff.png


z

1. metadata length = 0 bytes for both files, so digest for empty message is DA39A3EE5E6B4B0D3255BFEF95601890AFD80709.
2. r,s validated and valid of course. so you can use make_npdata the newest version for validate signatures into edats. there are no mistakes, it is realy ecdsa sig.
3. Both signatures has 40 bytes, first 20 bytes is R , second 20 bytes is S.
4. Sony used full 20 bytes length sha1 hash for validate ECDSA signatures.
5. Correct info. SCE pkg file have only header signature. edat have metadata sig and header sig.

m
You are right, I've verified all, as you can see in my shots.
I've also noticed one thing that explain something: with zeroed ECDSA signature every digest results in a valid signature!
Why?
Because the signature becomes the point at infinity!
That's because on signature generation when r = 0 you have to select another random integer, as 0 < rand < n! And the same applies for s.
But really cool stuff can happen exacly with this kind of crazyness!
EDAT signatures on vsh curve 1.png
EDAT signatures on vsh curve 2.png


z
Im verified metadata and header signatures for both edat files. Check my screenshotes please.
Hdd package key.edat ECDSA validation.jpg
Destiny.edat ECDSA validation.jpg
m

Checked your data, validated the same: 

r =     00a2732e0161e20c290108fdd0b567120c42aab3d2
s =     00b894e8775aff90a3cbb6cc08bc918c14f759d439
hash =  da39a3ee5e6b4b0d3255bfef95601890afd80709 < zerolength metadata digest
call to check_ecdsa return 1, signature is VALID!
r =     00ff83adbd03d9ba619f3a6d80efef6408561f08d2
s =     009c3102a2852cdda21648014c4d0a1471bd6512fc
hash =  c9210133558bedda8981e5e06d6189be0dee84f3
call to check_ecdsa return 1, signature is VALID!
r =     0011f2e3ded044e3ace8e4513306a81ee124356e7a
s =     00ac9e20528900839f7a577c4b84e026539b89425e
hash =  6db5d204d7f9fa19442209a27647c3973a7e7232
call to check_ecdsa return 1, signature is VALID!

I can confirm your two signatures EDATs, when metadata length is zero the signature is valid as you told me and verified.
could you try to validate a zeroed signature on two random hash with your implementation?
f0f's one (and derived make_npdata) does not check for 1 < (r, s) < N - 1 as stated in signature verification algorithm, so a zeroed sig is valid for us!!


z
Im tryed to validate a zeroed signature on two random hashes. Check my screenshot please. My Conclusion. Signatures R would be same only when random numbers are same. -->> Random numbers are not random again! So you can find another examples with another same digests and same signatures(R,S) -->> Random number are depends of digest. If we find algorithm how the "Random" numbers depends of the digests , we can calculate the "Random" number itself and obtain the private key.
Zeroed signature validation.jpg
  • conclusion

when you EDAT have your famous zero metadata length, so the same digest, they MUST use EVER the same signature, else they let us solve the math!
that's the real reason that explain also your wrong think about "there is only one signature" for a digest.

ps3toolchain and psl1ght from andoma, gmplib port, xbm font in sconsole: compute P = kG to eternity

Petitboot NAND/NOR precompiled images[edit source]

  • Not sure what is happening with you right now, but do you have some petitboot precompiled images? That'd be nice contribution for the wiki. Thanks :)
Retrieved from "http://www.psdevwiki.com/ps3/index.php?title=User_talk:Masterzorag&oldid=64921"