33C3: Chris Gerlinsky Cracks Pay TV

December 27, 2016 by Elliot Williams 40 Comments

People who have incredible competence in a wide range of fields are rare, and it can appear deceptively simple when they present their work. [Chris Gerlinksy]’s talk on breaking the encryption used on satellite and cable pay TV set-top boxes was like that. (Download the slides, as PDF.) The end result of his work is that he gets to watch anything on pay TV, but getting to watch free wrestling matches is hardly the point of an epic hack like this.

The talk spans hardware reverse engineering of the set-top box itself, chip decapping, visual ROM recovery, software reverse analysis, chip glitching, creation of custom glitching hardware, several levels of crypto, and a lot of very educated guessing. Along the way, you’ll learn everything there is to know about how broadcast streams are encrypted and delivered. Watch this talk now.

Some of the coolest bits:

Reading out the masked ROM from looking at it with a microscope never fails to amaze us.
A custom chip-glitcher rig was built, and is shown in a few iterations, finally ending up in a “fancy” project box. But it’s the kind of thing you could build at home: a microcontroller controlling a switch on a breadboard.
The encoder chip stores its memory in RAM: [Chris] uses a beautiful home-brew method of desoldering the power pins, connecting them up to a battery, and desoldering the chip from the board for further analysis.
The chip runs entirely in RAM, forcing [Chris] to re-glitch the chip and insert his payload code every time it resets. And it resets a lot, because the designers added reset vectors between the bytes of the desired keys. Very sneaky.
All of this was done by sacrificing only one truckload of set-top boxes.

Our jaw dropped repeatedly during this presentation. Go watch it now.

Disassembly Required

December 23, 2016 by Al Williams 29 Comments

If you really want to hack software, you are going to face a time when you have to take apart someone’s machine code. If you aren’t very organized, it might even be your own — source code does get lost. If you want to impress everyone, you’ll just read through the hex code (well, the really tough old birds will read it in binary). That was hard to do even when CPUs only had a handful of instructions.

A more practical approach is to use a tool called a disassembler. This is nothing more than a program that converts numeric machine code into symbolic instructions. The devil, of course, is in the details. Real programs are messy. The disassembler can’t always figure out the difference between code and data, for example. The transition points between data and code can also be tricky.

When Not to Use

If you are coding your own program in assembly, a disassembler isn’t usually necessary. The disassembly can’t recover things like variable names, some function names, and — of course — comments. If you use a high-level language and you want to check your compiler output, you can easily have the compiler provide assembly language output (see below).

The real value of a disassembler is when you don’t have the source code. But it isn’t easy, especially for anything nontrivial. Be prepared to do a lot of detective work in most cases.

Continue reading “Disassembly Required” →

TP-Link Debug Protocol Gives Up Keys To Kingdom

December 14, 2016 by Elliot Williams 25 Comments

If the headline makes today’s hack sound like it was easy, rest assured that it wasn’t. But if you’re interested in embedded device hacking, read on.

[Andres] wanted to install a custom OS firmware on a cheap home router, so he bought a router known to be reflashable only to find that the newer version of the firmware made that difficult. We’ve all been there. But instead of throwing the device in the closet, [Andres] beat it into submission, discovering a bug in the firmware, exploiting it, and writing it up for the manufacturer. (And just as we’re going to press: posting the code for the downgrade exploit here.)

This is not a weekend hack — this took a professional many hours of serious labor. But it was made a lot easier because TP-Link left a debugging protocol active, listening on the LAN interface, and not requiring authentication. [Andres] found most of the information he needed in patents, and soon had debugging insight into the running device.

Continue reading “TP-Link Debug Protocol Gives Up Keys To Kingdom” →

[CNLohr] Reverses Vive, Valve Engineers Play Along

December 12, 2016 by Elliot Williams 11 Comments

[CNLohr] needs no introduction around these parts. He’s pulled off a few really epic hacks. Recently, he’s set his sights on writing a simple, easy to extend library to work with the HTC Vive VR controller equipment, and in particular the Watchman controller.

