SceSblGcAuthMgr

SBL Game Card Auth Manager

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

command 0x1000B 0x18
224bit version of PSP Kirk 0x11 service

command 0x1000B 0x4
Original PSP Kirk 4 service for encrypting data

command 0x1000B 0x4
Original PSP Kirk 4 service for encrypting data

command 0x1000B 0x4
Original PSP Kirk 4 service for encrypting data

command 0x1000B 0x4
Original PSP Kirk 4 service for encrypting data

command 0x1000B 0x7
Original PSP Kirk 7 service for decrypting data

command 0x1000B 0x7
Original PSP Kirk 7 service for decrypting data

command 0x1000B 0x7
Original PSP Kirk 7 service for decrypting data

command 0x1000B 0x4 0x7
Original PSP Kirk Enc and Dec

enc_dec
Includes both AES and PSP Kirk 0x1000B 4 and 7.

error
Returns error 0x808A040A.

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

Buffer is obtained with KIRK command 0x20.

memcmp_safe_5018
Temp name was memcmp_5018_fast.

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

CMD56 response Buffer is obtained with KIRK command 0x20

For example it is called from SceAppMgr.

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

clear_sensitive_data
Clears some sensitive data.

Called after.

clear_sensitive_data_2
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.

SceSblGcAuthMgrAdhocBBForDriver
Present on FW 1.69. Not present on FWs >= 3.60.

SceSblGcAuthMgrPcactForDriver
This library is present on System Software versions 0.990.000-1.692.000. Not present since System Software version 1.80.

sceSblGcAuthMgrPcactActivationForDriver
Calls get_aes_dec_key then SceNpDrm set_act_data.

sceSblGcAuthMgrPcactGetChallengeForDriver
Calls.

get_aes_dec_key
aes_dec_key is derived from act_data. prng seems to be a temporary work buffer.

sceSblGcAuthMgrPkgVryForDriver
Calls Secure_Modules_Functions to verify PKG ECDSA signature.

SceSblGcAuthMgrSclkForDriver
Related to Secure clock.

sceSblGcAuthMgrSclkGetData1ForDriver
AES256ECB encrypts a buffer made from a "genuine random number" followed by zeroes.

sceSblGcAuthMgrSclkSetData2ForDriver
Checks header, sha256, AES256ECB decrypts then sets some secure RTC.

cmd56_handshake
This is a wrapper function that starts initialization subroutine through SceKernelThreadMgr.

get_act_data
Executes KIRK command 0x1000B 19.

sceSblGcAuthMgrMsSaveBBCipherInitForDriver
AES encrypts with null IV using a Kirk command.

sceSblGcAuthMgrMsSaveBBMacUpdateForDriver
AES encrypts a 0x800 buffer.

sceSblGcAuthMgrMsSaveBBCipherUpdateForDriver
AES decrypts a 0x800 buffer then AES decrypts with null IV using a Kirk command.

_sceSblGcAuthMgrGetMediaIdType01
Returns MediaIdType01 by using Kirk command 0x23 on a global buffer.

gcauthmgr_sm calls to Kirk commands in cmep
The use of os0:sm/gcauthmgr_sm.self is to support the new generation of Kirk. It uses a similar input structure to the original Kirk on the PSP.

PSP Kirk support
4, 7, 0xC, 0xD, 0xE, 0x10, 0x11, 0x12 are the classic PSP Kirk services supported by gcauthmgr_sm. However, keys and seeds are sometimes different and look similar to PS3 crypto.

New PS Vita Kirk services
0x14-0x19, 0x1B-0x23 are the new Kirk services supported by gcauthmgr_sm. Most are just 224bit versions of original Kirk commands.


 * 0x14 is the 224bit version of ECDSA key pair gen (Kirk command 0xC). 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 the 224bit version of pseudo random number generator (Kirk command 0xE). It will return 0x1C bytes of random data into the buffer.
 * 0x17-0x19 are the 224bit ECDSA versions of PSP's 160bit Kirk commands 0x10-0x12.
 * 0x1B-0x23 have no equivalent on PSP Kirk but are maybe also present on PS3

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. This error number is used in SceNpKdc, which is found in. The error code itself is created when the activation response is received:

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

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

The response you get on 3.60 is

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

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

It appears that data from  (see Secure Modules Functions) along with ,   (the RTC in seconds), DMAC engine, and maybe other data are entangled together into a 0x70-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 (almost same code as in PS Vita):

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 Cmep and therefore spoofing it would require a Cmep 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 PS Vita to PSN for Content and PSN Account (per-console) activations is not checked anymore. Strange...

I can think about 4 reasons:

1) Sony wanted to fight ReStore by killing its purpose. In this 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: Sony removed ConsoleId checks on its servers for 3 months, around 2016-11-11, then restored the verification with even more securities. In the PS Vita case, they would have been quicker at fixing the challenge if that was for security.

4) Sony is working on a big change of PSN. This is very plausible since we discovered that they are adapting old PSN to work with a new "Account Id" because now people can change Sony Entertainment Network (PSN) ID. Moreover, on 2022-05-10, Sony released System Software version 3.74 to enforce the two-factor authentication system. This change also targets PS3 and PS4 and makes ReStore totally obsolete if it was needed again.