{
	"id": "327933e3-a3e9-4a22-b601-a2755ad2b523",
	"created_at": "2026-04-06T00:11:21.022805Z",
	"updated_at": "2026-04-10T03:35:36.693654Z",
	"deleted_at": null,
	"sha1_hash": "451920845a72dee8f0dc418b27bea3c5eb583a8a",
	"title": "How the Nintendo Wii Security Was Defeated",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 927285,
	"plain_text": "How the Nintendo Wii Security Was Defeated\r\nBy vedard\r\nPublished: 2023-08-06 · Archived: 2026-04-05 18:46:26 UTC\r\nThis is the story and the technical details of how the hacker group named Fail0verflow (formerly known as Team Twiizer)\r\ndiscovered and exploited numerous vulnerabilities to defeat the security mechanisms of the Nintendo Wii.\r\nThe Architecture of the Nintendo Wii\r\nBefore delving into the security flaws of the console, it’s essential to understand the design of the Wii and the security\r\nmechanisms implemented by Nintendo.\r\nHardware\r\nThe Nintendo Wii was released towards the end of the year 2006 and features the following hardware.\r\nStorage: The Wii includes 512 MB of NAND flash memory, serving as internal storage for system software,\r\napplications, game saves, and user settings. The majority of data stored in the NAND flash is encrypted using a\r\nunique key specific to each console.\r\nCPU: The Wii’s processor is the “Broadway” CPU, a 729 MHz processor manufactured by IBM using the\r\n“PowerPC” microarchitecture. It handles running games and applications on the console.\r\nGPU: The Wii is equipped with the “Hollywood” GPU, manufactured by ATI, responsible for handling graphics\r\nprocessing.\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 1 of 12\n\nThe Nintendo Wii’s motherboard\r\nThe Secret Coprocessor\r\nHidden inside the GPU Hollywood is a second CPU nicknamed as “Starlet.” This ARM processor serves as an IO bridge for\r\ngames executed on the Broadway processor and the Wii hardware components (NAND flash, wireless chip, disk drive, etc.).\r\nStarlet runs its own program called IOS, which stands for Input/Output System. This program is responsible for all the\r\nsecurity mechanisms of the Wii, with hardware implementations of cryptographic functions such as SHA1 (hashing), AES\r\n(encryption), and RSA (signing).\r\nInitially, the existence of the Starlet CPU wasn’t known. Developers would access its functionality through the Nintendo’s\r\nSDK completely unaware of its presence. It wasn’t discovered until a year and a half after the Wii’s release when hackers\r\nstumbled upon ARM instructions within the binaries distributed by Nintendo during a system upgrade.\r\nTitle and Ticket\r\nAll the games and applications for the Wii are referred to as “Titles.” When these are distributed, either through Wii discs or\r\nthe Wii Shop, they are encrypted with an AES key called the “Title Key.” This key is provided with the game upon purchase\r\nin the form of a “Ticket.” The ticket, in turn, is encrypted with AES using the master key called the “Common Key,” which\r\nis universal and stored securely in the console. In addition to encryption, the titles are also signed with an RSA certificate,\r\nand the private key for this signature is known only to Nintendo, preventing modifications.\r\nTitles run on the Broadway processor, which is much more powerful and suitable for games. However, this processor cannot\r\ndirectly communicate with the Wii’s hardware. For instance, if a game intends to utilize the Wii’s storage to save a player’s\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 2 of 12\n\nprogress, it must do so through the IOS API and won’t be able to save everything everywhere. IOS acts like a firewall to\r\nrestrict what the game processor can do.\r\nThe System Menu on the Wii is the primary graphical interface, allowing the player to select a title to launch. It is not an\r\noperating system but simply another title that runs barebone on the Broadway processor with “elevated” permission. This\r\nallows it, for example, to request IOS to install, delete, or launch a title.\r\n The System Menu\r\nIt’s worth noting that only one title can run at a time on the Broadway processor, so IOS will terminate the System Menu to\r\nlaunch a new title.\r\nThe Boot Process\r\nDuring the power-on process of the Nintendo Wii, the Starlet CPU executes a boot loader chain before the Broadway CPU is\r\nactivated.\r\nboot0: Small boot loader situated in a read-only memory (ROM) within the Hollywood chip. Its purpose is to decrypt\r\nand validate boot1 using an AES key and SHA1 hash stored in the OTP chip.\r\nboot1: Located at the beginning of the NAND storage, boot1’s role is to decrypt, verify, and load boot2.\r\nboot2: Responsible for loading the System Menu from the NAND storage and the appropriate version of IOS.\r\nThe Wii’s boot process\r\nAll boot loaders are stripped-down versions of IOS, so the same security flaw can sometimes be found across different boot\r\nloaders. Furthermore, Nintendo cannot remotely update boot0 and boot1. This operation can only be done at the factory.\r\nExploitation and vulnerability\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 3 of 12\n\nThe Tweezer Attack\r\nThe Nintendo Wii offers full backward compatibility with the Gamecube. GameCube titles are not signed, and when they\r\nare launched, the Broadway processor reboot into a restricted “Sandbox” mode, disabling most new functionality from the\r\nWii and limiting access to only 16 MB of the 64 MB memory.\r\nIn 2007, Fail0verflow discovered that it is possible to expose other sections of the RAM by shorting specific lines beneath\r\nthe chip using a pair of metallic tweezer. This attack slide the 16 MB of accessible memory, allowing them to sequentially\r\ndump portion of the memory via a serial port soldered onto the Gamecube controller connector.\r\nA pair of tweezer shorting an address line underneath the RAM chip\r\nSince the sandbox was never intended to access the other 48 MB of memory, this space remained unclear and contained the\r\nIOS code along with some cryptographic keys. This includes the famous “Common Key” mentioned earlier, which is used to\r\ndecrypt tickets and titles.\r\nThe Signing Bug\r\nBy carefully examining the IOS machine code extracted through the tweezer attack with a disassembler, a serious flaw was\r\ndiscovered in the module responsible for validating the signature of a Wii title.\r\nNintendo uses RSA to sign a Wii title, where a SHA-1 hash of the game content is encrypted with Nintendo’s private key\r\nand distributed as a signature. The Wii validates the title by decrypting the signature using the public key and comparing it\r\nto the actual hash of the content proving that it had not been modified.\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 4 of 12\n\nHowever, the Wii used a string comparison function (similar to strncmp ) to compare the hashes instead of a function for\r\nbinary values. And since strings in C are terminated by a null byte ( 0x00 or \\0 ), the comparison can end early with a\r\nsuccessful result if both the signature and the hash start with the null byte.\r\n1. The signature of a title can easily be replaced with zeros. This is because RSA by design uses an exponent operation\r\nto encrypt data, and 0 to the power of anything is always 0.\r\n2. The hash can quickly be brute-forced by adding padding to the game content.\r\nComparison of signed title vs a fake signed title\r\nHere’s a Python script demonstrating how to brute force the first byte of SHA1 hash:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\nimport hashlib\r\noriginal_content = b\"Game Data\"\r\npadded_content = original_content\r\npadding = 1\r\nwhile not hashlib.sha1(padded_content).digest()[0] == 0x00:\r\n padded_content = original_content + str.encode(str(padding))\r\n padding += 1\r\nprint(padded_content) # b'Game Data266'\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 5 of 12\n\nThe vulnerability is present everywhere, and as a consequence, it allows for the execution of unsigned games, the\r\ninstallation of custom titles or custom IOS, and even the modification of boot2. It was eventually patched in IOS by system\r\nupdate and in boot1 at the factory only for new Wii manufactured after some point in 2008.\r\nThe Twilight Hack\r\nIn “The Legend of Zelda: Twilight Princess,” players have the opportunity to rename their horse. Fail0verflow discovered\r\nthat while the interface limits the number of characters for the name, the check is not implemented when loading up a save\r\nfile and can be exploited to cause a buffer overflow.\r\nSave files can be imported from an SD card, but these files are encrypted and signed by IOS to prevent players from easily\r\ntampering with them (e.g., adding lives, unlocking items). However, with the knowledge of the keys obtained from the\r\ntweezer attack, it becomes possible to craft a correctly signed save file.\r\nTriggering the buffer overflow to crash the game is pretty simple. However, running custom code is far more challenging.\r\nTwilight Princess with debugging tools enabled\r\nWith the signing bug, Fail0verflow was able to patch the game to re-enable all debugging functions, allowing them, for\r\nexample, to view the content of memory registers. Ultimately, they managed to create the right payload to achieve code\r\nexecution simply by loading a saved game. It was the first publicly available exploit and opened doors for many similar\r\nexploits to be discovered in other games. It was, however, patched by Nintendo a year later.\r\nThe LetterBomb\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 6 of 12\n\nThe “LetterBomb” exploit is comparable to the “Twilight Hack,” as it enables the execution of codes on the Broadway\r\nprocessor. However, unlike the latter, it’s not necessary to possess a specific game, since it exploits a vulnerability in the\r\nMessage Board functionality directly accessible from the System Menu.\r\nHow the LetterBomb message appears on the Message Board\r\nThe Wii Message Board allows users to save short messages on a calendar. These messages can be stored on the Wii’s\r\ninternal storage or on an SD card. They are saved in the binary format illustrated below.\r\nA hex dump of the Letterbomb message\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 7 of 12\n\nInside, you can find a signature and encrypted content. This is a form of obfuscation that Nintendo uses to prevent users\r\nfrom easily altering these files. However, the encryption key is simply composed of 16 null bytes, and the Wii ID is used to\r\nsign the file. The Wii ID is simply a number derived from the MAC address and a constant \\x75\\x79\\x79 .\r\nWithin the encrypted content, there is the title and body of the message. It’s within the message body that a Buffer Overflow\r\nvulnerability exists, exploitable if a long body is inserted into the file.\r\nA hex dump of the decrypted part of the LetterBomb\r\nThe payload below, created by Fail0verflow, is slightly obfuscated but allows the loading and execution of a file\r\n( boot.elf ) located on the SD card.\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 8 of 12\n\nThe strings from the deobfuscated payload\r\nTo this day, the LetterBomb remains one of the preferred vulnerabilities for installing the Homebrew Channel.\r\nThe Homebrew Channel\r\nIt is tedious to run an exploit every time you wish to launch a custom application. That’s why Fail0verflow created the\r\nHomebrew Channel, an application that can be installed on the Wii and serve as launcher accessible directly from the\r\nSystem Menu.\r\nThe Homebrew Channel\r\nThe installation process consists in:\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 9 of 12\n\n1. Exploiting a vulnerability in a title (e.g.: LetterBomb) to gain access to the Broadway processor\r\n2. Launching the HackMii Installer from the SD card ( boot.elf )\r\n3. Exploiting a vulnerability in IOS to gain access to the Starlet CPU\r\n4. Installing the Homebrew Channel\r\nThe various vulnerability chains to be exploited to install the Homebrew Channel\r\nThe early versions of HackMii Installer could simply utilize the Signing Bug to install the Homebrew Channel. However,\r\nafter Nintendo patched it, Fail0verflow had to discover new security flaws in IOS.\r\nThe STM Release Exploit\r\nFor some time, the HackMii Installer utilized an exploit in the STM module of IOS to disable the signature verification,\r\nallowing the installation of the Homebrew Channel. The STM module is responsible for handling various hardware\r\nfunctions, such as the front LED and power buttons. Games could register a callback to received notification when for\r\nexample the reset button was pressed.\r\nThe vulnerability lies in the mechanism to unregister from this callback ( STM_UnregisterStateEvent ), the IOS code is\r\nmissing a return statement, meaning that if there is no callback registered the function would continue unintentionally and\r\ndereference a NULL structure. This unintended behaviour leads to writing a value of 0 to an address that can be controlled\r\nby the Broadway processor.\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\nvoid STM_UnregisterStateEvent(ios_message *imm_msg)\r\n{\r\n struct ios_message *the_hook_msg = hook_msg;\r\n printf_disabled(\"Release\\n\");\r\n if (!the_hook_msg) {\r\n AckMessage(imm_msg, -6);\r\n // \u003c------- Missing a return statement here\r\n }\r\n hook_msg = NULL;\r\n // if the_hook_msg is null,\r\n // 0 is written to an address from the pointer at 0x00 (null) + 0x18 (offset of buffer_out)\r\n *(u32*)the_hook_msg-\u003ebuffer_out = 0;\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 10 of 12\n\n15\r\n16\r\n17\r\n AckMessage(the_hook_msg, 0);\r\n AckMessage(imm_msg, 0);\r\n}\r\nBy changing the address to the return address in the stack, the exploit would trick STM_UnregisterStateEvent to return and\r\nexecute code located at address 0, which is modifiable by the Broadway processor. Although the STM module had limited\r\npermission in IOS, it still possessed the capability to make syscalls. get_kernel_flavor is a syscall that can write specific\r\nvalues to any address with kernel permission.\r\n1\r\n2\r\n3\r\n4\r\n5\r\nvoid get_kernel_flavor(u32 *a, u16 *b)\r\n{\r\n *a = 3;\r\n *b = 0;\r\n}\r\nWith the ability to write the value 0 to any address, it becomes possible to disable signature verification and enable the\r\ninstallation of any software. The exploit was eventually patched by Nintendo, and as a result Fail0verflow released a detail\r\nexplanation here: https://hackmii.com/2010/01/the-stm-release-exploit\r\nIt is challenging to determine precisely how HackMii Installer works today because its code has multiple layers of\r\nobfuscation to prevent Nintendo from discovering and fixing the vulnerabilities exploited. However, the latest release notes\r\nrefer to a vulnerability discovered by tueidj, which appears to be related to the ES_GetTicketViews function.\r\nThe ES_GetTicketViews Exploit\r\nThere is a specific syscall in IOS void syscall_54(int factory_mode) that enable the HW_AHBPROT setting. When\r\nactivated, this setting grants Broadway full access to the hardware components (Wireless, Storage, etc.) without the need to\r\ncommunicate with IOS. It’s used at the factory to test the Wii’s hardware, but in the case of the HackMii Installer, this\r\nsetting would enable software to be installed directly to the storage without being validated by IOS.\r\nThe problem is that this syscall can only be invoked from a particular IOS module the E-Ticket Services (ES). This where\r\nthe function ES_GetTicketViews(u64 titleID, tikview *views, u32 cnt) comes into play.\r\nThe purpose of the function is to write tickets into the memory address specified by the pointer, IOS ensures that this is a\r\nvalid address range. The upper bound of the address range is determined by the following formula: START_ADDRESS +\r\nTICKETVIEW_COUNT * TICKETVIEW_SIZE\r\nEach ticket view occupies 216 bytes of memory. By requesting 536 870 912 tickets, the upper bound (unsigned int32)\r\noverflows to exactly 0. As a result, IOS will not validate the address before writing the ticket.\r\nTo take advantage of this vulnerability, the tikview pointer can be set to a specific location on the ES stack. When the\r\nfunction returns, it will execute the code at the start of MEM1, a location that can be modified by the Broadway processor\r\nwith instructions to invoke syscall_54 giving it full control to install the Homebrew Channel.\r\nHere’s a simplified pseudocode implementation for the ES_GetTicketViews exploit:\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 11 of 12\n\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\npayload[] =\r\n{\r\n 0xE3A00001, // mov r0, #1\r\n 0xE6000A90, // call syscall_54(1) (Enable HW_AHBPROT)\r\n 0xE3A00065, // mov r0, #101 (return 101)\r\n // Additional instructions to return to the correct place...\r\n};\r\n// Backup the original content of MEM1\r\nmemcpy(backup, MEM1, sizeof(backup))\r\n// Copy the payload to MEM1\r\nmemcpy(MEM1, payload, sizeof(payload))\r\n// Try different location on the ES stack till a success\r\nfor (stack = 0x20111000; stack \u003c 0x20112500; stack += 4)\r\n{\r\n ES_GetTicketViews(title_id, (void*)stack, 536870912)\r\n if (ret == 101)\r\n break // Exploit successful\r\n}\r\n// Restore the original content of MEM1\r\nmemcpy(MEM1, backup, sizeof(backup))\r\nClosing thoughts\r\nThe Nintendo Wii was designed with multiple security mechanisms to prevent the execution of unauthorized software, but it\r\nwas weaknesses in the implementation that opened the door to hackers. Right now, it’s really easy to hack the Nintendo Wii,\r\njust copy some files to the SD card and click on the LetterBomb message and voilà. It’s all done automatically, but only\r\nthanks to the impressive work of Fail0verflow.\r\nI highly recommend listening to their presentation from 2008 on the subject which inspired me to write about their journey.\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nSource: https://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nhttps://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia"
	],
	"references": [
		"https://blog.0x7d0.dev/history/how-the-nintendo-wii-security-was-defeated/"
	],
	"report_names": [
		"how-the-nintendo-wii-security-was-defeated"
	],
	"threat_actors": [
		{
			"id": "1a3a682c-7499-4954-ad98-da1485b78563",
			"created_at": "2024-09-20T02:00:04.591212Z",
			"updated_at": "2026-04-10T02:00:03.704068Z",
			"deleted_at": null,
			"main_name": "Fail0verflow",
			"aliases": [
				"Team Twiizer"
			],
			"source_name": "MISPGALAXY:Fail0verflow",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434281,
	"ts_updated_at": 1775792136,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/451920845a72dee8f0dc418b27bea3c5eb583a8a.pdf",
		"text": "https://archive.orkl.eu/451920845a72dee8f0dc418b27bea3c5eb583a8a.txt",
		"img": "https://archive.orkl.eu/451920845a72dee8f0dc418b27bea3c5eb583a8a.jpg"
	}
}