SceSblGcAuthMgr

Module

Known NIDs

Version	Name	World	Privilege	NID
1.69	SceSblGcAuthMgr	Non-secure	Kernel	0x4B777EBC
3.60	SceSblGcAuthMgr	Non-secure	Kernel	0xDB1A9016

Libraries

Known NIDs

Version	Name	World	Visibility	NID
1.69	SceSblGcAuthMgrDrmBBForDriver	Non-secure	Kernel	0x1926B182
3.60	SceSblGcAuthMgrDrmBBForDriver	Non-secure	Kernel	0x1926B182
1.69	SceSblGcAuthMgrPcactForDriver	Non-secure	Kernel	0x0B8600A5
3.60	SceSblGcAuthMgrPcactForDriver	Non-secure	Kernel	NOT PRESENT
1.69	SceSblGcAuthMgrMlnpsnlForDriver	Non-secure	Kernel	0x29ED0109
3.60	SceSblGcAuthMgrMlnpsnlForDriver	Non-secure	Kernel	0x29ED0109
1.69	SceSblGcAuthMgrAdhocBBForDriver	Non-secure	Kernel	0x2EFA9203
3.60	SceSblGcAuthMgrAdhocBBForDriver	Non-secure	Kernel	NOT PRESENT
1.69	SceSblGcAuthMgrPkgForDriver	Non-secure	Kernel	0x82FBA7D
3.60	SceSblGcAuthMgrPkgForDriver	Non-secure	Kernel	0x082FBA7D
1.69	SceSblGcAuthMgrSclkForDriver	Non-secure	Kernel	0xF24F760D
3.60	SceSblGcAuthMgrSclkForDriver	Non-secure	Kernel	0xF24F760D
1.69	SceSblGcAuthMgrGcAuthForDriver	Non-secure	Kernel	0xC6627F5E
3.60	SceSblGcAuthMgrGcAuthForDriver	Non-secure	Kernel	0xC6627F5E
1.69	SceSblGcAuthMgr	Non-secure	User	0x7B13BCF7
3.60	SceSblGcAuthMgr	Non-secure	User	0x7B13BCF7
3.60	SceSblGcAuthMgrPsmactForDriver	Non-secure	Kernel	0x1C53F37D
3.60	SceSblGcAuthMgrMsSaveBBForDriver	Non-secure	Kernel	0x5032E8D4

Data segment layout

Address	Size	Description
0x0000	0x4BC4	unknown
0x4BC4	0x30	temp buffer for storing parts of cmd56 packets
0x4BF4	0x200	cmd56 request buffer
0x4DF4	0x04	packet6 gc parameter
0x4DF8	0x200	temp buffer for initializing cm56 req packets
0x4FF8	0x20	temp buffer for storing parts of cmd56 packets
0x5018	0x34	one of kirk responses
0x504C	0x200	cmd56 response buffer 1
0x524C	0x200	cmd56 response buffer 2
0x544C	0x20	one of kirk responses
0x546C	0x898	unknown

SceSblGcAuthMgrDrmBBForDriver

command 0x1000B 0x11

Version	NID
3.60	0x4CEA150C

Original PSP Kirk 0x11 service for 160bit ECC signature verification.

command 0x1000B 0x18

Version	NID
3.60	0x4B506BE7

Almost certainly a 224bit version of 0x11

command 0x1000B 0x21

Version	NID
3.60	0x30A0B441

command 0x1000B 0x22

Version	NID
3.60	0x050DC6DF

command 0x1000B 0x4

Version	NID
3.60	0x500F5157

Original PSP Kirk 4 service for encrypting data

command 0x1000B 0x4

Version	NID
3.60	0x6EF3C9DB

Original PSP Kirk 4 service for encrypting data

command 0x1000B 0x4

Version	NID
3.60	0x7F98E4E2

Original PSP Kirk 4 service for encrypting data

command 0x1000B 0x4

Version	NID
3.60	0xE950BE32

Original PSP Kirk 4 service for encrypting data

command 0x1000B 0x7

Version	NID
3.60	0x3C25F9FA

Original PSP Kirk 7 service for decrypting data

command 0x1000B 0x7

