34C3: Microphone Bugs

January 1, 2018 by Sven Gregori 32 Comments

Inspiration can come from many places. When [Veronica Valeros] and [Sebastian Garcia] from the MatesLab Hackerspace in Argentina learned that it took [Ai Weiwei] four years to discover his home had been bugged, they decided to have a closer look into some standard audio surveillance devices. Feeling there’s a shortage of research on the subject inside the community, they took matters in their own hands, and presented the outcome in their Spy vs. Spy: A modern study of microphone bugs operation and detection talk at 34C3. You can find the slides here, and their white paper here.

Focusing their research primarily on FM radio transmitter devices, [Veronica] and [Sebastian] start off with some historical examples, and the development of such devices — nowadays available off-the-shelf for little money. While these devices may be shrugged off as a relic of Soviet era spy fiction and tools of analog times, the easy availability and usage still keeps them relevant today. They conclude their research with a game of Hide and Seek as real life experiment, using regular store-bought transmitters.

An undertaking like this would not be complete without the RTL-SDR dongle, so [Sebastian] developed the Salamandra Spy Microphone Detection Tool as alternative for ready-made detection devices. Using the dongle’s power levels, Salamandra detects and locates the presence of potential transmitters, keeping track of all findings. If you’re interested in some of the earliest and most technologically fascinating covert listening devices, there is no better example than Theremin’s bug.

Continue reading “34C3: Microphone Bugs” →

34C3: North Korea’s Consumer Technology

December 30, 2017 by Adam Fabio 19 Comments

[Will Scott] and [Gabe Edwards] shed some light on the current state of consumer computing technology at 34C3 in their talk DPRK Consumer Technology. The pair has also created a website to act as a clearinghouse for this information — including smartphone OS images up at koreaComputerCenter.org.

Not a whole lot is known about what technology North Korean citizens have available to them. We have seen Red Star OS, the Mac-like Linux based operating system used on PC based desktops. But what about other systems like smartphones?

[Will] and [Gabe] found that cell phones in North Korea are typically manufactured by Chinese companies, running a custom version of the Android Operating system. The phone hardware is common — the phone sold as the Pyongyang 2407 in North Korea is also sold in India as the Genie v5. If you can get your hands on the Genie, you can run the Korean version of the Android OS on that hardware.

Continue reading “34C3: North Korea’s Consumer Technology” →

34C3: Using Your Car As Video Game Controller

December 30, 2017 by Christian Trapp 6 Comments

Despite the presence of human drivers, modern cars are controlled by computers. In his talk at the Chaos Communication Congress [Guillaume Heilles] and [P1kachu] demonstrate the potential of taking control of a car’s computer. This of course leads to the natural conclusion of emulate an Xbox controller and using the car to play computer games.

His research was limited by the fact that the only cars they had access to were the daily drivers of different members of [P1kachu]’s family, which meant that all tinkering had to be strictly non-destructive. Despite this, they achieved impressive results and deliver a great introduction into reverse engineering.

[P1kachu] used a RasPi and an OBD-II adapter to access the car’s CAN bus and begins the presentation with a quick overview of the protocol. He then briefly touches on security measures that he ran into, which are optional and their implementation varies widely between manufacturers. His first attempt to access the CAN bus was successfully blocked by a challenge-response algorithm doing its work. His mother’s convertible however provided no such obstacles and gaining access allowed him to map the position of the steering wheel and pedals to a game controller, using the car to play video games.

After this, [Guillaume] steps in and walks us through the teardown of a gadget that plugs into the OBD-II port and claims to do amazing things for your car’s mileage by reprogramming the ECU. The device was not brand specific and after having seen the variations in the ways different manufacturers implement the protocol, [Guillaume] and [P1kachu] doubted that the gadget was capable of even holding the information required to modify every known implementation out there. Listening to the output of the device, along with a quick analysis of the circuit followed by decapping the single chip they found, showed that their doubt was justified. The lecture closes with an extended Q&A that adds more information on car hacking. Those that don’t have access to a car can instead tear down hot glue guns, doppler modules or antique calculators.

Continue reading “34C3: Using Your Car As Video Game Controller” →

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.