Devices can get drunk too. Fewer bytes, twice the fun!
This one didn’t even require impairing drugs, all it took was asking nicely.
Brought to you by 30 hackers and 3 tables:
It has come to our attention that nobody seems to have any idea what the past 4 posts have been about. In an attempt to clarify things, we have prepared a handy diagram:
As you’re likely aware, our team gave a lecture at the 30th Chaos Communication Congress on hacking the Wii U. This blog post is a follow-up to the talk and contains clarifications, corrections, and material that we couldn’t fit in the one-hour time slot.
If you haven’t yet, please watch the talk before reading the rest of this post:
It is quite an interesting vulnerability on many aspects. Among them, and thanks to its hardware basis, it impacts many operating systems. For instance, as long as they run on a Intel processor in long mode (obviously), FreeBSD, NetBSD, Solaris, Xen and Microsoft Windows have been reported to be vulnerable. This therefore gives us quite an incentive to develop an exploit ;).
If you haven’t yet read Xen’s blog post The Intel SYSRET privilege escalation please do because we won’t go again into too much details about the vulnerability itself.
Without further delay, let’s dig right into the FreeBSD exploitation!
I’ve always liked the idea of building complex logic systems out of a simple primitive that is just powerful enough to construct all logic - particularly in videogames. For example, in LittleBigPlanet, you can build a Tic-Tac-Toe AI out of physical elements like pistons and magnetic switches. In Minecraft, you can build an ALU out of a primitive construction element that behaves, essentially, as a NOT gate. And, if games aren’t your thing, you can build CMOS logic out of UNIX pipes with a simple “mosfet” program.
Just a few days ago, Notch, the creator of Minecraft, revealed a new game, 0x10c. Instead of giving players a simple logic element, it will include a full-blown 16-bit CPU that can be programmed. I find this intriguing, because it allows for much more complex development yet it doesn’t step right into the boring world of “let’s just throw in a lua scripting engine and call it a day”. You’re still limited by emulation speed and by memory constraints.
However, after checking out the preliminary spec for the CPU, I was a bit disappointed.
It’s been almost 7 years since the Wii was released. Back in 2006, not many owned a living room PC. PCs were still relatively bulky, and the Chinese offerings were limited to horrible media players. At the time, the prospect of having a game console double as a HTPC and being able to browse the web, play games for older platforms with emulation, and run homebrew games on a device which you already had in the living room was rather appealing.
Fast forward to today. Mobile SoCs have made huge advances - you can get a quad-core chip in a phone these days - and have made the jump to the living room. Spend $25 and you can get a Raspberry Pi, which is about on par with the Wii at 1/10 of the launch price and 1/7th of the power consumption (with HD video). Spend $100 and you can get an Ouya, which beats the Wii U’s CPU and doesn’t have too shabby graphics at one third the cost. These mobile-derived devices aren’t quite a replacement for game consoles yet, but they’re catching up fast. They’re cheap enough that they’re almost disposable. The software ecosystem is much larger and wider than any console has ever had. More importantly, they’re open, and the development tools and environments are way better for open development than any game console ever was.
Let’s take a break from Wii U hacking to take a quick look at Mega’s security.
In case you’ve been living under a rock the past few days, Kim Dotcom (of Megaupload infamy) has launched his new cloud storage site, Mega. Mega has an impressive sales pitch, promising secure cloud storage where only the user has the key to decrypt his or her files, and the encryption and decryption happens securely in the browser.
One of the things we’ve been playing with recently is the AT&T Microcell. This device is intended to provide a cheap way for AT&T to increase their network coverage at the expense of their customers. The device is essentially a small cell-tower in a box, which shuttles your calls and data back to the AT&T mothership over your home broadband connection.
This kind of device is becoming more and more popular with the various mobile providers. They are commonly known as residential femtocells.
We’re curious. We love gadgets. We love to take gadgets apart and see what makes them tick. So naturally, we’ve taken a look at a number of different femtocells.
We finally got around to looking at this AT&T variant this week, and discovered that it is totally full of fail.
On Friday, the 13th of January 2012, the ACM Queue published an article by Poul-Henning Kamp entitled ‘The CRYPO-CS-SETI challenge: An Un-programmng challenge’. In this post, Kamp challenged his readers to attempt to disassemble a program for an unknown computer. In what we assume was an attempt at increased dramatic impact, he described a scenario where part of an extra-terrestrial computer is discovered, with only a memory storage device intact.
We first heard of the challenge on the morning of Saturday the 14th, and thought it sounded like fun. Within five days we had completely disassembled the program. In addition, we had accidentally identified the oh-so-terrestrial source of the code.
This is the first in a series of posts in which we’ll describe how we went about reverse-engineering the machine architecture using nothing but the binary blob and our wits.
We finally have a YouTube channel and we thought we’d kick things off with a little teaser:
Keep in mind that this is purely a demonstration at this stage. Depending on how things progress and what direction development takes, we may or may not release something like this in this form. Please don’t ask for release dates. We’d rather spend time investigating the new system than putting together a release that may or may not end up being the Right Way to do things in the future ;).