33C3: Dissecting 3G/4G Phone Modems

[LaForge] and [Holger] have been hacking around on cell phones for quite a while now, and this led to them working on the open cellphone at OpenMoko and developing the OsmocomBB GSM SDR software. Now, they are turning their sights on 3G and 4G modems, mostly because they would like to use them inside their own devices, but would also like to make them accessible to the broader hacker community. In this talk at the 33rd Chaos Communications Congress (33C3), they discuss their progress in making this darkest part of the modern smartphone useful for the rest of us.

This talk isn’t about the plug-and-play usage of a modern cell-phone modem, though, it’s about reprogramming it. They pick a Qualcomm chipset because it has a useful DIAG protocol, and in particular choose the Quectel EC20 modem that’s used in the iPhone5, because it makes the DIAG stream easily available.

Our story begins with a firmware upgrade from the manufacturer. They unzipped the files, and were pleasantly surprised to find that it’s actually running Linux, undocumented and without the source code being available. Now, [LaForge] just happens to be the founder of gpl-violations.org and knows a thing or two about getting code from vendors who use Linux without following the terms and conditions. The legal story is long and convoluted, and still ongoing, but they got a lot of code from Quectel, and it looks like they’re trying to make good.

Qualcomm, on the other hand, makes the Linux kernel source code available, if not documented. (This is the source on which Quectel’s code is based.) [LaForge] took over the task of documenting it, and then developing some tools for it — there is more going on than we can cover. All of the results of their work are available on the wiki site, if you’re getting ready to dig in.

Continue reading “33C3: Dissecting 3G/4G Phone Modems”

33C3: Edible Soft Robotics

Certainly one of the more entertaining talks of the 33rd Chaos Communications Congress was [Kari Love]’s talk on her experiments in mixing food with function. In [Kari]’s talk at the 2016 Hackaday Supercon, she talked extensively about working on soft robotic for NASA. At the 33C3, her focus was twofold: on a fun side project to make mobile robots out of stuff that you can eat, and to examine the process of creative engineering through the lens of a project like this.

homeelliotpendrive33c3-8113-eng-edible_soft_roboticsmp4-shot0005If you look up edible robotics, you get a lot of medical literature about endoscopes that you can swallow, or devices that take samples while they’re inside you. That’s not what [Kari]’s after at all. She’s after a robot that’s made of candy, a yummy machine. And while this is still a work in progress, she demonstrated a video of an all-licorice cable-based actuator.

homeelliotpendrive33c3-8113-eng-edible_soft_roboticsmp4-shot0006_thumbnailBut more than that, she demonstrated all of the materials she’s looked at so far, and the research she’s done. To some extent, the process is the substance of this project, but there’s nothing wrong with some tasty revelations along the way.

This talk was a potpourri of helpful tips and novel facts. For instance, if you’re working in candy robotics, don’t eat your mistakes. That stomach ache that your mom always said you’d get? You will. Did you know that the gummi in gummibears is re-heatable and re-moldable? In addition, of the gels that she made, it was the most delicious. And finally, Pop Rocks don’t have enough CO2 in them to drive pneumatics. Who knew? [Kari] knows. And now you do too.

Continue reading “33C3: Edible Soft Robotics”

33C3: Memory Deduplication, the Hacker’s Friend

At the 33rd annual Chaos Communications Congress, [Antonio Barresi] and [Erik Bosman] presented not one, not two, but three (3!!) great hacks that were all based on exploiting memory de-duplication in virtual machines. If you’re interested in security, you should definitely watch the talk, embedded below. And grab the slides too. (PDF)

Memory de-duplication is the forbidden fruit for large VM setups — obviously dangerous but so tempting. Imagine that you’re hosting VMs and you notice that many of the machines have the same things in memory at the same time. Maybe we’re all watching the same cat videos. They can save on global memory across the machines by simply storing one copy of the cat video and pointing to the shared memory block from each of the machines that uses it. Notionally separate machines are sharing memory. What could go wrong?

Continue reading “33C3: Memory Deduplication, the Hacker’s Friend”

33C3: Hunz Deconstructs the Amazon Dash Button