Version	NID
3.60	0xB13577E2

Original PSP Kirk 7 service for decrypting data

command 0x1000B 0x7

Version	NID
3.60	0xC0F37F18

Original PSP Kirk 7 service for decrypting data

command 0x1000B 0x4 0x7

Version	NID
3.60	0x4FE89ADB

Original PSP Kirk Enc and Dec

int unk_4FE89ADB(int unk0, int unk1, int unk2, int unk3, int arg_0);

clear_context

Version	NID
3.60	0x48D7784E

typedef struct ctx_48D7784E //size is 0x28
{
   uint32_t unk_0;
   char unk_4[0x10];
   char unk_14[0x10];
   uint32_t unk_24;
}ctx_48D7784E;

int clear_context(ctx_48D7784E *ctx, int idx);

clear_context

Version	NID
3.60	0x6E6D2B89

typedef struct ctx_6E6D2B89 //size is 0x18
{
   uint32_t unk_0;
   uint32_t unk_4;
   char unk_8[0x10];
}ctx_6E6D2B89;

int clear_context(ctx_6E6D2B89 *ctx);

enc_dec

Version	NID
3.60	0x4C5DE1AA

Includes both aes and psp kirk 0x1000B 4 and 7

int enc_dec(void* data, void* dec_rif_key, int unk2, void* unk3);

error

Version	NID
3.60	0x535B87BC

Returns error 0x808A040A.

get_5018_data

Version	NID
3.60	0xBB70DDC0

This function copies first 0x20 bytes of the buffer of size 0x34 to destination.

Buffer is obtained with KIRK command 0x20.

int get_5018_data(char* dest);

memcmp_5018_fast

Version	NID
3.60	0x22FD5D23

This function verifies that last 0x14 bytes of last response of size 0x34 from the game card (cmd56) are valid

CMD56 response is obtained with Buffer is obtained with KIRK command 0x20

For example it is called from sceAppMgrGameDataMount

int memcmp_5018_fast(char* in_data);

This is a timing safe memcmp. Xyz (talk) 10:02, 1 May 2017 (UTC)

clear_sensitive_data

Version	NID
3.60	0x812B2B5C

Clears some sensitive data.

Called after verify_checksum.

int clear_sensitive_data(int unk, int* value);

clear_sensitive_data

Version	NID
3.60	0xBB451E83

Clears sensitive data that is left after cmd56 custom initialization.

This includes data generated by Kirk services 0x1C, 0x1F, 0x20 and packet6.

Buffer offsets are 0x4BC4, 0x4FF8, 0x5018, 0x544C.

Called after initialize_sd_device.

int clear_sensitive_data();

SceSblGcAuthMgrAdhocBBForDriver

Present on 1.69. Not present on 3.60+.

SceSblGcAuthMgrPcactForDriver

Present on 1.69. Not present on 3.60+.

SceSblGcAuthMgrMlnpsnlForDriver

SceSblGcAuthMgrMlnpsnlForDriver_296ABD68

Version	NID
3.60	0x296ABD68

SceSblGcAuthMgrMlnpsnlForDriver_DABC01F5

Version	NID
3.60	0xDABC01F5

SceSblGcAuthMgrPkgForDriver

SceSblGcAuthMgrPkgForDriver_E459A9A8

Version	NID
3.60	0xE459A9A8

SceSblGcAuthMgrSclkForDriver

SceSblGcAuthMgrSclkForDriver_11D5570B

Version	NID
3.60	0x11D5570B

SceSblGcAuthMgrSclkForDriver_F723A9BA

Version	NID
3.60	0xF723A9BA

SceSblGcAuthMgrGcAuthForDriver

cmd56_handshake

Version	NID
3.60	0x68781760

This is a wrapper function that starts initialization subroutine through run_exclusively().

int cmd56_handshake(int sd_ctx_index);

SceSblGcAuthMgrPsmactForDriver

get_act_data

Version	NID
3.60	0x39222A58

Executes KIRK command 0x1000B 19.

// data is of size 0x80
int get_act_data(void* data);

SceSblGcAuthMgrMsSaveBBForDriver

