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.

Hackaday Prize Bring-a-Hack Munich Was Great

May 6, 2017 by Elliot Williams 9 Comments

Thanks to everyone who came to the Hackaday Prize Make Munich Meetup and Bring-a-Hack last night! We had a great time, and there were a bunch of cool projects on display, some of which we even got pictures of. Frankly, we were enjoying chatting too much to be peering through a camera lens.

Around 30 people made it over to the Munich CCC, including some familiar faces from the last time we had a party in Munich. Although it was a mostly local crowd, we also had visitors from Switzerland, Austria, and even the US of A: TV-B-Gone inventor, HaD Prize judge, and mad hacker [Mitch Altmann] was in the house.

After we got a little food and drink, we opened up the floor for the projects, lightning-talk style. The largest projects were probably a tie between an own-design CoreXY 3D printer and a boombox with some serious sound output. One guest’s automated bacterial culture apparatus probably wouldn’t have fit on the table, so it’s OK that it got left in the lab. The smallest hack? Probably [Alex]‘s super-mini USB LED clock gizmo, complete with hand-soldered 0402 LEDs, and “even smaller stuff on the backside”.

Continue reading “Hackaday Prize Bring-a-Hack Munich Was Great” →

33C3: Works For Me

December 30, 2016 by Elliot Williams 20 Comments

The Chaos Communication Congress (CCC) is the largest German hacker convention by a wide margin, and it’s now in its thirty-third year, hence 33C3. The Congress is a techno-utopian-anarchist-rave with a social conscience and a strong underpinning of straight-up hacking. In short, there’s something for everyone, and that’s partly because a CCC is like a hacker Rorschach test: everyone brings what they want to the CCC, figuratively and literally. Somehow the contributions of 12,000 people all hang together, more or less. The first “C” does stand for chaos, after all.

What brings these disparate types to Hamburg are the intersections in the Venn diagrams. Social activists who may actually be subject to state surveillance are just as interested in secure messaging as the paranoid security geek or the hardcore crypto nerd who’s just in it for the algorithms. Technology, and how we use it to communicate and organize society, is a pretty broad topic. Blinking lights also seem to be in the intersection. But on top of that, we are all geeks. There’s a lot of skill, smarts, and know-how here, and geeks like sharing, teaching, and showing off their crazy creations.

Continue reading “33C3: Works For Me” →

Hackers And Heroes: Rise Of The CCC And Hackerspaces

January 12, 2016 by Elliot Williams 27 Comments

From its roots in phone phreaking to the crackdowns and legal precedents that drove hacking mostly underground (or into business), hacker culture in the United States has seen a lot over the last three decades. Perhaps the biggest standout is the L0pht, a visible 1990s US hackerspace that engaged in open disclosure and was, arguably, the last of the publicly influential US hacker groups.

The details of the American hacker scene were well covered in my article yesterday. It ended on a bit of a down note. The L0pht is long gone, and no other groups that I know of have matched their mix of social responsibility and public visibility. This is a shame because a lot of hacker-relevant issues are getting decided in the USA right now, and largely without our input.

Chaos Computer Club

But let’s turn away from the USA and catch up with Germany. In the early 1980s, in Germany as in America, there were many local computer clubs that were not much more than a monthly evening in a cafeteria or a science museum or (as was the case with the CCC) a newspaper office. Early computer enthusiasts traded know-how, and software, for free. At least in America, nothing was more formally arranged than was necessary to secure a meeting space: we all knew when to show up, so what more needed to be done?

Things are a little different in the German soul. Peer inside and you’ll find the “Vereinsmentalität” — a “club-mentality”. Most any hobby or sport that you can do in Germany has an associated club that you can join. Winter biathlon, bee-keeping, watercolor painting, or hacking: when Germans do fun stuff, they like to get organized and do fun stuff together.

Continue reading “Hackers And Heroes: Rise Of The CCC And Hackerspaces” →

32C3: Running Linux On The PS4

December 31, 2015 by Brian Benchoff 16 Comments

At the 2010 Chaos Communication Congress, fail0verflow (that’s a zero, not the letter O) demonstrated their jailbreak of the PS3. At the 2013 CCC, fail0verflow demonstrated console hacking on the Wii U. In the last two years, this has led to an active homebrew scene on the Wii U, and the world is a better place. A few weeks ago, fail0verflow teased something concerning the Playstation 4. While this year’s announcement is just a demonstration of running Linux on the PS4, fail0verflow can again claim their title as the best console hackers on the planet.

Despite being able to run Linux, there are still a few things the PS4 can’t do yet. The current hack does not have 3D acceleration enabled; you won’t be playing video games under Linux with a PS4 any time soon. USB doesn’t work yet, and that means the HDD on the PS4 doesn’t work either. That said, everything to turn the PS4 into a basic computer running Linux – serial port, framebuffer, HDMI encoder, Ethernet, WiFi, Bluetooth, and the PS4 blinkenlights – is working.

