PS3 HAN PS3Xploit v3 HAN/HFW SPRX Module and Library Replacer

[pinky]

yeah, I'd suggest PUAD. just select dev_flash . the other options will decrypt various files of the flash. you don't need that for sprx files and han.

 

[k9mo]

Simply extracting, I use PUAD to extract the Dev flash files from pups.

Thanks bro

yeah, I'd suggest PUAD. just select dev_flash . the other options will decrypt various files of the flash. you don't need that for sprx files and han.

Thanks

 

[junaid]

but how to know which sprx to replace?

 

[pinky]

but how to know which sprx to replace?

xmb_plugin.sprx iirc. I think it shows your ip address or something on the bottom right area of the xmb.

 

[junaid]

xmb_plugin.sprx iirc. I think it shows your ip address or something on the bottom right area of the xmb.

is there a documentation on all of them?

 

[esc0rtd3w]

but how to know which sprx to replace?

that's where the fun begins

 

[junaid]

that's where the fun begins

Should I start cuz I have transferred them into the extra directories. Anything particular to look out for ? are there any triggers or something? Also should i copy the rco cuz in some cases they are different than ofw

 

[esc0rtd3w]

Should I start cuz I have transferred them into the extra directories. Anything particular to look out for ? are there any triggers or something?

although the DEX SPRX will load, additional VSH memory patches probably required (similar to HAN Enabler) to make use of certain functions

 

[k9mo]

although the DEX SPRX will load, additional VSH memory patches probably required (similar to HAN Enabler) to make use of certain functions

Are those patches possible through the current userland exploit (same exploit used for HAN)??

 

[esc0rtd3w]

Are those patches possible through the current userland exploit (same exploit used for HAN)??

of course

we can patch any part of the VSH memory

 

[pinky]

off topic, but @esc0rtd3w , I just realized that you had four links in your sig. I think the limit used to be 3. I just added my ps vita tutorials to mine after seeing that. I just wish we could have around six or seven for my other tutorials.

 

[esc0rtd3w]

i started testing and adding SPRX files from DEX that work on 4.82 CEX.

i added them to OP, and will update as i go

..and yes xmb_plugin.sprx does work and shows the ip address on XMB!

 

[junaid]

So you are testing on 4.82. Well I'm try them all on 4.81 and report my findings. I got the dex from psdevwiki so I assume it must be the real deal.

 

[junaid]

Also have a few more questions.

1. How will I know if it worked? Should I assume it worked if the console reboots?

2. Can I edit the html to add more than one sprx at a time?

3. Some RCO and xml are of different sizes so should I add them?

 

[Squaardo]

[QUOTE = "esc0rtd3w, post: 114038, membre: 28568"] NON !! maintenant partez [/ QUOTE]
Est-ce un site web public ...

 

[junaid]

found something which might explain things a bit

NPDRM Self algorithm

THIS DOES NOT ALLOW TO OBTAIN 3.60+ keys

On NPDRM self decryption all the security levels of the PS3 are involved: user space (vsh), kernel space(lv2), hypervisor( lv1) and isolated SPU (metldr + appldr)

The process start on vsh.elf...

VSH:

Once the vsh detects that user is trying to start a self, it looks for the appinfo header type. If the type is 8, then the control digest element type 3 (NPD element) is located. From this NPD header the vsh gets the license type (free, local or network license).

If a free content(type 3) is detected then a generic klicense will be use for further steps (go to LV2). That klicensee is already public (see geohot npdrm_omac_key_1).

However if a paid content is to be loaded the vsh loads the act.dat and the rif associated to the content (if local it will locate a file with the same titleid on NPD element, if remote it will download to vsh process memory)

Then the signature is checked (last 0x28 bytes of both RIF and act.dat). The curves used are on vsh.self. It is a 3 element table, having the first curve nulled. The curve index for rif/act is 2. The curve values are negated as in the apploader and has the following structure

struct curve {
uint8_t p[0x14];
uint8_t a[0x14];
uint8_t b[0x14];
uint8_t N[0x14];
uint8_t Gx[0x14];
uint8_t Gy[0x14];
}

If the curve checks then vsh will process the rif:

struct rif {
uint8_t unk1[0x10]; //version, license type and user number
uint8_t titleid[0x30]; //Content ID
uint8 padding[0xC]; //Padding for randomness
uint32_t actDatIndex; //Key index on act.dat between 0x00 and 0x7F
uint8 key[0x10]; //encrypted klicensee
uint64_t unk2; //timestamp??
uint64_t unk3; //Always 0
uint8_t rs[0x28];
};

struct ACTDAT {
uint8_t unk1[0x10]; //Version, User number
uint8_t keyTable[0x800]; //Key Table
......
uint8_t signature[0x28];
}

Using the RIF_KEY it will obtain the actdatIndex:

