SceSblGcAuthMgr

Secure BootLoader GameCard Auth Manager

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

command 0x1000B 0x18
Almost certainly a 224bit version of 0x11

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_5018_fast
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

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
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 1.69. Not present on 3.60+.

SceSblGcAuthMgrPcactForDriver
Present on 0.990-1.69. Not present on 3.60+.

sceSblGcAuthMgrPcactActivationForDriver
Calls get_aes_dec_key then SceNpDrm set_act_data.

sceSblGcAuthMgrPcactGetChallengeForDriver
Calls SceSblGcAuthMgrPcactForDriver_B7AE58B9.

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

sceSblGcAuthMgrPkgVryForDriver
Calls F00D_Commands to verify PKG ECDSA signature.

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

get_act_data
Executes KIRK command 0x1000B 19.

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. 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  (F00D Commands) along with ,   (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):

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.