Shield Server Handling

TSecLoaderMiscData (size: 0x120 = 288 bytes):

struct {
u8 bootStrapperSignature[16];
u8 snippetSignature[16];
u8 snippetCodeIV[16];
u8 globalDataSignature[16];
u8 globalDataIV[16];
u32_t flags;
u32_t returnCode;
u32 version;
u32 fps;
u8 stateSignature[16];
u8 randSignature[16];
BootstrapState boot;
RandState rnd;
ProtocolState proto;
}

BootstrapState (size 0x30 = 48 bytes):

struct {
ServerState ttl;
u8_t init;
u8_t ttl_adjusted;
u8 pad[6];
u32_t ttr_count;
u32_t ttl_count;
}

ServerState (size 0x20 =  32 bytes)

struct {
u32_t ttl;
u32_t ttr;
u32 nonce[2];
u8 snippetSignature[16];
}

RandState (size 0x30 = 48 bytes):

struct {
u8 seed[16];
u32_t ctr;
u8 pad[12];
u32 nonce[2];
u8 pad2[8];
}

ProtocolState (size 0x40 = 64 bytes):

struct {
u8 sessionId[16];
u8 sessionKey[16];
u8 R[16];
u32 nonce[2];
u8 pad[8];
}




My god the debug stuff has the server point of view included rofl, this might actually still be happening!

1. Client Out ---> ServerChallengeIn (0x50 = 80 bytes):

struct {
u8 falconVersion[64];
u8 UID[16]; //always e816ebb8-44b7-3a37-9398-47ec566a63cd on Pheenohs Shield (since it claims to be unique this might be the android device id)
}

2. ServerChallengeOut ---> ClientChallengeIn (size 0x20 =  32 bytes)

struct {
u8 challenge[16]; //always "0x2E2E2E2E NVSI_2.0 0x2E2E2E2E"
u8 R1[16]; //16 random bytes. Wouldnt be surprised if the actual challenge the client needs to solve is to XOR them with the challenge bytes or the UID (or both)
}

the server sends more data after those 32 bytes but since its always the same stuff it doesnt matter)

3. ClientAuthenticateDeviceOut ---> ServerAuthenticateDeviceIn (size 0x34 = 52 bytes):

struct {
u8 UID[16]; //repeat of UID from Client Out ---> ServerChallengeIn Stage
u8 keyboxId[16]; //Always 6235D3E3 30DEC513 4DC9DABB 59FF02F6 (e3d33562-de30-13c5-c94d-ff59bbdaf602) for Pheenoh. Since the prior and next content is probably device unique this one is probably too (hence "device auth"). Probably an Android Keybox request ID.
u8 AID[4]; //always 0x1C1DFE67 for Pheenohs Shield. Read in from the "sys/devices/platform/tegra-fuse/aid" file. Probably device unique
u8 R1[16]; //the solved challenge submitted by the server
}

4. ServerAuthenticateDeviceOut ---> Client (size 0x40 = 64 bytes):

struct {
u8 sessionKey[16]; //the session key. appears to be random
u8 sessionId[16]; //the id for this session, probably entirely random too. Maybe the keyboxId comes into play here somehow
u8 R2[16]; //another random 16 bytes
u8 signature[16]; //this should sign the prior 48 bytes so the client can confirm its authenticity. Probably a hash checksum
}

(Server seems to send an .img file afterwards, perhaps the challenger.img used for the very next step, always identical)


5. Client sends the Session Data off for further processing to the TSecProtocolSessionIn (size: 0xC0 = 192 bytes) :

struct {
u8 sessionKey[16];
u8 sessionId[16];
u8 R2[16];
u8 signature[16]; //up to here should be a 1:1 match for what the server put out
u8 appName[128]; //"com.nvidia.nintendo.twipri", this must have some use, maybe used in de/encryption
}

6. GPU finishes processing and spits out TSecProtocolSessionOut (size: 0xC0 = 192 bytes):

struct {
u8 appName[128]; //"com.nvidia.nintendo.twipri" or already truncated to "ndo.twipri"
u8 sessionId[16]; //transformed session id ; perhaps by using the session key. Does not use R3 or signature since those can already differ
u8 R2[16]; //transformed R2 ; perhaps using the session key. Does not use R3 or signature since those can already differ
u8 R3[16]; //new 16 random bytes generated by the GPU. Future new session key?
u8 signature[16]; //this should sign the prior 48 bytes (maybe the app name too) so the client can confirm its authenticity. Probably a hash checksum
}

7. Client ---> ServerGenerateNonceIn (size: 0xC4 = 196):

struct {
u32 appNameL; //no clue, but always 0x0000001A
u8 appName[128]; //truncated app name. "com.nvidia.nintendo.twipri" turns into "ndo.twipri"
u8 sessionId[16]; //the transformed session id
u8 R2[16]; //transformed R2
u8 R3[16]; //16 random bytes
u8 signature[16]; //signature, random due R3 being random
}

8. Server ---> Client: (size 0x50 = 80 bytes):

struct
{
u8 nonce[16]; //random 16 byte nonce
u8 sessionId[16]; //warped session id, possibly by using R3 or R2
u8 R3[16]; //warped R3, possibly by using R3 or R2 (I think R2 is still used so the key is not used to encrypt itself)
u8 R4[16]; //another random 16 bytes
u8 signature[16]; //this should sign the prior 48 bytes (or all 64 of them) so the client can confirm its authenticity. Probably a hash checksum
}


9. Client ---> TSecProtocolNonceIn (size 0x50 = 80 bytes):

struct {
u8 nonce[16]; //nonce 1:1 as send by the server
u8 sessionId[16]; //warped session id by R2
u8 R3[16]; //warped R3 by R2 (we fail this Stage right here atm)
u8 R4[16]; //new random 16 bytes
u8 signature[16]; //signature for 48 or 64 byes
}

10. TSecProtocolNonceOut (size 0x50 = 80 bytes):

struct {
u8 nonce[16]; //nonce 1:1 as send by the server
u8 sessionId[16]; //warped session id by R3
u8 R4[16]; //warped R4 by R3
u8 R5[16]; //new random 16 bytes
u8 signature[16]; //sig for 48 (or unlikely 64) bytes
}

11. 3rd Party Server is contacted with Nonce. Gets a reply with response and sig and verifies it being okay

12. Client packages giant response package including code_snippet.img

13. Client ---> ServerValidateLicenseIn (size 0x44 = 68 bytes, 104 with padding):

struct {
u8 sessionId[16]; //warped session id by r3
u8 R4[16]; //warped R4 by R3
u8 R5[16]; //new random 16 bytes
u8 signature[16]; //sig for 48 bytes
//some consistent padding (36 bytes)
u32 responseL; //response code from 3rd party = 0x00AC0231 ("1") if the check passed
}

//|response|sig follow from 3rd party, then code_snippet.img

14. Server ---> Client

struct {

u8 weirdSig[16] //mirror of an IV?

//ttl and ttr follow

u8 weirdSig2[8] //mirror of a sig or final new nonce?
u8 sessionId[16]; //warped session id by R4
u8 R5[16]; //warped R5 by R4
u8 R6[16]; //new random 16 bytes or signature (since no more send operations after this one)

//several img files, sig files and iv files follow. img files with a corresponding iv file are encrypted by it

u8 weirdSig3[16]; //mirror of a sig or actual signature?

--->Needs a lot more testing lol