Forum rules: Forum rule Nº 15 is strictly enforced in this subforum.
#20712 by The Lemon Man
Sun Jan 16, 2011 9:06 pm
Code: Select allint enc (char *in, char **out, int size, const char *aes, const char *cmac, char *****, int shit_sz)
{
    char *buf, *k1, *p;
   
    printf("enc\n");
   
    buf = calloc(1, sizeof(KIRK_CMD1_HEADER) + size + shit_sz);
    k1 = calloc(1, 0x40 + sizeof(KIRK_CMD1_HEADER) + size + shit_sz);

   
    ((KIRK_CMD1_HEADER*)buf)->mode = KIRK_MODE_CMD1;
    ((KIRK_CMD1_HEADER*)buf)->data_offset = shit_sz;
    ((KIRK_CMD1_HEADER*)buf)->data_size = size;
   
    memcpy(((KIRK_CMD1_HEADER*)buf)->AES_key, aes, 0x10);
    memcpy(((KIRK_CMD1_HEADER*)buf)->CMAC_key, cmac, 0x10);
   
    memcpy(buf + sizeof(KIRK_CMD1_HEADER), ****, shit_sz);
   
    memcpy(buf + sizeof(KIRK_CMD1_HEADER) + shit_sz, in, size);
   
    printf("before zero\n");
   
    int ret = kirk_CMD0(k1 + 0x40, buf, size, 0);
   
    printf("cmd0 %i\n", ret);
   
    const char data_cmac [] = {
        0x31, 0x5c, 0xf7, 0x20, 0xd0, 0x39, 0xb9, 0x09, 0xfe, 0x09, 0xa9, 0xde, 0x7a, 0xdd, 0x97, 0xa9
    };
   
    memcpy(((KIRK_CMD1_HEADER*)(k1 + 0x40))->CMAC_data_hash, data_cmac, 0x10);
   
    ret = kirk_forge(k1 + 0x40, size);
   
    dump_header(k1 + 0x40);
   
    *out = k1;

    return size;
}


When i decrypt back the prx encrypted with this function i get all the file right but the last part that contains the same pattern all over, any hint about where the problem is ?
Advertising
#20715 by Mathieulh
Sun Jan 16, 2011 9:09 pm
KEYS, KEYS, KEYS !!!!


Code: Select allSpock cmd 0x09 (Spock's "Master key"): u8 key[16] =
   {
      0x9F, 0x46, 0xF9, 0xFC, 0xFA, 0xB2, 0xAD, 0x05,
      0x69, 0xF6, 0x88, 0xD8, 0x79, 0x4B, 0x92, 0xBA
   };

Kirk cmd 0x11 key: u8 idskey0[16] =
{
   0x47, 0x5E, 0x09, 0xF4, 0xA2, 0x37, 0xDA, 0x9B,
   0xEF, 0xFF, 0x3B, 0xC0, 0x77, 0x14, 0x3D, 0x8A
};


Kirk cmd 0x12 ECDSA PUB Keys (likely as they are yet to be tested):

    // certSig0
    0x40, 0x04, 0xC8, 0x0B, 0xD9, 0xC8, 0xBA, 0x38,
    0x22, 0x10, 0x65, 0x92, 0x3E, 0x32, 0x4B, 0x5F,
    0x0E, 0xC1, 0x65, 0xED, 0x6C, 0xFF, 0x7D, 0x9F,
    0x2C, 0x42, 0x0B, 0x84, 0xDF, 0xDA, 0x6E, 0x96,
    0xC0, 0xAE, 0xE2, 0x99, 0x27, 0xBC, 0xAF, 0x1E,
     
    // certSig1
    0x06, 0x48, 0x5F, 0xD0, 0x29, 0x85, 0x3B, 0x55,
    0x2F, 0x7E, 0xFD, 0xD6, 0x7A, 0x2D, 0xE7, 0xA1,
    0xA4, 0xE2, 0x55, 0x37, 0xB2, 0x45, 0x9D, 0x87,
    0x86, 0x42, 0x6D, 0x5B, 0x27, 0xEF, 0xA5, 0xA9,
    0x31, 0x1C, 0xB8, 0xAB, 0xAB, 0xFA, 0x0E, 0xCE,

    // certSig2
    0x3F, 0x8C, 0x34, 0xF2, 0x10, 0xAE, 0xC4, 0x8E,
    0x15, 0x20, 0xFF, 0x2A, 0x44, 0x89, 0x9E, 0x05,
    0x4A, 0x0D, 0xA3, 0x3D, 0xF8, 0xB9, 0x75, 0x4B,
    0x09, 0xC0, 0xEC, 0x7E, 0x61, 0x86, 0x7A, 0x51,
    0x26, 0xFE, 0x69, 0x26, 0x97, 0x21, 0x96, 0xF5,
   
    // certSig3
    0xCC, 0xB3, 0x44, 0x0D, 0xC4, 0x83, 0x6D, 0xD5,
    0x19, 0xE1, 0x3B, 0x28, 0x05, 0xB3, 0x08, 0x70,
    0xDC, 0xAE, 0xE4, 0x62, 0x13, 0x6B, 0x38, 0x88,
    0x65, 0x1A, 0x98, 0xE0, 0x2B, 0x29, 0xFA, 0x0C,
    0xD3, 0x4F, 0x16, 0x16, 0xF1, 0xED, 0x57, 0x86,
   
    // certSig4
    0x08, 0xB3, 0x36, 0x92, 0x5C, 0x2B, 0x44, 0x5D,
    0x03, 0xA9, 0xBE, 0x51, 0xB9, 0xAA, 0xBF, 0x54,
    0xE4, 0xCC, 0x14, 0x2E, 0xA7, 0x2A, 0x23, 0xBB,
    0x80, 0x60, 0xB0, 0x3B, 0x71, 0xCD, 0xE0, 0x77,
    0x2D, 0xE8, 0x2A, 0xD8, 0x93, 0x16, 0x48, 0xD6,
   
    // certSig5
    0x4F, 0x0A, 0x2B, 0xC9, 0x98, 0x76, 0x40, 0x86,
    0x0E, 0x22, 0xEE, 0x5D, 0x86, 0x08, 0x7C, 0x96,
    0x92, 0x47, 0x0B, 0xDF, 0x59, 0xDC, 0x4C, 0x1F,
    0x2E, 0x38, 0xF9, 0x2C, 0xE7, 0xB6, 0x68, 0x75,
    0xB5, 0x9E, 0xD1, 0x0C, 0x9D, 0x84, 0xFA, 0x6A,



Cheers :)

