Changes

This bug was discovered by accident, and in fact it is a real honest-to-goodness software bug that is not only exploitable, but a nuisance during regular use. To understand it, you need to understand how STM works.

This bug was discovered by accident, and in fact it is a real honest-to-goodness software bug that is not only exploitable, but a nuisance during regular use. To understand it, you need to understand how STM works.

[[IOS#STM|STM]] is the [[IOS]] module in responsible for some hardware functions like handling the fan, “idle” ([[WiiConnect24]]) mode, the front slot LED (including the blink patterns), and the buttons. It has been to referred to as “State-TM” a few times on the Wii. A main function of STM is to provide a way for PowerPC software to get notifications when either the Reset or the Power buttons are pressed. It’s worth noting that it is unknown why they did this –the PowerPC already knows about Reset via the legacy GameCube interface, and can be given direct access to Power including IRQ via the shared GPIO system, and IOS doesn’t use these buttons at all– but they did. It works like this: STM creates two devices, an “immediate” device, and an “event” device. The immediate device is used to issue commands to STM that take effect immediately, while the event device is the callback mechanism. The PowerPC code issues an IOS_IoctlAsync() call on the “event” device, and this call blocks (asynchronously) until there is an event (such as a button press). When this happens, the call returns with the event code, and the PowerPC code reissues it to listen for further events.

[[IOS#STM|STM]] (State Transition Manager) is the [[IOS]] module in responsible for some hardware functions like handling the fan, “idle” ([[WiiConnect24]]) mode, the front slot LED (including the blink patterns), and the front-panel buttons. A main function of STM is to provide a way for PowerPC software to get notifications when either the Reset or the Power buttons are pressed. It’s worth noting that it is unknown why they did this –the PowerPC already knows about Reset via the legacy GameCube interface, and can be given direct access to Power including IRQ via the shared GPIO system, and IOS doesn’t use these buttons at all– but they did. It works like this: STM creates two devices, an “immediate” device, and an “event” device. The immediate device is used to issue commands to STM that take effect immediately, while the event device is the callback mechanism. The PowerPC code issues an IOS_IoctlAsync() call on the “event” device, and this call blocks (asynchronously) until there is an event (such as a button press). When this happens, the call returns with the event code, and the PowerPC code reissues it to listen for further events.

One problem with this approach is that the PowerPC needs a way to shut down the event callback. The IOS [[Hardware/IPC|IPC]] mechanism doesn’t provide a way for the PowerPC to cancel an ongoing request; it must wait until its completion. When PowerPC code needs to hand off execution, it needs to clean up all references and file descriptors to IOS, so it needs a way to get rid of the event call. STM implements this by having a call on the immediate interface that forces the event call to return with a zero event code. So far so good. If you’re interested, check out stm.c on libogc (particularly the functions with EventHook in the name).

One problem with this approach is that the PowerPC needs a way to shut down the event callback. The IOS [[Hardware/IPC|IPC]] mechanism doesn’t provide a way for the PowerPC to cancel an ongoing request; it must wait until its completion. When PowerPC code needs to hand off execution, it needs to clean up all references and file descriptors to IOS, so it needs a way to get rid of the event call. STM implements this by having a call on the immediate interface that forces the event call to return with a zero event code. So far so good. If you’re interested, check out stm.c on libogc (particularly the functions with EventHook in the name).

In order to better understand the mechanism, it’s worth looking at the individual messages as they are exchanged with IOS. Here’s what it might look like:

In order to better understand the mechanism, it’s worth looking at the individual messages as they are exchanged with IOS. Here’s what it might look like:

  Initializing STM

open(path=”/dev/stm/immediate”)

open() fd = 1

open(path=”/dev/stm/eventhook”)

open() fd = 2

| colspan="2" style="text-align: center;" | Initializing STM

ioctl(fd=2, num=EVENTHOOK, evbuf=0×12345600)

Time passes, user presses button

| open(path=”/dev/stm/immediate”)

Write event code to 0×12345600

ioctl(fd=2) result = 0

Read event code from 0×12345600

ioctl(fd=2, num=EVENTHOOK, evbuf=0×12345600)

| open() fd = 1

Time passes, software decides to shut down STM

ioctl(fd=1, num=RELEASE)

| open(path=”/dev/stm/eventhook”)

Write 0 event code to 0×12345600

ioctl(fd=2) result = 0

open() fd = 2

| ioctl(fd=2, num=EVENTHOOK, evbuf=0×12345600)

| colspan="2" style="text-align: center;" | Time passes, user presses button

| Write event code to 0×12345600  

| ioctl(fd=2) result = 0

| Read event code from 0×12345600

ioctl(fd=2, num=EVENTHOOK, evbuf=0×12345600)

| colspan="2" style="text-align: center;" | Time passes, software decides to shut down STM

ioctl(fd=1, num=RELEASE)

Write 0 event code to 0×12345600

| ioctl(fd=2) result = 0

  ioctl(fd=1) result = 0

  ioctl(fd=1) result = 0

close(2)

close(2) result = 0

| close(2)

close(1)

close(1) result = 0

| close(2) result = 0

| close(1)

| close(1) result = 0

Things didn’t work well when using the [[Twilight Hack]] because Zelda’s STM eventhook was still active, and STM won’t let you register a new one. So an STM eventhook release was added to the Twilight Hack. One slight issue is that we can’t know if there was an old eventhook or not, depending on what the state of the machine was (since the Twilight Hack can be relaunched from software, as an SD loader of sorts, and this was popular in the early days), so we just make it attempt to release the eventhook always. This is fine, as the release function will return an error if there is no eventhook active.

Things didn’t work well when using the [[Twilight Hack]] because Zelda’s STM eventhook was still active, and STM won’t let you register a new one. So an STM eventhook release was added to the Twilight Hack. One slight issue is that we can’t know if there was an old eventhook or not, depending on what the state of the machine was (since the Twilight Hack can be relaunched from software, as an SD loader of sorts, and this was popular in the early days), so we just make it attempt to release the eventhook always. This is fine, as the release function will return an error if there is no eventhook active.