AES_KEY rifKey;
int result = AES_set_decrypt_key(RIF_KEY, 0x80, &rifKey);
AES_decrypt(&rif->padding, &rif->padding, &rifKey);

And finally having the actDat key index the execution pass to LV2 syscall 471

LV2

Lv2 is accessed using syscall471 which haves the following syntax:

int syscall_471(uint32_t type, char* titleID, void* klicensee, uint8_t* actdat, uint8_t* rif, int32_t licenseType, uint8_t* magicVersion);

The function has different parameters depending if the content is debug, free or paid:

FREE: syscall471(npd.type, &npd.titleID, freeklicensee, NULL, NULL, npd.license, &npd);
PAID: syscall471(npd.type, &npd.titleID, NULL, &actdat.keyTable[rif.actDatIndex*0x10], &rif.key, npd.license, &npd);

The lv2 keeps a memory table with contentID and the associated key.
When it receives a free content (r5 is not null) then copies the titleID and the klicensee to the table. For a paid content the rif.key is converted to the klicensee using:

AES_KEY IDPSKey, ConstKey, ActDatKey;
uint8_t encrConst[0x10];
uint8_t decryptedActDat[0x10];
uint8_t klicensee[0x10];
int result = AES_set_encrypt_key(&IDPSVariation, 0x80, &IDPSKey);
AES_encrypt(&CONSTACTDAT, &encrConst, &IDPSKey);
result = AES_set_decrypt_key(&encrConst,0x80,&ConstKey);
AES_decrypt(actDat,&decryptedActDat,&ConstKey);
result = AES_set_decrypt_key(&decryptedActDat,0x80,&ActDatKey);
AES_decrypt(rif,&klicensee,&ActDatKey);


