34C3: Hacking The Nintendo Switch

December 29, 2017 by Tom Nardi 37 Comments

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.

We’ve seen other attempts at reverse engineering Nintendo’s hardware, but by the looks of it, the Switch has put up a much harder fight than previous console generations. Makes you wonder what tricks Nintendo will have up their sleeves for the next generation.

Continue reading “34C3: Hacking The Nintendo Switch” →

34C3: Fitbit Sniffing And Firmware Hacking

December 29, 2017 by Brian McEvoy 19 Comments

If you walked into a gym and asked to sniff exercise equipment you would get some mighty strange looks. If you tell hackers you’ve sniffed a Fitbit, you might be asked to give a presentation. [Jiska] and [DanielAW] were not only able to sniff Bluetooth data from a run-of-the-mill Fitbit fitness tracker, they were also able to connect to the hardware with data lines using test points etched right on the board. Their Fitbit sniffing talk at 34C3 can be seen after the break. We appreciate their warning that opening a Fitbit will undoubtedly void your warranty since Fitbits don’t fare so well after the sealed case is cracked. It’s all in the name of science.

There’s some interesting background on how Fitbit generally work. For instance, the Fitbit pairs with your phone which needs to be validated with the cloud server. But once the cloud server sends back authentication credentials they will never change because they’re bound to to the device ID of the Fitbit. This process is vulnerable to replay attacks.

Data begin sent between the Fitbit and the phone can be encrypted, but there is a live mode that sends the data as plain text. The implementation seemed to be security by obscurity as a new Bluetooth handle is used for this mode. This technique prevents the need to send every encrypted packet to the server for decryption (which would be for every heartbeat packet). So far the fix for this has been the ability to disable live mode. If you have your own Fitbit to play with, sniffing live mode would be a fun place to start.

The hardware side of this hack begins by completely removing the PCB from the rubber case. The board is running an STM32 and the team wanted to get deep access by enabling GDB. Unfortunately, the debug pins were only enabled during reset and the stock firmware disables them at startup (as it should). The workaround was to rewrite the firmware so that the necessary GPIO remain active and there’s an interesting approach here. You may remember [Daniel Wegemer] from the Nexmon project that reverse engineered the Nexus 5 WiFi. He leveraged the binary patching he used on Nexmon to patch the Fitbit firmware to enable debugging support. Sneaky!

For more about 34C3 we have a cheatsheet of the first day and for more about Fitbit security, check out this WAV file.

Continue reading “34C3: Fitbit Sniffing And Firmware Hacking” →

34C3: Ultimate Apollo Guidance Computer Talk

December 28, 2017 by Tom Nardi 14 Comments

While it might not be as exciting as the Saturn V rocket itself, the Apollo Guidance Computer (AGC) was one of the most important developments of the entire Apollo program. While comically underwhelming compared to modern hardware, the AGC was nothing short of revolutionary when it was developed in the 1960’s. Before the AGC, the smallest computers were about the size of a refrigerator and consumed hundreds of watts; both big problems if you’re trying to pack them into a relatively tiny space capsule with limited resources. Not only did the AGC get humanity to the Moon and back, but it also redefined the state of the art for microcomputers, paving the way for the desktop systems of the 1970’s.

That said, the design and operation of the AGC is downright bizarre to modern eyes; it comes from a time of limitations we can hardly fathom. With this in mind, [Michael Steil] and [Christian Hessmann] put together “The Ultimate Apollo Guidance Computer Talk” for 34C3.

This hour-long presentation walks viewers through every aspect of not only the AGC itself, but how it interacted with the Saturn V rocket and the overall lunar mission. Even if you aren’t enough of a vintage computing aficionado to appreciate the complexities of core rope memory, the presentation gives a fascinating look at the gritty details of one of humanity’s greatest achievements.

Though very slick and easy to understand graphics, [Michael] and [Christian] break down the alien world of the AGC. Even if a lot of this part of the presentation goes over your head, just listen for the sounds of laughter or applause from the audience: that’s when you’re looking at something really off-the-wall.

Of particular note during this presentation is the explanation of how the astronauts actually interacted with the AGC. The AGC’s display and keyboard (referred to as DSKY) may seem rather obtuse even to those who used to hack on a VT100, but [Michael] and [Christian] explain how it’s not quite as complex as it seems. Comparing the input and output of the DSKY with what we would see on a more contemporary command line interface, the presentation makes the case that it’s actually a very straightforward way of talking to the computer.

There’s also a complete breakdown of the different phases of the Apollo mission from launch to landing, explaining what the AGC would be doing at any given time. The DSKY is overlaid on actual footage from the Apollo missions, giving a unique perspective as to what the astronauts would see on their computer during iconic moments such as stage separation or lunar touchdown.

