mirror of
https://github.com/jakcron/nstool
synced 2024-11-14 17:56:39 +00:00
Move advice for encrypted files from README.md to SWITCH_KEYS.md
This commit is contained in:
jakcron
parent
1e2902202b
commit
2ab44c8a8c
2 changed files with 116 additions and 109 deletions
104
README.md
104
README.md
|
|
@ -102,109 +102,9 @@ nstool -d some_file.bin
|
|||
Some file types have some internal file system that can be displayed or extracted
|
||||
|
||||
## Encrypted Files
|
||||
Some Nintendo Switch files are partially or completely encrypted. These require the user to supply the encryption keys to NSTool so that it can process them. Follow the below advice for what keys are required and how to supply them to NSTool.
|
||||
Some Nintendo Switch files are partially or completely encrypted. These require the user to supply the encryption keys to NSTool so that it can process them.
|
||||
|
||||
### NX GameCard Image
|
||||
The `GameCard ExtendedHeader` is encrypted with one of 8 keys, specified by the `KekIndex` in the `GameCard Header`.
|
||||
It isn't required to extract game data, it just contains metadata.
|
||||
|
||||
Only two keys are currently defined:
|
||||
| KeyIndex | Name | Description |
|
||||
| ----------- | --------------- | ----------- |
|
||||
| 00 | Production | Usually selected for prod images. Some dev images use this key index. |
|
||||
| 01 | Development | Usually selected for dev images. This was changed from key index 00 at some point. |
|
||||
|
||||
In order to read the XCI Extended Header, the header key(s) must be defined in `prod.keys`/`dev.keys` (Prod and dev share the same keydata).
|
||||
```
|
||||
xci_header_key_00 = <32 char AES128 key here>
|
||||
xci_header_key_01 = <32 char AES128 key here>
|
||||
```
|
||||
|
||||
### Nintendo Content Archive
|
||||
Nintendo Content Archive (NCA) files have both an encrypted header and content. The encrypted header determines the layout/format/encryption method of the content, which contains the game data.
|
||||
|
||||
In order to read the NCA header, the header key must be defined in `prod.keys`/`dev.keys`.
|
||||
|
||||
This can be explicitly:
|
||||
```
|
||||
nca_header_key = <64 char AES128-XTS key-data here>
|
||||
```
|
||||
Or allow NSTool to derive it from key sources:
|
||||
```
|
||||
master_key_00 = <32 char AES128 key-data here>
|
||||
aes_kek_generation_source = <32 char AES128 key-data here>
|
||||
aes_key_generation_source = <32 char AES128 key-data here>
|
||||
nca_header_kek_source = <32 char AES128 key-data here>
|
||||
nca_header_key_source = <64 char AES128 key-data here>
|
||||
```
|
||||
|
||||
In order to read the NCA content, the content key must be determined. Unlike the header key which is fixed, each NCA will have a unique content key.
|
||||
|
||||
Content keys are either:
|
||||
1) "Internal", where they are encrypted the NCA Header KeyArea
|
||||
2) "External", where they are encrypted in an external Ticket file (.tik) (external content keys are sometimes called title keys)
|
||||
|
||||
#### Internal Content Key
|
||||
Decrypting the content key from the NCA Header Key Area requires the appropriate `nca_key_area_key` to be defined in `prod.keys`/`dev.keys`.
|
||||
However for security reasons Nintendo revises this key periodically, and within each key revision there are 3 separate keys for different categories of applications.
|
||||
|
||||
It's best to define as many of these as possible, to reduce the number of times you need to edit the keyfiles.
|
||||
|
||||
So for a given key revision these key area keys can be defined explicitly (`##` represents the key revision in hexadecimal):
|
||||
```
|
||||
nca_key_area_key_application_## = <32 char AES128 key-data here>
|
||||
nca_key_area_key_ocean_## = <32 char AES128 key-data here>
|
||||
nca_key_area_key_system_## = <32 char AES128 key-data here>
|
||||
```
|
||||
Or allow NSTool to derive them from key sources: (`##` represents the key revision in hexadecimal):
|
||||
```
|
||||
master_key_## = <32 char AES128 key-data here>
|
||||
aes_kek_generation_source = <32 char AES128 key-data here>
|
||||
aes_key_generation_source = <32 char AES128 key-data here>
|
||||
nca_key_area_key_application_source = <32 char AES128 key-data here>
|
||||
nca_key_area_key_ocean_source = <32 char AES128 key-data here>
|
||||
nca_key_area_key_system_source = <32 char AES128 key-data here>
|
||||
```
|
||||
|
||||
#### External Content Key
|
||||
For NCAs that use an external content key, the user must supplied the key to NSTool.
|
||||
|
||||
Most NCAs that use an external content key will be bundled with a ticket file (*.tik) that contains the content key in an encrypted form.
|
||||
|
||||
The ticket can be supplied by the user using the `--tik` option:
|
||||
```
|
||||
nstool --tik <32 char rightsid>.tik <32 char contentid>.nca
|
||||
```
|
||||
This however requires the the appropriate commonkey to be defined in `prod.keys`/`dev.keys` to decrypt the content key in the ticket. However for security reasons Nintendo revises this key periodically. So it's best to define as many of these as possible, to reduce the number of times you need to edit the keyfiles.
|
||||
|
||||
So for a given key revision the common key can be defined explicitly (`##` represents the key revision in hexadecimal):
|
||||
```
|
||||
ticket_commonkey_## = <32 char AES128 key-data here>
|
||||
```
|
||||
Or allow NSTool to derive them from key sources: (`##` represents the key revision in hexadecimal):
|
||||
```
|
||||
master_key_## = <32 char AES128 key-data here>
|
||||
ticket_commonkey_source = <32 char AES128 key-data here>
|
||||
```
|
||||
|
||||
Alternatively you can supply the raw encrypted content key (also called a title key) directly with the `--titlekey` option:
|
||||
```
|
||||
nstool --titlekey <32 char AES128 key-data here> <32 char contentid>.nca
|
||||
```
|
||||
|
||||
It is also possible to supply the decrypted content key directly with the `--contentkey` option:
|
||||
```
|
||||
nstool --contentkey <32 char AES128 key-data here> <32 char contentid>.nca
|
||||
```
|
||||
|
||||
##### Scene Tickets
|
||||
Please note that "Scene" tickets have been known to have errors. If you have issues using the `--tik` option, try passing the raw encrypted titlekey directly with the `--titlekey` option. The titlekey can be found by reading the ticket with NSTool:
|
||||
```
|
||||
nstool <32 char rightsid>.tik
|
||||
```
|
||||
|
||||
##### Personalised Tickets
|
||||
If the ticket is personalised (encrypted with console unique RSA key), NSTool will not support it. You will need to use extract the title key with another tool and pass the encrypted title key directly with the `--titlekey` option.
|
||||
See [SWITCH_KEYS.md](/SWITCH_KEYS.md) for more info.
|
||||
|
||||
# External Keys
|
||||
NSTool doesn't embed any keys that are copyright protected. However keys can be imported via various keyset files.
|
||||
|
|
|
|||
121
SWITCH_KEYS.md
121
SWITCH_KEYS.md
|
|
@ -87,12 +87,119 @@ acid_sign_key_private : alias for acid_sign_key_00_private
|
|||
titlekek_source : hactool alias for ticket_commonkey_source
|
||||
header_key_source : hactool alias for nca_header_key_source
|
||||
header_kek_source : hactool alias for nca_header_kek_source
|
||||
key_area_key_application_source : hactool alias for nca_body_keak_application_source
|
||||
key_area_key_ocean_source : hactool alias for nca_body_keak_ocean_source
|
||||
key_area_key_system_source : hactool alias for nca_body_keak_system_source
|
||||
key_area_key_application_source : hactool alias for nca_key_area_key_application_source
|
||||
key_area_key_ocean_source : hactool alias for nca_key_area_key_ocean_source
|
||||
key_area_key_system_source : hactool alias for nca_key_area_key_system_source
|
||||
titlekek_## : hactool alias for ticket_commonkey_##
|
||||
header_key : hactool alias for nca_header_key
|
||||
key_area_key_application_## : hactool alias for nca_body_keak_application_##
|
||||
key_area_key_ocean_## : hactool alias for nca_body_keak_ocean_##
|
||||
key_area_key_system_## : hactool alias for nca_body_keak_system_##
|
||||
```
|
||||
key_area_key_application_## : hactool alias for nca_key_area_key_application_##
|
||||
key_area_key_ocean_## : hactool alias for nca_key_area_key_ocean_##
|
||||
key_area_key_system_## : hactool alias for nca_key_area_key_system_##
|
||||
```
|
||||
|
||||
## Encrypted File Types
|
||||
See below for advice on what keys are required to decrypt certain file types.
|
||||
|
||||
### NX GameCard Image
|
||||
The `GameCard ExtendedHeader` is encrypted with one of 8 keys, specified by the `KekIndex` in the `GameCard Header`.
|
||||
It isn't required to extract game data, it just contains metadata.
|
||||
|
||||
Only two keys are currently defined:
|
||||
| KeyIndex | Name | Description |
|
||||
| ----------- | --------------- | ----------- |
|
||||
| 00 | Production | Usually selected for prod images. Some dev images use this key index. |
|
||||
| 01 | Development | Usually selected for dev images. This was changed from key index 00 at some point. |
|
||||
|
||||
Define the header key(s) in `prod.keys`/`dev.keys` (Prod and dev share the same keydata):
|
||||
```
|
||||
xci_header_key_00 = <32 char AES128 key here>
|
||||
xci_header_key_01 = <32 char AES128 key here>
|
||||
```
|
||||
|
||||
### Nintendo Content Archive
|
||||
Nintendo Content Archive (NCA) files have both an encrypted header and content. The encrypted header determines the layout/format/encryption method of the content, which contains the game data.
|
||||
|
||||
Define the header key in `prod.keys`/`dev.keys`.
|
||||
```
|
||||
nca_header_key = <64 char AES128-XTS key-data here>
|
||||
```
|
||||
Or allow NSTool to derive it from key sources:
|
||||
```
|
||||
master_key_00 = <32 char AES128 key-data here>
|
||||
aes_kek_generation_source = <32 char AES128 key-data here>
|
||||
aes_key_generation_source = <32 char AES128 key-data here>
|
||||
nca_header_kek_source = <32 char AES128 key-data here>
|
||||
nca_header_key_source = <64 char AES128 key-data here>
|
||||
```
|
||||
|
||||
In order to read the NCA content, the content key must be determined. Unlike the header key which is fixed, each NCA will have a unique content key.
|
||||
|
||||
Content keys are either:
|
||||
1) "Internal", where they are encrypted the NCA Header KeyArea
|
||||
2) "External", where they are encrypted in an external Ticket file (.tik) (external content keys are sometimes called title keys)
|
||||
|
||||
#### Internal Content Key
|
||||
Decrypting the content key from the NCA Header Key Area requires the appropriate `nca_key_area_key` to be defined in `prod.keys`/`dev.keys`.
|
||||
However for security reasons Nintendo revises this key periodically, and within each key revision there are 3 separate keys for different categories of applications.
|
||||
|
||||
It's best to define as many of these as possible, to reduce the number of times you need to edit the keyfiles.
|
||||
|
||||
So for a given key revision these key area keys can be defined explicitly (`##` represents the key revision in hexadecimal):
|
||||
```
|
||||
nca_key_area_key_application_## = <32 char AES128 key-data here>
|
||||
nca_key_area_key_ocean_## = <32 char AES128 key-data here>
|
||||
nca_key_area_key_system_## = <32 char AES128 key-data here>
|
||||
```
|
||||
Or allow NSTool to derive them from key sources: (`##` represents the key revision in hexadecimal):
|
||||
```
|
||||
master_key_## = <32 char AES128 key-data here>
|
||||
aes_kek_generation_source = <32 char AES128 key-data here>
|
||||
aes_key_generation_source = <32 char AES128 key-data here>
|
||||
nca_key_area_key_application_source = <32 char AES128 key-data here>
|
||||
nca_key_area_key_ocean_source = <32 char AES128 key-data here>
|
||||
nca_key_area_key_system_source = <32 char AES128 key-data here>
|
||||
```
|
||||
|
||||
#### External Content Key
|
||||
For NCAs that use an external content key, the user must supplied the key to NSTool.
|
||||
|
||||
Most NCAs that use an external content key will be bundled with a ticket file (*.tik) that contains the content key in an encrypted form.
|
||||
|
||||
The ticket can be supplied by the user using the `--tik` option:
|
||||
```
|
||||
nstool --tik <32 char rightsid>.tik <32 char contentid>.nca
|
||||
```
|
||||
This however requires the the appropriate commonkey to be defined in `prod.keys`/`dev.keys` to decrypt the content key in the ticket. However for security reasons Nintendo revises this key periodically.
|
||||
|
||||
It's best to define as many of these as possible, to reduce the number of times you need to edit the keyfiles.
|
||||
|
||||
So for a given key revision the common key can be defined explicitly (`##` represents the key revision in hexadecimal):
|
||||
```
|
||||
ticket_commonkey_## = <32 char AES128 key-data here>
|
||||
```
|
||||
Or allow NSTool to derive them from key sources: (`##` represents the key revision in hexadecimal):
|
||||
```
|
||||
master_key_## = <32 char AES128 key-data here>
|
||||
ticket_commonkey_source = <32 char AES128 key-data here>
|
||||
```
|
||||
|
||||
Alternatively you can supply the raw encrypted content key (also called a title key) directly with the `--titlekey` option:
|
||||
```
|
||||
nstool --titlekey <32 char AES128 key-data here> <32 char contentid>.nca
|
||||
```
|
||||
|
||||
It is also possible to supply the decrypted content key directly with the `--contentkey` option:
|
||||
```
|
||||
nstool --contentkey <32 char AES128 key-data here> <32 char contentid>.nca
|
||||
```
|
||||
|
||||
##### Scene Tickets
|
||||
Please note that "Scene" tickets have been known to have errors. If you have issues using the `--tik` option, try passing the raw encrypted titlekey directly with the `--titlekey` option. The titlekey can be found by reading the ticket with NSTool:
|
||||
```
|
||||
nstool <32 char rightsid>.tik
|
||||
```
|
||||
|
||||
##### Personalised Tickets
|
||||
If the ticket is personalised (encrypted with console unique RSA key), NSTool will not support it. You will need to use extract the title key with another tool and pass the encrypted title key directly with the `--titlekey` option.
|
||||
|
||||
# Title
|
||||
Loading…
Reference in a new issue