wraggster
January 28th, 2010, 01:04
Marcan is back with a rather long post over at Hackmii:
Wow, time does fly. More than a year ago, on October 23rd, 2008, Nintendo finally released an update that fixed the strncmp (fakesigning) exploit in all forks of IOS. This disabled any direct methods to install unofficial content on all updated Wii consoles. At the time, version beta9 of The Homebrew Channel had been in the making for a while, so we decided to take the opportunity to use one of our stockpiled IOS exploits to work around the update and release beta9. These exploits differ from fakesigning in that they directly exploit the IOS runtime, injecting code that lets us take control and disable signatures altogether. Therefore, this was our first released IOS code execution exploit. HBC beta9 was released and worked great on all Wiis, as always.
In order to hinder Nintendo’s attempts at fixing it, and to avoid misuse by warez kiddies, sven and I had a lot of fun obfuscating the exploit over a couple afternoons. We decided not to release information about it, hoping it would last long enough to be useful for future installers and BootMii. Later we kind of forgot about this, but on a few occassions people have asked us to document it, and we proposed a challenge: we would document the exploit as soon as someone “broke” our obfuscation and figured out how the exploit works. The intent was to promote reverse engineering and also see just how long it would take people to crack it. Apparently, either people weren’t very interested or we did a pretty good obfuscation job, because it took pretty long
Well, I’m happy to say that today I received an e-mail from an anonymous hacker who successfully reverse engineered our layers of obfuscation. He (or she!) discovered the inner workings of the STM Release Exploit, as I will be calling it, and did so after three weekends of reverse engineering. Hats off to you, and thank you for taking the challenge!
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.
STM is the IOS module in charge of random hardware functions such as handling the fan, “idle” (WC24) mode, the front slot LED (including the blink patterns), and the buttons. I have no clue what STM means, but I’ve seen it called “State-TM” somewhere on the Wii. One of the main functions 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 I have no clue 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 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).
Full article --> http://hackmii.com/2010/01/the-stm-release-exploit/
Wow, time does fly. More than a year ago, on October 23rd, 2008, Nintendo finally released an update that fixed the strncmp (fakesigning) exploit in all forks of IOS. This disabled any direct methods to install unofficial content on all updated Wii consoles. At the time, version beta9 of The Homebrew Channel had been in the making for a while, so we decided to take the opportunity to use one of our stockpiled IOS exploits to work around the update and release beta9. These exploits differ from fakesigning in that they directly exploit the IOS runtime, injecting code that lets us take control and disable signatures altogether. Therefore, this was our first released IOS code execution exploit. HBC beta9 was released and worked great on all Wiis, as always.
In order to hinder Nintendo’s attempts at fixing it, and to avoid misuse by warez kiddies, sven and I had a lot of fun obfuscating the exploit over a couple afternoons. We decided not to release information about it, hoping it would last long enough to be useful for future installers and BootMii. Later we kind of forgot about this, but on a few occassions people have asked us to document it, and we proposed a challenge: we would document the exploit as soon as someone “broke” our obfuscation and figured out how the exploit works. The intent was to promote reverse engineering and also see just how long it would take people to crack it. Apparently, either people weren’t very interested or we did a pretty good obfuscation job, because it took pretty long
Well, I’m happy to say that today I received an e-mail from an anonymous hacker who successfully reverse engineered our layers of obfuscation. He (or she!) discovered the inner workings of the STM Release Exploit, as I will be calling it, and did so after three weekends of reverse engineering. Hats off to you, and thank you for taking the challenge!
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.
STM is the IOS module in charge of random hardware functions such as handling the fan, “idle” (WC24) mode, the front slot LED (including the blink patterns), and the buttons. I have no clue what STM means, but I’ve seen it called “State-TM” somewhere on the Wii. One of the main functions 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 I have no clue 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 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).
Full article --> http://hackmii.com/2010/01/the-stm-release-exploit/