SpotPass - Revision history

DaniElectra: /* Payload Content Header */ Expand documentation

2025-08-21T14:54:16Z

Payload Content Header: Expand documentation

← Older revision		Revision as of 18:54, 21 August 2025
Line 142:		Line 142:
	\| 0x0		\| 0x0
	\| 0x8		\| 0x8
	\| ~~ProgramID~~		\| Program ID
	\|-		\|-
	\| 0x8		\| 0x8
Line 176:		Line 176:
	This signature is signed by Nintendo with the same key-pair as the content header.		This signature is signed by Nintendo with the same key-pair as the content header.

	The hash at offset 0x1C hashes the 0x1C-byte data at offset 0x0 followed by a zero u16, followed by all of the remaining cleartext data following this header(the actual content data).		The hash at offset 0x1C hashes the 0x1C-byte data at offset 0x0 followed by a zero u16, followed by all of the remaining cleartext data following this header (the actual content data).

	The downloaded boss data is written in the following format to extdata. ~~The file name that is generated might be Base85/Ascii85 encoded.~~		The file name of the downloaded boss data is Ascii85 encoded with the following data:
	First an extdata header in the following format
			{\| class="wikitable"
			! Offset !! Length !! Description
			\|-
			\| 0x0 \|\| 0x5 \|\| NS Data ID
			\|-
			\| 0x5 \|\| 0x5 \|\| Version
			\|-
			\| 0xA \|\| 0x5 \|\| Content datatype
			\|-
			\| 0xF \|\| 0x1 \|\| New flag
			\|}

			The downloaded boss data is written in the following format to extdata. First an extdata header in the following format:
	{\| class="wikitable"		{\| class="wikitable"
	\|-		\|-
Line 191:		Line 204:
	\|-		\|-
	\| 0x1		\| 0x1
	\| ~~0xB~~		\| 0x3
	\| ~~Usually zero?~~		\| Padding
			\|-
			\| 0x4
			\| 0x4
			\| [[BOSSU:GetNsDataAdditionalInfo\|Additional info]]
	\|-		\|-
	\| ~~0xC~~		\| 0x8
	\| 0x4		\| 0x4
	\| Unknown		\| Unknown
	\|-		\|-
	\| ~~0x10~~		\| 0xC
	\| ~~0x4~~		\| 0x8
	\| ~~Download date~~ in ~~format: Bit 0-5 = day, Bit 6-9 = month, Bit 10-20 =~~ year		\| [[BOSSU:GetNsDataLastUpdate\|Last update]] in number of seconds since the year 2000
	\|-		\|-
	\| 0x14		\| 0x14
	\| 0x4		\| 0x4
	\| ~~Usually zero?~~ Padding?		\| Padding
	\|}		\|}

	Followed by the Payload Content Header without the hash and signature (first 0x1C bytes) and the actual payload.		Followed by the Payload Content Header without the hash and signature (first 0x1C bytes) and the actual payload.

DaniElectra: /* Content Header */ Document meaning of first byte

2025-08-21T14:42:21Z

Content Header: Document meaning of first byte

← Older revision		Revision as of 18:42, 21 August 2025
Line 127:		Line 127:
	\|}		\|}

	The first 0x10-bytes are all-zero except the first byte ~~which~~ is ~~usually 0x80~~. ~~It's unknown what~~ the ~~first 0x10-bytes are used for~~.		The first 0x10-bytes are all-zero except the first byte. If the 7th bit (0x80) is not set, the arrived flag will only be marked if the session for the target program ID was made with a privileged session. Otherwise, the arrived flag will always be marked.

	The 16-bit value at 0x10 tells how many payload contents follow after this the content header. For example there can be a downloaded file for a game followed by a message for the news system module.		The 16-bit value at 0x10 tells how many payload contents follow after this the content header. For example there can be a downloaded file for a game followed by a message for the news system module.

Meleemeister: /* Payload Content Header */

2024-07-03T11:45:08Z

Payload Content Header

← Older revision		Revision as of 15:45, 3 July 2024
Line 200:		Line 200:
	\| 0x10		\| 0x10
	\| 0x4		\| 0x4
	\| Download date in format: Bit 0-6 = day, Bit 7-10 = month, Bit 11-21 = year		\| Download date in format: Bit 0-5 = day, Bit 6-9 = month, Bit 10-20 = year
	\|-		\|-
	\| 0x14		\| 0x14

Meleemeister: /* Payload Content Header */

2024-05-21T06:53:53Z

Payload Content Header

