Advertising (This ad goes away for registered users. You can Login or Register)

PS3 packages and how it leads to PSP signing

Forum rules
Forum rule Nº 15 is strictly enforced in this subforum.
tpu
Posts: 24
Joined: Sat Jan 22, 2011 3:05 am

about kirk cmd 0x11

Post by tpu » Sat Jan 22, 2011 1:58 pm

I got this code from google:

Code: Select all

// KIRK cmd0x11
// pubkey is 320bit public key
// hash is SHA1 of data to verify
// sig is two 20Byte DSA signature from siggenint
sceDdrdbSigvry(u8 *pubkey, u8 *hash, u8 *sig)
{
	memcpy(g_buf, pubkey, 40);
	memcpy(g_buf+40, hash, 20);
	memcpy(g_buf+60, sig, 40);

	int res = sceUtilsBufferCopyWithRange(NULL, 0, g_buf, 100, 0x11);
	memset(g_buf, 0, 100);
	return(res ? 0x80530300 : 0);
}
Mathieulh: do you have more infomation for this cmd?
Advertising

Mathieulh
Guru
Posts: 46
Joined: Thu Jan 06, 2011 6:17 am
Contact:

Re: about kirk cmd 0x11

Post by Mathieulh » Sat Jan 22, 2011 2:46 pm

tpu wrote:I got this code from google:

Code: Select all

