iQueBrew - User contributions [en]

IO

2018-05-06T21:43:03Z

Hexkyz: Add a bunch of stuff

Memory mapped registers available on the iQue Player.

= MI =
{| class="wikitable"
|-
! Address
! Size
! Description
! Note
|-
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||
|-
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||
|-
| 0xA4300008 || 4 || MI_INTR_REG ||
|-
| 0xA430000C || 4 || MI_INTR_MASK_REG ||
|-
| 0xA4300010 || 4 || ||
|-
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within game code causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = ?, bit 2 = SKC, the other bits seem unused. bit 9 = execute related? (isBb?), bit 8 = execute related?
|-
| 0xA4300028 || 4 || ||
|-
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.
|-
| 0xA4300030 || 4 || ||
|-
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).
|-
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.
|}

= VI =
{| class="wikitable"
|-
! Address
! Size
! Description
! Note
|-
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG ||
|-
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG ||
|-
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG ||
|-
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG ||
|-
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG ||
|-
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG ||
|-
| 0xA4400018 || 4 || VI_V_SYNC_REG ||
|-
| 0xA440001C || 4 || VI_V_SYNC_REG ||
|-
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG ||
|-
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||
|-
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||
|-
| 0xA440002C || 4 || VI_V_BURST_REG ||
|-
| 0xA4400030 || 4 || VI_X_SCALE_REG ||
|-
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||
|}

= AI =
{| class="wikitable"
|-
! Address
! Size
! Description
! Note
|-
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG ||
|-
| 0xA4500004 || 4 || AI_LEN_REG ||
|-
| 0xA4500008 || 4 || AI_CONTROL_REG ||
|-
| 0xA450000C || 4 || AI_STATUS_REG ||
|-
| 0xA4500010 || 4 || AI_DACRATE_REG ||
|-
| 0xA4500014 || 4 || AI_BITRATE_REG ||
|}

= PI =
{| class="wikitable"
|-
! Address
! Size
! Description
! Note
|-
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG ||
|-
| 0xA4600004 || 4 || PI_CART_ADDR_REG ||
|-
| 0xA4600008 || 4 || PI_RD_LEN_REG ||
|-
| 0xA460000C || 4 || PI_WR_LEN_REG ||
|-
| 0xA4600010 || 4 || PI_STATUS_REG ||
|-
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG ||
|-
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG ||
|-
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG ||
|-
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG ||
|-
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||
|-
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||
|-
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||
|-
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||
|-
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not
|-
| 0xA4600040 || 4 || ||
|-
| 0xA4600044 || 4 || ||
|-
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA
|-
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card
|-
| 0xA4600050 || 4 || ||
|-
| 0xA4600054 || 4 || ||
|-
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register
|-
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register
|-
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more
|-
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing
|-
| 0xA4610000 || 4 || ||
|-
| 0xA4610200 || 4 || ||
|-
| 0xA4610420 || 176 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine
|-
| 0xA46104D0 || 16 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine
|-
| 0xA4610500 || 4 || || ATB?
|-
| 0xA4610504 || 4 || || ATB?
|-
| 0xA4620000 || 4 || ||
|-
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||
|-
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||
|-
| 0xA46E0004 || 2 || ||
|-
| 0xA46E0400 || 2 || || RDB related
|-
| 0xA46E0402 || 2 || || RDB related
|-
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||
|}

== PI_MISC_REG ==
{| class="wikitable"
|-
! Bit(s)
! Description
|-
| 31-15 || Box Id
|-
| 6-7 || RTC mask
|-
| 5 || Error led mask (always 0x01)
|-
| 4 || Power mask (always 0x01)
|-
| 2-3 || RTC status
|-
| 1 || Error led
|-
| 0 || Power status (on or off)
|}

= USB =
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.

{| class="wikitable"
|-
! Address
! Size
! Description
! Note
|-
| 0xA4900000 || 4 || ||
|-
| 0xA4940010 || 4 || USB0_STATUS_REG ||
|-
| 0xA4A00000 || 4 || ||
|-
| 0xA4A40010 || 4 || USB1_STATUS_REG ||
|}

Virage2

2018-05-06T16:48:13Z

Hexkyz:

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 || 0x20 || publicKey || Per-console ECC public key
|-
| 0x74 || 0x04 || bbId || Per-console ID
|-
| 0x78 || 0x40 || 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

Virage0-1

2018-05-06T16:41:45Z

Hexkyz: Fix mistakes and update

Virage0 and Virage1 are two 4K EEPROM banks located inside the SoC that can only be read in secure mode.

{| class="wikitable"
|-
! Offset
! Size
! Description
! Note
|-
| 0x00 || 0x01 || tsCrlVersion || Seems to be always 0x00
|-
| 0x01 || 0x01 || caCrlVersion || Seems to be always 0x00
|-
| 0x02 || 0x01 || cpCrlVersion || Seems to be always 0x01
|-
| 0x03 || 0x01 || contentRlVersion || Seems to be always 0x00
|-
| 0x04 || 0x02 || ticketRlVersion || Seems to be always 0x0000
|-
| 0x06 || 0x02 || tidWindow || Seems to be always 0x001A
|-
| 0x08 || 0x34 || cc || Play-time (600 minutes = 0x0258)
|-
| 0x3C || 0x02 || seq || CRC
|-
| 0x3E || 0x02 || sum || CRC
|}

IQue Player System Flaws

2018-04-29T20:10:56Z

