Hackaday Links: September 13, 2020

Like pretty much every other big conference, the Chaos Communication Conference is going virtual this year. What was supposed to be 37C3 has been rebranded as rC3, the remote Chaos Experience. It’s understandable, as a 17,000 person live event would have not only been illegal but a bit irresponsible in the current environment. The event appears to be a hybrid of small local events hosted in hackerspaces linked with streamed talks and a program of workshops and “online togetherness.” rC3 is slated to run in the week between Christmas and New Year, and it seems like a great way to wrap up 2020.

Speaking of remote conferences, don’t forget about our own Remoticon. While it won’t be quite the same as everyone getting together in sunny — historically, at least — Pasadena for a weekend of actual togetherness, it’s still going to be a great time. The event runs November 6 to 8; we’ve had a sneak peek at the list of proposed workshops and there’s some really cool stuff. Prepare to be dazzled, and make sure you keep up on the Remoticon announcements — you really don’t want to miss this.

Continue reading “Hackaday Links: September 13, 2020”

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

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!

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: Fitbit Sniffing And Firmware Hacking

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: Hacking Into A CPU’s Microcode

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.