where CONSTACTDAT is a constant value on lv2, IDPSVaritaion appears to be IDPS (not checked but DRM_Manager_initialize (see graf_chokolo's "bible") to something with the same structure), actdat are the 0x10bytes selected by rif keyIndex, and rif is rif.key (bytes 0x50-0x5f).

Once transformed it is stored on memory table...

I haven't check further steps on vsh nor lv2 so perhaps there are further transformations on the paid case (NOT FOR THE FREE AS I HAVE DECRYPTED THOSE) so we are jumping directly to the appldr

AppLdr

As you can see from graf_chokolo payloads a parameter is passed on spu_args.field60. That parameter is the previously stored klicensee.

However this key must be transformed (again) even for the free case. The transformation is:

uint8_t decryptedKLicensee[0x10]
AES_KEY KLicenseeKey
int result = AES_set_decrypt_key(&KLicenseeDecryptKey,0x80,&KLICENSEEKEY);
AES_decrypt(klicensee,&decryptedKLicensee,&KLicenseeKey);
EY is another key located inside the apploader and klicensee is the parameter.

Then we can finally remove the NPDRM layer using:


AES_KEY key;
uint8_t iv[0x10];
memset(&iv[0],0,0x10);
int result = AES_set_decrypt_key(&KLicenseeDecryptKey,0x80,&key);
AES_cbc_encrypt(self + self->metaoffset + 0x20, self + self->metaoffset + 0x20,0x40,&key,&iv,0);

Once that layer is removed we proceed as normal:
-Decrypt using AESCBC256 with the NPDRM keys to obtain the metadata keys
-Decrypt using AESCTR128 the data sha,hmac,iv keys
-Decrypt the data.

SOURCE​

 

[DeViL303]

found something which might explain things a bit

NPDRM Self algorithm

THIS DOES NOT ALLOW TO OBTAIN 3.60+ keys

On NPDRM self decryption all the security levels of the PS3 are involved: user space (vsh), kernel space(lv2), hypervisor( lv1) and isolated SPU (metldr + appldr)

The process start on vsh.elf...

VSH:

Once the vsh detects that user is trying to start a self, it looks for the appinfo header type. If the type is 8, then the control digest element type 3 (NPD element) is located. From this NPD header the vsh gets the license type (free, local or network license).

If a free content(type 3) is detected then a generic klicense will be use for further steps (go to LV2). That klicensee is already public (see geohot npdrm_omac_key_1).

However if a paid content is to be loaded the vsh loads the act.dat and the rif associated to the content (if local it will locate a file with the same titleid on NPD element, if remote it will download to vsh process memory)

Then the signature is checked (last 0x28 bytes of both RIF and act.dat). The curves used are on vsh.self. It is a 3 element table, having the first curve nulled. The curve index for rif/act is 2. The curve values are negated as in the apploader and has the following structure

struct curve {
uint8_t p[0x14];
uint8_t a[0x14];
uint8_t b[0x14];
uint8_t N[0x14];
uint8_t Gx[0x14];
uint8_t Gy[0x14];
}

If the curve checks then vsh will process the rif:

struct rif {
uint8_t unk1[0x10]; //version, license type and user number
uint8_t titleid[0x30]; //Content ID
uint8 padding[0xC]; //Padding for randomness
uint32_t actDatIndex; //Key index on act.dat between 0x00 and 0x7F
uint8 key[0x10]; //encrypted klicensee
uint64_t unk2; //timestamp??
uint64_t unk3; //Always 0
uint8_t rs[0x28];
};

struct ACTDAT {
uint8_t unk1[0x10]; //Version, User number
uint8_t keyTable[0x800]; //Key Table
......
uint8_t signature[0x28];
}

Using the RIF_KEY it will obtain the actdatIndex:

AES_KEY rifKey;
int result = AES_set_decrypt_key(RIF_KEY, 0x80, &rifKey);
AES_decrypt(&rif->padding, &rif->padding, &rifKey);

And finally having the actDat key index the execution pass to LV2 syscall 471

LV2

Lv2 is accessed using syscall471 which haves the following syntax:

int syscall_471(uint32_t type, char* titleID, void* klicensee, uint8_t* actdat, uint8_t* rif, int32_t licenseType, uint8_t* magicVersion);

The function has different parameters depending if the content is debug, free or paid:

FREE: syscall471(npd.type, &npd.titleID, freeklicensee, NULL, NULL, npd.license, &npd);
PAID: syscall471(npd.type, &npd.titleID, NULL, &actdat.keyTable[rif.actDatIndex*0x10], &rif.key, npd.license, &npd);

The lv2 keeps a memory table with contentID and the associated key.
When it receives a free content (r5 is not null) then copies the titleID and the klicensee to the table. For a paid content the rif.key is converted to the klicensee using:

AES_KEY IDPSKey, ConstKey, ActDatKey;
uint8_t encrConst[0x10];
uint8_t decryptedActDat[0x10];
uint8_t klicensee[0x10];
int result = AES_set_encrypt_key(&IDPSVariation, 0x80, &IDPSKey);
AES_encrypt(&CONSTACTDAT, &encrConst, &IDPSKey);
result = AES_set_decrypt_key(&encrConst,0x80,&ConstKey);
AES_decrypt(actDat,&decryptedActDat,&ConstKey);
result = AES_set_decrypt_key(&decryptedActDat,0x80,&ActDatKey);
AES_decrypt(rif,&klicensee,&ActDatKey);


where CONSTACTDAT is a constant value on lv2, IDPSVaritaion appears to be IDPS (not checked but DRM_Manager_initialize (see graf_chokolo's "bible") to something with the same structure), actdat are the 0x10bytes selected by rif keyIndex, and rif is rif.key (bytes 0x50-0x5f).

Once transformed it is stored on memory table...

I haven't check further steps on vsh nor lv2 so perhaps there are further transformations on the paid case (NOT FOR THE FREE AS I HAVE DECRYPTED THOSE) so we are jumping directly to the appldr

AppLdr

As you can see from graf_chokolo payloads a parameter is passed on spu_args.field60. That parameter is the previously stored klicensee.

However this key must be transformed (again) even for the free case. The transformation is:

uint8_t decryptedKLicensee[0x10]
AES_KEY KLicenseeKey
int result = AES_set_decrypt_key(&KLicenseeDecryptKey,0x80,&KLICENSEEKEY);
AES_decrypt(klicensee,&decryptedKLicensee,&KLicenseeKey);
EY is another key located inside the apploader and klicensee is the parameter.

Then we can finally remove the NPDRM layer using:


AES_KEY key;
uint8_t iv[0x10];
memset(&iv[0],0,0x10);
int result = AES_set_decrypt_key(&KLicenseeDecryptKey,0x80,&key);
AES_cbc_encrypt(self + self->metaoffset + 0x20, self + self->metaoffset + 0x20,0x40,&key,&iv,0);

Once that layer is removed we proceed as normal:
-Decrypt using AESCBC256 with the NPDRM keys to obtain the metadata keys
-Decrypt using AESCTR128 the data sha,hmac,iv keys
-Decrypt the data.

SOURCE​

That is not related to sprx really. Also you won't find something like that 7 year old info that team ps3xploit does not already know about. Especially not stuff like that based on grafs Bible.

https://www.theregister.co.uk/2011/02/28/jailbreaker_defies_sony/

 

[Ps3_dev]

i started testing and adding SPRX files from DEX that work on 4.82 CEX.

i added them to OP, and will update as i go

..and yes xmb_plugin.sprx does work and shows the ip address on XMB!

Success with xmb_plugin what is the uses of wedftp_severe

 

[junaid]

@esc0rtd3w I edited the html to select multiple sprx but will it work? or just copy the first one?

 

[aldostools]

@esc0rtd3w is it possible to replace vsh.self with this tool? Or is there a "self replacer" incoming?