The Amazon Dash button is now in its second hardware revision, and in a talk at the 33rd Chaos Communications Congress, [Hunz] not only tears it apart and illuminates the differences with the first version, but he also manages to reverse engineer it enough to get his own code running. This opens up a whole raft of possibilities that go beyond the simple “intercept the IP traffic” style hacks that we’ve seen.

dash_block_diagramJust getting into the Dash is a bit of work, so buy two: one to cut apart and locate the parts that you have to avoid next time. Once you get in, everything is tiny! There are a lot of 0201 SMD parts. Hidden underneath a plastic blob (acetone!) is an Atmel ATSAMG55, a 120 MHz ARM Cortex-M4 with FPU, and a beefy CPU all around. There is also a 2.4 GHz radio with a built-in IP stack that handles all the WiFi, with built-in TLS support. Other parts include a boost voltage converter, a BTLE chipset, an LED, a microphone, and some SPI flash.

The strangest part of the device is the sleep mode. The voltage regulator is turned on by user button press and held on using a GPIO pin on the CPU. Once the microcontroller lets go of the power supply, all power is off until the button is pressed again. It’s hard to use any less power when sleeping. Even so, the microcontroller monitors the battery voltage and presumably phones home when it gets low.
Continue reading “33C3: Hunz Deconstructs the Amazon Dash Button”

33C3: How Can You Trust Your Random Numbers?

One of the standout talks at the 33rd Chaos Communications Congress concerned pseudo-random-number generators (PRNGs). [Vladimir Klebanov] (right) and [Felix Dörre] (left) provided a framework for making sure that PRNGs are doing what they should. Along the way, they discovered a flaw in Libgcrypt/GNUPG, which they got fixed. Woot.

mpv-shot0012-zoomCryptographically secure random numbers actually matter, a lot. If you’re old enough to remember the Debian OpenSSL debacle of 2008, essentially every Internet service was backdoorable due to bad random numbers. So they matter. [Vladimir] makes the case that writing good random number generators is very, very hard. Consequently, it’s very important that their output be tested very, very well.

So how can we test them? [Vladimir] warns against our first instinct, running a statistical test suite like DIEHARD. He points out (correctly) that running any algorithm through a good enough hash function will pass statistical tests, but that doesn’t mean it’s good for cryptography.
Continue reading “33C3: How Can You Trust Your Random Numbers?”

33C3: Works for Me

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”

33C3: If You Can’t Trust Your Computer, Who Can You Trust?

It’s a sign of the times: the first day of the 33rd Chaos Communications Congress (33C3) included two talks related to assuring that your own computer wasn’t being turned against you. The two talks are respectively practical and idealistic, realizable today and a work that’s still in the idea stage.

In the first talk, [Trammell Hudson] presented his Heads open-source firmware bootloader and minimal Linux for laptops and servers. The name is a gag: the Tails Linux distribution lets you operate without leaving any trace, while Heads lets you run a system that you can be reasonably sure is secure.

It uses coreboot, kexec, and QubesOS, cutting off BIOS-based hacking tools at the root. If you’re worried about sketchy BIOS rootkits, this is a solution. (And if you think that this is paranoia, you haven’t been following the news in the last few years, and probably need to watch this talk.) [Trammell]’s Heads distribution is a collection of the best tools currently available, and it’s something you can do now, although it’s not going to be easy.

Carrying out the ideas fleshed out in the second talk is even harder — in fact, impossible at the moment. But that’s not to say that it’s not a neat idea. [Jaseg] starts out with the premise that the CPU itself is not to be trusted. Again, this is sadly not so far-fetched these days. Non-open blobs of firmware abound, and if you’re really concerned with the privacy of your communications, you don’t want the CPU (or Intel’s management engine) to get its hands on your plaintext.

[Jaseg]’s solution is to interpose a device, probably made with a reasonably powerful FPGA and running open-source, inspectable code, between the CPU and the screen and keyboard. For critical text, like e-mail for example, the CPU will deal only in ciphertext. The FPGA, via graphics cues, will know which region of the screen is to be decrypted, and will send the plaintext out to the screen directly. Unless someone’s physically between the FPGA and your screen or keyboard, this should be unsniffable.

As with all early-stage ideas, the devil will be in the details here. It’s not yet worked out how to know when the keyboard needs to be encoded before passing the keystrokes on to the CPU, for instance. But the idea is very interesting, and places the trust boundary about as close to the user as possible, at input and output.