Difference between revisions of "SKSA"
(Created page with "'''SKSA''' (Secure Kernel / System App) is the "Upgradable Operating System" of the iQue Player, the main software that runs on the device. == Parts == As the name implies it...") |
m |
||
| Line 12: | Line 12: | ||
== Format == | == Format == | ||
The format of the SKSA is simple: a 64KiB SK, followed by SA1 (ticket + data), optionally followed by SA2 (ticket + data): | The format of the SKSA is simple: a 64KiB SK, followed by SA1 (ticket + data), optionally followed by SA2 (ticket + data): | ||
| − | {| | + | {| class="wikitable" |
|- | |- | ||
! Offset | ! Offset | ||
Revision as of 06:44, 24 March 2018
SKSA (Secure Kernel / System App) is the "Upgradable 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 where the hash of it is checked against a stored hash in the CPU. Probably only stored in NAND as it's cheaper than storing in CPU.
- System App 1: Consists of a ticket, followed by the actual SA1 data. Most SA1s are just the iQue Menu, though some seem to be factory/graphics tests. SA1 seems to be responsible for handling USB comms too.
- System App 2: Also has a ticket, followed by SA2 data. Unknown purpose, in SKSAs that have an SA2 the SA1 size is greatly reduced compared to single-SA SKSAs, assumably they moved some data from SA1 into this, but it seems like dual-SA SA1s can run without needing the corresponding SA2?
Format
The format of the SKSA is simple: a 64KiB SK, followed by SA1 (ticket + data), optionally followed by SA2 (ticket + data):
| Offset | Length | Type | Information |
|---|---|---|---|
| 0x0 | 0x10000 | encrypted bytes | Secure Kernel |
| 0x10000 | 0x4000 | ticket | SA1 ticket |
| 0x14000 | (sa1ticket.ContentSize) | encrypted bytes | SA1 data |
| 0x14000 + sa1ticket.ContentSize | 0x4000 | ticket | SA2 ticket |
| 0x18000 + sa1ticket.ContentSize | sa2ticket.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 SetSKSAData in iQueTool for an example on how the blocks are transformed, or see GenerateSpareData for how the SAData in the spare is set.
The 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 here.