35C3: Biggest Communication Congress, Yet Little Chaos

Every year for the past 35 years, the German Chaos Computer Club has met just after Christmas for a few days of “Spaß am Gerät” — having fun with the machines. And that’s everything from trying to bring an old PDP-8 back into running condition to forging new software to replace the old and busted social media platforms that permeate our lives. The sum total of around 17,000 people doing the nerdy stuff that they love, and sharing it together, is both amazing and inspiring. Four days of little sleep and much socializing later, I bet there was still another four days’ worth of stuff to see.

The official theme this year was “Refreshing Memories” which honestly sounds a bit too much like a cola slogan, but was a great opportunity to think back on the hacks of the past that got us where we are. Assemblies put up shrines to their hacker heroes of the past. Retro computers were everywhere, in the talks and on the floor. This year’s Congress was a great time to look back and remember, but also to create new memories for the future. On that front, it was a total success.

But the unofficial theme this year was “Smooth Running”. Everything went very well, which is no small feat considering that the infrastructure, decoration, security, and even the medical response teams are from the Chaos community. It’s the depth of engagement that makes this work: of the 17,000 people who showed up, just over 4,000 of them volunteered for “angel” shifts — meaning they helped guard the doors, staff the info desks, or build up or tear down. It was the largest ever CCC, and you could feel it, but they pulled it off, and then some.

The angels are geeks just like you and me, and since everything went so smoothly, they had time to play. For instance, the phone operations people offer DECT phone service so that attendees can bring in their home phones and use them at Congress. In years past, the lines to register and enroll phones were painfully long. This year, it all happened online, and the result is that the phone ops crew got bored. That explains how they had time to establish roaming home-phone wireless service in some of the normal Leipzig city trams. Wait, what?

Continue reading “35C3: Biggest Communication Congress, Yet Little Chaos”

35C3: Safe And Secure Drivers In High-Level Languages

Writing device drivers is always a good start for a journey into the Linux kernel code. Of course, the kernel is a highly complex piece of software, and if you mess up your code properly, you might take down the entire system with you. User-space drivers on the other hand might not look as good on your CV, but they can help to work around some of the dangers and complexity of the kernel space. Plus, you don’t necessarily have to limit yourself to C to write them, especially if you are concerned about the usual C pitfalls and the security issues they can lead to.

With that in mind, [Paul Emmerich] is researching the concept of Linux user-space drivers for Intel’s 10Gbit network cards using other high-level languages, and recruits his students to write their final theses about the implementation details of as many languages as possible.

At last year’s 34c3, [Paul] already demonstrated the basics of writing such a user-space network driver for Linux, which serves now as reference implementation for his students. We won’t see Bash or JavaScript here, but we will see a brief summary of what it generally means to develop user-space drivers in C#, Swift, OCaml, or Haskell, along a more detailed insight from [Sebastian Voit] and [Simon Ellmann] about Go and Rust. A collection of each language’s implementation can be found on GitHub.

Since some of these languages bring their own memory handling and perform unpredictable garbage collection, performance and latency are two big topics to cover here. But then, the general concept is language-independent, so even if nothing in the world could ever make you give up on C, you might at least take away some new ideas for driver development.
Continue reading “35C3: Safe And Secure Drivers In High-Level Languages”

35C3: A Deep Dive into DOS Viruses and Pranks

Oh, the hijinks that the early days of the PC revolution allowed. Back in the days when a 20MB hard drive was a big deal and MS-DOS 3.1 ruled over every plain beige PC-clone cobbled together by enthusiasts like myself, it was great fun to “set up” someone else’s machine to do something unexpected. This generally amounted to finding an unattended PC — the rooms of the residence hall where I lived in my undergrad days were a target-rich environment in this regard — and throwing something annoying in the AUTOEXEC.BAT file. Hilarity ensued when the mark next booted the machine and was greeted with something like an inverted display or a faked hard drive formatting. Control-G was good to me too.