Hexkyz: Consistency

{{DISPLAYTITLE:iQue Player System Flaws}}
==Hardware==
{| class="wikitable" border="1"
! Summary
! Description
! Timeframe this was discovered
! Discovered by
|-
| No known hardware exploits
|
|
|
|-
|}

==Secure Kernel==
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Timeframe this was discovered
! Discovered by
|-
| psychic paper: Secure Kernel could incorrectly consider a self-signed certificate chain as valid
| The function for verifying certificate chains at <tt>0x9FC028BC</tt> is passed an array of pointers to certificates.
For the first 5 elements, it checks to see if the certificate was issued by <tt>Root</tt>, if so it checks if the certificate was signed by the hardcoded <tt>Root</tt> public key (and returns immediately with the result).

If the certificate wasn't signed by <tt>Root</tt>, it checks if the certificate was signed by the public key of the next certificate in the array.

If all 5 certificates verified correctly, the function will return success.
| Assuming this function can be called with an attacker-controlled array of certificates, self-signing of certificates (and thus, arbitrary code execution, with full non-Secure Mode privileges)
(This is not the case for Secure Applications, the code in SK for verifying those sets up a hardcoded array on the stack for the certificate verification function)
| April 2018
| [[User:Riley|Riley]]
|-
| skLaunchSetup and skRecryptBegin leave CMD in memory if its signature does not verify
| The function called by skLaunchSetup (and skRecryptBegin) at <tt>0x9FC00BAC</tt> verifies ticket and CMD, and decrypts the titlekey.
After verifying the ticket signature, it copies the CMD to another place in memory, derives the titlekey encryption key, decrypts the titlekey with the titlekek, then verifies the CMD signature.

If the CMD signature does not verify successfully, the function just returns an error, leaving the unsigned CMD in place.

Most of the code that uses a CMD in SK uses the CMD in that place in memory that this function copies the CMD to, and trusts that whatever data is there has been verified already.

The entire CMD is covered by the ticket signature anyway, so this isn't that useful really, besides potentially making psychic paper easier to exploit.
| With existing code execution with access to skLaunchSetup or skRecryptBegin and some other SKC that uses SK's internal CMD copy (only non-test SAs have this level of access), and the ability to sign a ticket but not a CMD:
Allowing the use of an unsigned CMD by SK, potentially leading to privilege escalation (by specifying arbitrary allowed hardware access/allowed SKCs).
| April 26, 2018
| [[User:Riley|Riley]]
|-
| skLaunch does not check content hash if recrypt flag is set in CMD
| skLaunch calculates the SHA1 hash of the content and compares it to the value in the CMD, returning an error if the hash doesn't match. This entire block of code is jumped over if the recrypt flag is set in the CMD.
| With plaintext of an application with the recrypt flag set in its CMD, arbitrary code execution (via, for example, implementation of the attack described in pocorgtfo17)
| Early 2018?
| Everyone
|-
| skVerifyHash signature pointer not validated
| skVerifyHash takes in a u8 pointer to a signature to verify, but does not actually validate this pointer is valid before treating the memory it points to as an RSA/ECC signature.
| Causing the Secure Kernel to data abort -- possibly usable as an infoleak, depending on the provided cert chain
| April 29, 2018
| [[User:SciresM|SciresM]]
|-
| SK's ECDH implementation does no validation of the other party's public key
| When deriving the titlekek using ECDH, SK does no validation whatsoever of the public key, which comes from the ticket. Because ECDH is just multiplication, passing in an all-zero public key would lead to an all-zero titlekek being used.
| With the ability to sign a ticket (for example, psychic paper): causing SK to use a constant titlekek; no need to know a console's ECC keypair.
| April 29, 2018
| [[User:Riley|Riley]]
|}

==System Applications==
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Exploitable System Applications
! Timeframe this was discovered
! Discovered by
|-
| No known System Application exploits
|
|
|
|
|
|-
|}

SKC

2018-04-29T20:10:31Z

Hexkyz: Normalize SKC names and document args

= Secure Kernel calls =
All secure kernel calls return a s32 error code in $v0. 0 means success, below zero means error.

{| class=wikitable
! Id || Name || Arguments
|-
| 0x0 || skGetId || $a0=u32* out_bbid
|-
| 0x1 || skLaunchSetup || $a0=???, $a1=???, $a2=???
|-
| 0x2 || skLaunch || $a0=u8* decrypted_content
|-
| 0x3 || skRecryptListValid || $a0=u8* recrypt_list
|-
| 0x4 || skRecryptBegin || $a0=???, $a1=???, $a2=???
|-
| 0x5 || skRecryptData || $a0=???, $a1=???
|-
| 0x6 || skRecryptComputeState || $a0=u8* buf, $a1=u32 size
|-
| 0x7 || skRecryptEnd || $a0=u8* buf
|-
| 0x8 || skSignHash || $a0=u8* sha1hash, $a1=u8* out_signature
|-
| 0x9 || skVerifyHash || $a0=u8* sha1hash, $a1=u8* signature, $a2=certificate** certificate_chain, $a3=crl** crls?
|-
| 0xA || skGetConsumption || $a0=u8* out_size_buf, $a1=u8* out_buf
|-
| 0xB || skAdvanceTicketWindow || void
|-
| 0xC || skSetLimit || $a0=u16 limit_low?, $a1=u16 limit_high?
|-
| 0xD || skExit || void
|-
| 0xE || skKeepAlive || void
|}