PSN: Difference between revisions

From Vita Development Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
== Environments ==
== Environments ==


The only valid values for "/CONFIG/NP" "env" is <code>np</code>, <code>sp-int</code>, and <code>prod-qa</code>. SceShell checks the value on startup and if it is not valid, it will rewrite the key to be "invalid". The last two environments are only valid if the console is a test kit or a development kit.
The only valid (documented) values for "/CONFIG/NP" "env" are <code>np</code>, <code>sp-int</code>, and <code>prod-qa</code>. SceShell checks the value on startup and if it is not valid, it will rewrite the key to be "invalid". The last two environments are only valid if the console is a test kit or a development kit.


== Ticket ==
== Ticket ==


Upon logging into PSN, a session ticket is created. This ticket is what is used for all PSN services on the console (store, DLC, multiplayer, etc). The requesting of this ticket is subject to many checks that allow Sony to block lower firmware consoles from connecting to PSN. Most of what is documented for [http://www.psdevwiki.com/ps3/Online_Connections PS3] is still relevant to the Vita. PSN ticket acquiring is done by [[SceShell]] and all other apps that use PSN use the ticket that SceShell acquired. That means in order to spoof PSN, all you need to do is patch shell.self and to get platform unique parameters from a later firmware version, you only need to decrypt shell.self (a kernel exploit, therefore, is sufficient but not necessary). Additionally, all PSN communication is done through TLS, and therefore is not susceptible to MITM attacks (you cannot just sniff the parameters without hacking the device). The [[SceLibSsl#Internal_Get_CA|CAs]] are also signed so you cannot modify the root CAs from a higher firmware Vita. Below is a list of steps the Vita takes to request a NP Ticket.
Upon logging into Sony Entertainment Network (formerly PlayStation Network), a session ticket is created. This ticket is what is used for all SEN services on the console (store, DLC, multiplayer, etc). The requesting of this ticket is subject to many checks that allow Sony to block consoles running outdated System Software version from connecting to SEN. Most of what is documented for [http://www.psdevwiki.com/ps3/Online_Connections PS3] is still relevant to the PS Vita. SEN ticket acquiring is done by [[SceShell]] and all other apps that use SEN use the ticket that SceShell acquired. That means in order to spoof SEN, all you need to do is patch shell.self and to get platform unique parameters from a later System Software version, you only need to decrypt shell.self (a kernel exploit, therefore, is sufficient but not necessary). Additionally, all SEN communication is done through TLS, and therefore is not susceptible to MITM attacks (you cannot just sniff the parameters without hacking the device). The [[SceLibSsl#Internal_Get_CA|CAs]] are also signed so you cannot modify the root CAs from a higher System Software PS Vita. Below is a list of steps the PS Vita takes to request a NP Ticket.


# First, an update check is made over HTTP. This can be easily bypassed through a proxy. If the update check fails, then the update prompt will show.
# First, an update check is made over HTTP. This can be easily bypassed through a proxy. If the update check fails, then the update prompt will show.
# A <code>X-I-5-Passphrase</code> is generated with your account id and console id (?). It is then encrypted and signed by F00D (lv0) and converted to base64.
# A <code>X-I-5-Passphrase</code> is generated with your account id and console id (?). It is then encrypted and signed by [[Secure Modules]] and converted to base64.
# A platform unique (but not console unique) <code>X-Platform-Passphrase</code> is decrypted by F00D (lv0).
# A platform unique (but not console unique) <code>X-Platform-Passphrase</code> is decrypted by [[Secure Modules]].
# <code>X-Platform-Version</code> is set to <code>PSP2 X.YY</code> where X.YY is the console firmware version.
# <code>X-Platform-Version</code> is set to <code>PSP2 X.YY</code> where X.YY is the console System Software version.
# <code>User-Agent</code> is set to <code>Lediatio Lunto Ritna</code>. This does not seem to be for any security purpose and likely just vestigial code from legacy systems.
# <code>User-Agent</code> is set to <code>Lediatio Lunto Ritna</code>. This does not seem to be for any security purpose and likely just vestigial code from legacy systems.
# A SSL request is made to <code>https://TITLEID.auth.np.ac.playstation.net/nav/auth</code> with the headers generated above.
# A SSL request is made to <code>https://TITLEID.auth.np.ac.playstation.net/nav/auth</code> with the headers generated above.
# Either <code>X-I-5-Status: OK</code> is returned along with a ticket or <code>X-I-5-Status: NG; reason=CODE</code> is returned. CODE is then added to <code>0x80550400</code> to form the error code to display to the user. If the error code is that a firmware update is required, the update prompt will show.
# Either <code>X-I-5-Status: OK</code> is returned along with a ticket or <code>X-I-5-Status: NG; reason=CODE</code> is returned. CODE is then added to <code>0x80550400</code> to form the error code to display to the user. If the error code is that a System Software update is required, the update prompt will show.


Before 3.63, <code>X-Platform-Passphrase</code> never changed across firmware versions. That means PSN only checked <code>X-Platform-Version</code>. Whenever Sony releases a new firmware, they do not revoke access to the last firmware right away. As long as you bypass the update check (through a proxy), you can still access PSN. This is why you are always able to use PSN for 1-2 weeks after a new firmware is released. With the original HENkaku hack, we spoof <code>X-Platform-Version</code> to 3.61 and therefore PSN cannot tell a difference between a legitimate 3.61 console or a hacked 3.60 console since all other parameters are the same. However, in 3.63, Sony finally changed <code>X-Platform-Passphrase</code> but because of the 1-2 week grace period, people were still able to access PSN for a short amount of time after 3.63 was released. After the grace period, though, the old <code>X-Platform-Passphrase</code> is rejected, returning an <code>X-I-5-Status</code> error code indicating that the console needs to be updated. Additionally, because <code>X-I-5-Passphrase</code> is tied to the console id, it is not possible to use a <code>X-Platform-Passphrase</code> from another console such as PS3, PSP, or Android. I am also unsure if the firmware version is in <code>X-I-5-Passphrase</code> (which is generated by F00D), if that is the case, it is unlikely that PSN spoofing would ever work again (short of a lv0 hack, but in that case, there would be no need for PSN spoofing).
Before System Software version 3.63, <code>X-Platform-Passphrase</code> never changed across System Software versions. That means SEN only checked <code>X-Platform-Version</code>. Whenever Sony releases a new System Software, they do not revoke access to the last System Software right away. As long as you bypass the update check (through a proxy), you can still access SEN. This is why you are always able to use SEN for 1-2 weeks after a new System Software is released. With the original HENkaku hack, we spoof <code>X-Platform-Version</code> to 3.61 and therefore SEN cannot tell a difference between a legitimate 3.61 console or a hacked 3.60 console since all other parameters are the same. However, in 3.63, Sony finally changed <code>X-Platform-Passphrase</code> but because of the 1-2 week grace period, people were still able to access SEN for a short amount of time after 3.63 was released. After the grace period, though, the old <code>X-Platform-Passphrase</code> is rejected, returning an <code>X-I-5-Status</code> error code indicating that the console needs to be updated. Additionally, because <code>X-I-5-Passphrase</code> is tied to the console id, it is not possible to use a <code>X-Platform-Passphrase</code> from another console such as PS3, PSP, or Android. I am also unsure if the System Software version is in <code>X-I-5-Passphrase</code> (which is generated by [[Secure Modules]]). If that is the case, it is unlikely that SEN spoofing would ever work again (short of a [[Secure Modules]] hack, but in that case, there would be no need for SEN spoofing).


[[Category:Applications]]
[[Category:Applications]]

Revision as of 23:54, 20 July 2023

Environments

The only valid (documented) values for "/CONFIG/NP" "env" are np, sp-int, and prod-qa. SceShell checks the value on startup and if it is not valid, it will rewrite the key to be "invalid". The last two environments are only valid if the console is a test kit or a development kit.

Ticket

Upon logging into Sony Entertainment Network (formerly PlayStation Network), a session ticket is created. This ticket is what is used for all SEN services on the console (store, DLC, multiplayer, etc). The requesting of this ticket is subject to many checks that allow Sony to block consoles running outdated System Software version from connecting to SEN. Most of what is documented for PS3 is still relevant to the PS Vita. SEN ticket acquiring is done by SceShell and all other apps that use SEN use the ticket that SceShell acquired. That means in order to spoof SEN, all you need to do is patch shell.self and to get platform unique parameters from a later System Software version, you only need to decrypt shell.self (a kernel exploit, therefore, is sufficient but not necessary). Additionally, all SEN communication is done through TLS, and therefore is not susceptible to MITM attacks (you cannot just sniff the parameters without hacking the device). The CAs are also signed so you cannot modify the root CAs from a higher System Software PS Vita. Below is a list of steps the PS Vita takes to request a NP Ticket.

  1. First, an update check is made over HTTP. This can be easily bypassed through a proxy. If the update check fails, then the update prompt will show.
  2. A X-I-5-Passphrase is generated with your account id and console id (?). It is then encrypted and signed by Secure Modules and converted to base64.
  3. A platform unique (but not console unique) X-Platform-Passphrase is decrypted by Secure Modules.
  4. X-Platform-Version is set to PSP2 X.YY where X.YY is the console System Software version.
  5. User-Agent is set to Lediatio Lunto Ritna. This does not seem to be for any security purpose and likely just vestigial code from legacy systems.
  6. A SSL request is made to https://TITLEID.auth.np.ac.playstation.net/nav/auth with the headers generated above.
  7. Either X-I-5-Status: OK is returned along with a ticket or X-I-5-Status: NG; reason=CODE is returned. CODE is then added to 0x80550400 to form the error code to display to the user. If the error code is that a System Software update is required, the update prompt will show.

Before System Software version 3.63, X-Platform-Passphrase never changed across System Software versions. That means SEN only checked X-Platform-Version. Whenever Sony releases a new System Software, they do not revoke access to the last System Software right away. As long as you bypass the update check (through a proxy), you can still access SEN. This is why you are always able to use SEN for 1-2 weeks after a new System Software is released. With the original HENkaku hack, we spoof X-Platform-Version to 3.61 and therefore SEN cannot tell a difference between a legitimate 3.61 console or a hacked 3.60 console since all other parameters are the same. However, in 3.63, Sony finally changed X-Platform-Passphrase but because of the 1-2 week grace period, people were still able to access SEN for a short amount of time after 3.63 was released. After the grace period, though, the old X-Platform-Passphrase is rejected, returning an X-I-5-Status error code indicating that the console needs to be updated. Additionally, because X-I-5-Passphrase is tied to the console id, it is not possible to use a X-Platform-Passphrase from another console such as PS3, PSP, or Android. I am also unsure if the System Software version is in X-I-5-Passphrase (which is generated by Secure Modules). If that is the case, it is unlikely that SEN spoofing would ever work again (short of a Secure Modules hack, but in that case, there would be no need for SEN spoofing).