Talk:Graf's PSGroove Payload: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
mNo edit summary |
||
| Line 24: | Line 24: | ||
iv: 0xE8663A69CD1A5C454A761E728C7C254E | iv: 0xE8663A69CD1A5C454A761E728C7C254E | ||
hmac: 0xCC30C4229113DB25733553AFD06E8762B3729D9EFAA6D5F35A6F58BF38FF8B5F58A25BD9C9B50B01D1AB4028676968EAC7F88833B662935D7506A6B5E0F9D97A | hmac: 0xCC30C4229113DB25733553AFD06E8762B3729D9EFAA6D5F35A6F58BF38FF8B5F58A25BD9C9B50B01D1AB4028676968EAC7F88833B662935D7506A6B5E0F9D97A | ||
</pre> | </pre> | ||
<!--// erk: 0x34, 0x18, 0x12, 0x37, 0x62, 0x91, 0x37, 0x1C, 0x8B, 0xC7, 0x56, 0xFF, 0xFC, 0x61, 0x15, 0x25, 0x40, 0x3F, 0x95, 0xA8, 0xEF, 0x9D, 0x0C, 0x99, 0x64, 0x82, 0xEE, 0xC2, 0x16, 0xB5, 0x62, 0xED // iv: 0xE8, 0x66, 0x3A, 0x69, 0xCD, 0x1A, 0x5C, 0x45, 0x4A, 0x76, 0x1E, 0x72, 0x8C, 0x7C, 0x25, 0x4E // hmac: 0xCC, 0x30, 0xC4, 0x22, 0x91, 0x13, 0xDB, 0x25, 0x73, 0x35, 0x53, 0xAF, 0xD0, 0x6E, 0x87, 0x62, 0xB3, 0x72, 0x9D, 0x9E, 0xFA, 0xA6, 0xD5, 0xF3, 0x5A, 0x6F, 0x58, 0xBF, 0x38, 0xFF, 0x8B, 0x5F,0x58, 0xA2, 0x5B, 0xD9, 0xC9, 0xB5, 0x0B, 0x01, 0xD1, 0xAB, 0x40, 0x28, 0x67, 0x69, 0x68, 0xEA, 0xC7, 0xF8, 0x88, 0x33, 0xB6, 0x62, 0x93, 0x5D, 0x75, 0x06, 0xA6, 0xB5, 0xE0, 0xF9, 0xD9, 0x7A //--> | <!--// erk: 0x34, 0x18, 0x12, 0x37, 0x62, 0x91, 0x37, 0x1C, 0x8B, 0xC7, 0x56, 0xFF, 0xFC, 0x61, 0x15, 0x25, 0x40, 0x3F, 0x95, 0xA8, 0xEF, 0x9D, 0x0C, 0x99, 0x64, 0x82, 0xEE, 0xC2, 0x16, 0xB5, 0x62, 0xED // iv: 0xE8, 0x66, 0x3A, 0x69, 0xCD, 0x1A, 0x5C, 0x45, 0x4A, 0x76, 0x1E, 0x72, 0x8C, 0x7C, 0x25, 0x4E // hmac: 0xCC, 0x30, 0xC4, 0x22, 0x91, 0x13, 0xDB, 0x25, 0x73, 0x35, 0x53, 0xAF, 0xD0, 0x6E, 0x87, 0x62, 0xB3, 0x72, 0x9D, 0x9E, 0xFA, 0xA6, 0xD5, 0xF3, 0x5A, 0x6F, 0x58, 0xBF, 0x38, 0xFF, 0x8B, 0x5F,0x58, 0xA2, 0x5B, 0xD9, 0xC9, 0xB5, 0x0B, 0x01, 0xD1, 0xAB, 0x40, 0x28, 0x67, 0x69, 0x68, 0xEA, 0xC7, 0xF8, 0x88, 0x33, 0xB6, 0x62, 0x93, 0x5D, 0x75, 0x06, 0xA6, 0xB5, 0xE0, 0xF9, 0xD9, 0x7A //--> | ||
Revision as of 18:45, 28 May 2011
<Slynk> Hmm had a thought : / You know how the token and token seed are made at the same time? That means the token seed isn't passed into the processor... what is? It can't be just your idps right? Unless sony doesn't use the HV to make their tokens. There must be other info passed in that determines whether you receive a dummy token or the full one. ... Just a thought. ^^; <rms> i can make my own tokens from a nor/nand dump. just like hypervisor <kevin6548> so what does that mean when a sedd is created it passes something to proccessor . nit the whole seed but a by product of creating it . is that theroy <rms> seed is calculated from eid which allows token to be calculated. its more of a byproduct/intermediate product. if you do the math, its simple: v+s+f+h=t
- the seed value is made from your EID (from a NAND/NOR dump, either software with payload, or hardware)
- updater manager calls spu_token_processor
- sent out of spu_token_processor
- IBM Cell Simulator with SE Linux (not the ancient Sony SPU Simulator from old pre 0.9x SDKs)
- seed : 80 bytes, only the first 20 are populated
- combo > 3 < 10 buttons
there are two algorithms used (one's an alternative of a hashing algorithm / one's a block cipher):
- HMAC-SHA1
- AES 256 CBC - Advanced Encryption Standard Cipher-block chaining; fixed block size 128 bit, key size 256 bit - with 4x4 byte matrices
erk: 0x341812376291371C8BC756FFFC611525403F95A8EF9D0C996482EEC216B562ED iv: 0xE8663A69CD1A5C454A761E728C7C254E hmac: 0xCC30C4229113DB25733553AFD06E8762B3729D9EFAA6D5F35A6F58BF38FF8B5F58A25BD9C9B50B01D1AB4028676968EAC7F88833B662935D7506A6B5E0F9D97A