Ernie Secure: Difference between revisions

From Vita Development Wiki
Jump to navigation Jump to search
m (Yifan Lu moved page Private:Ernie Secure to Ernie Secure without leaving a redirect)
m (→‎SNVS: Add note on SNVS sector 1)
 
(21 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== SNVS ==
For security reasons, sensitive Ernie commands packets are encrypted with a per-session key. This key is generated and shared at second_loader stage through a '''handshake''' between cMeP and Ernie. SNVS (Secure NVS) is a part of NVS that is XTS encrypted and can only be accessed using Ernie secure command 0xD2. eMMC is also XTS encrypted and is accessed with the same command.


The syscon provides raw storage. Kermit partitions some of this storage for encrypted data. The keys to encrypt/decrypt this data is from slots 0x502-0x504. They are derived by second_loader by encrypting a constant buffer with key slot 0x216 using AES-256-CBC, which is console unique. Consoles with factory firmware < 0.996 use a set of static keys found in second_loader. Factory firmware comes from idstorage.
See also [[Ernie Firmware]].


== Shared Secrets ==
= Ernie Secure Packets =


{| class="wikitable sortable"
Packets sent/received with Ernie command 0xD2 are AES-128-ECB encrypted with the Ernie communication session key (stored in [[DMAC#Bigmac_Key_Ring|Cmep keyring 0x511]]).
|-
 
! Class !! Shared Key A !! Shared Key B !! Shared Key C !! Shared Data A !! Shared Data B
There is a 4 byte command field, 4 byte counter (from Cmep keyring 0x512) that increments per send, 6 bytes of zeros, optional data, and a 2 byte checksum. The checksum is the sum of all previous bytes and then negated.
|-
 
| 0xB || <code>BB644721CB4C55072E83177BEB3BBEE9</code> || <code>DC6B6EE0F457DF0E7BAD1C5EA338027F</code> || <code>00000000000000000000000000000000</code> || <code>CF2E93E9F94E28CCA48026134C7C77CE</code> ||
<source lang="C">
|-
// 30 02 00 0F (step 2, keyset 15)
| 0xF || <code>50E4C3A77264167C409C72A9B57A8609</code> || <code>9E34087C48985B4B351A63572D9B481B</code> || <code>EBE3460D84A41754AC441368CF0200D8</code> || <code>C86B51FB019A207F32118E55462D5008</code> || <code>457798C6D9B8390DDCA49745746F65A000000000000000000000000000000000</code>
typedef struct ernie_packet_handshake_step_2_data_plain { // size is 0x20
|-
    char cmep_challenge[8]; // random from Cmep PRNG
|}
    char ernie_challenge[8]; // random from Ernie during step 1
    char step2_passphrase[0x10]; // hardcoded
} ernie_packet_handshake_step_2_data_plain;
 
// 30 04 00 0F (step 4, keyset 15)
typedef struct ernie_packet_handshake_step_4_data_plain { // size is 0x20
    char step4_5_passphrase[0x10]; // hardcoded
    char padding[0x10];
} ernie_packet_handshake_step_4_data_plain;
 
typedef struct ernie_secure_packet { // size is 0x28
    char unk_0; // 0x30 for commands 0xA0, 0xD0
    char step; // 0-5 for command 0xD0
    char unk_2; // usually 0, 0x20 (command 0xD2)
    char keyset; // 6 (?SNVS?), 11 (command 0xA0), 14 (SNVS), 15 (command 0xD0)
    SceUInt32 unk_4; // zeroed or not
    char enc_data[0x20]; // AES128ECB with key = Cmep keyring 0x511, or with the corresponding Step Key for commands 0xA0 and 0xD0
} ernie_secure_packet;
</source>
 
= Ernie Secure Commands =
 
== Command 0xA0 ==
 
This command uses keyset 11 and is only seen in second_loader. No data transfer is seen. The Ernie communication session key derived here is actually not used. The hypothesis is that this handshake serves as a checkpoint for Ernie to know that cMeP has successfully decrypted ConsoleId and OpenPsId since in between the handshake each decryption happens. The decryption does not use any data from this handshake.
 
== Command 0xD0 ==
 
This command establishes a handshake with keyset 15. It is used by updater_service_sm command 0xD0002 as well as second_loader.
 
After handshake:
* Cmep keyring 0x511 is programmed with the Ernie communication session key.
* Cmep keyring 0x512 is programmed with a 32 bit random number from Cmep PRNG.
 
== Command 0xD2 ==
 
Command for SNVS read/write.
 
=== Boot dumps ===
 
First transaction (Mgmt Data read):
 
cMeP => Ernie: <code>00 00 20 00 47 D3 65 F4 00 00 00 00 00 00 6C FD</code>
 
cMeP <= Ernie: <code>00 00 20 00 47 D3 65 F4 00 00 00 00 00 00 01 DD C7 AB 57 AD 28 9E 00 93 51 F8 D3 D2 29 2E 78 B6 8C 63 5A 26 7A A9 6B C8 E3 AC F3 3D 61 77 F0 EC</code>
 
SNVS sector is decrypted using a Cmep keyring in 0x502-0x504 and result (Mgmt Data) is written to Cmep keyring 0x50B (8 bytes).
 
Second transaction (Current firmware version read):
 
cMeP => Ernie:  <code>20 00 20 00 48 D3 65 F4 00 00 00 00 00 00 4B FD</code>
 
cMeP <= Ernie:  <code>20 00 20 00 48 D3 65 F4 00 00 00 00 00 00 95 AD 79 D1 FE 5E 96 4B 3F 66 7D 47 04 28 05 E9 EB D1 26 86 E2 C1 9B 7B 53 B6 D3 11 76 8F 2D 3F 80 ED</code>
 
Decrypted is a list of versions, two are read using some information from the MBR. Those are both checked to be 0x03600000 on 3.60 (hard coded). If they are 0xDEADBEEF, the check is skipped. Additionally, in the decrypted buffer from the previous command (written to Cmep keyring 0x50B), if bit 1 at byte offset 0x4 is set, then the version check is skipped. Then, if boot is not resume the version from kernel_boot_loader.self is also checked. Finally slot 0x50E and 0x518 are written with these two version codes.
 
= Ernie Secure Handshake =
 
This handshake is used totally or partially by Ernie secure commands 0xA0 and 0xD0.
 
== Step 0: cMeP challenges Ernie ==
 
# cMeP generates an empty buffer <code>30 00 00 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00</code> and sends it to Ernie.


== Syscon four part key exchange ==
== Step 1: Ernie returns Ernie Challenge ==


The <code>0F</code> here appears to be a class id. Only <code>0F</code> and <code>0B</code> has been seen but only <code>0F</code> seems to be supported by the update sm using the command [[F00D_Commands#0xD0002|0xD0002]] (with different sequence number for each part).
# Ernie returns header <code>30 01 00 0F 00 00 00 00</code> + 8 byte Ernie Challenge.


=== Part 1: Ernie challenges Kermit ===
== Step 2: cMeP sends cMeP Challenge ==
# Generate an empty buffer <code>30 00 00 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00</code> and send it to Syscon.
# Syscon returns header <code>30 01 00 0F 00 00 00 00</code> + 8 byte challenge.


=== Part 2: Kermit responds and challenges Ernie ===
# cMeP composes a data buffer that is 8 bytes of RNG value, 8 byte Ernie Challenge from step 1, and 16 bytes of '''Step 2 Passphrase'''.
# F00D composes a data buffer that is 8 bytes of RNG value, 8 bytes copied from challenge in part 1.2, and 16 bytes of '''Shared Data A'''.
# cMeP encrypts this data using AES-128-ECB and '''Step 2 Key'''.
# This data is encrypted using AES-128-CBC with all zero IV and '''Shared Key A''' as the key.
# cMeP appends the header <code>30 02 00 0F 01 00 00 00</code> and sends to Ernie.
# A header is prepended <code>30 02 00 0F 01 00 00 00</code> to the data and sent to Syscon


=== Part 3: Session Key Establishment ===
== Step 3: Ernie confirms it has received cMeP Challenge ==
# Gets a 0x28 byte response from Syscon with a header <code>30 03 00 0F 00 00 00 00</code> and 0x20 buffer.
# Decrypt with AES-128-CBC with all zero IV and the key '''Shared Key B'''.
# Check that first 8 byte matches the challenge from part 1.2 and next 8 byte matches the F00D nonce generated in part 2.1. The remaining 16 bytes are zero.
# Encrypt the same buffer back using '''Shared Key C''' for 16 bytes. The IV will be the last 16 bytes from the encrypted input buffer.
# This is now the session key!


=== Part 4: Verification ===
# Ernie returns header <code>30 03 00 0F 00 00 00 00</code> and a 0x20 byte encrypted buffer.
# Using the session key, encrypt a known value, '''Shared Data B'''.
# cMeP decrypts it with AES-128-ECB and '''Step 3 Key'''.
# Append the header <code>30 04 00 0F 00 00 00 00</code> and send to Syscon
# cMeP checks that first 8 byte matches the Ernie Challenge from step 2 and next 8 byte matches the cMeP Challenge generated in step 2. The remaining 16 bytes are zero.
# Get a response back from Syscon (header <code>30 05 00 0F 00 00 00 00</code>), decrypt the buffer with the session, and check that it matches the known value. Both the plaintext and ciphertext should match.
This part is only seen used with command 0xD0 and not 0xA0.


=== Channel Protocol ===
== Step 3 bis: cMeP registers the Ernie Communication Session Key ==


Packets sent/received with command 0xD2 are encrypted with the session key and IV = 0. There is a 4 byte command field, 4 byte counter (from keyslot 0x512) that increments per send, 6 bytes of zeros, optional data, and a 2 byte checksum. The checksum is the sum of all previous bytes and then negated.
# The following operations are only done with Ernie command 0xD0 as it is the only one that registers the Ernie communication session key, once for all.
# cMeP AES-128-ECB encrypts the same 16 byte challenge buffer using '''Ernie Communication Session Key Master Key'''.
# This is the '''Ernie Communication Session Key'''. cMeP registers it into Cmep keyring 0x511.


== Syscon 0xA0 ==
== Step 4: cMeP tells Ernie to register the Ernie Communication Session Key ==
This command uses class 0xB and is only seen in secure_loader. No data transfer is seen. The session key derived here is actually not used. The hypothesis is that this handshake serves as a checkpoint for the Syscon to know that F00D has successfully decrypted IDPS and OpenPSID since in between the handshake each decryption happens. The decryption does not use any data from this handshake.


== Syscon 0xD0 ==
# Using the Ernie communication session key, cMeP encrypts a known value, '''Step 4-5 Passphrase'''.
Establishes a secure channel for class 0xF used by updater 0xD0002 as well as second_loader.
# cMeP appends the header <code>30 04 00 0F 00 00 00 00</code> and sends to Ernie.
# Ernie decrypts the received data and checks that the passphrase is valid.
# Ernie generates the '''Ernie Communication Session Key''' the same way as cMeP and registers it in its memory.


After handshake:
== Step 5: cMeP receives Ernie encrypted packet for Ernie Communication Session Key verification ==


Keyslot 0x511 is programmed with the session key.
# cMeP gets a response back from Ernie (header <code>30 05 00 0F 00 00 00 00</code>), decrypts the encrypted data with the '''Ernie communication session key''', and checks that it matches the '''Step 4-5 Passphrase'''.


Keyslot 0x512 is programmed with a 32 bit random number from Bigmac.
= Ernie Secure Keysets =


== Syscon 0xD2 ==
{| class="wikitable"
Data transfer for class 0xF.
|-
! Keyset !! Usage !! Syscon command !! RPC command
|-
| 0 || start/enter SD boot mode || ?none? || 0x110
|-
| 1 || unlock T2 || ?none? || 0x110
|-
| 4 || Jig || ? by pm_sm ||
|-
| 6 || Jig || ? by pm_sm ||
|-
| 11 || Hello || 0xD2 by second_loader ||
|-
| 12 || Jig || ? by pm_sm ||
|-
| 14 || SNVS/Jig - unlock T8 || 0xD2 by second_loader, ? by pm_sm || 0x110
|-
| 15 || Handshake for boot and Syscon firmware update (derives Ernie communication session key for Cmep keyring 0x511) || 0xD0 by updater_service_sm command 0xD0002 and second_loader ||
|}


=== Seen at boot ===
= SNVS =


First transaction
Ernie provides raw storage in its Data Flash memory, named NVS (Non-Volatile Storage) by SCE. The PS Vita OS partitions some of this storage for encrypted data. The keys to encrypt/decrypt these data are from Cmep keyrings 0x502-0x504. They are derived by second_loader by encrypting a seed using AES-256-CBC with Cmep keyring 0x216, which is console unique. Consoles with minimum firmware < 0.996 use a set of static keys found in second_loader. Minimum firmware comes from IdStorage SMI leaf.


F00D => Syscon: <code>00 00 20 00 47 D3 65 F4 00 00 00 00 00 00 6C FD</code>
Sectors where data is written are encrypted with AES-XTS.


F00D <= Syscon: <code>00 00 20 00 47 D3 65 F4 00 00 00 00 00 00 01 DD C7 AB 57 AD 28 9E 00 93 51 F8 D3 D2 29 2E 78 B6 8C 63 5A 26 7A A9 6B C8 E3 AC F3 3D 61 77 F0 EC</code>
1 sector is 0x20 bytes.


Data decrypted using a slot in 0x502-0x504 and result is written to slot 0x50B (8 bytes).
<source lang="C">
typedef struct SceMgmtData { // size is 0x20-bytes. for SNVS sector 0.
SceUInt32 magic;
SceUInt32 version;
SceUInt32 status; // ((status & 1) != 0): manu mode/((status & 2) != 0): sd mode
SceUInt32 flags; // ((flags & 1) == 0): SNVS inited/((flags & 2) == 0): QAF inited
SceUInt8 cmac[0x10];
} SceMgmtData;
</source>


Second transaction
{| class="wikitable"
|-
! Sector pos !! nSector !! Comment !! Used by
|-
| 0 || 1 || A special SNVS sector called "Mgmt Data". Embeds SNVS flags and ProductMode. Used for Update, PM and QAF. || "sceSblQafManagerSetFlag" (sub_81001610 on FW 0.990), "SpkgInfoUtilGetSNVSFlagStatus" and "SpkgInfoUtilSetSNVSFlagStatus" (on FW 0.931), setProductMode
|-
| 1 || 1 || System Software version info.
[0] = SLB2 Bank 0 SdkVersion


F00D => Syscon:  <code>20 00 20 00 48 D3 65 F4 00 00 00 00 00 00 4B FD</code>
[1] = SLB2 Bank 1 SdkVersion
| ?SceSblUpdateMgr when updating any component?
|-
| 2 || 1 || Processor version info. (Current System Software version, Syscon version, unknown processor, CP version) || ?SceSblUpdateMgr when updating any component?
|-
| 3 || 2 || Some flags. ||
|-
| 5 || 1 || Active SLB2 sha256. || SceSblUpdateMgr when updating SLB2.
|-
| 6 || 1 || Inactive SLB2 sha256. || SceSblUpdateMgr when updating SLB2.
|-
| 7 || 3 || Unknown sectors. ||
|-
| 0xA || 1 || Battery HW info, Battery FW info, unknown info. || SceSblUpdateMgr when updating Battery IC firmware.
|-
| 0xB || 0xA || Unknown sectors. Filled by 0xDEADBEEF. ||
|-
| 0x15 || 1 || QA Flag Version. 0x10 bytes data + 0x10 bytes AES256CMAC. If not QA Flagged unit, 0xFFed with non XTS encrypted. || "sceSblQafManagerSetQaFlagVersion" on FW 0.940
|-
| 0x16 || 0xA || Unknown. 0xFFed. ||
|}


F00D <= Syscon:  <code>20 00 20 00 48 D3 65 F4 00 00 00 00 00 00 95 AD 79 D1 FE 5E 96 4B 3F 66 7D 47 04 28 05 E9 EB D1 26 86 E2 C1 9B 7B 53 B6 D3 11 76 8F 2D 3F 80 ED</code>


Decrypted is a list of versions, two are read using some information from the MBR. On a default 3.60 retail system, the two offsets used are at 0x4 and 0x8. Those are both checked to be 0x03600000 on 3.60 (hard coded). If they are 0xDEADBEEF, the check is skipped. Additionally, in the decrypted buffer from the previous command (written to slot 0x50B), if bit 1 at byte offset 0x4 is set, then the version check is skipped. Then, if boot is not resume the version from kernel_boot_loader.self is also checked. Finally slot 0x50E and 0x518 are written with these two version codes.
[[Category:Syscon]]

Latest revision as of 09:27, 11 August 2024

For security reasons, sensitive Ernie commands packets are encrypted with a per-session key. This key is generated and shared at second_loader stage through a handshake between cMeP and Ernie. SNVS (Secure NVS) is a part of NVS that is XTS encrypted and can only be accessed using Ernie secure command 0xD2. eMMC is also XTS encrypted and is accessed with the same command.

See also Ernie Firmware.

Ernie Secure Packets

Packets sent/received with Ernie command 0xD2 are AES-128-ECB encrypted with the Ernie communication session key (stored in Cmep keyring 0x511).

There is a 4 byte command field, 4 byte counter (from Cmep keyring 0x512) that increments per send, 6 bytes of zeros, optional data, and a 2 byte checksum. The checksum is the sum of all previous bytes and then negated. 

// 30 02 00 0F (step 2, keyset 15)
typedef struct ernie_packet_handshake_step_2_data_plain { // size is 0x20
    char cmep_challenge[8]; // random from Cmep PRNG
    char ernie_challenge[8]; // random from Ernie during step 1
    char step2_passphrase[0x10]; // hardcoded
} ernie_packet_handshake_step_2_data_plain;

// 30 04 00 0F (step 4, keyset 15)
typedef struct ernie_packet_handshake_step_4_data_plain { // size is 0x20
    char step4_5_passphrase[0x10]; // hardcoded
    char padding[0x10];
} ernie_packet_handshake_step_4_data_plain;

typedef struct ernie_secure_packet { // size is 0x28
    char unk_0; // 0x30 for commands 0xA0, 0xD0
    char step; // 0-5 for command 0xD0
    char unk_2; // usually 0, 0x20 (command 0xD2)
    char keyset; // 6 (?SNVS?), 11 (command 0xA0), 14 (SNVS), 15 (command 0xD0)
    SceUInt32 unk_4; // zeroed or not
    char enc_data[0x20]; // AES128ECB with key = Cmep keyring 0x511, or with the corresponding Step Key for commands 0xA0 and 0xD0
} ernie_secure_packet;

Ernie Secure Commands

Command 0xA0

This command uses keyset 11 and is only seen in second_loader. No data transfer is seen. The Ernie communication session key derived here is actually not used. The hypothesis is that this handshake serves as a checkpoint for Ernie to know that cMeP has successfully decrypted ConsoleId and OpenPsId since in between the handshake each decryption happens. The decryption does not use any data from this handshake.

Command 0xD0

This command establishes a handshake with keyset 15. It is used by updater_service_sm command 0xD0002 as well as second_loader.

After handshake:

  • Cmep keyring 0x511 is programmed with the Ernie communication session key.
  • Cmep keyring 0x512 is programmed with a 32 bit random number from Cmep PRNG.

Command 0xD2

Command for SNVS read/write.

Boot dumps

First transaction (Mgmt Data read):

cMeP => Ernie: 00 00 20 00 47 D3 65 F4 00 00 00 00 00 00 6C FD

cMeP <= Ernie: 00 00 20 00 47 D3 65 F4 00 00 00 00 00 00 01 DD C7 AB 57 AD 28 9E 00 93 51 F8 D3 D2 29 2E 78 B6 8C 63 5A 26 7A A9 6B C8 E3 AC F3 3D 61 77 F0 EC

SNVS sector is decrypted using a Cmep keyring in 0x502-0x504 and result (Mgmt Data) is written to Cmep keyring 0x50B (8 bytes).

Second transaction (Current firmware version read):

cMeP => Ernie: 20 00 20 00 48 D3 65 F4 00 00 00 00 00 00 4B FD

cMeP <= Ernie: 20 00 20 00 48 D3 65 F4 00 00 00 00 00 00 95 AD 79 D1 FE 5E 96 4B 3F 66 7D 47 04 28 05 E9 EB D1 26 86 E2 C1 9B 7B 53 B6 D3 11 76 8F 2D 3F 80 ED

Decrypted is a list of versions, two are read using some information from the MBR. Those are both checked to be 0x03600000 on 3.60 (hard coded). If they are 0xDEADBEEF, the check is skipped. Additionally, in the decrypted buffer from the previous command (written to Cmep keyring 0x50B), if bit 1 at byte offset 0x4 is set, then the version check is skipped. Then, if boot is not resume the version from kernel_boot_loader.self is also checked. Finally slot 0x50E and 0x518 are written with these two version codes.

Ernie Secure Handshake

This handshake is used totally or partially by Ernie secure commands 0xA0 and 0xD0.

Step 0: cMeP challenges Ernie

  1. cMeP generates an empty buffer 30 00 00 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 and sends it to Ernie.

Step 1: Ernie returns Ernie Challenge

  1. Ernie returns header 30 01 00 0F 00 00 00 00 + 8 byte Ernie Challenge.

Step 2: cMeP sends cMeP Challenge

  1. cMeP composes a data buffer that is 8 bytes of RNG value, 8 byte Ernie Challenge from step 1, and 16 bytes of Step 2 Passphrase.
  2. cMeP encrypts this data using AES-128-ECB and Step 2 Key.
  3. cMeP appends the header 30 02 00 0F 01 00 00 00 and sends to Ernie.

Step 3: Ernie confirms it has received cMeP Challenge

  1. Ernie returns header 30 03 00 0F 00 00 00 00 and a 0x20 byte encrypted buffer.
  2. cMeP decrypts it with AES-128-ECB and Step 3 Key.
  3. cMeP checks that first 8 byte matches the Ernie Challenge from step 2 and next 8 byte matches the cMeP Challenge generated in step 2. The remaining 16 bytes are zero.

Step 3 bis: cMeP registers the Ernie Communication Session Key

  1. The following operations are only done with Ernie command 0xD0 as it is the only one that registers the Ernie communication session key, once for all.
  2. cMeP AES-128-ECB encrypts the same 16 byte challenge buffer using Ernie Communication Session Key Master Key.
  3. This is the Ernie Communication Session Key. cMeP registers it into Cmep keyring 0x511.

Step 4: cMeP tells Ernie to register the Ernie Communication Session Key

  1. Using the Ernie communication session key, cMeP encrypts a known value, Step 4-5 Passphrase.
  2. cMeP appends the header 30 04 00 0F 00 00 00 00 and sends to Ernie.
  3. Ernie decrypts the received data and checks that the passphrase is valid.
  4. Ernie generates the Ernie Communication Session Key the same way as cMeP and registers it in its memory.

Step 5: cMeP receives Ernie encrypted packet for Ernie Communication Session Key verification

  1. cMeP gets a response back from Ernie (header 30 05 00 0F 00 00 00 00), decrypts the encrypted data with the Ernie communication session key, and checks that it matches the Step 4-5 Passphrase.

Ernie Secure Keysets

Keyset Usage Syscon command RPC command
0 start/enter SD boot mode ?none? 0x110
1 unlock T2 ?none? 0x110
4 Jig ? by pm_sm
6 Jig ? by pm_sm
11 Hello 0xD2 by second_loader
12 Jig ? by pm_sm
14 SNVS/Jig - unlock T8 0xD2 by second_loader, ? by pm_sm 0x110
15 Handshake for boot and Syscon firmware update (derives Ernie communication session key for Cmep keyring 0x511) 0xD0 by updater_service_sm command 0xD0002 and second_loader

SNVS

Ernie provides raw storage in its Data Flash memory, named NVS (Non-Volatile Storage) by SCE. The PS Vita OS partitions some of this storage for encrypted data. The keys to encrypt/decrypt these data are from Cmep keyrings 0x502-0x504. They are derived by second_loader by encrypting a seed using AES-256-CBC with Cmep keyring 0x216, which is console unique. Consoles with minimum firmware < 0.996 use a set of static keys found in second_loader. Minimum firmware comes from IdStorage SMI leaf.

Sectors where data is written are encrypted with AES-XTS.

1 sector is 0x20 bytes. 

typedef struct SceMgmtData { // size is 0x20-bytes. for SNVS sector 0.
	SceUInt32 magic;
	SceUInt32 version;
	SceUInt32 status; // ((status & 1) != 0): manu mode/((status & 2) != 0): sd mode
	SceUInt32 flags; // ((flags & 1) == 0): SNVS inited/((flags & 2) == 0): QAF inited
	SceUInt8 cmac[0x10];
} SceMgmtData;
Sector pos nSector Comment Used by
0 1 A special SNVS sector called "Mgmt Data". Embeds SNVS flags and ProductMode. Used for Update, PM and QAF. "sceSblQafManagerSetFlag" (sub_81001610 on FW 0.990), "SpkgInfoUtilGetSNVSFlagStatus" and "SpkgInfoUtilSetSNVSFlagStatus" (on FW 0.931), setProductMode
1 1 System Software version info.

[0] = SLB2 Bank 0 SdkVersion

[1] = SLB2 Bank 1 SdkVersion

?SceSblUpdateMgr when updating any component?
2 1 Processor version info. (Current System Software version, Syscon version, unknown processor, CP version) ?SceSblUpdateMgr when updating any component?
3 2 Some flags.
5 1 Active SLB2 sha256. SceSblUpdateMgr when updating SLB2.
6 1 Inactive SLB2 sha256. SceSblUpdateMgr when updating SLB2.
7 3 Unknown sectors.
0xA 1 Battery HW info, Battery FW info, unknown info. SceSblUpdateMgr when updating Battery IC firmware.
0xB 0xA Unknown sectors. Filled by 0xDEADBEEF.
0x15 1 QA Flag Version. 0x10 bytes data + 0x10 bytes AES256CMAC. If not QA Flagged unit, 0xFFed with non XTS encrypted. "sceSblQafManagerSetQaFlagVersion" on FW 0.940
0x16 0xA Unknown. 0xFFed.
Retrieved from "http://wiki.henkaku.xyz/index.php?title=Ernie_Secure&oldid=21322"