iQueBrew - User contributions [en]

IQueCrypt

2020-03-16T18:08:31Z

Jbop:

{{Lowercase title}}
{{infobox_homebrew
|HB_title=iQueCrypt
|HB_Author=[[User:Jbop|Jbop]]
|HB_Type=PC utility
|HB_License=GPL (v3 or later)
|HB_Version=1.3.0
|HB_Released=August 13, 2018
|HB_Website=[https://github.com/jbop1626/iquecrypt GitHub]
|HB_Download=[https://github.com/jbop1626/iquecrypt/releases/latest GitHub]
}}

'''iQueCrypt''' is a tool for extracting information from a [[CMD]] file, from a console's [[ticket.sys]] file, or from a [[Virage2]] dump;
as well as for encrypting and decrypting apps and title keys. To obtain these files, a user will need a [[NAND]] dump of their iQue or already-extracted files. Some operations also ''require'' a Virage2 dump.

== Usage ==
iQueCrypt has four modes: encrypt, decrypt, extract, and ecdh. See the [https://github.com/jbop1626/iquecrypt/blob/master/USAGE.md usage manual] for more in-depth instructions.

=== Encryption ===
The main use for the encrypt mode is to create an "injection", where an app is encrypted with the recrypt key of another (legitimately-obtained) app on an iQue. When this encrypted app is run, the iQue treats it as the legitimate app, and decrypts and executes it normally. This can be used to run other, normal iQue games as well as [[:Category:Homebrew|hacks or homebrew]].

To create an injection, follow these steps:

# Obtain the plaintext ROM of the game you want to inject
# Dump the console's [[NAND]] or otherwise obtain its [[recrypt.sys]] file.
# Dump the console's [[Virage2]].
# Pick a game on your console to serve as the "host" for the injection and take note of its [[Content ID|content ID]] (in hex). This must be a game that has already been launched and exists as a .rec on NAND. Some games are not as compatible with others. Try to have matching save types and matching or greater hardware access and [[SKC]] access.
# Extract the content iv of the host game from its [[CMD]] or [[ticket]].
# Use the encrypt mode on the plaintext ROM, with the recrypt.sys file, Virage2 dump, content ID, and content iv obtained in the preceding steps.
# The output should be a .rec which is the plaintext ROM encrypted with the host's recrypt key and content iv.
# Rename the file to (hex content ID of host game).rec
# Backup the original .rec of the same name on your console, and then wrie the newly generated .rec back to the NAND.

=== Decryption ===
This allows the user to obtain plaintext versions of title keys and apps (if given the appropriate keys and ivs).

=== Extraction ===
Extract mode can extract keys, initialization vectors, and other information from CMDs, ticket.sys files, and V2 dumps. This makes it easy to obtain the files or information a user needs to encrypt or decrypt files.

=== ECDH ===
iQueCrypt can compute the ECDH of a console's ECC private key and a ticket's ECC public key, in order to create the AES key used to re-encrypt the title key in a game's [[CMD]]. This allows the owner of an iQue to obtain the title key for each game that they own by following these steps:

# Dump the console's [[NAND]] or otherwise obtain its [[ticket.sys]] file.
# Dump the console's [[Virage2]].
# Extract the iQue common key and ECC private key from the V2 dump.
# Extract the ticket of the desired game to obtain its (twice-encrypted) title key, title key iv, title key iv 2, and ECC public key
# Use the ecdh mode with the V2 ECC private key and the ticket's ECC public key to generate the file ecdh_key.bin.
# Decrypt the title key using ecdh_key.bin and title key iv 2.
# Decrypt the result of the previous step with the common key and title key iv.
# The result of the above step will be the plaintext title key of the game or app.

[[Category:PC utilities]]

NAND

2019-08-05T21:25:59Z

Jbop: Fix block map range offsets

The iQue uses a 64MiB '''NAND''' flash, which consists of 4096 logical blocks of 16384 bytes each (made up of 32 512-byte pages). Each page also has its own "spare" area, which is detailed below.

== Block Map ==
* '''0x0 - 0x3F''' - SKSA area, marked in the BBFS FAT as reserved
* '''0x40 - 0xFEF''' - data area, used for files in the BBFS
* '''0xFF0 - 0xFFF''' - BBFS area, each block holds a copy of the BBFS along with a 'sequence number', highest sequence number is the latest BBFS.

== BBFS ==
BBFS is the filesystem used on the iQue NAND, a very simple file-system used to store games and config data. The Wii NAND's SFFS is actually very similar to BBFS, though with many more features.

The BBFS is made up of three parts: a FAT (file-allocation table), an entry table and a footer:

=== FAT ===
The FAT is located at 0x0 in the BBFS block, made up of 4096 16-bit signed integers, one for each block in the NAND. This is used to specify if a block may be reserved, bad, available, or it might point to another block in the 'chain' (ie. file 0 points to block 0, block 0 points to block 2, block 2 points to block 15...), or signify the end of the chain.

Files make use of the FAT by simply pointing to a block in the FAT as its start block. Extracting the file is then just a matter of following the chain of pointers in the FAT, reading in each block until you reach an end-of-chain marker.

Possible FAT entries:

{| class="wikitable" style="width:30%"
|-
! Value
! Description
|-
| 0
| Free/unused block
|-
| -1
| End-of-chain marker
|-
| -2
| Bad block
|-
| -3
| Reserved block (used for SKSA area)
|}

=== Entry Table ===
File entries are stored from 0x2000 - 0x3FF4 in the BBFS block, allowing for 409 entries per BBFS.

Each entry has the format:
{| class="wikitable"
|-
! Offset
! Length
! Type
! Information
|-
| 0x0
| 0x8
| char
| File name
|-
| 0x8
| 0x3
| char
| File extension
|-
| 0xB
| 0x1
| byte
| Valid indicator (1 if file is valid)
|-
| 0xC
| 0x2
| int16
| Start block #
|-
| 0xE
| 0x2
| bytes
| Padding?
|-
| 0x10
| 0x4
| int32
| File size
|}

Files may be deleted by simply having the Valid indicator set to 0, or having a block number of -1, so when reading the entry table you should make sure to read all 409 entries first and then filter out any invalid ones.

=== Footer ===
From 0x3FF4 to 0x4000 is the BBFS footer, which simply contains a BBFS signature to identify it as a BBFS block, a sequence number used for finding the latest BBFS, and a checksum for verifying the BBFS contents.

{| class="wikitable"
|-
! Offset
! Length
! Type
! Information
|-
| 0x0
| 0x4
| char
| Magic (BBFS or BBFL)
|-
| 0x4
| 0x4
| int32
| Sequence number
|-
| 0x8
| 0x2
| int16
| Link block #
|-
| 0xA
| 0x2
| int16
| Checksum
|}

The "Link block #" field seems to be used for linking two BBFS blocks together, though this hasn't been seen in any NAND dumps so far (maybe meant for NANDs larger than 4096 blocks, or containing more than 409 entries?).

Checksum is a basic adder, the fields value is made by adding each uint16 from 0x0 - 0x3FFE, and taking the result away from 0xCAD7. For verifying, 0x0 - 0x4000 is added together, and if the result is 0xCAD7 the checksum is valid.

== Spare data ==
Each 512 page page in the NAND has a 16 byte "spare" area associated with it, which is used for bad-block markers, error-correction codes and block-pointers for the [[SKSA|SA]] area.

Unfortunately the I@H USB commands for reading/writing NAND can only access the last page-spare of each block, though hardware NAND writers can access all of them. It seems that writing a "block-spare" over USB will actually copy the spare data to all the page-spares in the block (besides the ECC section), and can also recalculate ECC itself if given ECC data of all 0xFF.

Blocks in the SA area (containing SA1/SA2 tickets or data) also have 3 bytes in the spare used for pointing toward the next SA block, ie. SA1 ticket block -> SA1 data block 1 -> SA1 data block n -> SA2 ticket block, it's guessed this is for working around any bad-blocks in the SA area.

ECC is calculated using a Hamming code, as documented in [https://www.kernel.org/doc/Documentation/mtd/nand_ecc.txt the Linux kernel nand_ecc documentation], a working iQue implementation is available inside [https://github.com/emoose/iQueTool/blob/master/iQueTool/Structs/iQueBlockSpare.cs#L56 the iQueTool source code].

So far the known spare format is:

{| class="wikitable"
|-
! Offset
! Length
! Type
! Information
|-
| 0x0
| 0x3
| bytes
| SA block data (1 byte, copied to all 3 bytes)
|-
| 0x3
| 0x2
| bytes
| Unknown (always 0xFF?)
|-
| 0x5
| 0x1
| byte
| Bad block indicator (0 if block is bad)
|-
| 0x6
| 0x2
| bytes
| Unknown (always 0xFF?)
|-
| 0x8
| 0x3
| bytes
| ECC data for 0x100-0x200 in the page
|-
| 0xB
| 0x2
| bytes
| Unknown (always 0xFF?)
|-
| 0xD
| 0x3
| bytes
| ECC data for 0x0-0x100 in the page
|}

[[Category:File formats]]

SKSA

2019-02-06T19:49:44Z

Jbop: Some corrections; this page should really be cleaned up, and ideally a page for each of SK, SA1, and SA2 should be created.

'''SKSA''' (Secure Kernel / System App) is the "Upgradeable Operating System" of the iQue Player, the main software that runs on the device.

== Parts ==
As the name implies it consists of two parts: a [[secure kernel]], and a [[system app]]. In later SKSAs the system-app area may also be divided into two sections: SA1 and SA2.

* '''Secure Kernel''': the 'boot1' of the iQue. Doesn't ever seem to change between SKSA versions, so might be similar to the Wii boot1; the hash of it is checked against a stored hash in [[Virage2]].

* '''System App 1''': Consists of a [[CMD|contentDesc-less CMD]], followed by the actual SA1 data. Most SA1s are just the [[iQue Menu]], though some seem to be [[Factory Tests|factory/graphics tests]]. SA1 is responsible for handling USB communications in the two most recent SKSA versions.

* '''System App 2''': Also has a CMD, followed by SA2 data. Unknown purpose, in SKSAs that have an SA2 the SA1 size is greatly reduced compared to single-SA SKSAs, presumably they moved some data from SA1 into this, but it seems like dual-SA SA1s can run without needing the corresponding SA2. SA2 contains the iQue Menu in the two most recent SKSA versions.

== Format ==
The format of the SKSA is simple: a 64KiB SK, followed by SA1 (CMD + data), optionally followed by SA2 (CMD + data):
{| class="wikitable"
|-
! Offset
! Length
! Type
! Information
|-
| 0x0
| 0x10000
| encrypted bytes
| Secure Kernel
|-
| 0x10000
| 0x4000
| CMD
| SA1 CMD
|-
| 0x14000
| sa1CMD.ContentSize
| encrypted bytes
| SA1 data
|-
| 0x14000 + sa1CMD.ContentSize
| 0x4000
| CMD
| SA2 CMD
|-
| 0x18000 + sa1CMD.ContentSize
| sa2CMD.ContentSize
| encrypted bytes
| SA2 data
|}

== NAND format ==
On NAND the format is slightly changed however: instead of storing the SA1 & SA2 data exactly as stored in the cached SKSA, the data is instead reversed in 0x4000 byte blocks (though tickets are unaffected). The NAND spare data is used to store pointers for these blocks, to allow for skipping any bad blocks in the SKSA area.

See [https://github.com/emoose/iQueTool/blob/master/iQueTool/Files/iQueNand.cs#L207 SetSKSAData in iQueTool] for an example on how the blocks are transformed, or see [https://github.com/emoose/iQueTool/blob/master/iQueTool/Files/iQueNand.cs#L506 GenerateSpareData] for how the SAData in the spare is set.

The [[NAND#BBFS|BBFS]] FAT table also sets the SKSA blocks to 0xfffd (reserved), to ensure that no files will overwrite them.

== Testing ==
A spreadsheet of the different SKSAs that have been tested (whether it boots, what happens when it boots, etc) is available [https://docs.google.com/spreadsheets/d/13wb-jwPEJ9HV2-XUbaLr3VVkGXTrX2LEf6cGce7WdU8/edit?usp=sharing here].

== [http://www.ique.com/products/Player_upgrade.htm Official update log] ==
===Jan 2004 update===

Added Settings(管理) menu and "i-Timer" Smart Clock, allowing parents to set time limit on gaming and allowing games to use real-world time.

===Sept 2004 update===

Added [[iQue@Home]] support to the console.

This update is most likely corresponds to the SKSA version 1095 as it is the first version to have [[iQue@Home]] USB support.

[[Category:File_formats]]

IQueCrypt

2018-08-13T20:25:45Z

Jbop: Update version

{{Lowercase title}}
{{infobox_homebrew
|HB_title=iQueCrypt
|HB_Author=[[User:Jbop|Jbop]]
|HB_Type=PC utility
|HB_License=GPL
|HB_Version=1.2.1
|HB_Released=August 13, 2018
|HB_Website=[https://github.com/jbop1626/iquecrypt GitHub]
}}

'''iQueCrypt''' is a tool for extracting information from a [[CMD]] file, from a console's [[ticket.sys]] file, or from a [[Virage2]] dump;
as well as for encrypting and decrypting apps and title keys. To obtain these files, a user will need a [[NAND]] dump of their iQue or already-extracted files. Some operations also ''require'' a Virage2 dump.

== Usage ==
iQueCrypt has four modes: encrypt, decrypt, extract, and ecdh. See the [https://github.com/jbop1626/iquecrypt/blob/master/USAGE.md usage manual] for more in-depth instructions.

=== Encryption ===
The main use for the encrypt mode is to create an "injection", where an app is encrypted with the recrypt key of another (legitimately-obtained) app on an iQue. When this encrypted app is run, the iQue treats it as the legitimate app, and decrypts and executes it normally. This can be used to run other, normal iQue games as well as [[:Category:Homebrew|hacks or homebrew]].

To create an injection, follow these steps:

# Obtain the plaintext ROM of the game you want to inject
# Dump the console's [[NAND]] or otherwise obtain its [[recrypt.sys]] file.
# Dump the console's [[Virage2]].
# Pick a game on your console to serve as the "host" for the injection and take note of its [[Content ID|content ID]] (in hex). This must be a game that has already been launched and exists as a .rec on NAND. Some games are not as compatible with others. Try to have matching save types and matching or greater hardware access and [[SKC]] access.
# Extract the content iv of the host game from its [[CMD]] or [[ticket]].
# Use the encrypt mode on the plaintext ROM, with the recrypt.sys file, Virage2 dump, content ID, and content iv obtained in the preceding steps.
# The output should be a .rec which is the plaintext ROM encrypted with the host's recrypt key and content iv.
# Rename the file to (hex content ID of host game).rec
# Backup the original .rec of the same name on your console, and then wrie the newly generated .rec back to the NAND.

=== Decryption ===
This allows the user to obtain plaintext versions of title keys and apps (if given the appropriate keys and ivs).

=== Extraction ===
Extract mode can extract keys, initialization vectors, and other information from CMDs, ticket.sys files, and V2 dumps. This makes it easy to obtain the files or information a user needs to encrypt or decrypt files.

=== ECDH ===
iQueCrypt can compute the ECDH of a console's ECC private key and a ticket's ECC public key, in order to create the AES key used to re-encrypt the title key in a game's [[CMD]]. This allows the owner of an iQue to obtain the title key for each game that they own by following these steps:

# Dump the console's [[NAND]] or otherwise obtain its [[ticket.sys]] file.
# Dump the console's [[Virage2]].
# Extract the iQue common key and ECC private key from the V2 dump.
# Extract the ticket of the desired game to obtain its (twice-encrypted) title key, title key iv, title key iv 2, and ECC public key
# Use the ecdh mode with the V2 ECC private key and the ticket's ECC public key to generate the file ecdh_key.bin.
# Decrypt the title key using ecdh_key.bin and title key iv 2.
# Decrypt the result of the previous step with the common key and title key iv.
# The result of the above step will be the plaintext title key of the game or app.

[[Category:PC utilities]]

IQueCrypt

2018-07-04T19:26:04Z

Jbop: Add injection instructions and more links

{{Lowercase title}}
{{infobox_homebrew
|HB_title=iQueCrypt
|HB_Author=[[User:Jbop|Jbop]]
|HB_Type=PC utility
|HB_License=GPL
|HB_Version=1.2.0
|HB_Released=June 22, 2018
|HB_Website=[https://github.com/jbop1626/iquecrypt GitHub]
}}

'''iQueCrypt''' is a tool for extracting information from a [[CMD]] file, from a console's [[ticket.sys]] file, or from a [[Virage2]] dump;
as well as for encrypting and decrypting apps and title keys. To obtain these files, a user will need a [[NAND]] dump of their iQue or already-extracted files. Some operations also ''require'' a Virage2 dump.

== Usage ==
iQueCrypt has four modes: encrypt, decrypt, extract, and ecdh. See the [https://github.com/jbop1626/iquecrypt/blob/master/USAGE.md usage manual] for more in-depth instructions.

=== Encryption ===
The main use for the encrypt mode is to create an "injection", where an app is encrypted with the recrypt key of another (legitimately-obtained) app on an iQue. When this encrypted app is run, the iQue treats it as the legitimate app, and decrypts and executes it normally. This can be used to run other, normal iQue games as well as [[:Category:Homebrew|hacks or homebrew]].

To create an injection, follow these steps:

# Obtain the plaintext ROM of the game you want to inject
# Dump the console's [[NAND]] or otherwise obtain its [[recrypt.sys]] file.
# Dump the console's [[Virage2]].
# Pick a game on your console to serve as the "host" for the injection and take note of its [[Content ID|content ID]] (in hex). This must be a game that has already been launched and exists as a .rec on NAND. Some games are not as compatible with others. Try to have matching save types and matching or greater hardware access and [[SKC]] access.
# Extract the content iv of the host game from its [[CMD]] or [[ticket]].
# Use the encrypt mode on the plaintext ROM, with the recrypt.sys file, Virage2 dump, content ID, and content iv obtained in the preceding steps.
# The output should be a .rec which is the plaintext ROM encrypted with the host's recrypt key and content iv.
# Rename the file to (hex content ID of host game).rec
# Backup the original .rec of the same name on your console, and then wrie the newly generated .rec back to the NAND.

=== Decryption ===
This allows the user to obtain plaintext versions of title keys and apps (if given the appropriate keys and ivs).

=== Extraction ===
Extract mode can extract keys, initialization vectors, and other information from CMDs, ticket.sys files, and V2 dumps. This makes it easy to obtain the files or information a user needs to encrypt or decrypt files.

=== ECDH ===
iQueCrypt can compute the ECDH of a console's ECC private key and a ticket's ECC public key, in order to create the AES key used to re-encrypt the title key in a game's [[CMD]]. This allows the owner of an iQue to obtain the title key for each game that they own by following these steps:

# Dump the console's [[NAND]] or otherwise obtain its [[ticket.sys]] file.
# Dump the console's [[Virage2]].
# Extract the iQue common key and ECC private key from the V2 dump.
# Extract the ticket of the desired game to obtain its (twice-encrypted) title key, title key iv, title key iv 2, and ECC public key
# Use the ecdh mode with the V2 ECC private key and the ticket's ECC public key to generate the file ecdh_key.bin.
# Decrypt the title key using ecdh_key.bin and title key iv 2.
# Decrypt the result of the previous step with the common key and title key iv.
# The result of the above step will be the plaintext title key of the game or app.

[[Category:PC utilities]]

IQue Player Security

2018-07-04T15:57:44Z

Jbop: Create security/encryption page

{{Lowercase title}}

Unlike its predecessor the Nintendo 64, the [[iQue Player]] makes extensive use of encryption for security. This is probably due to the console's USB connectivity, as well as its ability to [[IQue@Home|download games]] from the iQue server over the internet -- which would make pirating games extremely easy if they were transmitted and stored unencrypted. The security scheme is similar to that of the Wii, though more rudimentary.

== General ==
The iQue makes use of several encryption algorithms:

All symmetric encryption is done using [https://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES-128-CBC]

[https://en.wikipedia.org/wiki/Elliptic-curve_cryptography ECC] (using the curve NIST B-233 / sect233r1) is used to cryptographically sign certain files, and also to generate AES keys through [https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman ECDH].

[https://en.wikipedia.org/wiki/RSA_(cryptosystem) RSA-2048] is used to sign files.

== Usage ==

=== AES ===

==== Secure Kernel ====
{| class="wikitable"
|-
! Key / IV
! Location
|-
| SK key
| Offset 0x1460 in the [[bootrom]]
|-
| SK IV
| Offset 0x1470 in the bootrom
|-
|}

==== Title Keys ====
Encrypted once with the common key, and then again if the app is a game.

(The title keys for SA's are only encrypted once).

{| class="wikitable"
|-
! Key / IV #1
! Location
|-
| iQue Player common key
| Offset 0xB8 in [[Virage2]]
|-
| Title key IV
| Offset 0x2814 in [[CMD]]
|-
|}

{| class="wikitable"
|-
! Key / IV #2
! Location
|-
| Derived using ECDH with console's private key and a public key in the game's ticket
| See ECC section for more info
|-
| Title key IV 2
| Offset 0x29BC in [[ticket]]
|-
|}

==== .apps ====
An application/game downloaded from the iQue server, or on the console before first launch, will have the .app extension.

{| class="wikitable"
|-
! Key / IV
! Location
|-
| Title key
| Offset 0x289C in [[CMD]] This is encrypted once or twice; see above for details.
|-
| Content IV
| Offset 0x2838 in CMD
|-
|}

==== .recs ====
If the recrypt flag is set in its CMD, a .app file will be re-encrypted and made into a .rec file on first launch.

{| class="wikitable"
|-
! Key / IV
! Location
|-
| Recrypt key (unique to both game and console)
| Encrypted 32-byte entry in [[recrypt.sys]]. Starts at offset 0x04 in decrypted entry.
|-
| Content IV
| Offset 0x2838 in [[CMD]]
|-
|}

==== recrypt.sys ====
Each individual 32-byte entry in the recrypt list is encrypted.

{| class="wikitable"
|-
! Key / IV
! Location
|-
| Recrypt list key
| Offset 0xC8 in [[Virage2]]
|-
| [[recrypt.sys|Derived from BBID]]
| -
|-
|}

=== ECC ===
Each console contains a unique key pair located in [[Virage2]].
The private key is located at offset 0x98, and the public key is located at offset 0x54.

This key pair is used to sign [[recrypt.sys]] with ECDSA to prevent tampering.
Game saves are also signed when being copied to NAND, and their signatures are stored in (the aptly-named) [[sig.db]].

Each game's ticket includes an ECC public key. This is used with the console's private key to create a unique AES key with which to re-encrypt
the title key in the CMD. This derived key is created by taking the 16 bytes starting at offset 0x04 in the x-coordinate of the ECDH result.

=== RSA ===
The public key is located in [[SKSA|SK]].

Every CMD and ticket is covered by an RSA-2048 signature to prevent alterations, such as granting more hardware and secure kernel call access or changing what console the ticket is for. Unlike the Wii, the iQue Player does not suffer from the [http://wiibrew.org/wiki/Signing_bug Trucha bug], so currently there is no way to use unsigned tickets other than patching SK, or possibly taking advantage of the [[IQue Player System Flaws|"psychic paper" bug]]

Recrypt.sys

2018-07-04T00:11:51Z

Jbop: Add file format category

'''recrypt.sys''' is a file that contains a list of the recrypt keys for each .rec that has been created by the console. The list is itself both encrypted and signed to prevent tampering.

== Purpose ==

Most iQue apps have the "recrypt flag" set in their [[CMD]]. When a console launches these apps for the first time, a new key is generated and the plaintext app is re-encrypted using this key and the content iv from the app's CMD. This ensures that each iQue has uniquely encrypted .rec files, rather than all iQues using the same encrypted files from the server or factory.

After generating this new "recrypt key", the console stores it in recrypt.sys, and encrypts it using the recrypt list key from the console's [[Virage2]] and an initialization vector generated from the console's BBID like so:

<source lang=c>
uint32_t recrypt_list_iv[4] = { BBID, BBID + 1, BBID + 2, BBID + 3 } // BBID is big-endian
</source>

== Format ==
recrypt.sys is cryptographically signed, but like [[sig.db]] it is signed with an elliptic curve signature (using the console's ECC private key) rather than RSA-2048. This is most likely because it must be altered and re-signed even when the console is not connected to the iQue server, and the iQue itself does not contain the RSA private key needed to sign files.

After the signature is a 4-byte unsigned int containing the number of entries in the recrypt key list.

Each 32-byte entry is encrypted with the above-mentioned recrypt list key and BBID-derived initialization vector. The plaintext of each entry contains the content ID of the associated .rec, the recrypt key, and an unknown 12-byte field that seems to be the same for each entry.

{| class="wikitable"
|-
! Offset
! Length
! Description
! Information
|-
| 0x0
| 0x40
| ECC signature
| Signed with console private key
|-
| 0x40
| 0x04
| numEntries
| Number of entries in the recrypt list
|-
| 0x44
| (variable)
| Recrypt list
| Array of 32-byte, encrypted recrypt list entries
|-
|}

[[Category:File formats]]

Sig.db

2018-07-04T00:11:35Z

Jbop:

'''sig.db''' is a file that contains a list of game save filenames and the ECC signatures of those save files. Every time a game is exited, its save file is copied back to NAND, signed with ECDSA, and the signature stored in sig.db. This is presumably to prevent altering save files externally.

''However'', it seems that saves can actually be altered freely and the signing of saves is pointless:

If a save's signature is found to be invalid, the only effect is SA simply does not re-sign the save when it is next copied back to NAND. This means the validation of a save's signature has no bearing on whether or not the save can be used.

[[Category:File formats]]

Sig.db

2018-07-04T00:10:31Z

Jbop: Create sig.db

IQueCrypt

2018-06-22T21:34:02Z

Jbop: ver/date

Recrypt.sys

2018-06-16T21:02:17Z

Jbop:

IQueCrypt

2018-06-16T20:50:07Z

Jbop: Add category

{{Lowercase title}}
{{infobox_homebrew
|HB_title=iQueCrypt
|HB_Author=[[User:Jbop|Jbop]]
|HB_Type=PC utility
|HB_License=GPL
|HB_Version=1.1.0
|HB_Released=June 13, 2018
|HB_Website=[https://github.com/jbop1626/iquecrypt GitHub]
}}

'''iQueCrypt''' is a tool for extracting information from a [[CMD]] file, from a console's [[ticket.sys]] file, or from a [[Virage2]] dump;
as well as for encrypting and decrypting apps and title keys. To obtain these files, a user will need a NAND dump of their iQue or already-extracted files. Some operations also ''require'' a Virage2 dump.

== Usage ==
iQueCrypt has four modes: encrypt, decrypt, extract, and ecdh. See the [https://github.com/jbop1626/iquecrypt/blob/master/USAGE.md usage manual] for more in-depth instructions.

=== Encryption ===
The main use for the encrypt mode is to create an "injection", where an app is encrypted with the recrypt key of another (legitimately-obtained) app on an iQue. When this encrypted app is run, the iQue treats it as the legitimate app, and decrypts and executes it normally. This can be used to run other, normal iQue games as well as hacks or homebrew.

=== Decryption ===
This allows the user to obtain plaintext versions of title keys and apps (if given the appropriate keys and ivs).

=== Extraction ===
Extract mode can extract keys, initialization vectors, and other information from CMDs, ticket.sys files, and V2 dumps. This makes it easy to obtain the files or information a user needs to encrypt or decrypt files.

=== ECDH ===
iQueCrypt can compute the ECDH of a console's ECC private key and a ticket's ECC public key, in order to create the AES key used to re-encrypt the title key in a game's CMD. This allows the owner of an iQue to obtain the title key for each game that they own by following these steps:

# Dump the console's NAND or otherwise obtain its ticket.sys file.
# Dump the console's Virage2.
# Extract the iQue common key and ECC private key from the V2 dump.
# Extract the ticket of the desired game to obtain its (twice-encrypted) title key, title key iv, title key iv 2, and ECC public key
# Use the ecdh mode with the V2 ECC private key and the ticket's ECC public key to generate the file ecdh_key.bin.
# Decrypt the title key using ecdh_key.bin and title key iv 2.
# Decrypt the result of the previous step with the common key and title key iv.
# The result of the above step will be the plaintext title key of the game or app.

[[Category:PC utilities]]

Ique-sksa-decrypt

2018-06-16T20:49:27Z

Jbop: Add category

{{Lowercase title}}
{{infobox_homebrew
|HB_title=ique_sksa_decrypt
|HB_Author=marshallh
|HB_Type=PC utility
|HB_License=_
|HB_Version=0.2
|HB_Released=_
|HB_Website=[https://github.com/marshallh/ique_sksa_decrypt GitHub]
}}

'''ique_sksa_decrypt''' is a tool for extracting and decrypting the SK, SA1, or SA1+SA2 from a [[SKSA]] file dumped or extracted using (for example) [[iQueTool]]. Since SK/SA perform many of the central operations of the iQue, it is important to be able to examine them unencrypted.

== Usage ==
A [https://github.com/marshallh/ique_sksa_decrypt/blob/master/extract_all.bat handy batch file] is included for Windows users. Extracting and decrypting the SK requires the SK key and iv, and extracting SA1 and/or SA2 requires the iQue common key.

[[Category:PC utilities]]

IQueCrypt

2018-06-16T20:45:58Z

Jbop: Created page with "{{Lowercase title}} {{infobox_homebrew |HB_title=iQueCrypt |HB_Author=Jbop |HB_Type=PC utility |HB_License=GPL |HB_Version=1.1.0 |HB_Released=June 13, 2018 |HB_W..."

Ique-sksa-decrypt

2018-06-16T20:44:12Z

Jbop: Created page with "{{Lowercase title}} {{infobox_homebrew |HB_title=ique_sksa_decrypt |HB_Author=marshallh |HB_Type=PC utility |HB_License=_ |HB_Version=0.2 |HB_Released=_ |HB_Website=[https://g..."

Template:Lowercase title

2018-06-16T20:29:21Z

Jbop: Lowercase title template from wiibrew

{{DISPLAYTITLE:{{#if:{{NAMESPACE}}|{{NAMESPACE}}:|}}{{lcfirst:{{PAGENAME}}}}}}<noinclude>
This is a template for lowercase titles.
</noinclude>

Template:Infobox homebrew

2018-06-16T20:07:18Z

Jbop:

{|class="infobox" cellpadding=2 cellspacing=2 width=265 style="float:right;padding:4px;margin:0 0 1em 1em;font-size:11px;background-color:#f0f7ff;border:1px solid #85bff9"
|align=center colspan=2 bgcolor=#a8d1fa style=font-size:13px{{!}}'''{{{HB_Title|{{PAGENAME}}}}}'''
|-style=vertical-align:top align=left
|'''Author(s)'''
|{{{HB_Author|}}}
|-bgcolor=#cce6ff style=vertical-align:top align=left
|'''Type'''
|{{{HB_Type|}}}
|-style=vertical-align:top align=left
|'''License'''
|{{{HB_License|}}}
|-bgcolor=#cce6ff style=vertical-align:top align=left
|'''Version'''
|{{{HB_Version|}}}
|-style=vertical-align:top align=left
|'''Release date'''
|{{{HB_Released|}}}
|-bgcolor=#cce6ff style=vertical-align:top align=left
|'''Website'''
|{{{HB_Website|}}}
|}<noinclude>{{br}}
==Usage==
{|border=1 style=border-collapse:collapse;width:70%;float:right;margin-left:1em; cellpadding=3
!colspan=2|Syntax
|-
||HB_Title=
|Name of the homebrew program
|-
||HB_Author=
|Who wrote the program
|-
||HB_Type=
|What type of program? (e.g. loader, PC utility)
|-
||HB_License=
|Released under what license (e.g. MIT, GPL, Freeware, Proprietary)
|-
||HB_Version=
|Latest version
|-
||HB_Released=
|Latest release date
|-
||HB_Website=
|Website for the program (e.g. where to download)
|}
<pre>
{{infobox_homebrew
|HB_title=
|HB_Author=
|HB_Type=
|HB_License=
|HB_Version=
|HB_Released=
|HB_Website=
}}
</pre>
[[Category:Infobox templates|{{PAGENAME}}]]</noinclude>

Template:Infobox homebrew

2018-06-16T18:07:43Z

Jbop: woops

{|class="infobox" cellpadding=2 cellspacing=2 width=265 style="float:right;padding:4px;margin:0 0 1em 1em;font-size:11px;background-color:#f0f7ff;border:1px solid #85bff9"
|align=center colspan=2 bgcolor=#a8d1fa style=font-size:13px{{!}}'''{{{HB_Title|{{PAGENAME}}}}}'''
|-style=vertical-align:top align=left
|'''Author(s)'''
|{{{HB_Author|}}}
|-bgcolor=#cce6ff style=vertical-align:top align=left
|'''Type'''
|{{{HB_Type|}}}
|-style=vertical-align:top align=left
|'''License'''
|{{{HB_License|}}}
|-bgcolor=#cce6ff style=vertical-align:top align=left
|'''Version'''
|{{{HB_Version|}}}
|-style=vertical-align:top align=left
|'''Latest release date'''
|{{{HB_Released|}}}
|-bgcolor=#cce6ff style=vertical-align:top align=left
|'''Website'''
|{{{HB_Website|}}}
|}<noinclude>{{br}}
==Usage==
{|border=1 style=border-collapse:collapse;width:70%;float:right;margin-left:1em; cellpadding=3
!colspan=2|Syntax
|-
||HB_Title=
|Name of the homebrew program
|-
||HB_Author=
|Who wrote the program
|-
||HB_Type=
|What type of program? (e.g. loader, PC utility)
|-
||HB_License=
|Released under what license (e.g. MIT, GPL, Freeware, Proprietary)
|-
||HB_Version=
|Latest version
|-
||HB_Released=
|Latest release date
|-
||HB_Website=
|Website for the program (e.g. where to download)
|}
<pre>
{{infobox_homebrew
|HB_title=
|HB_Author=
|HB_Type=
|HB_License=
|HB_Version=
|HB_Released=
|HB_Website=
}}
</pre>
[[Category:Infobox templates|{{PAGENAME}}]]</noinclude>

Template:Infobox homebrew

2018-06-16T18:06:11Z

Jbop: Basic for now

{|class="infobox" cellpadding=2 cellspacing=2 width=265 style="float:right;padding:4px;margin:0 0 1em 1em;font-size:11px;background-color:#f0f7ff;border:1px solid #85bff9"
|align=center colspan=2 bgcolor=#a8d1fa style=font-size:13px{{!}}'''''{{{HB_Title|{{PAGENAME}}}}}'''''
|-style=vertical-align:top align=left
|'''Author(s)'''
|{{{HB_Author|}}}
|-bgcolor=#cce6ff style=vertical-align:top align=left
|'''Type'''
|{{{HB_Type|}}}
|-style=vertical-align:top align=left
|'''License'''
|{{{HB_License|}}}
|-bgcolor=#cce6ff style=vertical-align:top align=left
|'''Version'''
|{{{HB_Version|}}}
|-style=vertical-align:top align=left
|'''Latest release date'''
|{{{HB_Released|}}}
|-bgcolor=#cce6ff style=vertical-align:top align=left
|'''Website'''
|{{{HB_Website|}}}
|}<noinclude>{{br}}
==Usage==
{|border=1 style=border-collapse:collapse;width:70%;float:right;margin-left:1em; cellpadding=3
!colspan=2|Syntax
|-
||HB_Title=
|Name of the homebrew program
|-
||HB_Author=
|Who wrote the program
|-
||HB_Type=
|What type of program? (e.g. loader, PC utility)
|-
||HB_License=
|Released under what license (e.g. MIT, GPL, Freeware, Proprietary)
|-
||HB_Version=
|Latest version
|-
||HB_Released=
|Latest release date
|-
||HB_Website=
|Website for the program (e.g. where to download)
|}
<pre>
{{infobox_homebrew
|HB_title=
|HB_Author=
|HB_Type=
|HB_License=
|HB_Version=
|HB_Released=
|HB_Website=
}}
</pre>
[[Category:Infobox templates|{{PAGENAME}}]]</noinclude>

Ticket

2018-06-15T20:25:53Z

Jbop:

A '''ticket''' is used to store data about an associated app and per-console information, such as encryption keys and whether or not the app is time-limited.

== Format ==

A ticket (BbTicket) consists of two parts: the [[CMD|content metadata]] for the app, and a ticket head (BbTicketHead).

{| class="wikitable"
|-
! Offset
! Length
! Type
! Description
! Information
|-
| 0x00
| 0x29AC
| -
| [[CMD]]
| Content metadata for the associated app
|-
| 0x29AC
| 0x04
| uint32
| bbId
| ID of the console this ticket is for
|-
| 0x29B0
| 0x02
| uint16
| tid
| ticket ID; if bit 15 is set, then it is a trial ticket
|-
| 0x29B2
| 0x02
| uint16
| code
| What type of trial limitation: 0 or 2 = time, 1 = number of launches
|-
| 0x29B4
| 0x02
| uint16
| limit
| number of minutes, or number of launches, before limit is reached
|-
| 0x29B6
| 0x02
| uint16
| reserved
| padding
|-
| 0x29B8
| 0x04
| uint32
| tsCrlVersion
| ticket_crl_version
|-
| 0x29BC
| 0x10
| uint8[16]
| cmdIv
| titlekey_iv; IV used to re-encrypt title key (with ECDH key)
|-
| 0x29CC
| 0x40
| uint8[64]
| serverKey
| ECC public key used with console's ECC private key to derive unique title key encryption key via ECDH
|-
| 0x2A0C
| 0x40
| uint8[64]
| issuer
| Certificate used to sign the ticket
|-
| 0x2A4C
| 0x100
| uint8[256]
| ticketSign
| RSA-2048 signature over all of the above ''and'' the CMD
[[Category:File formats]]

Ticket

2018-06-15T19:25:57Z

Jbop:

Ticket

2018-06-15T19:24:48Z

Jbop: Add names just because

A '''ticket''' is used to store data about an associated app and per-console information, such as encryption keys and whether or not the app is time-limited.

== Format ==

A ticket (BbTicket) consists of two parts: the [[CMD|content metadata]] for the app, and a ticket head (BbTicketHead).

{| class="wikitable"
|-
! Offset
! Length
! Type
! Description
! Information
|-
| 0x00
| 0x29AC
| -
| [[CMD]]
| Content metadata for the associated app
|-
| 0x29AC
| 0x04
| uint32
| bbId
| ID of the console this ticket is for
|-
| 0x29B0
| 0x02
| uint16
| tid
| ticket ID; if bit 15 is set, then it is a trial ticket
|-
| 0x29B2
| 0x02
| uint16
| code
| What type of trial limitation: 0 or 2 = time, 1 = number of launches
|-
| 0x29B4
| 0x02
| uint16
| limit
| number of minutes, or number of launches, before limit is reached
|-
| 0x29B6
| 0x02
| uint16
| reserved
| padding
|-
| 0x29B8
| 0x04
| uint32
| tsCrlVersion
| ticket_crl_version
|-
| 0x29BC
| 0x10
| uint8[16]
| cmdIv
| titlekey_iv; IV used to re-encrypt title key (with ECDH key)
|-
| 0x29CC
| 0x40
| uint8[64]
| serverKey
| ecc_pubkey; used with console's ECC private key to derive unique title key encryption key via ECDH
|-
| 0x2A0C
| 0x40
| uint8[64]
| issuer
| signer; certificate used to sign the ticket
|-
| 0x2A4C
| 0x100
| uint8[256]
| ticketSign
| RSA-2048 signature over all of the above ''and'' the CMD

CMD

2018-06-15T19:18:33Z

Jbop: Complete rewrite to fix basically everything, took stuff from Title Data as well (that should now be deleted)

A '''content metadata''' or '''CMD''' is a file or structure used to store data about an iQue app, such as encryption keys, its access to secure kernel calls, and its access to various hardware. It is used on its own in [[SKSA]] (where SA1 and SA2 both have their own attached CMD) and also contained as part of every [[ticket]].

== Format ==
A CMD consists of two parts: '''contentDesc''', an optional 0x2800-byte long structure containing information about a game such as its save type, title, and thumbnail image; and '''BbContentMetaDataHead'''. The former is not used in the content metadata for SAs.

=== contentDesc ===
{| class="wikitable"
|-
! Offset
! Length
! Type
! Information
|-
| 0x00
| 0x04
| uint32
| EEPROM RDRAM location (typically 0x807C0000, 0 if unused)
|-
| 0x04
| 0x04
| uint32
| EEPROM size (either 0x200 or 0x800)
|-
| 0x08
| 0x04
| uint32
| Flash RDRAM location (typically 0x807C0000, 0 if unused)
|-
| 0x0C
| 0x04
| uint32
| Flash size (0x20000 if used)
|-
| 0x10
| 0x04
| uint32
| SRAM RDRAM location (typically 0x807C0000, 0 if unused)
|-
| 0x14
| 0x04
| uint32
| SRAM size (0x8000 if used)
|-
| 0x18
| 0x04
| uint32
| Controller Pak 0 RDRAM location (could be 0x807C0000 or 0x807C0000, 0 if unused)
|-
| 0x1C
| 0x04
| uint32
| Controller Pak 1 RDRAM location (0 if unused)
|-
| 0x20
| 0x04
| uint32
| Controller Pak 2 RDRAM location (0 if unused)
|-
| 0x24
| 0x04
| uint32
| Controller Pak 3 RDRAM location (0 if unused)
|-
| 0x28
| 0x04
| uint32
| Controller Pak size (0x8000 when used)
|-
| 0x2C
| 0x04
| uint32
| Probably osRomBase (always 0xB0000000?)
|-
| 0x30
| 0x04
| uint32
| Probably osTvType (always 1? which is for NTSC)
|-
| 0x34
| 0x04
| uint32
| Probably osMemSize (always 0x400000? for no expansion pak)
|-
| 0x38
| 0x04
| uint32
| Unknown, possibly another libultra boot param
|-
| 0x3C
| 0x04
| uint32
| Unknown, possibly another libultra boot param
|-
| 0x40
| 0x03
| chars
| "CAM", unknown purpose
|-
| 0x43
| 0x01
| byte
| Number of ".u0x" files for this game?
|-
| 0x44
| 0x02
| uint16
| Thumb image length (can't be more than 0x4000, decompressed size must be exactly 0x1880)
|-
| 0x46
| 0x02
| uint16
| Title image length (can't be more than 0x10000, how exactly would that even fit?)
|-
| 0x48
| ''Thumb image length''
| bytes
| Gzipped thumb image RGBA5551 (56px * 56px)
|-
| 0x48 + ''Thumb image length''
| ''Title image length''
| bytes
| Gzipped title image RGBA5551 (184px * 24px)
|-
| 0x48 + ''Thumb image length'' + ''Title image length''
| 0x27B8 - image lengths
| chars
| Title name + ISBN
|}

=== BbContentMetaDataHead ===
{| class="wikitable"
|-
! Offset
! Length
! Type
! Description
! Information
|-
| 0x2800
| 0x04
| uint32
| unusedPadding
| padding
|-
| 0x2804
| 0x04
| uint32
| caCrlVersion
| Certificate Authority(?) CRL version
|-
| 0x2808
| 0x04
| uint32
| cpCrlVersion
| Content Protection(?) CRL version
|-
| 0x280C
| 0x04
| uint32
| size
| Size (in bytes) of the associated app
|-
| 0x2810
| 0x04
| uint32
| descFlags
| Seemingly unused/unchecked; bit 0 set if the associated app is SA
|-
| 0x2814
| 0x10
| uint8[16]
| commonCmdIv
| titlekey_iv; IV used to encrypt title key (with common key)
|-
| 0x2824
| 0x14
| uint8[20]
| hash
| SHA-1 hash of the plaintext of the associated app
|-
| 0x2838
| 0x10
| uint8[16]
| iv
| content_iv; IV used to encrypt content
|-
| 0x2848
| 0x04
| uint32
| execFlags
| Despite the name, only one use/flag is known: if bit 1 is set (the "recrypt flag"), the associated app will be re-encrypted on first launch
|-
| 0x284C
| 0x04
| uint32
| hwAccessRights
| bitfield, each bit enables access to some MMIO regs new to iQue Player:
* bits 0-7: new PI stuff
* bit 0: PI buffer used for aes/NAND read output and PI DMA (1KB at PI_BASE+0x10000)
* bit 1: NAND flash regs in PI
* bit 2: memory mapper for old PI dma
* bit 3: hardware AES-engine in PI
* bit 4: new PI dma engine, DMAs from/to PI buffer
* bit 5: new GPIO; power + LED
* bit 6: external IO bus stuff (debug?)
* bit 7: new PI error stuff
* bit 8: enables access to USB regs
* bit 9: enables access to internal ram used for SK stack
(0x0000 for games except for Animal Forest which is 0x0033, 0x0013 for iQue Club, 0x01F7/0x01B3 for SA)
|-
| 0x2850
| 0x04
| uint32
| secureKernelRights
| Which [[SKC|secure kernel calls]] the associated app can use, one bit per syscall: bit 0 allows SKC 0, etc.
|-
| 0x2854
| 0x04
| uint32
| bbid
| If not zero, can only be run on the specified console (used for SAs, not games)
|-
| 0x2858
| 0x40
| uint8[64]
| issuer
| Certificate used to sign the cmd
|-
| 0x2898
| 0x04
| uint32
| id
| Content ID of the associated app
|-
| 0x289C
| 0x10
| uint8[16]
| key
| The associated app's title key. It is encrypted once with the common key. If the associated app is not an SA, then it is encrypted ''again'' with a key derived using the result of ECDH with the console's private key in the Virage2 and the public key in the app's ticket.
|-
| 0x28AC
| 0x100
| uint8[256]
| contentMetaDataSign
| RSA-2048 signature over all of the above, but before the title key is encrypted a second time.
|}

[[Category:File formats]]

Ticket

2018-06-15T17:53:31Z

Jbop:

A '''ticket''' is used to store data about an associated app and per-console information, such as encryption keys and whether or not the app is time-limited.

== Format ==

A ticket consists of two parts: the [[CMD|content metadata]] for the app, and a ticket head.

{| class="wikitable"
|-
! Offset
! Length
! Type
! Description
! Information
|-
| 0x00
| 0x29AC
| -
| [[CMD]]
| Content metadata for the associated app
|-
| 0x29AC
| 0x04
| uint32
| bbId
| ID of the console this ticket is for
|-
| 0x29B0
| 0x02
| uint16
| tid
| ticket ID; if bit 15 is set, then it is a trial ticket
|-
| 0x29B2
| 0x02
| uint16
| code
| What type of trial limitation: 0 or 2 = time, 1 = number of launches
|-
| 0x29B4
| 0x02
| uint16
| limit
| number of minutes, or number of launches, before limit is reached
|-
| 0x29B6
| 0x02
| uint16
| reserved
| padding
|-
| 0x29B8
| 0x04
| uint32
| tsCrlVersion
| ticket_crl_version
|-
| 0x29BC
| 0x10
| uint8[16]
| cmdIv
| titlekey_iv; IV used to re-encrypt title key (with ECDH key)
|-
| 0x29CC
| 0x40
| uint8[64]
| serverKey
| ecc_pubkey; used with console's ECC private key to derive unique title key encryption key via ECDH
|-
| 0x2A0C
| 0x40
| uint8[64]
| issuer
| signer; certificate used to sign the ticket
|-
| 0x2A4C
| 0x100
| uint8[256]
| ticketSign
| RSA-2048 signature over all of the above ''and'' the CMD

Ticket.sys

2018-06-15T17:25:44Z

Jbop: Fix/rewrite page

'''ticket.sys''' is a file that contains the [[ticket]] for each app installed on the console.

In the code there appears to be a hard limit of 48 tickets in ticket.sys. There may be further practical limits on the number of tickets in ticket.sys (and therefore also on the number of titles installed on a console).

== Format ==

{| class="wikitable"
|-
! Offset
! Length
! Description
! Information
|-
| 0x0
| 0x04
| numTickets
| Number of tickets contained in the file
|-
| 0x04
| (variable)
| Tickets
| Array of [[ticket|tickets]]
|-
|}

Recrypt.sys

2018-06-15T15:49:53Z

Jbop: Create recrypt.sys

'''recrypt.sys''' is a file that contains a list of the recrypt keys for each .rec that has been created by the console. The list is itself both encrypted and signed to prevent tampering.

== Purpose ==

Most iQue apps have the "recrypt flag" set in their [[CMD]]. When a console launches these apps for the first time, a new key is generated and the plaintext app is re-encrypted using this key and the content iv from the app's CMD. This ensures that each iQue has uniquely encrypted .rec files, rather than all iQues using the same encrypted files from the server or factory.

After generating this new "recrypt key", the console stores it in recrypt.sys, and encrypts it using the recrypt list key from the console's [[Virage2]] and an initialization vector generated from the console's BBID like so:

<source lang=c>
uint32_t recrypt_list_iv[4] = { BBID, BBID + 1, BBID + 2, BBID + 3 } // BBID is big-endian
</source>

== Format ==
recrypt.sys is cryptographically signed, but like [[sigs.db]] it is signed with an elliptic curve signature (using the console's ECC private key) rather than RSA-2048. This is most likely because it must be altered and re-signed even when the console is not connected to the iQue server, and the iQue itself does not contain the RSA private key needed to sign files.

After the signature is a 4-byte unsigned int containing the number of entries in the recrypt key list.

Each 32-byte entry is encrypted with the above-mentioned recrypt list key and BBID-derived initialization vector. The plaintext of each entry contains the content ID of the associated .rec, the recrypt key, and an unknown 12-byte field that seems to be the same for each entry.

{| class="wikitable"
|-
! Offset
! Length
! Description
! Information
|-
| 0x0
| 0x40
| ECC signature
| Signed with console private key
|-
| 0x40
| 0x04
| numEntries
| Number of entries in the recrypt list
|-
| 0x44
| (variable)
| Recrypt list
| Array of 32-byte, encrypted recrypt list entries
|-
|}

Virage2

2018-06-02T21:01:33Z

Jbop: Fixed ECC public/private key lengths and offsets

Virage2 is a 16K EEPROM bank located inside the SoC that can only be read in secure mode (mapped at <tt>0xBFCA0000</tt>).

{| class="wikitable"
|-
! Offset
! Size
! Description
! Note
|-
| 0x00 || 0x14 || skHash || Secure Kernel hash
|-
| 0x14 || 0x40 || romPatch || ROM patch bitmap (4 x 0x10)
|-
| 0x54 || 0x40 || publicKey || Per-console ECC public key
|-
| 0x94 || 0x04 || bbId || Per-console ID
|-
| 0x98 || 0x20 || privateKey || Per-console ECC private key
|-
| 0xB8 || 0x10 || bootAppKey || Common key
|-
| 0xC8 || 0x10 || recryptListKey || Per-console key
|-
| 0xD8 || 0x10 || appStateKey || Per-console key
|-
| 0xE8 || 0x10 || selfMsgKey || Per-console key
|-
| 0xF8 || 0x04 || csumAdjust || Per-console checksum adjustment
|-
| 0xFC || 0x04 || jtagEnable || JTAG status field