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” →

The Bedside Light App That Phones Home

December 26, 2017 by Jenny List 31 Comments

Desiring a bedside lamp with a remote control, [Peadar]’s wife bought a Xiaomi Yeelight, an LED model with an accompanying Android app. And since he’s a security researcher by trade, he subjected the app to a close examination and found it to be demanding permissions phoning home to a far greater extent than you’d expect from a bedside light.

His write-up is worth a read for its fascinating run-through of the process for investigating any Android app, as it reveals the level to which the software crosses the line from simple light-controller into creepy data-slurper. The abilities to create accounts on your device, download without notification, take your WiFi details and location, and record audio are not what you’d expect to be necessary in this application. He also looks into the Xiaomi web services the app uses to phone home, revealing some interesting quirks along the way.

This story has received some interest across the Internet, quite rightly so since it represents a worrying over-reach of corporate electronic intrusion. It is interesting though to see commentary whose main concern is that the servers doing the data-slurping are in China, as though somehow in this context the location is the issue rather than the practice itself. We’ve written before about how some mildly sinister IoT technologies seem to bridge the suspicion gap while others don’t, it would be healthy to see all such services subjected to the same appraisal.

As a postscript, [Peadar] couldn’t get the app to find his wife’s Yeelight, let alone control it. That the spy part of the app works while the on-the-surface part doesn’t speaks volumes about the development priorities of its originator.

Image: Xiaomi Yeelight website.

Edward Snowden Introduces Baby Monitor For Spies

December 24, 2017 by Tom Nardi 25 Comments

Famed whistleblower [Edward Snowden] has recently taken to YouTube to announce Haven: an Open Source application designed to allow security-conscious users turn old unused Android smartphones and tablets into high-tech monitoring devices for free. While arguably Haven doesn’t do anything that wasn’t already possible with software on the market, the fact that it’s Open Source and designed from the ground up for security does make it a bit more compelling than what’s been available thus far.

Developed by the Freedom of the Press Foundation, Haven is advertised as something of a role-reversal for the surveillance state. Instead of a smartphone’s microphone and camera spying on its owner, Haven allows the user to use those sensors to perform their own monitoring. It’s not limited to the camera and microphone either, Haven can also pull data from the smartphone’s ambient light sensor and accelerometer to help determine when somebody has moved the device or entered the room. There’s even support for monitoring the device’s power status: so if somebody tries to unplug the device or cut power to the room, the switch over to the battery will trigger the monitoring to go active.

Thanks to the Open Source nature of Haven, it’s hoped that continued development (community and otherwise) will see an expansion of the application’s capabilities. To give an example of a potential enhancement, [Snowden] mentions the possibility of using the smartphone’s barometer to detect the opening of doors and windows.

With most commercially available motion activated monitor systems, such as Nest Cam, the device requires a constant Internet connection and a subscription. Haven, on the other hand, is designed to do everything on the local device without the need for a connection to the Internet, so an intruder can’t just knock out your Wi-Fi to kill all of your monitoring. Once Haven sees or hears something it wants you to know about it can send an alert over standard SMS, or if you’re really security minded, the end-to-end encrypted Signal.

The number of people who need the type of security Haven is advertised as providing is probably pretty low; unless you’re a journalist working on a corruption case or a revolutionary plotting a coup d’etat, you’ll probably be fine with existing solutions. That being said, we’ve covered on our own pages many individuals who’ve spent considerable time and effort rolling their own remote monitoring solutions which seem to overlap the goals of Haven.

So even if your daily life is more John Doe than James Bond, you may want to check out the GitHub page for Haven or even install it on one of the incredibly cheap Android phones that are out there and take it for a spin.

Continue reading “Edward Snowden Introduces Baby Monitor For Spies” →

DRM Workarounds Save Arcade Cabinet

December 19, 2017 by Bryan Cockfield 31 Comments

DRM has become a four-letter word of late, with even media companies themselves abandoning the practice because of how ineffective it was. DRM wasn’t invented in the early 2000s for music, though. It’s been a practice on virtually everything where software is involved, including arcade cabinets. This is a problem for people who restore arcade machines, and [mon] has taken a swing at unraveling the DRM for a specific type of Konami cabinet.