If this presentation has you hungry for more Apollo-era computer technology, we’ve covered plenty of projects to keep you occupied. From building a replica DSKY to leisurely paging through the printed version of the AGC’s source code.

34C3: Hacking Into A CPU’s Microcode

December 28, 2017 by Elliot Williams 67 Comments

Inside every modern CPU since the Intel Pentium fdiv bug, assembly instructions aren’t a one-to-one mapping to what the CPU actually does. Inside the CPU, there is a decoder that turns assembly into even more primitive instructions that are fed into the CPU’s internal scheduler and pipeline. The code that drives the decoder is the CPU’s microcode, and it lives in ROM that’s normally inaccessible. But microcode patches have been deployed in the past to fix up CPU hardware bugs, so it’s certainly writeable. That’s practically an invitation, right? At least a group from the Ruhr University Bochum took it as such, and started hacking on the microcode in the AMD K8 and K10 processors.

The hurdles to playing around in the microcode are daunting. It turns assembly language into something, but the instruction set that the inner CPU, ALU, et al use was completely unknown. [Philip] walked us through their first line of attack, which was essentially guessing in the dark. First they mapped out where each x86 assembly codes went in microcode ROM. Using this information, and the ability to update the microcode, they could load and execute arbitrary microcode. They still didn’t know anything about the microcode, but they knew how to run it.

So they started uploading random microcode to see what it did. This random microcode crashed almost every time. The rest of the time, there was no difference between the input and output states. But then, after a week of running, a breakthrough: the microcode XOR’ed. From this, they found out the syntax of the command and began to discover more commands through trial and error. Quite late in the game, they went on to take the chip apart and read out the ROM contents with a microscope and OCR software, at least well enough to verify that some of the microcode operations were burned in ROM.

The result was 29 microcode operations including logic, arithmetic, load, and store commands — enough to start writing microcode code. The first microcode programs written helped with further discovery, naturally. But before long, they wrote microcode backdoors that triggered when a given calculation was performed, and stealthy trojans that exfiltrate data encrypted or “undetectably” through introducing faults programmatically into calculations. This means nearly undetectable malware that’s resident inside the CPU. (And you think the Intel Management Engine hacks made you paranoid!)

[Benjamin] then bravely stepped us through the browser-based attack live, first in a debugger where we could verify that their custom microcode was being triggered, and then outside of the debugger where suddenly xcalc popped up. What launched the program? Calculating a particular number on a website from inside an unmodified browser.

He also demonstrated the introduction of a simple mathematical error into the microcode that made an encryption routine fail when another particular multiplication was done. While this may not sound like much, if you paid attention in the talk on revealing keys based on a single infrequent bit error, you’d see that this is essentially a few million times more powerful because the error occurs every time.

The team isn’t done with their microcode explorations, and there’s still a lot more of the command set left to discover. So take this as a proof of concept that nearly completely undetectable trojans could exist in the microcode that runs between the compiled code and the CPU on your machine. But, more playfully, it’s also an invitation to start exploring yourself. It’s not every day that an entirely new frontier in computer hacking is bust open.

34C3: The First Day Is A Doozy

December 27, 2017 by Elliot Williams 8 Comments

It’s 5 pm, the sun is slowly setting on the Leipzig conference center, and although we’re only halfway through the first day, there’s a ton that you should see. We’ll report some more on the culture of the con later — for now here’s just the hacks. Continue reading “34C3: The First Day Is A Doozy” →

Hackaday At 34C3

December 24, 2017 by Elliot Williams 19 Comments

It’s that time of year. While the rest of the Christmas-celebrating world sits around and plays with the toys that they got out from under the tree, German nerds head off to the biggest European hacker con: the 34th annual Chaos Communications Congress, running Dec. 27th through 30th.

The CCC is both a grandparent among hacker cons, and the most focused on using technology to improve the world and bringing folks together. (The “communications” in the name is a dead giveaway.) This year’s motto, “tuwat!” is slangy-dialecty for “do something!” and is call to get up off the couch and use your super-powers for good.

If you can’t get over to Leipzig to join us, you’ll be able to read our extensive coverage starting up shortly after the opening ceremonies, and probably stretching well into 2018. And since the CCC media folks manage to stream every talk, hackers all over the world can follow along live. Most talks are in English, so get together with folks in your hackspace and have a video night!

And if you are in Leipzig, be on the lookout for [Elliot] who will be wandering around, attending workshops, and writing down as much as possible. Show me something cool, rave about a particularly good talk, or just say “hi”.

Fairy Dust clipart courtesy [sonoftroll].