The Nintendo DSi was surpassed by newer and better handhelds many years ago, but that doesn’t stop people like [Nathan Farlow] from attempting to break into the old abandoned house through a rather unexpected place: the (browser) window.
When the Nintendo DSi was released in 2008, one of its notable features was a built-in version of the Opera 9.50 web browser. [Nathan] reasoned an exploit in this browser would be an ideal entry point, as there’s no OS or kernel to get past — once you get execution, you control the system. To put this plan into action, he put together two great ideas. First he used the WebKit layout tests to get the browser into weird edge cases, and then tracked down an Windows build of Opera 9.50 that he could run on his system under WINE. This allowed him to identify the use-after-free bugs that he was looking for.
Now that he had an address to jump to, he just had to get his code into the right spot. For this he employed what’s known as a NOP sled; basically a long list of commands that do nothing, which if jumped into, will slide into his exploit code. In modern browsers a good way to allocate a chunk of memory and fill it would be a Float32Array, but since this is a 2008 browser, a smattering of RGBA canvases will do.
The actual payload is designed to execute a boot.nds file from the SD card, such as a homebrew launcher. If you want to give it a shot on your own DSi, all you need to do is point the system’s browser to stylehax.net.
There’s a natural order to the world of game console hacking: every time a manufacturer releases a new game console they work in security measures that prevent the end user from running anything but commercially released games, and in turn every hacker worth his or her salt tries to break through. The end goal, despite what the manufacturers may have you believe, is not to run “bootleg” games, but rather to enable what is colloquially referred to as “homebrew”. That is to say, enabling the novel concept of actually running software of your choice on the hardware you paid for.
At 34C3, noted console hackers [Plutoo], [Derrek], and [Naehrwert] have demonstrated unsigned code running on Nintendo’s latest and greatest and while they are keeping the actual exploit to themselves for now, they’ve promised that a platform for launching homebrew is coming shortly for those who are on firmware version 3.0.0. From the sound of it, after 9 months on the market, Switch owners will finally have complete access to the hardware they purchased.
The key to running the team’s own code was through a WebKit exploit that was already months old by the time the Switch was released. Loading up an arbitrary webpage was the tricky part, as the Switch generally uses its web browser for accessing official sources (like the online game store). But hidden away in the help menus of Tetris, the developers helpfully put a link to their website which the Switch will dutifully open if you select it. From there it’s just a matter of network redirection to get the Switch loading a webpage from your computer rather than the Internet.
It’s easier to ask for forgiveness than permission.
But as the more security-minded of our readers may have guessed already, that just gets you into the browser’s sandbox. The team now had to figure out a way to break out and get full control of the hardware. Through a series of clever hacks the team was able to learn more about the Switch’s internal layout and operating system, slowly working their way up the ladder.
A particularly interesting hack was used to get around a part of the Switch’s OS that is designed to check which services code is allowed to access. It turns out that if code doesn’t provide this function with its own process ID (PID), the system defaults to PID 0 because the variable is not initialized. In other words, if you don’t ask the operating system which functions you have access to, you will get access to them all. This is a classic programming mistake, and a developer at Nintendo HQ is likely getting a very stern talking to right about now.
But not everything was so easy. When trying to get access to the boot loader, the team sniffed the eMMC bus and timed the commands to determine when it was checking the encryption keys. They were then able to assemble a “glitcher” which fiddled with the CPU’s power using FPGA controlled MOFSETs during this critical time in an attempt to confuse the system.
The rabbit hole is pretty deep on this one, so we’d recommend you set aside an hour to watch the entire presentation to see the long road it took to go from a browser bug to running their first complete demo. It’s as much a testament to the skill of [Plutoo], [Derrek], and [Naehrwert] as it is the lengths at which Nintendo went to keep people out.
[Huan Truong] was looking for an Internet interface for one of his projects. In this case it’s a temperature logger, but it could be just about anything. He decided to give the Chumby a try, but was turned off by its use of Flash as the app framework. He decided to open up more options by running WebKit via his custom Chumby’s firmware.
In the video after the break he shows the boot sequence and demonstrates his first app. The device runs through a screen calibration as it powers on. When the app comes up it looks and responds much more like an Android or iPhone app than the Chumby interfaces we’re accustomed to. This technique gives you pretty wide range of app development languages. That’s because all the Chumby really cares about is the index.cgi file that serves as the interface. Development and debugging can be done on a desktop (not that it couldn’t before but Flash development under Linux was always a pain).
It looks like this idea isn’t new, but we don’t recall seeing any other projects that used WebKit as an alternative Chumby interface.
Here’s a watering can and water vortex that are controlled with a webkit browser interface. The interface displays a drawing of the watering can on your browser. If you grab one of the handles on the circle around the image and move it, the can will rotate as well.
Okay, so this isn’t going to change the world and actually presents a fairly useless watering setup. But [Ben] seems to be a master of fabrication and that’s what we appreciate in this build. The watering can is solidly mounted and moves fluidly with seemingly little effort from the motor. He uses a spring to keep the rope loop taut, sourcing a castor wheel and automotive power-window motor to provide the motion. The hinged base on which the can sits has a potentiometer in it, used to measure the current position of the watering can. Remember these techniques as they’ll come in handy in your future builds.
There’s also a little bonus at the end of the video after the break. We wondered what [Ben] might use that power drill controller hack for. Looks like it makes an appearance in his water vortex work.
With netbooks being slim and mostly utilitarian, it seems a bit contradictory to use a standard and somewhat bulky web browser with them. After all, we’re trimmingdown the operating system to perform faster on these little devices, so why not thin out the focal point of the netbook: the browser. Firefox, Chrome, or Safari may be well and great for a full powered desktop or laptop, so how about something a bit more trimmed? Enter the lightweight Webkit based browsers: Arora and Midori.
While working towards open-sourcing Android, the team continued to work on new features in their own private development branch. These have now been published publicly in the “cupcake” branch. There’s a lot of interesting new features and bug fixes included. We’ve got a rundown of many of the significant additions after the break.
Now that he had an address to jump to, he just had to get his code into the right spot. For this he employed what’s known as a NOP sled; basically a long list of commands that do nothing, which if jumped into, will slide into his exploit code. In modern browsers a good way to allocate a chunk of memory and fill it would be a Float32Array, but since this is a 2008 browser, a smattering of RGBA canvases will do.