Although the five-minute lightning talk didn’t go into much detail, there is enough information on their slides to show what a monumental task this was. fail0verflow changed 7443 lines in the kernel, and discovered the engineers responsible for the southbridge in the PS4 were ‘smoking some real good stuff’.

This is only fail0verflow’s announcement that Linux on the PS4 works, and the patches and bootstrap code are ‘coming soon’. Once this information is released, you’ll need to ‘Bring Your Own Exploit™’ to actually install Linux.

Video of the demo below.

Continue reading “32C3: Running Linux On The PS4” →

32C3: Vector Video Games

December 29, 2015 by Brian Benchoff 33 Comments

There are a few classic video games that rely on vector graphics and special monitors. Asteroids is incomplete if you’re not playing it in its original arcade format. The same goes with Tempest, Lunar Lander, and the 1983 Star Wars arcade game. Emulation of these games is possible, even with MAME, but the display – like every display you can buy today – is still rasterized. The solution to this problem is to create a vector display output for MAME that works in conjunction with adapter boards and DACs connected to a monitor.

For this year’s Chaos Computer Congress, that’s exactly what [Trammell Hudson] and [Adelle Lin] did. They’ve created an open source vector gaming system that connects MAME to XY monitors and oscilloscopes.

The build uses a custom board equipped with a Teensy 3.1 microcontroller and a 12-bit DAC to convert XY coordinates sent by MAME to vectors that can be displayed on any XY monitor. This, of course, requires a patch to MAME, which the maintainers rejected as being an, “unacceptably hacky way to achieve the intended result.” It does achieve the intended result, though: allowing dozens of vector games playable on whatever monitor supports vector graphics.

So far, [Trammell] and [Adelle] have gotten their system working on Vectrex consoles, analog oscilloscopes set to XY mode, and vectorscopes that litter every broadcast station and surplus shop. Check out [Trammell] and [Adelle]’s talk, and if you want to build the V.st vector display driver, the board is available from OSHPark.

32C3: Towards Trustworthy X86 Laptops

December 28, 2015 by Brian Benchoff 38 Comments

Security assumes there is something we can trust; a computer encrypting something is assumed to be trustworthy, and the computer doing the decrypting is assumed to be trustworthy. This is the only logical mindset for anyone concerned about security – you don’t have to worry about all the routers handling your data on the Internet, eavesdroppers, or really anything else. Security breaks down when you can’t trust the computer doing the encryption. Such is the case today. We can’t trust our computers.

In a talk at this year’s Chaos Computer Congress, [Joanna Rutkowska] covered the last few decades of security on computers – Tor, OpenVPN, SSH, and the like. These are, by definition, meaningless if you cannot trust the operating system. Over the last few years, [Joanna] has been working on a solution to this in the Qubes OS pro ject, but everything is built on silicon, and if you can’t trust the hardware, you can’t trust anything.

And so we come to an oft-forgotten aspect of computer security: the BIOS, UEFI, Intel’s Management Engine, VT-d, Boot Guard, and the mess of overly complex firmware found in a modern x86 system. This is what starts the chain of trust for the entire computer, and if a computer’s firmware is compromised it is safe to assume the entire computer is compromised. Firmware is also devilishly hard to secure: attacks against write protecting a tiny Flash chip have been demonstrated. A Trusted Platform Module could compare the contents of a firmware, and unlock it if it is found to be secure. This has also been shown to be vulnerable to attack. Another method of securing a computer’s firmware is the Core Root of Trust for Measurement, which compares firmware to an immutable ROM-like memory. The specification for the CRTM doesn’t say where this memory is, though, and until recently it has been implemented in a tiny Flash chip soldered to the motherboard. We’re right back to where we started, then, with an attacker simply changing out the CRTM chip along with the chip containing the firmware.

But Intel has an answer to everything, and to the house of cards for firmware security, Intel introduced their Management Engine. This is a small microcontroller running on every Intel CPU all the time that has access to RAM, WiFi, and everything else in a computer. It is security through obscurity, though. Although the ME can elevate privileges of components in the computer, nobody knows how it works. No one has the source code for the operating system running on the Intel ME, and the ME is an ideal target for a rootkit.

Is there hope for a truly secure laptop? According to [Joanna], there is hope in simply not trusting the BIOS and other firmware. Trust therefore comes from a ‘trusted stick’ – a small memory stick that contains a Flash chip that verifies the firmware of a computer independently of the hardware in a computer.

This, with open source firmwares like coreboot are the beginnings of a computer that can be trusted. While the technology for a device like this could exist, it will be a while until something like this will be found in the wild. There’s still a lot of work to do, but at least one thing is certain: secure hardware doesn’t exist, but it can be built. Whether secure hardware comes to pass is another thing entirely.

You can watch [Joanna]’s talk on the 32C3 streaming site.