Difference between revisions of "Wii system flaws"
Jump to navigation
Jump to search
Hallowizer (talk | contribs) (→boot2: boot2 seems to have a normal ES module for launching) |
Hallowizer (talk | contribs) (→boot2: listed MIOS) |
||
Line 62: | Line 62: | ||
|- | |- | ||
| No signature checks | | No signature checks | ||
− | | Unlike [[boot1]], [[boot2]] does not check the signature of | + | | Unlike [[boot1]], [[boot2]] does not check the signature of titles it launches, which means they can be freely modified. |
− | | Modifying the System Menu or System Menu IOS does not brick the system | + | | Modifying the [[System Menu]] or System Menu [[IOS]] does not brick the system, and a custom [[MIOS]] can be loaded this way. |
| Unfixed | | Unfixed | ||
| {{SortableMonth}} | | {{SortableMonth}} |
Revision as of 23:24, 5 July 2021
This page documents the various bugs in the Wii.
Hardware
Summary | Description | Successful exploitation result | Fixed in hardware revision | Discovered | Discovered by |
---|---|---|---|---|---|
HW_BOOT0 not clear-only | To prevent boot0 from being dumped, boot2 clears register HW_BOOT0 that allows the boot0 ROM to be read. However, Nintendo forgot to make this register clear-only, so simply re-enabling it allows boot0 to be dumped from 0xFFFE0000 or 0xFFFF0000 in memory. | boot0 can be obtained. | Unfixed | May 2008 | fail0verflow |
DVD-Video support is inadequately protected | While the Wii was initially meant to support DVD playback, it was scrapped to avoid needing to pay licensing fees. This support was removed in later revisions of the disc drive. However, when the Hollywood register ahbprot is disabled (e.g. by The Homebrew Channel), or diflags is enabled, homebrew can be used to read DVDs. | DVDs can be read on the Wii. | Unknown | July 2008 | fail0verflow |
boot1
Summary | Description | Successful exploitation result | Fixed in boot1 version | Discovered | Discovered by |
---|---|---|---|---|---|
strncmp used to compare hashes | boot1 verifies the signature of boot2 before booting it, however, the signing bug is present, allowing a fake boot2 to be loaded. | A custom bootloader can be installed, such as BootMii. | boot1c | January 2008 | fail0verflow |
HW_BOOT0 is not cleared until boot2 | When the Wii boots, boot2 clears HW_BOOT0 to unmap boot0 and prevent it from being dumped. However, when boot2 is replaced through the signing bug, HW_BOOT0 is not yet cleared. | Dumping of boot0 | Unfixed | January 2008 | fail0verflow |
boot2
Summary | Description | Successful exploitation result | Fixed in boot2 version | Discovered | Discovered by |
---|---|---|---|---|---|
No signature checks | Unlike boot1, boot2 does not check the signature of titles it launches, which means they can be freely modified. | Modifying the System Menu or System Menu IOS does not brick the system, and a custom MIOS can be loaded this way. | Unfixed | Unknown | fail0verflow |
IOS
Module | Summary | Description | Successful exploitation result | Fixed in system update | Discovered | Discovered by |
---|---|---|---|---|---|---|
Kernel | No sanity checks on arguments passed to get_kernel_flavor and get_unk_flavor | System calls get_kernel_flavor and get_unk_flavor do not check to ensure that the pointers passed are appropriate to write to; they will write to any addresses. | If IOS code execution is gained, any address can be overwritten to some specific values by passing those addresses into get_kernel_flavor or get_unk_flavor. | Unknown | Unknown | fail0verflow |
Kernel | Default keys exist in the kernel binary. | The Wii includes an OTP bank of memory, which contains securely stored keys. However, IOS includes a copy of these keys, which it falls back to if the OTP keys are missing. Because these keys are identical, the OTP keys can easily be extracted from the IOS kernel binary if it is dumped. | Most OTP keys can be obtained. | Unfixed[check] | December 2007 | fail0verflow |
ES | Trucha bug | The Wii used the strncmp function to check signatures, which always stopped at the first null byte, weakening the security. More information can be found at signing bug. | Custom titles can be installed, and fakesigned discs can be played. | 3.3 (IOS30 only), October 23 Update (still exploitable by IOS16 pirates), 4.0 | Unknown | fail0verflow and xt5 (independently) |
ES | Title signatures are only checked at installation time. | NAND title signatures are checked on install, but never on launch. This means that if a title can be installed, it can be launched without further exploitation. This applies to both IOSes and apps, including the System Menu. | One-time exploitation leads to trivial persistence. | Unfixed | June 2008 | fail0verflow |
ES | No address check in ES_GetTitles | One of the parameters of ES_GetTitles is a buffer address for the titles to be written, however, this address is not checked to ensure that it is a Broadway-accessible address. By passing an address to overwrite, the titles fetched will be placed there. | Any address accessible from the ES module can be overwritten. | Unfixed | February 2020 | Fullmetal5 |
ES | ES_DiVerify does not check the calling module | ES contains no checks when ES_DiVerify is called, responding to any module that calls it. By sending this call from the Broadway over IPC, ES will receive this from the PPCBOOT process, and proceed normally. | Homebrew can identify as any title. | 4.0 | March 2008 | fail0verflow and Waninkoko (independently) |
ES | ES_AddTitleFinish does not check signatures | ES_AddTitleFinish does not check the signature of the title passed to ES_AddTitleStart, as it expects the signature to be valid by that point. By changing the contents of /import before calling ES_AddTitleFinish, any title can be installed. | Installation of any title | 4.3 | Unknown | Unknown |
ES | No out-of-bounds check when determining the common key from the ticket | Korean titles have a byte that is set to 0 to use the normal common key, and 1 to use the Korean key. This value is used as an index in an array containing the locations of both common keys. However, the value is never sanity checked, so any value can be inserted. | Arbitrary common key usage | Unknown | September 2008 | fail0verflow |
FS | /dev/flash is unprotected | Permission checks in IOS exist for files, but the FS module does not check for permissions when reading the raw NAND contents. If the NAND key is obtained, the NAND can be freely modified. | Arbitrary NAND modification | 3.4[check] | Unknown | Unknown |
STM | STM release bug | The state transition manager checks if a handle is invalid before releasing it, but forgets to actually refuse to release it if it is invalid. More information can be seen at STM Release Exploit | Control over IOS can be gained. | 4.0 | Unknown | fail0verflow, Anonymous person (from reverse engineering Homebrew Channel installer) |
System Menu
Summary | Description | Successful exploitation result | Fixed in system update | Discovered | Discovered by |
---|---|---|---|---|---|
Buffer overflow in mail parser | When parsing a message saved to the SD Card, the Wii Message Board has a buffer overflow bug when copying the message body. By overwriting the memory allocation table this way, the next allocation address can be placed on the stack, allowing code to be returned to. LetterBomb and Wilbrand exploit this. | Code execution in the System Menu | Unfixed | August 2011 | fail0verflow and giantpune (independently) |
Twilight Hack check only checks one zeldaTp.dat | The savefile check to prevent Twilight Hack returns after checking one zeldaTp.dat. By placing a legitimate zeldaTp.dat somewhere else in the file, the real zeldaTp.dat can bypass the check. | A new version of the Twilight Hack works. | 3.4 | June 2008 | fail0verflow |
Twilight Hack check allows all unaligned zeldaTp.dat sizes | The savefile check that prevents Twilight Hack checks the number of bytes read against the file size, aligned to 32 bytes. By leaving the size misaligned, the checker will go past it without deleting it. | The new Twilight Hack survives Broadway resets. | 3.4 | June 2008 | fail0verflow |
Twilight Hack check only looks at the last zeldaTp.dat file | When fixing the 3.3 bugs in the Twilight Hack checker, Nintendo started only checking the final zeldaTp.dat found. By placing a legitimate save later in the WAD, the checker can be bypassed once again. | Another Twilight Hack works on 3.4. | 4.0 | November 2008 | fail0verflow |
BC
Summary | Description | Successful exploitation result | Fixed in BC version | Discovered | Discovered by |
---|---|---|---|---|---|
strncmp used to compare hashes | BC verifies the signature of boot2 before booting it, however, the signing bug is present, allowing a fake boot2 to be loaded. | If a fakesigned boot2 is installed, GameCube mode will launch it fine. | v4 | January 2008 | fail0verflow |
MIOS
Summary | Description | Successful exploitation result | Fixed in MIOS version | Discovered | Discovered by |
---|---|---|---|---|---|
Memory not cleared before booting GC game | When MIOS loads a GameCube game, it never clears the 48K bytes of memory that the game should not have access to. By using a pair of tweezers to change the address lines, the entire memory can be dumped. | MIOS and the rest of memory can be dumped using GameCube homebrew. | v8 | Unknown | fail0verflow |
No boot2 signature check | When the power button is pressed in GameCube mode, MIOS loads boot2 in a shutdown state. However, it has no signature verification, so it is easy to reboot into software such as BootMii this way. | The Wii will not hang on shutdown from MIOS if a custom boot2 is installed. | Unfixed | Unknown | fail0verflow |
Nintendo SDK
These flaws exist in every official application, because they are bundled in, probably in the official SDK. For this reason, they are very difficult to fix.
Summary | Description | Successful exploitation result | Discovered | Discovered by |
---|---|---|---|---|
No upper bound to CCB array | The Fluoride Bluetooth stack includes a function to get a CCB from an ID. This function checks whether the ID is below the lower bound, however, no upper bound is enforced.
By carefully crafting an ID, a fake CCB entry can be placed in the handles array. Sending a packet to free this struct causes it to "unlink" from its adjacent entries, which can be used to get an arbitrary write, and therefore code execution. |
PPC code execution (used in Bluebomb) | September 2019 | Fullmetal5 |
No size limit to BigInts in Opera | In Opera, the dtoa module includes a number of functions operating on big integers with a maximum size, however, any sizes passed in are never checked. By passing in a value too large, the BigInt allocation table will return a smaller BigInt, which leads to a buffer overflow. | PPC code execution (used in str2hax) | December 2018 | Fullmetal5 |
Use-after-free in Flash objects | Flash includes a feature to watch certain properties and get notified when they change, with the ability to easily change it again by returning a value from the event handler. If the event handler decides to delete the object holding that property, the caller still sets the value at that address.
With some manipulation of the garbage collector and thread-switching systems, the stack pointer can be changed, allowing ROP to begin. |
ROP in the PPC (used in FlashHax) | March 2018 | Fullmetal5 |