Memory Card: Difference between revisions

From Vita Development Wiki
Jump to navigation Jump to search
No edit summary
 
(8 intermediate revisions by 5 users not shown)
Line 2: Line 2:


Memory Card can be accessed with [[SceMsif]] module. It has the following [[Partitions|partitions]]:
Memory Card can be accessed with [[SceMsif]] module. It has the following [[Partitions|partitions]]:
{| class="wikitable"
{| class="wikitable"
|-
|-
! code !! type !! name !! desc
! code !! type !! offset !! size !! name !! description
|-
|-
| 0xD || raw || || Some data
| 0xD || raw || 0x400000 || 0x400000 || || Some data
|-
|-
| 0x8 || exfat || ux0 || Memory Card
| 0x8 || exfat || 0x800000 || (mc size - 0x800000) || ux0 || Memory Card contents
|-
|-
|}
|}


== Findings about Memory Card ==
== mediaid ==


It turns out that memory card supports standard Memory Stick protocol (TPC).
Memory Card <code>raw</code> partition contains so called mediaid data. It can be accessed as <code>sdstor0:mcd-lp-act-mediaid</code>. One of the important fields in this partition is a field that stores special <code>sleep_session_id</code>. This is a random number that is generated and stored there before PS Vita goes to sleep mode. Upon wakeup this <code>sleep_session_id</code> is verified and error is shown if the value is unexpected, which leads to power off. Hence why one cannot swap Memory Card while PS Vita is in sleep mode.


Msif driver allows to read and write single values on memory card according to the (TPC) protocol.
== Findings about Memory Card ==


It can also read and write chunks of data from memory card using (TPC) protocol.
It turns out that Memory Card supports standard Memory Stick protocol (TPC).