// KIRK cmd0x11
// pubkey is 320bit public key
// hash is SHA1 of data to verify
// sig is two 20Byte DSA signature from siggenint
sceDdrdbSigvry(u8 *pubkey, u8 *hash, u8 *sig)
{
	memcpy(g_buf, pubkey, 40);
	memcpy(g_buf+40, hash, 20);
	memcpy(g_buf+60, sig, 40);

	int res = sceUtilsBufferCopyWithRange(NULL, 0, g_buf, 100, 0x11);
	memset(g_buf, 0, 100);
	return(res ? 0x80530300 : 0);
}
Mathieulh: do you have more infomation for this cmd?
I believe kirk cmd 0x11 is just a hash (some kind of per psp signcheck) of the idstorage keys/certificate (themselves signed with an ECDSA key checked by cmd 0x12) Of course I assume cmd 0x11 could be used for other things than idstorage keys. It'd actually make sense to use it for drms. I posted the kirk cmd 0x11 key a few days ago along with its syntax. I'd also assume there are some official demos in iso format, I don't believe those would be encrypted with cmd 0x11 as they couldn't be shared from one psp to another (but perhaps that's the case)

Please check out my previous posts:

viewtopic.php?f=5&t=1381&start=190#p20780

viewtopic.php?f=5&t=1381&start=190#p20715

here is how idstorage keys signature are checked by cmd 0x12:
You can see the 6 PUB keys in there. (Did anyone check if sony use the same R on psp ?)

P.S. This code below wasn't written by me, I don't think the author would mind if I post it here but I rather ask him first before mentioning his nick in here.

Code: Select all

// protoyptes
int module_start(SceSize args, void *argp);
int sceVerifyFlashData(void);
int verifyCert(u8 *certBuf, u8 *certSig);

// buffer for 0x40 keys (0x100-0x13F)
u8 g_certBuf[0x200*0x40] __attribute__((aligned(64)));

u8 g_sigGen[0x20+0x14] __attribute__((aligned(64)));
u8 g_sigVry[0x28+0x14+0x28] __attribute__((aligned(64)));

u8 g_hashBuf[0x38] __attribute__((aligned(64)));
u8 *g_hash = g_hashBuf;

u8 g_certSig[0x28*6] __attribute__((aligned(64))) =
{
    // 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,

};



int module_start(SceSize args, void *argp)
{
    return 0;
}



int verifyCert(u8 *certBuf, u8 *certSig)
{
    // cert verify
    if (sceUtilsBufferCopyWithRange(NULL, 0, certBuf, 0xB8, 0x12) != 0)
        return -1;



    memcpy(&g_sigGen[0x00], &certBuf[0x88], 0x20);
    memset(&g_sigGen[0x20], 0, 0x14);

    // sig gen
    if (sceUtilsBufferCopyWithRange(g_sigGen, sizeof(g_sigGen), g_sigGen, sizeof(g_sigGen), 0x10) != 0)
        return -1;

    memcpy(&g_sigVry[0x00], &certBuf[0x10], 0x28);
    memset(&g_sigVry[0x28], 0, 0x14);
    memcpy(&g_sigVry[0x3C], &g_sigGen[0x00], 0x28);

    // sig verify
    if (sceUtilsBufferCopyWithRange(NULL, 0, g_sigVry, sizeof(g_sigVry), 0x11) != 0)
        return -1;
        
        

    if (memcmp(&certBuf[0x60], certSig, 0x28) != 0)
        return -1;



    *(int*)&g_hashBuf[0] = 0x38;
    memcpy(&g_hash[4], certBuf, 0x38);

    // sha1 hash
    if (sceUtilsBufferCopyWithRange(g_hash, sizeof(g_hashBuf), g_hash, sizeof(g_hashBuf), 0xB) != 0)
        return -1;

    memcpy(&g_sigVry[0x00], certSig, 0x28);
    memcpy(&g_sigVry[0x28], g_hash, 0x14);
    memcpy(&g_sigVry[0x3C], &certBuf[0x38], 0x28);

    // sig verify
    if (sceUtilsBufferCopyWithRange(NULL, 0, g_sigVry, sizeof(g_sigVry), 0x11) != 0)
        return -1;

        

    return 0;
}



int sceVerifyFlashData(void)
{
    // read keys 0x100-0x13F
    int i;
    for(i=0; i<0x40; i++)
    {
        if (sceIdStorageLookup(0x100+i, 0, &g_certBuf[0x200*i], 0x200) != 0)
            return -12;
    }



    // verify the 6 cert sections (key 0x100-0x102)
    u8 *certStart = &g_certBuf[0x38];

    if (verifyCert(&certStart[0xB8*0], &g_certSig[0x28*0]) < 0)
        return -14;

    if (verifyCert(&certStart[0xB8*1], &g_certSig[0x28*1]) < 0)
        return -15;

    if (verifyCert(&certStart[0xB8*2], &g_certSig[0x28*2]) < 0)
        return -16;

    if (verifyCert(&certStart[0xB8*3], &g_certSig[0x28*3]) < 0)
        return -17;

    if (verifyCert(&certStart[0xB8*4], &g_certSig[0x28*4]) < 0)
        return -18;

    if (verifyCert(&certStart[0xB8*5], &g_certSig[0x28*5]) < 0)
        return -19;



    // verify the backups (key 0x120-0x122)
    u8 *certBackupStart = &g_certBuf[(0x20*0x200)+0x38];

    if (verifyCert(&certBackupStart[0xB8*0], &g_certSig[0x28*0]) < 0)
        return -29;

    if (verifyCert(&certBackupStart[0xB8*1], &g_certSig[0x28*1]) < 0)
        return -30;

    if (verifyCert(&certBackupStart[0xB8*2], &g_certSig[0x28*2]) < 0)
        return -31;

    if (verifyCert(&certBackupStart[0xB8*3], &g_certSig[0x28*3]) < 0)
        return -32;

    if (verifyCert(&certBackupStart[0xB8*4], &g_certSig[0x28*4]) < 0)
        return -33;

    if (verifyCert(&certBackupStart[0xB8*5], &g_certSig[0x28*5]) < 0)
        return -34;



    // check keys 0x100-0x11F == keys 0x120-0x13F
    if (memcmp(&g_certBuf[0], &g_certBuf[0x20*0x200], 0x20*0x200) != 0)
        return -35;



    return 0;
}
P.S. I haven't touched the psp in ages and it could be that I have mixed up cmd 0x11 with cmd 0x12 and vice/versa, so please double check, it is very well possible that 0x11 checks the ecdsa while 0x12 does the signcheck.
Advertising
---
PGP Fingerprint: DF46 8C79 5D1A 76FF 75B2 C345 4679 EDEF 1B5B B192
Public Key: https://pgp.mit.edu/pks/lookup?op=get&search=0x1B5BB192

Proof: https://keybase.io/mathieulh

coyotebean
Guru
Posts: 96
Joined: Mon Sep 27, 2010 3:22 pm

Re: PS3 packages and how it leads to PSP signing

Post by coyotebean » Sat Jan 22, 2011 3:53 pm

I believe Cmd 0x11 is a standard ECDSA signature verification. It take 320bits (Public Key), sha1 hash, and another 320bits (R & S). With this signature verification, the private key is not fixed. The domain parameters of the curve need to be discovered in order to crack Cmd 0x11.

Sony does use the same R in signing firmware files and it looks like Cmd 1 uses a fixed public key (i.e. a fixed private key). I am no expert, but without the modulo N, I don't think the private key can be calculated.

That Cmd 0x10 to generate signature for verify with Cmd 0x11 looks interesting... would that be D & K in the input ??
Oh, Cmd 0x10 take 0x20+0x14 bytes input? Cmd 0x10 does generate validate signature for the 0x14 hash.

Summary above source (assuming 0x11 is really ECDSA signature verification):
The whole cert block is verify with Kirk Cmd 0x12 (possibly a hash check against 0xA8-0xB7?)
0x88-0xA7, append with 0x14 zero feed to Cmd 0x10 to produce (R1,S1) (Is this signature gen or just decrypt?)
Cmd 0x11 is performed using public key Q1 at 0x10-0x37, hash 0, (R1,S1) from above to verify
0x60-0x87 (Q2) is compared with supplied cert
Cmd 0x11 is performed using public key Q2, sha-1 of 0x00-0x37, (R2,S2) at 0x38-0x5F to verify
Last edited by coyotebean on Sun Jan 23, 2011 6:54 am, edited 1 time in total.
GBASP x1, GBM x2, NDSL x2, PSP 100X x3, PSP 200X x6, PSP 300X x5, PSP Go x4, Wii x1

silverspring
Guru
Posts: 12
Joined: Fri Jan 07, 2011 10:06 am

Re: about kirk cmd 0x11

Post by silverspring » Sun Jan 23, 2011 2:27 am

tpu wrote:I got this code from google:

Code: Select all

// KIRK cmd0x11
// pubkey is 320bit public key
// hash is SHA1 of data to verify
// sig is two 20Byte DSA signature from siggenint
sceDdrdbSigvry(u8 *pubkey, u8 *hash, u8 *sig)
{
	memcpy(g_buf, pubkey, 40);
	memcpy(g_buf+40, hash, 20);
	memcpy(g_buf+60, sig, 40);

	int res = sceUtilsBufferCopyWithRange(NULL, 0, g_buf, 100, 0x11);
	memset(g_buf, 0, 100);
	return(res ? 0x80530300 : 0);
}
Mathieulh: do you have more infomation for this cmd?
Yea I wrote that (you grabbed it from a pastebin right? dang googlebots, grabs everything). That was written a while back when I had to make assumptions about cmd0x11, I know a little bit more about it now.
Mathieulh wrote: P.S. This code below wasn't written by me, I don't think the author would mind if I post it here but I rather ask him first before mentioning his nick in here.

Code: Select all

// protoyptes
int module_start(SceSize args, void *argp);
int sceVerifyFlashData(void);
int verifyCert(u8 *certBuf, u8 *certSig);

// buffer for 0x40 keys (0x100-0x13F)
u8 g_certBuf[0x200*0x40] __attribute__((aligned(64)));

u8 g_sigGen[0x20+0x14] __attribute__((aligned(64)));
u8 g_sigVry[0x28+0x14+0x28] __attribute__((aligned(64)));

u8 g_hashBuf[0x38] __attribute__((aligned(64)));
u8 *g_hash = g_hashBuf;

u8 g_certSig[0x28*6] __attribute__((aligned(64))) =
{
    // 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,

};



int module_start(SceSize args, void *argp)
{
    return 0;
}



int verifyCert(u8 *certBuf, u8 *certSig)
{
    // cert verify
    if (sceUtilsBufferCopyWithRange(NULL, 0, certBuf, 0xB8, 0x12) != 0)
        return -1;



    memcpy(&g_sigGen[0x00], &certBuf[0x88], 0x20);
    memset(&g_sigGen[0x20], 0, 0x14);

    // sig gen
    if (sceUtilsBufferCopyWithRange(g_sigGen, sizeof(g_sigGen), g_sigGen, sizeof(g_sigGen), 0x10) != 0)
        return -1;

    memcpy(&g_sigVry[0x00], &certBuf[0x10], 0x28);
    memset(&g_sigVry[0x28], 0, 0x14);
    memcpy(&g_sigVry[0x3C], &g_sigGen[0x00], 0x28);

    // sig verify
    if (sceUtilsBufferCopyWithRange(NULL, 0, g_sigVry, sizeof(g_sigVry), 0x11) != 0)
        return -1;
        
        

    if (memcmp(&certBuf[0x60], certSig, 0x28) != 0)
        return -1;



    *(int*)&g_hashBuf[0] = 0x38;
    memcpy(&g_hash[4], certBuf, 0x38);

    // sha1 hash
    if (sceUtilsBufferCopyWithRange(g_hash, sizeof(g_hashBuf), g_hash, sizeof(g_hashBuf), 0xB) != 0)
        return -1;

    memcpy(&g_sigVry[0x00], certSig, 0x28);
    memcpy(&g_sigVry[0x28], g_hash, 0x14);
    memcpy(&g_sigVry[0x3C], &certBuf[0x38], 0x28);

    // sig verify
    if (sceUtilsBufferCopyWithRange(NULL, 0, g_sigVry, sizeof(g_sigVry), 0x11) != 0)
        return -1;

        

    return 0;
}



int sceVerifyFlashData(void)
{
    // read keys 0x100-0x13F
    int i;
    for(i=0; i<0x40; i++)
    {
        if (sceIdStorageLookup(0x100+i, 0, &g_certBuf[0x200*i], 0x200) != 0)
            return -12;
    }



    // verify the 6 cert sections (key 0x100-0x102)
    u8 *certStart = &g_certBuf[0x38];

    if (verifyCert(&certStart[0xB8*0], &g_certSig[0x28*0]) < 0)
        return -14;

    if (verifyCert(&certStart[0xB8*1], &g_certSig[0x28*1]) < 0)
        return -15;

    if (verifyCert(&certStart[0xB8*2], &g_certSig[0x28*2]) < 0)
        return -16;

    if (verifyCert(&certStart[0xB8*3], &g_certSig[0x28*3]) < 0)
        return -17;

    if (verifyCert(&certStart[0xB8*4], &g_certSig[0x28*4]) < 0)
        return -18;

    if (verifyCert(&certStart[0xB8*5], &g_certSig[0x28*5]) < 0)
        return -19;



    // verify the backups (key 0x120-0x122)
    u8 *certBackupStart = &g_certBuf[(0x20*0x200)+0x38];

    if (verifyCert(&certBackupStart[0xB8*0], &g_certSig[0x28*0]) < 0)
        return -29;

    if (verifyCert(&certBackupStart[0xB8*1], &g_certSig[0x28*1]) < 0)
        return -30;

    if (verifyCert(&certBackupStart[0xB8*2], &g_certSig[0x28*2]) < 0)
        return -31;

    if (verifyCert(&certBackupStart[0xB8*3], &g_certSig[0x28*3]) < 0)
        return -32;

    if (verifyCert(&certBackupStart[0xB8*4], &g_certSig[0x28*4]) < 0)
        return -33;

    if (verifyCert(&certBackupStart[0xB8*5], &g_certSig[0x28*5]) < 0)
        return -34;



    // check keys 0x100-0x11F == keys 0x120-0x13F
    if (memcmp(&g_certBuf[0], &g_certBuf[0x20*0x200], 0x20*0x200) != 0)
        return -35;



    return 0;
}
That's cool, I wrote this one too :p
I'm in the process of releasing everything I have anyway, don't have too much time these days to work on PSP.

Libre
Posts: 47
Joined: Sat Jan 01, 2011 4:51 pm

Re: PS3 packages and how it leads to PSP signing

Post by Libre » Tue Jan 25, 2011 8:20 pm

I'm kind of lost trying to encrypt a gzipped PRX.

I saw that Total Noob did it with his last TN-C HEN, using the psp & kirk header from the everybodys sukkiri demo.

My PRX file is compressed with 'gzip -n', which seems to give the right output, and then I encrypt it with prxencrypter (with new headers and size).
It works with prxdecrypter, but I got a 80020148 error on my PSP when I run it.

I'm wondering if the problem could be due to a bad crc check or something like that.
- should I add null offsets to my prx, to match the original file size, before gzip compression ?
- should I do the gzip compression before or after the CMAC forge trick ?

Proxima
Guru
Posts: 47
Joined: Mon Jan 03, 2011 2:38 pm

Re: PS3 packages and how it leads to PSP signing

Post by Proxima » Tue Jan 25, 2011 8:41 pm

The gzip file has to unzip to the ELF size listed in the header. You'll need to append 0s to the ELF until its the correct size, then gzip it and it should work better.

Libre
Posts: 47
Joined: Sat Jan 01, 2011 4:51 pm

Re: PS3 packages and how it leads to PSP signing

Post by Libre » Tue Jan 25, 2011 9:24 pm

Proxima wrote:The gzip file has to unzip to the ELF size listed in the header. You'll need to append 0s to the ELF until its the correct size, then gzip it and it should work better.
Thanks, it works better that way :)