SceSblGcAuthMgrMsSaveBBForDriver_3C185A67

Version	NID
3.60	0x3C185A67

SceSblGcAuthMgrMsSaveBBForDriver_4A249828

Version	NID
3.60	0x4A249828

SceSblGcAuthMgrMsSaveBBForDriver_79A9BE44

Version	NID
3.60	0x79A9BE44

SceSblGcAuthMgrMsSaveBBForDriver_805C860B

Version	NID
3.60	0x805C860B

SceSblGcAuthMgrMsSaveBBForDriver_8E6626A0

Version	NID
3.60	0x8E6626A0

SceSblGcAuthMgrMsSaveBBForDriver_F66D5F76

Version	NID
3.60	0xF66D5F76

SceSblGcAuthMgr

_sceSblGcAuthMgrPcactActivation

Version	NID
1.69	0x032E7CEA
3.60	0x032E7CEA

_sceSblGcAuthMgrMsSaveBBCipherInit

Version	NID
3.60	0x064BA38A

_sceSblGcAuthMgrAdhocBB160Shutdown

Version	NID
3.60	0x076ADAB3

_sceSblGcAuthMgrGetMediaIdType01

Version	NID
1.69	0x0AC64154
3.60	0x0AC64154

_sceSblGcAuthMgrAdhocBB224Auth1

Version	NID
1.69	0x307FD67C
3.60	0x307FD67C

_sceSblGcAuthMgrPkgVry

Version	NID
1.69	0x3E168BC4
3.60	0x3E168BC4

_sceSblGcAuthMgrAdhocBB224Auth5

Version	NID
1.69	0x459F5503

_sceSblGcAuthMgrAdhocBB224Init

Version	NID
1.69	0x5AB126A7

_sceSblGcAuthMgrAdhocBB224Auth4

Version	NID
1.69	0x5CCC216C

_sceSblGcAuthMgrAdhocBB224Auth2

Version	NID
1.69	0x788C0517

_sceSblGcAuthMgrSclkSetData2

Version	NID
1.69	0x837D0FB6

_sceSblGcAuthMgrSclkGetData1

Version	NID
1.69	0x8A3AF1E8

_sceSblGcAuthMgrAdhocBB224Shutdown

Version	NID
1.69	0x8ECEACF9

_sceSblGcAuthMgrPcactGetChallenge

Version	NID
1.69	0x98153286

_sceSblGcAuthMgrAdhocBB224GetKeys

Version	NID
1.69	0xC236FB28

_sceSblGcAuthMgrAdhocBB224Auth3

Version	NID
1.69	0xD3F95259

gcauth_sm "KIRK" calls to F00D

The use of os0:sm/gcauthmgr_sm.self is to support the next generation of KIRK. It uses a similar input structure to the original KIRK on the PSP.

PSP support

4, 7, 0xC, 0xD, 0xE, 0x10, 0x11, 0x12 are the classic PSP KIRK Services supported by gcauth_sm.

New PSVita Codes

0x14-0x19, 0x1B-0x23 are the new KIRK Services supported by gcauth_sm.

0x14 is the 224bit ecdsa keypair gen. The only input is an empty buffer size (3*0x1C) it returns 3 values. Private key, Public X point, Public Y point. Each value is 0x1C bytes long.

0x16 is random 224bit generator. It will return 0x1C bytes of random data into the buffer. 0x17-0x19 are the 224bit ecdsa versions of PSP's 160bit 0x10-0x12.

PSN Activation Block

