Editing User talk:Masterzorag

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

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 109: Line 109:


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.
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]]
[[File:Smaller hdd.jpg|200px|thumb|left|6Gb]] GameOS (must) accept it. [[File:Smaller hdd 2.jpg|200px|thumb|left|60Gb]]
 
GameOS (must) accept it.<br />


=ps3vuart-tools=
=ps3vuart-tools=
Line 189: Line 187:


We got info0 + info1, 64bytes each
We got info0 + info1, 64bytes each
content is 2845bytes, total is data length 2973
content is 2845bytes, total is data lenght 2973
info0, info1 are not encrypted
info0, info1 are not encrypted
</pre>
</pre>
Line 280: Line 278:
*verify signature against computed digest
*verify signature against computed digest
  ecdsa_verify(digest, r, s) == 1
  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 :)
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)
Retrieved from "http://www.psdevwiki.com/ps3/User_talk:Masterzorag"