The game in question, Reflec Beat, is a rhythm-based game released in 2010, and the security is pretty modern. Since the game comes with a HDD, a replacement drive can be ordered with a security dongle which acts to decrypt some of the contents on the HDD, including the game file and some other information. It’s not over yet, though. [mon] still needs to fuss with Windows DLL files and a few levels of decryption and filename obfuscation before getting the cabinet functional again.

The writeup on this cabinet is very detailed, and if you’re used to restoring older games, it’s a bit of a different animal to deal with than the embedded hardware security that older cabinets typically have. If you’ve ever wanted to own one of these more modern games, or you’re interested in security, be sure to check out the documentation on the project page. If your tastes are more Capcom and less Konami, check out an article on their security system in general, or in de-suiciding boards with failing backup batteries.

Bluetooth Gun Safe Cracked By Researchers

December 13, 2017 by Tom Nardi 64 Comments

Believe it or not, there are quite a few people out there who have purchased gun safes that can be remotely unlocked by Bluetooth. Now we can understand why somebody might think this was a good idea: the convenience of being able to hit a button on your phone and have your weapon available in the heat of the moment is arguably a big selling point for people who are purchasing something like this for home defense. But those with a more technical mind will likely wonder if the inherent risks of having your firearm (or other valuables) protected by a protocol that often relies on security by obscurity outweighs the convenience of not needing to enter in a combination on the keypad.

Well, you can wonder no more, as researchers at [Two Six Labs] have recently published a detailed document on how they managed to remotely unlock the Vaultek VT20i with nothing more exotic than an Ubertooth. In the end, even the Ubertooth wasn’t actually required, as this particular device turned out to be riddled with security issues.

[Two Six Labs] has not publicly released the complete source code of the software demonstrated in their YouTube video for very obvious reasons, but the page on their site does go into fantastic detail on how they uncovered the multiple vulnerabilities that allowed them to write it. Even if you’re not the kind of person who would ever need a gun safe, the information contained in their documentation about analyzing Bluetooth communications is fascinating reading.

It was discovered that the PIN for the safe was actually being transmitted by the accompanying smartphone application in plain-text, which would be bad enough normally. But after further analysis, it became clear that the safe wasn’t even bothering to check the PIN code anyway.

Scripting app interactions with ADB and Python

For extra style points, [Two Six Labs] also show a way to brute force the PIN using the Vaultek Android application by writing a Python script that punches in codes sequentially until it hits on the right one; the developers didn’t even bother to put in limits on failed attempts.

For a device that is ostensibly designed to contain a deadly weapon, the security flaws the team at [Two Six Labs] discovered are absolutely inexcusable. But there is a positive outcome, as the manufacturer has vowed to update the vulnerable safes and make a better effort in the future to more rigorously design and test their Bluetooth implementation. This is the goal of responsible disclosure, and we’re encouraged to see the manufacturer doing the right thing

The security concerns of Bluetooth controlled locks are well known, so it’s a bit disappointing that devices like this are still slipping through the cracks. We suggest you remain skeptical of any security device utilizing Bluetooth until the industry starts taking things a little more seriously.

Continue reading “Bluetooth Gun Safe Cracked By Researchers” →

What You Need To Know About The Intel Management Engine

December 11, 2017 by Brian Benchoff 95 Comments

Over the last decade, Intel has been including a tiny little microcontroller inside their CPUs. This microcontroller is connected to everything, and can shuttle data between your hard drive and your network adapter. It’s always on, even when the rest of your computer is off, and with the right software, you can wake it up over a network connection. Parts of this spy chip were included in the silicon at the behest of the NSA. In short, if you were designing a piece of hardware to spy on everyone using an Intel-branded computer, you would come up with something like the Intel Managment Engine.

Last week, researchers [Mark Ermolov] and [Maxim Goryachy] presented an exploit at BlackHat Europe allowing for arbitrary code execution on the Intel ME platform. This is only a local attack, one that requires physical access to a machine. The cat is out of the bag, though, and this is the exploit we’ve all been expecting. This is the exploit that forces Intel and OEMs to consider the security implications of the Intel Management Engine. What does this actually mean?

Continue reading “What You Need To Know About The Intel Management Engine” →