There’s been a lot of previous work on the device, so [Charles] wasn’t starting from scratch, and he live-streamed his work, allowing others to play along. In the process, two engineers who actually worked on the hardware in question, [Alan Yates] and [Ben Jackson], stopped by and gave some oblique hints and “warmer-cooler” guidance. A much-condensed version is up on YouTube (and embedded below). In the links, you’ll find code and the live streams in their original glory, if you want to see what went down blow by blow. Code and more docs are in this Gist.

Continue reading “[CNLohr] Reverses Vive, Valve Engineers Play Along” →

Reverse Engineering An ST-Link Programmer

December 10, 2016 by Elliot Williams 11 Comments

We’re not sure why [lujji] would want to hack ST’s ST-Link programmer firmware, but it’s definitely cool that he did, and his writeup is a great primer in hacking embedded devices in two parts: first he unpacks and decrypts the factory firmware and verifies that he can then upload his own encrypted firmware through the bootloader, and then he dumps the bootloader, figures out where it’s locking the firmware image, and sidesteps the protection.

[lujji]’s project was greatly helped out by having the firmware’s encryption keys from previous work by [Taylor Killian]. Once able to run his own code on an intact device, [lujji] wrote a quick routine that dumped the entire flash ROM contents out over the serial port. This gave him the bootloader binary, the missing piece in the two-part puzzle.

If you’ve ever broken copy protection of the mid-1990’s, you won’t be surprised what happened next. [lujji] located the routine where the bootloader adds in the read protection, and NOPped it out. After uploading firmware with this altered bootloader, [lujji] found that it wasn’t read-protected anymore. Game over!

We glossed over a couple useful tips and tricks along the way, so if you’re into reversing firmware, give [lujji]’s blog a look. If you just want a nice ARM programmer with UART capabilities, however, there’s no reason to go to these extremes. The Black Magic Probe project gives you equal functionality and it’s open source. Or given that the official ST-Link programmers are given away nearly free with every Nucleo board, just buying one is clearly the path of least resistance. But a nice hack like this is its own reward for those who want to take that path. Thanks, [lujji] for writing it up.

IPhone NVMe Chip Reversed With Custom Breakout Boards

November 18, 2016 by Brian Benchoff 36 Comments

Ever so slowly, the main storage in our computers has been moving from spinning disks, to SSDs over SATA, to Flash drives connected to a PCI something or other. The latest technology is NVMe — Non-Volitile Memory Express — a horribly named technology that puts a memory controller right on the chip. Intel has a PCI-based NVMe drive out, Samsung recently released an M.2 NVMe drive, and the iPhone 6S and 6S Plus are built around this storage technology.

New chips demand a reverse engineering session, and that’s exactly what [Ramtin Amin] did (Internet Archive). He took a few of these chips out of an iPhone, created a board that will read them, and managed to analyze the firmware.

Any reverse engineering will begin with desoldering the chip. This is easy enough, with the real trick being getting it working again outside whatever system it was removed from. For this, [Ramtin] built his own PCIe card with a ZIF socket. This socket was custom-made, but the good news is you can buy one from ITEAD. Yes, it is expensive — that’s what you get with a custom-made ZIF socket.

With the chip extracted, a custom PCIe card, and a bit of work with the NVMe implementation for Linux, [Ramtin] had just about everything working. Eventually, he was able to dump the entire file system on the chip, allowing anyone to theoretically back up the data on their iPhone or MacBook Air. Of course, and especially for the iPhone, this data is encrypted. It’s not possible to clone an iPhone using this method, but it is a remarkably deep dive into the hardware that makes our storage tick.

Glitching USB Firmware For Fun

October 4, 2016 by Elliot Williams 37 Comments

[Micah Elizabeth Scott], aka [scanlime], has been playing around with USB drawing tablets, and got to the point that she wanted with the firmware — to reverse engineer, see what’s going on, and who knows what else. Wacom didn’t design the devices to be user-updateable, so there aren’t copies of the ROMs floating around the web, and the tablet’s microcontroller seems to be locked down to boot.

With the easy avenues turning up dead ends, that means building some custom hardware to get it done and making a very detailed video documenting the project (embedded below). If you’re interested in chip power glitching attacks, and if you don’t suffer from short attention span, watch it, it’s a phenomenal introduction.

Continue reading “Glitching USB Firmware For Fun” →