34C3: Reverse Engineering FPGAs

We once knew a guy who used to tell us that the first ten times he flew in an airplane, he jumped out of it. It was his eleventh flight before he walked off the plane. [Mathias Lasser] has a similar story. Despite being one of the pair who decoded the iCE40 bitstream format a few years ago, he admits in his 34C3 talk that he never learned how to use FPGAs. His talk covers how he reverse engineered the iCE40 and the Xilinx 7 series devices.

If you are used to FPGAs in terms of Verilog and VHDL, [Mathias] will show you a whole new view of rows, columns, and tiles. Even if you don’t ever plan to work at that level, sometimes understanding hardware at the low level will inspire some insights that are harder to get at the abstraction level.

Continue reading “34C3: Reverse Engineering FPGAs”

Great People and Culture at 34th Chaos Communication Congress

If you’ve been to a Chaos Communication Congress, you know the feeling — the strange realization after it’s all over that you’re back in the “real world”. It’s somehow alienating and unfriendly in comparison to being surrounded by computer freaks, artists, hackers, activists, coders, and other like-minded individuals over the four days of the Congress. A hand-written poster by the podcasting center read “Endlich, normale Leute” — “At last, normal people” — which is irony piled on irony but the sentiment is still right for certain strange values of “normal”. Normal hackers? You’d probably fit right in.

We cover a lot of the talks from the Congress, because they’re first-class and because you can play along at home, but the real soul of the Congress is people getting together, making something temporary and crazy, talking over their common plans, learning new things directly from one-another, and simply having fun. Here’s our chance to give you a little of the other side of the Congress.
Continue reading “Great People and Culture at 34th Chaos Communication Congress”

34C3: Roll Your Own Network Driver In Four Simple Steps

Writing your own drivers is a special discipline. Drivers on the one hand work closely with external hardware and at the same time are deeply ingrained into the operating system. That’s two kinds of specialization in one problem. In recent years a lot of dedicated networking hardware is being replaced by software. [Paul Emmerich] is a researcher who works on improving the performance of these systems.

Making software act like network hardware requires drivers that can swiftly handle a lot of small packets, something that the standard APIs where not designed for. In his talk at this year’s Chaos Commnication Congress [Paul] dissects the different approaches to writing this special flavor of drivers and explains the shortcomings of each.

Continue reading “34C3: Roll Your Own Network Driver In Four Simple Steps”

34C3: Microphone Bugs

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

[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

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

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”