So it was with a sense of great nostalgia that I watched [Ben Cartwright-Cox]’s recent 35C3 talk on the anatomy and physiology of viruses from the DOS days. Fair warning to the seasoned reader that a sense of temporal distortion is inevitable while watching someone who was born almost a decade after the last meaningful release of MS-DOS discuss its inner workings with such ease. After a great overview of the DOS API elements that were key to getting anything done back then, malware or regular programs alike, he dives into his efforts to mine an archive of old DOS viruses, the payloads of most of which were harmless pranks. He built some tools to find viruses that triggered based on the system date, and used an x86 emulator he designed to test every day between 1980 and 2005. He found about 10,000 malware samples and explored their payloads, everything from well-wishes for the New Year to a bizarre foreshadowing of the Navy Seal Copypasta meme.

We found [Ben]’s talk a real treat, and it’s good to see someone from the current generation take such a deep dive into the ways many of us cut our teeth in the computing world.

Continue reading “35C3: A Deep Dive into DOS Viruses and Pranks”

35C3: Finding Bugs in Bluetooth

[Jiska Classen] and [Dennis Mantz] created a tool called Internal Blue that aims to be a Swiss-army knife for playing around with Bluetooth at a lower level. The ground for their tool is based in three functions that are common to all Broadcom Bluetooth chipsets: one that lets you read arbitrary memory, on that lets you run it, and one that lets you write it. Well, that was easy. The rest of their work was analyzing this code, and learning how to replace the firmware with their own version. That took them a few months of hard reversing work.

In the end, Internal Blue lets them execute commands at one layer deeper — the LMP layer — easily allowing monitoring and injection. In a series of live (and successful!) demos they probe around on a Nexus 6P from a modified Nexus 5 on their desk. This is where they started digging around in the Bluetooth stack of other devices with Broadcom chipsets, and that’s where they started finding bugs.

As is often the case, [Jiska] was just poking around and found an external code handler that didn’t do bounds checking. And that meant that she could run other functions in the firmware simply by passing the address handler offset. Since they’re essentially calling functions at any location in memory, finding which functions to call with which arguments is a process of trial and error, but the ramifications of this include at least a Bluetooth module crash and reset, but can also pull such tricks as putting the Bluetooth module into “Device Under Test” mode, which should only be accessible from the device itself. All of this is before pairing with the device — just walking by is sufficient to invoke functions through the buggy handler.

All the details of this exploit aren’t yet available, because Broadcom hasn’t fixed the firmware for probably millions of devices in the wild. And one of the reasons that they haven’t fixed it is that patching the bug will disclose where the flaw lies in all of the unpatched phones, and not all vendors can be counted on to push out updates at the same time. While they focused on the Nexus 5 cellphone, which is fairly old now, it’s applicable to any device with a similar Broadcom Bluetooth chipset.

Aside from the zero-day bug here, the big story is their Bluetooth analysis framework which will surely help other researchers learn more about Bluetooth, finding more glitches and hopefully helping make Bluetooth more openly scrutinized and more secure. Now anyone with a Raspberry Pi 3/3+ or a Nexus 5, is able to turn it into a low-level Bluetooth investigation tool.

You might know [Jiska] from her previous FitBit hack. If not, be sure to check it out.

Continue reading “35C3: Finding Bugs in Bluetooth”

Hackaday Assembling At 35C3

Hackaday is going to be at the 35th annual Chaos Communication Congress (35C3), December 27th – 31st, and we’re putting together an assembly. If you’re coming to 35C3, come join us!

If you’ve never been to a Congress before, it’s an amazing scene. This year over 15,000 hackers will take over the Leipzig Congress Hall, bringing whatever they’re working on with them, and showing off their last-minute dazzlers. Congress is awesome in both senses of the word: simultaneously incredible and a little bit intimidating.

With the scale of the Congress approaching absurd proportions, it’s nice to have a home base. “Assemblies”, small-ish gatherings of friends, members of a hackerspace, or even just like-minded folks, join forces and get some table space and Ethernet connections to call their own, and this year we’ll be flying the Jolly Wrencher.

November 28th is the deadline for changing our headcount, so if you’d like to take part, click over to the Hackaday 35C3 Assembly IO project ASAP and leave a comment or join the team so we have a good estimate. If you’ve already got a home away from home, we’ll keep some extra seats warm for you to come by and chat. [Elliot] will also be wearing his press hat, so if you’ve got a project in desperate need of a Hackaday writeup you’ll know where to find him.

Hackaday, assemble!