← Older revision		Revision as of 10:53, 21 May 2024
Line 178:		Line 178:
	The hash at offset 0x1C hashes the 0x1C-byte data at offset 0x0 followed by a zero u16, followed by all of the remaining cleartext data following this header(the actual content data).		The hash at offset 0x1C hashes the 0x1C-byte data at offset 0x0 followed by a zero u16, followed by all of the remaining cleartext data following this header(the actual content data).

	The downloaded boss data is written in the following format to extdata.		The downloaded boss data is written in the following format to extdata. The file name that is generated might be Base85/Ascii85 encoded.
	First an extdata header in the following format		First an extdata header in the following format
	{\| class="wikitable"		{\| class="wikitable"

DaniElectra: /* User Agent */ The unknown number represents the CTRSDK version that the BOSS sysmodule was built with

2024-04-23T15:58:53Z

User Agent: The unknown number represents the CTRSDK version that the BOSS sysmodule was built with

← Older revision		Revision as of 19:58, 23 April 2024
Line 21:		Line 21:
	The default user-agent used for SpotPass HTTPS requests (including the policylist) has the following format:		The default user-agent used for SpotPass HTTPS requests (including the policylist) has the following format:

	<tt><user agent codename>-<user agent version>/<printed hex u64 [[CfgS:GetLocalFriendCodeSeed\|LocalFriendCodeSeed]]>-<printed hex u64 [[FRDU:GetMyFriendKey\|Friend]] [[FRDU:PrincipalIdToFriendCode\|Code]]>/<text [[CVer\|system]] [[NVer\|version]]>/<~~unknown decimal value~~>/<[[Cfg:GetSystemModel\|system model number]]></tt>		<tt><user agent codename>-<user agent version>/<printed hex u64 [[CfgS:GetLocalFriendCodeSeed\|LocalFriendCodeSeed]]>-<printed hex u64 [[FRDU:GetMyFriendKey\|Friend]] [[FRDU:PrincipalIdToFriendCode\|Code]]>/<text [[CVer\|system]] [[NVer\|version]]>/<CTRSDK version of sysmodule>/<[[Cfg:GetSystemModel\|system model number]]></tt>

	The codename can be set to either <tt>PBOS</tt> (Production BOSS?) or <tt>DBOS</tt> (Development BOSS?) depending if the console is a [[Configuration_Memory#UNITINFO\|retail]] unit. As of system version 11.17, the user agent version is hardcoded to 8.0 and the ~~decimal value~~ is set to 62452 (0xF3F4).		The codename can be set to either <tt>PBOS</tt> (Production BOSS?) or <tt>DBOS</tt> (Development BOSS?) depending if the console is a [[Configuration_Memory#UNITINFO\|retail]] unit. As of system version 11.17, the user agent version is hardcoded to 8.0 and the CTRSDK version is set to 62452 (0xF3F4).

	No user-agent is used for plaintext HTTP requests with SpotPass.		No user-agent is used for plaintext HTTP requests with SpotPass.

Meleemeister at 11:43, 7 April 2024

2024-04-07T09:43:38Z

← Older revision		Revision as of 13:43, 7 April 2024
Line 207:		Line 207:
	\|}		\|}
	Followed by the Payload Content Header without the hash and signature (first 0x1C bytes) and the actual payload.		Followed by the Payload Content Header without the hash and signature (first 0x1C bytes) and the actual payload.

			==Tools==
			* [http://wiiucodes.ddnss.eu/tools/BossDecryptor3DS.zip BossDecryptor3DS] Decrypts an encrypted boss container
			* [http://wiiucodes.ddnss.eu/tools/BossEncryptor3DS.zip BossEncryptor3DS] Builds and encrypts a file into a boss container

	[[Category:Nintendo Software]]		[[Category:Nintendo Software]]

Meleemeister: /* BOSS Header */

2024-04-06T11:00:59Z

BOSS Header

← Older revision		Revision as of 15:00, 6 April 2024
Line 99:		Line 99:
	Data following the BOSS header is encrypted with AES-CTR. The AES key that is used is stored in [[AES_Registers#Keyslots\|keyslot 0x38]]. The first 12 bytes of the IV are from offset 0x1C of the header, while the last 32-bit integer of the IV in big-endian is 0x1. The IV from the header is random per file, and an unique random IV is used each time the content is updated. The cleartext data begins with the content header.		Data following the BOSS header is encrypted with AES-CTR. The AES key that is used is stored in [[AES_Registers#Keyslots\|keyslot 0x38]]. The first 12 bytes of the IV are from offset 0x1C of the header, while the last 32-bit integer of the IV in big-endian is 0x1. The IV from the header is random per file, and an unique random IV is used each time the content is updated. The cleartext data begins with the content header.

	The 64-bit number at 0xC may be a serial number which is increased every time someone requested to sign and create a boss container for ~~his~~ file. The 3DS sees the downloaded file as new if this number is different from the previous download (Doesn't matter if the number is bigger or smaller).		The 64-bit number at 0xC may be a serial number which is increased every time someone requested to sign and create a boss container for a file. The 3DS sees the downloaded file as new if this number is different from the previous download (Doesn't matter if the number is bigger or smaller).

	The boss system module v13314 begins at address 0x0010eb98 with the function for parsing the BOSS header.		The boss system module v13314 begins at address 0x0010eb98 with the function for parsing the BOSS header.

Meleemeister: /* BOSS Header */

2024-04-05T17:59:30Z

BOSS Header

← Older revision		Revision as of 21:59, 5 April 2024
Line 99:		Line 99:
	Data following the BOSS header is encrypted with AES-CTR. The AES key that is used is stored in [[AES_Registers#Keyslots\|keyslot 0x38]]. The first 12 bytes of the IV are from offset 0x1C of the header, while the last 32-bit integer of the IV in big-endian is 0x1. The IV from the header is random per file, and an unique random IV is used each time the content is updated. The cleartext data begins with the content header.		Data following the BOSS header is encrypted with AES-CTR. The AES key that is used is stored in [[AES_Registers#Keyslots\|keyslot 0x38]]. The first 12 bytes of the IV are from offset 0x1C of the header, while the last 32-bit integer of the IV in big-endian is 0x1. The IV from the header is random per file, and an unique random IV is used each time the content is updated. The cleartext data begins with the content header.

	The 64-bit number at 0xC may be serial number which is increased every time someone requested to sign and create a boss container for his file. The 3DS sees the downloaded file as new if this number is different from the previous download (Doesn't matter if the number is bigger or smaller).		The 64-bit number at 0xC may be a serial number which is increased every time someone requested to sign and create a boss container for his file. The 3DS sees the downloaded file as new if this number is different from the previous download (Doesn't matter if the number is bigger or smaller).

	The boss system module v13314 begins at address 0x0010eb98 with the function for parsing the BOSS header.		The boss system module v13314 begins at address 0x0010eb98 with the function for parsing the BOSS header.

Meleemeister: /* BOSS Header */

2024-04-05T17:46:37Z

BOSS Header

← Older revision		Revision as of 21:46, 5 April 2024
Line 99:		Line 99:
	Data following the BOSS header is encrypted with AES-CTR. The AES key that is used is stored in [[AES_Registers#Keyslots\|keyslot 0x38]]. The first 12 bytes of the IV are from offset 0x1C of the header, while the last 32-bit integer of the IV in big-endian is 0x1. The IV from the header is random per file, and an unique random IV is used each time the content is updated. The cleartext data begins with the content header.		Data following the BOSS header is encrypted with AES-CTR. The AES key that is used is stored in [[AES_Registers#Keyslots\|keyslot 0x38]]. The first 12 bytes of the IV are from offset 0x1C of the header, while the last 32-bit integer of the IV in big-endian is 0x1. The IV from the header is random per file, and an unique random IV is used each time the content is updated. The cleartext data begins with the content header.

	The 64-bit number may be serial number which is increased every time someone requested to sign and create a boss container for his file. The 3DS sees the downloaded file as new if this number is different from the previous download (Doesn't matter if the number is bigger or smaller).		The 64-bit number at 0xC may be serial number which is increased every time someone requested to sign and create a boss container for his file. The 3DS sees the downloaded file as new if this number is different from the previous download (Doesn't matter if the number is bigger or smaller).

			The boss system module v13314 begins at address 0x0010eb98 with the function for parsing the BOSS header.

	=== Content Header ===		=== Content Header ===

Meleemeister: /* BOSS Header */ This is in no way a UNIX timestamp

2024-04-05T17:38:19Z

BOSS Header: This is in no way a UNIX timestamp

← Older revision		Revision as of 21:38, 5 April 2024
Line 74:		Line 74:
	\| 0xC		\| 0xC
	\| 0x8		\| 0x8
	\| u64 ~~release date~~ (~~UNIX timestamp~~)		\| u64 serial number (?)
	\|-		\|-
	\| 0x14		\| 0x14
Line 98:		Line 98:

	Data following the BOSS header is encrypted with AES-CTR. The AES key that is used is stored in [[AES_Registers#Keyslots\|keyslot 0x38]]. The first 12 bytes of the IV are from offset 0x1C of the header, while the last 32-bit integer of the IV in big-endian is 0x1. The IV from the header is random per file, and an unique random IV is used each time the content is updated. The cleartext data begins with the content header.		Data following the BOSS header is encrypted with AES-CTR. The AES key that is used is stored in [[AES_Registers#Keyslots\|keyslot 0x38]]. The first 12 bytes of the IV are from offset 0x1C of the header, while the last 32-bit integer of the IV in big-endian is 0x1. The IV from the header is random per file, and an unique random IV is used each time the content is updated. The cleartext data begins with the content header.

			The 64-bit number may be serial number which is increased every time someone requested to sign and create a boss container for his file. The 3DS sees the downloaded file as new if this number is different from the previous download (Doesn't matter if the number is bigger or smaller).

	=== Content Header ===		=== Content Header ===