On 7/29/2017, all hacked Vitas on 3.60 spoofing the latest firmware (3.65) were blocked from console activation. This is particularly odd because the PSN passphrase did not change in 3.65. Additionally with the release of [ensō](https://enso.henkaku.xyz/) added to the confusion of what happened. Here is the result of a preliminary investigation of the situation.

Upon game activation, the Vita displays an dialog that shows the error number E-80558325. This error number is used in SceNpKdc, which is found in vs0:external/np_kdc.suprx. The error code itself is created when the activation response is received:

v5 = v45 | 0x80558300;

Here, v5 is the return code and v45 is the string error code from the server converted to a number. The request made to Sony's server looks like the following

Content-Type: application/x-www-form-urlencoded
User-Agent: My heart leaps up when I behold A rainbow in the sky
X-I-5-DRM-Version: 1.0

loginid=PSNID&epassword=ENCRYPTEDPASSWORD&platform=psp2&c1=CHALLENGESTRING

The request from a 3.65 stock console has the same headers and loginid and epassword (for the same account) so the only change visible to Sony is the challenge string c1.

The response you get on 3.60 is

HTTP/1.0 200 OK
Server: Apache
X-I-5-DRM-Version: 1.0
X-I-5-DRM-Status: NG; reason=25
Content-Length: 0
Content-Type: application/x-i-5-drm
X-N: S
Date: Sat, 29 Jul 2017 23:01:31 GMT
Connection: keep-alive

Challenge

The challenge string is constructed in SceNpKdc with a call to SceLibKernel_9557D15C. Farther investigation shows that SceLibKernel_9557D15C likely has the following call type:

int sceKernelPcactGetChallenge(int id, const char entropy[32], char challenge[128]);

It is called with id = 0 and entropy set to uninitialized stack space. Tracing this call, you eventually arrive at a kernel function in SceSblGcAuthMgrPcactForDriver with the NID 0xB7AE58B9. This call looks like the following

typedef struct {
    uint8_t length;      // must be 16
    uint8_t unk[15];     // must all be 0
    uint8_t entropy[32]; // from user
} challengeInput_t;

int createPcactChallenge(int id, const challengeInput_t *in, uint64_t *rtc_seconds, char challenge[128], char output[16]);

It appears that data from aimgr_sm.self (F00D Commands) along with in, rtc_seconds (the RTC in seconds), DMAC engine, and maybe other data are entangled together into a 112 byte sized block. Then a 20 byte SHA1-HMAC is computed over the buffer with some key. It is likely that the data itself is unimportant and just has to be random and console unique.

This is the challenge string generation code, reverse engineered from PSP openpsid.prx (same code as in vita):

#define KIRK_CMD_ENCRYPT_IV_0 4
#define KIRK_CMD_DECRYPT_IV_0 7
#define KIRK_CMD_SHA1_HASH 11
#define KIRK_CMD_PRNG 14

static int DecryptIV0(u32 *buf, u32 size, u32 code) {
	buf[0] = 5;
	buf[1] = 0;
	buf[2] = 0;
	buf[3] = code;
	buf[4] = size;

	return sceUtilsBufferCopyWithRange(buf, size+0x14, buf, size+0x14, KIRK_CMD_DECRYPT_IV_0);
}

static int EncryptIV0(u32 *buf, u32 size, u32 code) {
	buf[0] = 4;
	buf[1] = 0;
	buf[2] = 0;
	buf[3] = code;
	buf[4] = size;

	return sceUtilsBufferCopyWithRange(buf, size+0x14, buf, size+0x14, KIRK_CMD_ENCRYPT_IV_0);
}

static int generate_challenge(u8 mode, u8 *psid, u8 *entropy, u64 *rtc_tick, u8 *challenge, u8 *prng) {
	static u8 data_38BC[0x10] = { 0x38, 0x0A, 0x18, 0x0E, 0x36, 0x58, 0xBC, 0xC1, 0x70, 0x64, 0x69, 0xE3, 0x29, 0x60, 0x81, 0xF9 };
	static u8 data_38DC[0x10] = { 0xCA, 0x0E, 0x20, 0x6E, 0xCE, 0xE6, 0xFB, 0x66, 0x68, 0x28, 0x65, 0x42, 0xEF, 0x4F, 0xF8, 0x8F };
	static u8 work[0xB8];
	static u8 challenge_work[0x70];

	int res;
	int i;

	memset(work, 0, 0xB8);
	memset(challenge_work, 0, 0x70);

	memset(challenge, 0, 0x80);
	memset(prng, 0, 0x40);

	// get random data
	res = sceUtilsBufferCopyWithRange(work, 0x14, 0, 0, KIRK_CMD_PRNG);
	if (res < 0)
		return -2;

	memcpy(prng, work, 0x10);

	// encrypt prng
	memcpy(work+0x14, prng, 0x10);
	res = DecryptIV0(work, 0x10, 0x68);
	if (res < 0)
		return -3;

	memcpy(prng+0x10, work, 0x10);
	prng[0x20] = mode;

	memcpy(challenge_work, work, 0x10);              // random data
	memcpy(challenge_work+0x10, data_38DC, 0x10);    // constant data

	// encrypt psid
	memcpy(work+0x14, psid, 0x10);
	res = DecryptIV0(work, 0x10, 0x68);
	if (res < 0)
		return -3;

	memcpy(challenge_work+0x20, work, 0x10);         // encrypted psid
	memcpy(challenge_work+0x30, rtc_tick, 0x8);      // rtc tick 
	memcpy(challenge_work+0x38, entropy+0x10, 0x20); // entropy, 32 bytes of epassword

	// fuseid
	u32 fuseid0 = *(u32 *)0xBC100090;
	u32 fuseid1 = *(u32 *)0xBC100094;
	challenge_work[0x58] = fuseid1 >> 24;
	challenge_work[0x59] = fuseid1 >> 16;
	challenge_work[0x5A] = fuseid1 >> 8;
	challenge_work[0x5B] = fuseid1;
	challenge_work[0x5C] = fuseid0 >> 24;
	challenge_work[0x5D] = fuseid0 >> 16;
	challenge_work[0x5E] = fuseid0 >> 8;
	challenge_work[0x5F] = fuseid0;

	memcpy(work+0x14, challenge_work, 0x60);

	// xor with data_38BC keys
	for (i = 0; i < 0x60; i++) {
		work[0x14+i] ^= data_38BC[i % 0x10];
	}

	// encrypt data
	res = EncryptIV0(work, 0x60, 0x13);
	if (res < 0)
		return -4;
	
	// xor encrypted data with data_38BC keys
	for (i = 0; i < 0x60; i++) {
		work[0x14+i] ^= data_38BC[i % 0x10];
	}

	// build challenge string
	memset(challenge_work, 0, 0x10);
	challenge_work[0x00] = 0x11;
	challenge_work[0x01] = 0x01;
	challenge_work[0x02] = mode;
	memcpy(challenge_work+0x10, work+0x14, 0x60);

	// get sha1 hash digest
	*(u32 *)work = 0x80;
	memcpy(work+0x04, data_38BC, 0x10);
	memcpy(work+0x14, challenge_work, 0x70);
	res = sceUtilsBufferCopyWithRange(work, 0x84, work, 0x84, KIRK_CMD_SHA1_HASH);
	if (res < 0)
		return -5;

	// encrypt hash digest
	memcpy(work+0x14, work, 0x10);
	res = EncryptIV0(work, 0x10, 0x13);
	if (res < 0)
		return -4;

	// copy challenge string
	memcpy(challenge, challenge_work, 0x70);
	memcpy(challenge+0x70, work+0x14, 0x10);

	return 0;
}

How Sony Blocked Activation

There are at least two possible ways. First is that on 3.65, the random-looking data block has some specific structure that Sony looks for (or some console unique data in this block gives away the fact that the console is on 3.60). Second is that they changed the SHA1-HMAC key. If it is the latter case, then the next step is to find how this key is constructed. It is likely that the key is constructed in F00D and therefore spoofing it would require a F00D hack.

How Hackers Bypassed The Block

See ReStore / ReNpDrm vulnerability by CelesteBlue.

How Sony Unblocked Activation

Since May 2018, the challenge string in requests sent from PSVita to PSN for Content and PSN Account activations is not checked anymore. Strange...

I can think about 4 reasons:

1) Sony wanted to fight ReStore by killing its purpose. In that case, they would have better patched the vulnerability...

2) Sony has done that by mistake. Impossible.

3) Sony is working on a more secure PSN. We have an exemple: when Sony removed ConsoleId checks on its servers for 3 months, then restored the check with even more securities. In the PSVita case, they would have been quicker at fixing challenge if that was for security.

4) Sony is working on a big change of PSN. This is very plausible since we discovered they are adapting old PSN to work with a new "Account Id" because now people can change PSN ID.