421KB instead of 5454KB, it's nice.

TOcean
HBL Tester
Posts: 1020
Joined: Mon Sep 27, 2010 3:08 pm
Location: Flash0:/kd/vshmain.prx
Contact:

Re: PS3 packages and how it leads to PSP signing

Post by TOcean » Fri Jan 28, 2011 8:48 pm

liquidzigong found an bug:
BY ANONYMOUS ON THE 28TH OF JAN 2011 11:58:16 AMDOWNLOAD | RAW | EMBED | REPORT
diff -r 5b25b415c348 kirk_engine.c
--- a/kirk_engine.c Sun Jan 16 15:23:49 2011 +0000
+++ b/kirk_engine.c Sat Jan 29 01:58:25 2011 +0800
@@ -134,7 +134,7 @@
//Set the key
AES_ctx aesKey;
AES_set_key(&aesKey, key, 128);
- AES_cbc_encrypt(&aesKey, inbuff+sizeof(KIRK_AES128CBC_HEADER), outbuff, size);
+ AES_cbc_encrypt(&aesKey, inbuff+sizeof(KIRK_AES128CBC_HEADER), outbuff+sizeof(KIRK_AES128CBC_HEADER), size);

return KIRK_OPERATION_SUCCESS;
}
diff -r 5b25b415c348 kirk_engine.c
--- a/kirk_engine.c Sun Jan 16 15:23:49 2011 +0000
+++ b/kirk_engine.c Sat Jan 29 01:58:25 2011 +0800
@@ -134,7 +134,7 @@
//Set the key
AES_ctx aesKey;
AES_set_key(&aesKey, key, 128);
- AES_cbc_encrypt(&aesKey, inbuff+sizeof(KIRK_AES128CBC_HEADER), outbuff, size);
+ AES_cbc_encrypt(&aesKey, inbuff+sizeof(KIRK_AES128CBC_HEADER), outbuff+sizeof(KIRK_AES128CBC_HEADER), size);

return KIRK_OPERATION_SUCCESS;
}
source: http://pastebin.com/cKUgFnU3
source 2: https://twitter.com/liquidzigong

Draan
Posts: 72
Joined: Tue Dec 21, 2010 9:49 pm

Re: PS3 packages and how it leads to PSP signing

Post by Draan » Sat Jan 29, 2011 11:43 am

You're still using that stuff guyz? xP

Oh yeah, my bad. Silly bug ;)

Nickos_969
Posts: 1
Joined: Sat Jan 29, 2011 6:02 pm

Re: PS3 packages and how it leads to PSP signing

Post by Nickos_969 » Sat Jan 29, 2011 7:45 pm

Does it change something with the correction of the kirk-engine? How does it ruin Kirk_cmd4? :)

Post Reply

Return to “Programming and Security”