It is still not confirmed, however based on some findings in Msif driver, it is hypothesized that Vita`s memory card
[[SceMsif]] driver allows to read and write single values on Memory Card according to the (TPC) protocol. It can also read and write chunks of data from Memory Card using (TPC) protocol.
is simply new generation of memory stick with additional auth layer.  
These findings include:


* Support of TPC protocol
It is still not confirmed, however based on some findings in [[SceMsif]] driver, it is hypothesized that PSVita Memory Card is simply a new generation of Memory Stick with additional authentication layer. These findings include:
* Msif driver contains code that can handle <code>Model Name Device Information Entry</code> (In attribute area of the card). This code clearly shows that standard Memory Stick should be supported.
* Support of TPC protocol.
* Dump of real memory card shows, that <code>Attribute Information Area Confirmation Structure</code> is valid.
* [[SceMsif]] driver contains code that can handle <code>Model Name Device Information Entry</code> (in attribute area of the Memory Card). This code clearly shows that standard Memory Stick should be supported.
* Dump of real Memory Card shows that <code>Attribute Information Area Confirmation Structure</code> is valid.


== Memory Card Initialization ==
== Memory Card Initialization ==


Much like SD standard allows execution of vendor specific commands through CMD56, Vita's memory card has specific commands 0x48, 0x49, 0x4A and 0x4B.
Much like SD standard allows execution of vendor specific commands through CMD56, PS Vita Memory Card has specific commands 0x48, 0x49, 0x4A and 0x4B. To be able to read from Memory Card, it has to be properly initialized with commands 0x48 and 0x49 first. It is not completely tested yet, but commands 0x4A and 0x4B are probably not required, and used by PS Vita to check that Memory Card is genuine.
 
To be able to read from memory card, it has to be properly initialized with commands 0x48 and 0x49 first.
 
It is not completely tested yet, but commands 0x4A and 0x4B are probably not required, and used by Vita to check that memory card is genuine.
 
Memory card initialization also uses F00D [[F00D_Commands#rmauth_sm.self|rmauth_sm.self]] services 1 and 2.
 
Service 1 is used to obtain some data from F00D (1 byte).
 
Service 2 is used to set key, that is obtained from memory card, into slot 0x1C of [[Dmac5#Key_slots|SceSblDMAC5DmacKRBase]] keyring.
 
For encryption during memory card auth [[SceMsif]] driver uses 3-DES-CBC-CTS cipher.
 
Key that is returned from the card is unique to the card and is signed with ECDSA224 signature (custom curve).
 
This signature is verified by Msif driver.
 
Table of ECDSA224 parameters is stored in data section of Msif driver.


Table of ECDSA224 parameters is encrypted with AES-128-CBC (this still have to be doublechecked).
Memory card initialization also uses [[Secure_Modules_Functions#rmauth_sm.self|rmauth_sm.self]] functions 1 and 2. Function 1 is used to obtain some data from Cmep (1 byte). Function 2 is used to set key, that is obtained from Memory Card, into keyring 0x1C of [[DMAC#DMAC5_Key_Ring|SceSblDMAC5DmacKRBase]] keyring. For encryption during Memory Card authentication, [[SceMsif]] driver uses 3-DES-CBC-CTS cipher. Key that is returned from Memory Card is unique to that Memory Card and is signed with ECDSA-224 signature (custom curve). This signature is verified by [[SceMsif]] driver.


AES keys are stored in data section of Msif driver. There are multiple keys from which - one is chosen.
Table of ECDSA-224 parameters is stored in data section of [[SceMsif]] driver. Table of ECDSA-224 parameters is encrypted with AES-128-CBC (and some tweak?, this still have to be double-checked). AES keys are stored in data section of [[SceMsif]] driver. There are multiple keys from which - one is chosen. But it seems to be same key. AES keys are encrypted. They are decrypted with [[Secure_Modules_Functions#encdec_w_portability_sm.self|encdec_w_portability_sm.self]] function 0x2000A.


AES keys are encrypted. They are decrypted with F00D [[F00D_Commands#encdec_w_portability_sm.self|encdec_w_portability_sm.self]] service 0x2000A.
The ECDSA signature received from the memory card looks fixed regardless of session_id. So there is no private key in the memory card and it is possible that the signature is embedded in the factory.


{|
{|
Line 62: Line 42:
|}
|}


== Faking memory card with hardware ==
== Faking Memory Card with hardware ==
 
Is not entirely possible. Reasons:
 
1. Private key for ECDSA-224 is unknown.
 
2. F00D keys used for corresponding service calls are not public.
 
Main problem is 1. In theory specific key and signature pair can be taken (dumped) and put into clone cards.


However they can be blacklisted in next firmware update.
Faking Memory Card with hardware is not entirely possible because ECDSA-224 private key for command 0x4B is still unknown. In theory, specific key and signature pair can be taken (dumped) and put into clone Memory Cards. However they can be blacklisted in next System Software update.


== Patching in software ==
== Patching in software ==


Commands 0x48 and 0x49 are only used to verify that card is genuine. Data, given from card is used to calculate IV and compare it with IV that is calculated by the card. This can be removed by patching.
Commands 0x48 and 0x49 are only used to verify that Memory Card is genuine. Data given from Memory Card is used to calculate IV and compare it with IV that is calculated by the Memory Card. This can be removed by patching.


Command 0x4A is used by card to verify, that vita is genuine. Another IV is computed and sent to card to initialize it. This unlocks all I/O operations. This can be removed by patching.
Command 0x4A is used by Memory Card to verify that PS Vita is genuine. Another IV is computed and sent to Memory Card to initialize it. This unlocks all I/O operations. This can be removed by patching.


Command 0x4B is used by vita to verify that card is genuine. This is done by checking the card key that is signed with ECDSA-224 signature. This can be removed by patching.
Command 0x4B is used by PS Vita to verify that Memory Card is genuine. This is done by checking the Memory Card key that is signed with ECDSA-224 signature. This can be removed by patching.

Latest revision as of 08:27, 15 August 2023

Partitions

Memory Card can be accessed with SceMsif module. It has the following partitions:

code type offset size name description
0xD raw 0x400000 0x400000 Some data
0x8 exfat 0x800000 (mc size - 0x800000) ux0 Memory Card contents

mediaid

Memory Card raw partition contains so called mediaid data. It can be accessed as sdstor0:mcd-lp-act-mediaid. One of the important fields in this partition is a field that stores special sleep_session_id. This is a random number that is generated and stored there before PS Vita goes to sleep mode. Upon wakeup this sleep_session_id is verified and error is shown if the value is unexpected, which leads to power off. Hence why one cannot swap Memory Card while PS Vita is in sleep mode.

Findings about Memory Card

It turns out that Memory Card supports standard Memory Stick protocol (TPC).

SceMsif driver allows to read and write single values on Memory Card according to the (TPC) protocol. It can also read and write chunks of data from Memory Card using (TPC) protocol.

It is still not confirmed, however based on some findings in SceMsif driver, it is hypothesized that PSVita Memory Card is simply a new generation of Memory Stick with additional authentication layer. These findings include:

  • Support of TPC protocol.
  • SceMsif driver contains code that can handle Model Name Device Information Entry (in attribute area of the Memory Card). This code clearly shows that standard Memory Stick should be supported.
  • Dump of real Memory Card shows that Attribute Information Area Confirmation Structure is valid.

Memory Card Initialization

Much like SD standard allows execution of vendor specific commands through CMD56, PS Vita Memory Card has specific commands 0x48, 0x49, 0x4A and 0x4B. To be able to read from Memory Card, it has to be properly initialized with commands 0x48 and 0x49 first. It is not completely tested yet, but commands 0x4A and 0x4B are probably not required, and used by PS Vita to check that Memory Card is genuine.

Memory card initialization also uses rmauth_sm.self functions 1 and 2. Function 1 is used to obtain some data from Cmep (1 byte). Function 2 is used to set key, that is obtained from Memory Card, into keyring 0x1C of SceSblDMAC5DmacKRBase keyring. For encryption during Memory Card authentication, SceMsif driver uses 3-DES-CBC-CTS cipher. Key that is returned from Memory Card is unique to that Memory Card and is signed with ECDSA-224 signature (custom curve). This signature is verified by SceMsif driver.

Table of ECDSA-224 parameters is stored in data section of SceMsif driver. Table of ECDSA-224 parameters is encrypted with AES-128-CBC (and some tweak?, this still have to be double-checked). AES keys are stored in data section of SceMsif driver. There are multiple keys from which - one is chosen. But it seems to be same key. AES keys are encrypted. They are decrypted with encdec_w_portability_sm.self function 0x2000A.

The ECDSA signature received from the memory card looks fixed regardless of session_id. So there is no private key in the memory card and it is possible that the signature is embedded in the factory.

Memory Card authentication process

Faking Memory Card with hardware

Faking Memory Card with hardware is not entirely possible because ECDSA-224 private key for command 0x4B is still unknown. In theory, specific key and signature pair can be taken (dumped) and put into clone Memory Cards. However they can be blacklisted in next System Software update.

Patching in software

Commands 0x48 and 0x49 are only used to verify that Memory Card is genuine. Data given from Memory Card is used to calculate IV and compare it with IV that is calculated by the Memory Card. This can be removed by patching.

Command 0x4A is used by Memory Card to verify that PS Vita is genuine. Another IV is computed and sent to Memory Card to initialize it. This unlocks all I/O operations. This can be removed by patching.

Command 0x4B is used by PS Vita to verify that Memory Card is genuine. This is done by checking the Memory Card key that is signed with ECDSA-224 signature. This can be removed by patching.