P.S. None of those keys are on the ps3, don't bother looking there.
Advertising
Last edited by Mathieulh on Sun Jan 16, 2011 10:26 pm, edited 6 times in total.
#20720 by Mathieulh
Sun Jan 16, 2011 9:25 pm
For those who wonder, spock cmd 0x09 key is used to decrypt UMD keys stored in idstorage, those keys are then used by spock cmd 0x08 to decrypt the UMD master key (per disc key) Then this key is used in spock cmd 0x0A to decrypt the UMD raw sectors. Each different psp regions seems to have its own sets of UMD keys.

You can more or less access Spock through lepton's ram (there is some hidden test mode on lepton allowing you to do just this). More on this later If I ever get the time to clean up those sources.

P.S. Let's hope sony uses kirk cmd 0x12 for the kernel prx ECDSA checks and that they did the same fail as on ps3, would someone be so kind as to check it out ? :P
#20780 by Mathieulh
Mon Jan 17, 2011 1:34 am
Syntax for kirk cmd 0x11 key:

Code: Select allvoid GenerateSigncheck(SomeStructure *ss, int *b, u8 *out)
{
   AES_KEY ctx, ctx2; // sp+0x20
   int i, j;
   u8 sg_key1[0x10], sg_key2[0x10]; // sp, sp+0x10
      
   AES_set_encrypt_key(idskey0, 128, &ctx);
   AES_set_decrypt_key(idskey0, 128, &ctx2);

   for (i = 0; i < 16; i++)
   {
      sg_key1[i] = sg_key2[i] = ss->buf1[i % 8];
   }

   for (i = 0; i < 3; i++)
   {
      AES_encrypt(sg_key2, sg_key2, &ctx);
      AES_decrypt(sg_key1, sg_key1, &ctx2);
   }

   AES_set_encrypt_key(sg_key2, 128, &ctx);

   for (i = 0; i < 3; i++)
   {
      for (j = 0; j < 3; j++)
      {
         AES_encrypt(sg_key1, sg_key1, &ctx);
      }

      memcpy(out+(i*16), sg_key1, 0x10);      
   }

   memcpy(out+0x30, ss->buf1, 8);
   memcpy(out+0x38, b, 4);

   P1(out);
}
#20789 by coyotebean
Mon Jan 17, 2011 2:37 am
For people hijacking EBOOT, the purpose of the PSP info block is to let the system have access to critical information without decrypting the file. It is never scrambled. You can complete rewrite it (of course leaving the program type, and probably module attribute untouched is good idea). It is not a requirement to use the original psp info block.

For tag 0x00000000 to 0x0F000000 only
Last edited by coyotebean on Mon Jan 17, 2011 6:02 am, edited 1 time in total.
#20794 by Proxima
Mon Jan 17, 2011 3:34 am
My understanding is that since the psp header is included in the SHA1 hash, and since we don't have the keys for any mode other than 9, we cannot re-encode the proper SHA1 into the header. Changing the info in the header only is possible if we can re-encode the SHA1 data. Though I may have missed something...
#20819 by coyotebean
Mon Jan 17, 2011 6:00 am
Proxima wrote:My understanding is that since the psp header is included in the SHA1 hash, and since we don't have the keys for any mode other than 9, we cannot re-encode the proper SHA1 into the header. Changing the info in the header only is possible if we can re-encode the SHA1 data. Though I may have missed something...

Oh yes, you are right, the SHA1 hash is only exposed when using scramble algorithm type 0 (the initial tag 0x00000000 to 0x0F000000).

Who is online

Users browsing this forum: No registered users and 1 guest