 So, coming over to our next talk tonight. If you switch off your deck phone and if you're full of different impressions, full of different impressions of this day, you maybe want to watch TV. But it would be cool to have pay TV, unencrypted pay TV. So Chris Galinsky asks himself the same and how to achieve unencrypted pay TV, but the heck away. So Chris reverse engineered nothing less than the signal and the encryption for a standard that remains unencrypted since the late 90s. Please welcome with an anniversary edition applause, Chris Galinsky. My name is Chris Galinsky. I am a hacker from Canada and I'm here today to talk about how I cracked digital cable and satellite TV security. I studied an access control platform that's widely used across Canada and the USA. It's one of the two common platforms that's used in cable TV and it's also used in satellite TV by one of the two Canadian satellite TV operators. As far as I know, the system has remained secure since it was introduced in the 1990s and I was curious if I could understand the system based on the older set-top boxes. Some of them are 15 years old and they're still in use. So these devices haven't received upgraded security hardware in that time and I started looking at how this system works. Before I get into the reverse engineering, I'll start with a brief description of how digital television is sent over satellite or cable. Satellite and cable digital television are pretty similar for the most part. There are a variety of signal modulations used. The relevant ones here are QPSK at about 27 megabits and 8PSK TurboFac at about 38 megabits for satellite and QAM256 at about 38 megabits for cable. There's also an out-of-band channel used by cable which is QPSK modulated at 2 megabits. This out-of-band channel carries the subscription management program guide information, firmware upgrades, etc. And while you change channels and the cable box tunes to different frequencies, this out-of-band channel remains tuned so that the box continuously receives this data no matter what TV channel you are tuned to. In the satellite TV, this type of data is included within the main transport stream instead of in a secondary out-of-band transport stream. The video is sent as MPEG2 or H.264 transport stream. This is a standard format for curing video streams so it can be played by any hardware video decoder or a software decoder, for example, VLC. The encryption system used here is called DigiCypher2, which does not follow the DVB standards that are used in the rest of the world. The MPEG transport stream is made up of packets of 188 bytes. Each packet has a PID. This is used to differentiate different types of data. Pids range from 0 to hex 1FF. Each PID carries an MPEG packetized elementary stream, that's a video or audio stream, or the PID may carry one or more service information tables. The service information tables have an 8-bit table ID and a length of up to 1,024 bytes, including a CRC32 for error detection, and this table ID identifies the type of data that you can expect within the table. Table 0 is the program association table containing a list of programs carried in this transport stream and the PMT PID for each program. The program association table is always on PID 0. Table 2 is the program map table, which contains the list of packetized elementary streams and the PID for each, as well as an ECM PID. There's a program map table for each MPEG program or TV channel that's found in the stream. The ECM PID is where entitlement control messages are sent containing information that's used to generate the key that decrypts the packetized elementary streams. This system uses two types of ECM. Table 40, I call ECM 40, and table 41, I call ECM 41. On PID 1, there may be one or more conditional access tables, table ID number one. These tables identify a PID that carries EMMs, entitlement management messages. These messages are used to set access rates for individual set top boxes. The subscription information like what channels are available is carried inside of EMMs. This is a hardware interface to receive satellite data, GenPix Skywalker 1. The DC2 QPSK modulation isn't widely supported in the USB or PCI DVBS devices, and the 8PSK TurboFec modulation support is even less common. One of the devices that does support these signals is this GenPix device, which is using a Broadcom BCM4500 demodulator, and it supports both the DC2 QPSK and the 8PSK modulations. It works well. The Linux drivers need to be recompiled to include the support for these modes, and patches for this were published by Update.ly. There's a link on the slide. For cable, there's a variety of adapters supporting QAM256 demodulation. I used a USB HVR950Q tuner. Unfortunately, to tune the Out-of-Band channel is generally not supported by the off-the-shelf interfaces. Inside the cable box, it's handled within the integrated chip set, and for the clear QAM consumer devices, such as USB interfaces, access to the Out-of-Band data isn't actually required, and so they don't include it inside of the hardware. This Out-of-Band data is used only for pay TV services. With the satellite and cable interfaces, DVB Snoop can be used to view a lot of information about the transport stream. It's enough information to be quite overwhelming. So the trick to using it is to being able to sift through the output for the relevant information. DVB Snoop also doesn't recognize all of the DigiCypher 2 tables, because it's a non-standard system, and DVB Snoop is targeted towards the standard systems. So DVB Snoop may not be able to tell you everything about the transport stream, but it was still a very useful tool for all the information that it can provide. DVB Snoop and most other tools in documentation are designed for the DVB standard, or other recognized standards such as ATSC. DigiCypher cable and satellite systems use a lot of non-standard tables to carry the system information. For cable TV, some of these tables are standardized by the document SCTE65. There is no BAT or SDT, as you'd expect in DVB. Instead there is a virtual channel table that maps the transport streams and programs to channel numbers. The electronic program guide is also not DVB standard, so you don't even get the current and next program information in any kind of a standard format. Another cable TV adapter is the HD Home Run Prime. This one is a network-connected three-tuner device with cable card support. The set-top boxes I studied predate the cable cards, although the newer boxes do use the cable cards and they support the DigiCypher 2, but cable card support does also mean that this HD Home Run Prime includes the tuner and QPSK demodulator for the Out-of-Van channel, so it is able to pass this data to the cable card as necessary. However, even the HD Home Run doesn't make this Out-of-Van data available other than the cable card interface. So to access the demodulated Out-of-Van data, I tapped into the HD Home Run Prime with a cable card inserted and connected a logic analyzer to the data and clock signals. I wrote software using the Celia SDK to capture the QPSK demodulated data. Then in software, I performed deinterleaving, de-randomization and the forward error connection, and the output is an MPEG transport stream. So using an HD Home Run Prime connected to the logic analyzer, connected to the PC, running the software, the output finally is a two-megabit transport stream, and this transport stream looks like a standard transport stream, and inside are the conditional access management messages, program guide information, etc. Everything that was missing from the main QAM transport stream. Two bits in each packet will indicate if the packet is scrambled with the even key, odd key, or not scrambled at all. The keys change at short intervals. DVB systems typically would change every five to 30 seconds. DC2 every 133 milliseconds or one second. The key use for decryption alternates between even and odd. The odd key is in use while the even key is updated, and then the even key is in use while the odd key is updated. An encrypted transport stream is sent via the cabler satellite, and it's passed through the discrambler in the ACP, and the result is a decrypted transport stream that is played by the MPEG decoder. The discrambler uses a working key. This is a 56-bit DESK key that changes every 133 milliseconds, or in some cases they have it slowed down to changing every one second. This working key is generated by encrypting the frame count from ECM-40 packets with the program key. The program key, again DES, comes from the ECM-41 message and is encrypted with the category key. The program key is unique to each channel, and it changes daily or for every pay-per-view event. The category key, also DES, is shared by all the set-top boxes that are authorized for any channel from this provider. The category key is sent to each set-top box individually inside the EMM-95 message, and this category key typically changes monthly, but many cable operators change keys much less frequently. Some of them are using the same key for years at a time. To decrypt the EMM, in order to get the category key, seed keys are used. Each set-top box has a set of 56-bit DESK seed keys inside of the battery-backed RAM. These are initialized during manufacturing. For the lifetime of the set-top box, these keys are used to secure EMMs. So this forms a chain from the seed keys initialized during manufacturing and never changing to the decryption of the MPEG transport stream. Inside a satellite set-top box, we can see the main components of the system. The signal enters the tuner and is passed through the demodulator, which outputs a serial transport stream. This transport stream passes through the ACP, access control processor, and is then sent to the MPEG decoder to output a video signal to the TV. A 68K microcontroller acts as the set-top box main controller. It communicates with the MPEG decoder as well as with the ACP via an SPI bus. A battery provides backup power to the ACP, so it will retain RAM contents even when the set-top box is unplugged. There's a TV pass slot near the power supply. This is an upgrade slot with a card edge connector to allow for security upgrades. The system is state secure, so the TV pass slot was never used, and the newer set-top boxes don't actually include a TV pass slot inside. So at this point, it seems quite unlikely that this TV pass card will ever actually be used. Inside a cable set-top box, it's very similar to a satellite set-top box, but the cable boxes tend to be more tightly integrated. Signal enters the tuner and passes through a Broadcom chip that handles demodulation, and the same chip will also handle MPEG decoding after the transport stream has been decrypted by the ACP. A 68K microcontroller acts as the set-top box main controller, again talking to the ACP via SPI, and a battery provides backup power to the ACP and also to the non-volatile RAM used by the main controller. A TV pass slot is underneath the main board. It's not visible in this photo. The cable set-top boxes include a second tuner that's used to receive the Out-of-Band data. This Out-of-Band tuner operates independently of the main tuner and on a separate frequency range, and it's used to provide a transport stream containing the system information with the program guide, firmware updates, EMMs, etc. Here we see the ACP chip. It's a 100-pin TQFP package. From the markings, we can see it's a custom system on chip made for General Instrument Corporation, GIC. All the decryption is performed by the ACP, and all decryption keys are kept only within this chip. The newer set-top boxes use newer versions of the ACP. I studied the original ACP chip that's seen in this photo. As long as the set-top boxes using this chip are actively used, it remains a relevant target. Whether the newer ACPs include more advanced security features, or if they exist only for cost savings due to shrinking the die size, I don't really know. Some of the interesting pins on the ACP are labeled here. Pin 1 is marked at the top left corner of the chip. There's an SPI slave controller on pins 1 to 5 used for communication with the set-top box main controller. There's a battery backup pin that's connected to a 3-volt battery to keep the RAM contents of the ACP intact at all times. There's a serial transport stream input on pins 88 to 92, which receives the data from the demodulator. And there's a serial transport stream output on pins 28 to 33, which sends the decrypted transport stream to the MPEG decoder to be output to the TV. At one point, I had written software for an AVR32 device, not the one that's shown here, that has a synchronous serial peripheral that supports sending and receiving data at the 27 megabit rate of the transport stream. My AVR32 implementation turned out a bit ugly, but rather than cleaning it up, I was able to use it as it was. It had some limitations, like only accepting 64 kilobytes of data for replay and logging, which was just barely good enough for my studies. What the transport stream logging insert that did show me was that the transport stream passes through the ACP, with selected pins being decrypted, and then the output is the full transport stream, but a selected program has been decrypted. The AVR32 logging interface had rather limited use for me. Later on, when I did more thorough research, I did so using an ACP that I had removed from the box and I put on a breakout board, and then I could control the clock, and at that point, it was much easier to use an XMega AVR platform to send and receive the transport stream through the ACP at a much slower bit rate. Shown here is the XMega platform I settled on using for SPI and also the transport stream interfacing. To monitor the data pass between the set-top box main controller and the ACP on the SPI bus, I used the XMega development board. Two SPIA ports acted as slave. With the master out-slave-in signal connected to one and master in-slave-out signal connected to the master out-slave-in input of the second port. So for one port, bytes sent by the set-top box controller are received. From the other port, it receives bytes from the ACP. In case I want to talk directly to the ACP or the set-top box main controller, it's only necessary to connect both the Mazi and Mizo signals on one of the SPI interfaces. By holding the main controller in reset, my XMega was able to act as the SPI master and then talk to the ACP. So this set-top works for passively monitoring the SPI communications in the set-top box and can also act as the SPI master for interrogating the chip directly. By logging the SPI bus between the main controller and the ACP, we see that information about the current access levels is sent from the ACP. The ACP also receives EMMs via the SPI bus. EMMs have been filtered by the unit address number or the set-top box serial number. So the ACP only receives messages that are intended for that specific unit. Command 04 includes the current category key epochs and key selects in use. Command05 includes the unit address number. Command13 returns the authorized subscription tiers for this unit. Command7 and 87 provide information about the channel being currently decrypted. Additionally, via the SPI interface, the set-top box main controller tells the ACP which PIDs to decrypt and which is the ECM PID. The ACP doesn't send any keys on the bus and it only receives category keys that are encrypted within EMMs via the SPI. So all of the really interesting data is contained within the ACP chip itself and it's never sent out on any kind of a bus. So next, I started an invasive study of the chip, studying it under a microscope. The cost of microscopes can range from hundreds of dollars to tens of thousands of dollars or even higher for things like electron microscopes or other specialized equipment. Though I have a couple of microscopes that I use. This one is the Metatoyo FS70 microscope. These Metatoyo are often used for micro probing but you can also use it for other uses. For this project, I didn't do any micro probing but I used this microscope because it was what I had. For studying this kind of technology, you could use even more basic equipment but of course if you have the higher end equipment it's a lot nicer to work with. Another microscope I use is the Zeiss Axiotron. This microscope is designed for inspecting wafers and has really good optical quality. I said that more basic equipment could be used and it's true but when you get into this kind of thing you might find yourself again and again investing in more equipment. I have about $10,000 in this setup including the microscope and the camera and the scanning stage and other parts. To look at the chip under the microscope requires that the chip is decapsulated. Fuming nitric acid is used for this. The chip is immersed in heated red fuming nitric acid which reacts with the plastic packaging and removes it. The chip is then rinsed in acetone and cleaned with isopropyl alcohol in an ultrasonic bath which leaves the dye bare and clean. The nitric acid is quite aggressive and it's important to handle it carefully but the process is really straightforward. Most people probably wouldn't wanna do this in their home so you should go out to the garage and use your fume hood there. After the decapsulation the bare chips are left with bonding wires attached to them so these wires will be plucked off using tweezers to get them out of the way. Already in this photo we can see some of the larger structures on the chip. Half of it's covered with a metal plane and the other half shows some kind of visible circuitry. This is an image of the chip under the microscope. It's been stitched together from several smaller images to give an overview of the chip. Looking at the decapsulated chip we see the bond pads around the outside, the metal plane covering the top part of the chip and wires on the bottom of the chip, the spaghetti logic running all over the place with a couple of structures that look like they could be a type of memory. There's a lot still hidden from us. To see more of the chip it will be necessary to de-layer it. To de-layer the chip I used hydrofluoric acid to perform a wet etch. I used the Wink rust stain remover product. It's available in hardware stores all over the USA. It's a dilute HF solution that works really well for de-layering ICs. I put a small amount of the Wink liquid in a beaker and heated on the hot plate, then I dropped the decapsulated dye in. Using a pipette, I agitate the liquid to disturb the bubbles that form on the surface of the chip so the acid can etch the chip more evenly. The etching result isn't perfect. Some parts of the chip will be etched deeper than other parts but I've gotten quite useful results using this technique. You really don't want to breathe in these fumes so do this in the fume hood in your garage also. After a short time immersed in the heated Wink solution the chip was rinsed and put back under the microscope. Now the top metal plane has been removed so we can see what's below. There are some visual effects that we start to see in the photo from the etching being a little bit uneven but overall the de-layered chip looks quite good and is able to start studying it. At the top left, the tall rectangles are round. The four blocks at the top right are rom and then there's logic that tie these into the logic area below. I was interested in finding how the bits were encoded in ROM so I continued de-layering the chip. This was another dip in the Wink and another metal layer has been removed. Bits of the ROM were not visible yet so I continued the de-layering process. At this point we're starting to see more of the visual effects from the uneven etching but it's still not too bad. After a third dip in the Wink more metal has been removed. At this point the de-layering is becoming more and more uneven. We can see the ROM blocks have been half etched to a lower layer while half of the upper layer is still remaining. The wet etching process can be quite difficult to perform completely consistently without adding additional steps such as polishing and at the time I did this project I didn't have the polisher available so I was relying only on the wet etch. Some of the areas of the ROM are now showing visible bits. The other areas haven't been etched deeply enough so I continued to etch further to try and get a clean ROM. We can see the ROM bits quite clearly now. They're arranged in rows and columns and in this image, if a black dot is visible that indicates that the bit is a one. Image quality is important. The better the photographs, the more consistently the bits will be visible but it doesn't have to be really perfect. You can do some image processing on it. You can even repeat the process on multiple chips, de-layer them and photograph them and at some point you'll be able to have the entire ROM clean and consistently visible. With the visible bits exposed and photographs taken the bits can be extracted using a software image analysis tool or the bits could be extracted manually. The ROM here is 32 kilobytes or over 260,000 bits so manual extraction would be a bit labor intensive but it isn't impossible. A software tool is more efficient. So I wrote some software to analyze the images and identify the one in zero bits. There are bits marked with a yellow box for zero bits or a blue box for one bits. I use the software to analyze the image and then I can quickly review the results manually and identify any errors that I can see. After extracting the bits from the photographs I have a binary version of the ROM data. This is a visual representation of the bits extracted from this piece of ROM. The black boxes signify one bits and the white boxes signify zero bits. In this image I've overlaid the extracted bottom 13 rows of bits over the photograph. You can see some visual patterns inside this also and these visual patterns are a good indicator that this ROM is probably not scrambled. This image shows the end of the ROM where you can see a pattern covering most of the image due to a repeated pattern of filler bytes that occupy unused space at the end of the ROM. At the very end of ROM the pattern is interrupted. This is where the vectors table exists at the top end of memory indicating the reset address and the addresses of interrupt handlers. The ROM has unused space, the filler bytes at the end and the vectors table at address is fff6 through ffff. After extracting the bits and decoding them into bytes, the hex dump can be studied. There is a copyright 1997 CHCC ASCII string in ROM which is helpful to identify when the ROM has been decoded correctly. If you can read the ASCII text then surely the bits are in the correct order. The decoding in this case is just a matter of organizing the bits into bytes. It's quite straightforward. There was no scrambling or anything else that was complex. With the ROM contents extracted, the software can be disassembled and analyzed. The first step was to identify the CPU architecture. Studying the binary dump, it appeared to be an 8-bit CPU but wasn't 8051 or 6805 or any of the processor types I tried first. Eventually I tried disassembling in 6502 and the code made sense. Later I had remembered that I had looked at a previous version of the access controller from the same manufacturer which was used in another system, VideoCypher 2+, an ancestor of DigiCypher. On the older chip was a copyright notice from WDC who licenses the 6502 core IP. It was visible directly on the chip die under the microscope. So this would have been a great clue for the CPU architecture if I'd actually noticed it earlier. For disassembly I used IDA. It supports 6502 and is of course a very powerful disassembler. In addition to disassembly, I used 6502 simulation software to study the software in a virtual CPU. The simulation is really helpful when disassembling the software. It provides a lot of insight into what's going on. Since 6502 is a very well-known architecture it was not at all difficult to find an existing simulator even free with source code. The 6502 was used in 8-bit computers like the Apple II and Commodore 64. So there's really a lot of enthusiasts and a great deal of information about this architecture. As I gained understanding of the system on chip through disassembling the software I began adding some of the features into the simulator to emulate some of the hardware peripherals that were found inside the ACP device itself. One of the first things I saw on the disassembly was that there are two operating modes. During startup, values in RAM are checked and if the ACP hasn't been initialized it enters a personalization mode used during manufacturing to assign the unit address and seed keys. In normal conditions, after this setup box has left the factory this personalization software is bypassed and the ACP will always run its main application. The next thing I found was the application wasn't very simple. This 6502 actually runs a task switching operating system. Eight tasks are run, supporting decryption of up to two channels at the same time. There are two tasks to handle processing of ECM40 messages and generation of the working keys used to decrypt the transport stream and two tasks to handle processing of ECM41 messages to generate the program keys that are used to process the ECM40. One task for handling EMM processing and there is also a task to communicate with the TV pass interface for security upgrades with another task to handle the messages that are coming in over the SPI interface. Since the ACP is a custom system on chip there is no documentation available describing the hardware capabilities. So the disassembly was studied and the input output registers had to be guessed based on the software usage. There is an SPI slave peripheral for communication with the main controller. The SPI peripheral sends and receives data directly to RAM and then a signal is set indicating that transfer has been completed. There's a desk crypto peripheral. Key, data and operating mode are set in registers and when the decryption has been complete the result can be read from additional registers. There's a transport stream descrambler. The working key is set in hardware registers and the descrambler will then output decrypted transport stream on the serial transport stream interface. There are PID filters set by the set top box main controller over the SPI bus. These filters select which video and audio streams to descramble and which ECM packets should be received by the ACP. The received ECMs are placed in RAM and the 6502 is notified of a new ECM via a register bit. So at this point I am starting to get an idea of how the system works. I've studied the MPEG transport stream and logged ECM and EMM data. I've logged the SPI bus and understand messages between the set top box main controller and the ACP. I was able to extract the entire ROM contents optically and I've disassembled the software and run it in simulation. There are some keys that are found in ROM, fixed keys which never change and are used when a channel has a free preview weekend or something of this sort. Any set top box that has ever had any kind of authorization in the past is allowed to decrypt channels that are encrypted using the fixed key mode. So now the focus is on understanding the ECM and EMM algorithms within the ROM software. At this point I'm still missing some important information from the ACP. All the seed keys, category keys and program keys exist only within RAM. So to decrypt any of the channels not in free preview isn't possible yet at this point. The ECM 40 message is used to generate the working key used to decramble the MPEG streams. There's a service ID used to identify each channel and a frame count that's used with the program key to calculate the working key. The crypt mode identifies if the channel's operating unencrypted with a fixed key or with a normal secure keys which are typically used. The frame count is simply a 24 bit counter that increments each time the working key changes. There's a byte I've labeled hardware that has one bit set in it. This selects a special decryption mode that I'll come back to a little bit later. The ECM 41 contains encrypted program key that's needed to correctly decrypt the ECM 40. There's a provider ID that indicates which TV operator subscribers this ECM should be processed by and there's the same service ID that will be found within the ECM 40 messages. The category epoch identifies which category key is in use. There's also information about how long this program key will be valid for. ECM 41 contains one or more subscription tiers that must be found within the customer's ACP to allow this message to be processed. The subscription tiers are written to the ACP when the EMM containing authorization details is received. There is again a hardware crypto select byte that I will get back to. This slide shows what a half of a second of ECM 40 and ECM 41 activity might look like. To be able to de-scramble the program, the ACP must process a current ECM 41 to get the program key and then process an ECM 40 to get the working key. The working key is then used by the de-scrambler to decrypt MPEG stream. Until the ACP receives the ECM 41 with the current key, as well as an ECM 40 with the frame count, it's not yet possible to decrypt the transport stream. The working keys have a short lifetime, only 133 milliseconds. The series of ECMs shown here all would happen within a period of a half of a second. The EMMs are split into four parts. Each part contains a portion of the subscription information for this set-top box. A category key is calculated from each of the four parts and the key that is calculated for each part has to match the others or the EMM will be rejected and all authorization and category key will be wiped from this ACP. When the first EMM, part zero, is received, the authorization data inside the ACP is reset and will be replaced with authorization data from the EMM. When the next part, part one, is received, the existing authorization data within the ACP from part zero is hashed along with the data in part one. If the result is correct, then the authorization from part one is copied into the ACP alongside the existing data from part zero. If the result is incorrect, then the ACP's authorization is erased. In this way, the four EMM messages are linked together and if anything is modified within any of the EMM messages the authorization will fail. This is an example of an EMM. Each of the four EMM parts contains some common information like the unit address and which category epoch this EMM contains information for. The EMM can contain two category keys, one for the current epoch and also for the next so that when there is the change of the category key the ACP already has the next key available. To decrypt the category key from the EMM, the seed keys contained in the ACP are used. The seed keys are unique to each ACP and are assigned during manufacturing. EMMs are transmitted out of band for cable systems but they're passed to the ACP in the same ways for satellite systems. So at the ACP level, there's no difference between the satellite and the cable systems. At this point, it should be possible to decrypt channels that are using a fixed key mode. Analysis of the ROM has shown the algorithms used to process the ECMs and generate a working key. The fixed keys are known because they're contained in ROM. There could have been some question about the possibility of any bit errors from the optical ROM extraction process but the fixed keys can be confirmed is correct because the ROM software performs a checksum of this 256 byte area that contains the keys. Successfully running the checksum on the extracted ROM data indicates that the extracted keys seem to be correct. But when I attempted to decrypt a fixed key channel there was a problem, it did not work. Whether it was a bug in my decryption implementation or something else was unclear. However, I had noticed the bit in the ECM 40 was set that causes a bit within the ACP hardware peripherals to be set. The purpose of the bit was unclear, but its address was suspiciously close to the transport stream descrambler key. So I start to suspect that there might be some encryption other than just standard desks. To be able to learn more about the ACP, I started to look at glitching the chip. If I can succeed to glitch the chip, I may be able to find a way to read an even right memory and possibly a way to run my own software directly on the chip. This would allow me to control the hardware peripherals and be able to observe the chip's operation under different conditions. Timing tests of the ACPs suggest that the 6502 is running from an internal clock source. So this ruled out a clock glitch attack. A VCC glitch makes sense. And with the age of this chip, it seemed reasonable to expect that it would be susceptible to VCC glitches. The stronger protections against this type of attack are relatively recent. My glitcher design is quite simple. It's based on an XMega development board and breadboard. I use the XMega to communicate with the ACP over SPI and to control the glitch. A 74 series 4053 analog switch is used to quickly switch the ACP VCC between two voltages, a normal operating voltage and a lower glitch voltage. I use a Benchtop DC power supply and two outputs so I can easily adjust both the normal VCC and glitch VCC levels. Other parts on the breadboard are an oscillator to provide some clock inputs necessary for the ACP to operate and an inverter and NAND gate to cut out the clock during the time of the glitch. To simplify the test setup as much as possible, the ACP was removed from the set-top box and soldered to a breakout board. So in this process, the battery-backed RAM was disconnected and all the keys were lost. But for the purpose of developing working glitch, this was OK. This simple breadboard-based glitcher is quite flexible. The breadboard can be modified to test different ideas and reconfigure quickly. More complex and advanced glitcher wasn't necessary. To test the glitcher to find out if it will work and what voltage levels are successful, we can send a command to the ACP, then Glitch, and then see the response from the ACP. The general strategy is to lower the voltage just to the point where the chip sometimes resets due to the glitch. By adjusting voltage levels and glitch length and timing when the glitch will land, I succeeded to cause ACP responses to be altered. The checksum on SPI packets is very convenient. When unusual data is received from the ACP chip with a valid checksum, it's a pretty good sign that the glitch caused the temporary fault within the CPU but that normal operation was resumed. Depending when the glitch is delivered, different effects are seen. We can see that generally, as the glitch is moved later, it's the later bytes of the response packets that change. So at this point, it looks like the glitcher works and is able to cause a brief fault. Since I had an effective glitch, I took the circuit from the breadboard and etched a simple PCB that could plug directly on the X Mega Development Board. This performs exactly the same function as the breadboard glitcher, but I'm a bit less likely to accidentally unplug a wire from the breadboard and have to repair things. The circuit was simple enough that I could create a one-sided PCB, so it was very easy for myself to etch at home. Now my goal is to have the ACP execute the code of my choice. Because the 6502 is a von Neumann architecture, all code and data memory share the same address space. From software disassembly, I saw that there didn't appear to be any paging or MMU features. The software in ROM is fully self-contained. There is no eProm, and RAM is never used to hold executable code. So there aren't jumps into these areas to exploit, and in fact, it wasn't clear if there's anything preventing code execution outside of ROM. I decided to take a chance and test if RAM is executable. So I send a message via SPI, knowing that this message will be stored in RAM. The message contains 6502 executable code that will copy itself to an unused area of RAM, execute from this area, and send an act indicating it was successful. Because I studied the use of the SPI interface in the ROM code, I'm able to create this executable payload that will continue to receive commands via SPI after it's taken control of the ACP. To try to maximize chances of success, I looked through the ROM code for multi-byte instructions which have broken up, would have contained within them a jump opcode with a destination that should lead to where my executable payload was placed in RAM. Since the ACP has a single address space, this gives a lot of opportunities for glitching to cause execution to reach the payload. There are multiple scenarios possible in addition to my selected glitch target. Stack corruption is a possibility, and really any abnormal program flow has some possibility that it could eventually land in my code. The Von Neumann architecture without strong memory management is a very fertile ground for glitching. Anything in RAM potentially could be executed. So at this point there are several uncertainties, but so far nothing totally rules out the possibility of success. The ACP operates from an internal clock source and the interrupt driven task switching does add some further timing uncertainty. So I will send the code payload, delay, then glitch, and see the result. When it's unsuccessful, I change the delay and I try again. I try to aim for the instruction that I've identified as possibly corruptible into a jump, but there are a lot of unknowns. So really the process is like phishing, throw it a line in hope. I have a target, but no way to know if I can really hit it or if it will have the expected result. But sometimes phishing is good. Relatively quickly, the ACP returns an act indicating a successful glitch. The first successful glitch took some hours to find, and then after this it was possible to make it work repeatedly in a matter of minutes or even seconds. So now I have my code executing in RAM. I'm able to send the ACP additional pieces of code to be executed. This allows me to read any memory address, write any memory address, and perform any other operations possible with a 6502. I wrote a simple application to perform glitch searches and then to interact with the code payload backdoor installed in RAM. This program allows me to enter an address and length and have data returned or write to memory, et cetera. There's also support for setting the key in data and performing desk encrypt or decrypt using the desk hardware that's inside the ACP. A few things I noticed at this point. There is a two kilobyte area of ROM that if I attempted to read it caused the chip to reset. This area of ROM contains the personalization routines that are never normally used after the device leaves the factory. There's also protection against modifying the seed keys in RAM. Trying to store value to these memory locations appear to do nothing. There are specific addresses within RAM that can't be read or the chip will lock up. These are clever traps put in places of security measure. The seven byte, 56-bit keys stored in RAM straddle these dead addresses. So a potential exploit that could cause a linear dump of memory will be stopped before a complete key is ever read. When the chip is reset, it means having to glitch in again because my code payload exists only in RAM and there is no way to hook in a permanent backdoor. Since we can execute code on the ACP and receive a response, we can read the ROM to have its contents without any of the errors that were introduced during the optical extraction process. Comparing the results of the optical ROM extraction with a proper dump, we can see how many errors were in the optical extraction. Overall, the optical extraction was quite good. It was after all good enough to understand the software and get us to this point. There's only one byte with more than a single incorrectly flipped bit. Many of the errors that existed were quite obvious when disassembling the software. If an instruction is out of place, but flipping a single bit would make it sensible, then it was probably a bit air. I didn't keep detailed records, but I think I probably caught about half of the ROM errors during the disassembly process before I started glitching. The interesting keys in the ACP are all stored in RAM only. This includes working, program, category and seed keys. The RAM is battery backed. If the seed keys are ever lost for RAM, this ACP can no longer process EMMs and so is useless. It's possible to glitch the ACP and read memory, but the glitcher works on an ACP moved from the set-top box. When the ACP is in circuit, the connections to other components and 16 VCC connected pins pose the problem. To glitch the ACP in circuit will require some modifications to the set-top box, disconnecting the ACP from other parts. Or another alternative is to remove the ACP from the set-top box and place it on a breakout board without losing the battery power and wiping RAM. Rather than modify the set-top box, where each of several different models would have required unique modifications, I decided to try to remove the ACP with a battery still attached. The plan is to carefully lift the battery and ground pins while the set-top box is powered on, providing VCC. I use a small tool I made from a razor blade using a Dremel tool, then attach the handle of a screwdriver. This tool can be wedged under a pin. Then with some hot air, the solder will melt and a single pin can be lifted straight up without damaging any of the other pins. With the pins lifted, an external battery can be attached. After attaching an external battery, after attaching an external battery, the set-top box is unplugged and the ACP can be removed from the set-top box using hot air. The ACP can be removed from the set-top box, glitched, and can even be placed back in the set-top box if desired. To do this, I just use hot air on a lot of flux. Additionally, once the interesting keys have been extracted, it might not even be necessary to replace the ACP in the set-top box. The ACP is now placed on a breakout board and connected to the glitcher. Not all of the pins need to be connected. Only a handful of pins are actually used by the glitcher. You can also see at this point the glitcher is in a project box. The aesthetics greatly improved since the breadboard-based glitcher, but the functionality is identical. The timing of ACP responses is different on a chip with valid RAM compared to the previous chips that I'd glitched before. I didn't confirm whether the cause of the timing difference was due to a different oscillator configuration or just a different software path, but by adjusting the timing of the glitches, the executable code payload runs as it did on the previous chips. So now we can read the RAM contents of a valid ACP, including the category keys if the set-top box had current authorization, as well as the seed keys that are used by this ACP to decrypt EMMs. With a valid category key, ECMs can be decrypted and a correct working key can be calculated for any channel. Now, with the capability of running my own code of the ACP, it's time to look at the transport stream de-scrambling. There's a hardware register bit that's set or cleared based on a byte in the ECM-40. When this bit is clear, standard desk decryption is used. When the bit is set, the transport stream de-scrambler acts differently. Additionally, there's an 8-bit hardware register in the desk peripheral area. When it's zero, the peripheral operates the standard desk. For any other value, the peripheral acts differently. At this point, I started to think I might be looking at doing a gate-level reverse engineering of the chip to understand this functionality. The chip's using technology that's older, so reverse engineering should be feasible. But if possible, I'd like to avoid all this extra work. It would be quite time consuming and might give imperfect results similar to the optical ROM extraction. So I start with trying to characterize the scrambling modes. The transport stream packet is made up of a four-byte header and 23 blocks of eight bytes each. The desk operates on these eight-byte, 64-bit blocks. By flipping one bit in encrypted input, ECB, CBC, or OFB modes can be differentiated. Flipping one bit causes an eight-byte block to be corrected and the corresponding bit in the following block to be flipped just indicates CBC mode is in use. Timing of the input compared to the decrypted output was measured with the de-scrambler standard desk and in the custom hardware mode. No timing difference was seen. This suggests the internal properties of desk haven't changed, which makes sense because the decryption has to be done in real time. So this suggests that crypto-customizations are not affecting some desk internals like the number of rounds. Also by using an ACP as a decryption oracle, I determined that the customization affects each of the 23 blocks of the transport stream differently. Next, I tested the software using desk weak keys. These are certain keys not recommended for use with desk because their properties weaken the cryptographic strength. A key of all zero or all one bits will cause desk decryption and encryption to be identical, that is, running the same data through encrypt or decrypt will give the same result. I can test this on an ACP configured for standard desk decryption and see the expected weak key behavior. When tested with a de-scrambler in custom mode, the weak key behavior changes. Using a key of all zero or all one didn't produce the same results in encrypt and decrypt modes. Looking at the other hardware register, testing the desk peripheral with different values in the 8-bit register and using weak keys shows that the standard desk weak key behavior still exists. So my hunch at this point is that one customization affects the key and the other customization affects the data. At this point, I can't be certain, but I have a good feeling about the theory, so I continue to investigate. Based on the idea that the hardware customization affects only the key and decryption is static, I thought the simplest customization would be an XOR mask that's applied to the key before it's used for desk decryption. XOR requires only a single gate and series with a desk engine, so it fits the requirements of fast and very simple to implement in hardware. A change of even a single bit in the key could cause the observed effect. Flipping more than 28 bits would be pointless. That's the same as inverting a key and flipping fewer bits. More flip bits means more gates necessary for the customization, so it makes sense to flip a minimal number of bits. So I wrote this wonderful for loop nested 16 levels deep to test decryption results after flipping one bit of the key, then flipping two bits, then three bits, and so on, up to 16 bits. To test all the possible keys will take a long time, but if only a few bits are flipped, then it might be possible to run in a shorter period of time. And promising results did come quickly. It turns out the theory held up, and some of the blocks have as few as three bits flipped. This takes only seconds for the software to identify. After verifying that these worked for XOR masks for these blocks, the software then was left running to find all 23 masks. This simple brute force method worked. It ran for a couple of days to identify all the 23 masks. By more carefully analyzing which bits are being flipped in the early results, a pattern can actually be found, so the search could have been more limited. Using this technique, the software cracker could have completed it in under a second. After successfully solving the first hardware customization, the theory that the second customization is a data XOR looks promising. It makes sense that one or more XOR gate is enabled by each bit of the 8-bit hardware register. Using the ACP as a decryption oracle, a known key in data were decrypted with all values of the 8-bit register. Software attack of this function was successful and 255 XOR masks were identified, behavior matching what was expected. I haven't actually seen this customization in actual use. Presumably they're saving it to be used as a countermeasure against pirate devices when necessary, but it hasn't been necessary since the system never had a security breach. In order to implement a soft cam, a software implementation of the descrambler, a few cryptographic details need to be identified, but at this point I have all the tools to do so. The initialization vector used for CBC mode can be found through a simple XOR and the handling of short blocks, those less than the 64-bit desk block size can be identified likewise. With all these details, a software implementation of the EMM decryption of category key and ECM decryption of program key and working keys can be made and the transport stream descrambler can also be implemented in software. The rapid key changes in use of desks with hardware customizations makes it a bit different to implement compared to a soft cam for typical DVB systems, but overall the concept is the same. And now it's all working. I was able to test it and it's fully working on both the satellite and cable systems. This is a screen that's broadcast before a pay-per-view event goes live. The pay-per-view, like all other channels, can be decrypted with a soft cam using the algorithms learned in these keys that are extracted. With the ECM and EMM algorithms and seed keys for a set-top box with any level of authorization, the category key can be decrypted and then used to decrypt any and all of the channels that are broadcast by this provider. A few of the weaknesses that I identified in this system were that the ACPI studied is relatively old technology, almost 20 years old, so this makes it a lot easier for invasive analysis today than when it was brand new. The TQFP100 package is quite easy to deal with compared to modern alternatives. The chip is susceptible to the voltage glitching. It's a Von Neumann architecture without strong MMU protection preventing code to be executed from RAM. They didn't leave any possibility for code update or dynamic code execution for countermeasure purposes. The software for the ACPs contained entirely in ROM with no mechanism for software updates in the field. The hardware customizations to the crypto are quite simple and required no reverse engineering of the chip logic. I was basically able to guess the hardware customizations. I was impressed with the design of the system. It was actually stronger than I anticipated when I started the project. All the key handling and decryption is contained within a single chip which makes it impossible to do key sharing that's being done with some of the smart card systems. The fast working key change interval, only 133 milliseconds, also makes key sharing more difficult and the short lifetime of the key makes cracking it in real time quite unrealistic. The lack of code in any rewritable memory means there's nowhere to write code for a permanent backdoor to disable the access or to disable the access controls. I listed this also as a weakness, but in fact, this is a strength as it limits the attacker's capability to install any kind of persistent backdoor. The chip operates on an internal clock, eliminating clock glitch attack and making timing a voltage glitch a lot more difficult. These dead addresses in the middle of desk keys prevent linear readout of keys. If one were to cause a loop reading data to go out of bounds and reach the area of RAM where keys are stored, the chip will reset before an entire key is read. After the first couple of bytes, a dead address will be accessed that causes the chip to reset. The personalization ROM appears to be inaccessible, so it can't easily be used to modify the keys and unit address within the ACP. The seed keys aren't easily changed, so the set top boxes can't easily be cloned. The keys exist only in RAM, so you have to maintain a battery backup at all times. This rules out a lot of invasive attacks to retrieve the keys. There are no group keys used for EMMs. All unit addressing is to individual units, so you have to pull keys from an actively subscribed box in order to get active keys. That said, if you have keys from a box that is subscribed to any channel, you will receive an EMM containing the category key, which is capable of decrypting all channels. So you don't need to have a subscription to all channels you want to decrypt as long as you are authorized for at least one channel on the system. The software is generally well-designed and written. I didn't notice any glaring bugs within it. Although DES is used, the EMM decryption requires using three DES keys and multiple rounds are performed when decrypting EMM and ECMs, so this part isn't as simple as cracking a single 56-bit key. Brute forcing, starting from the encrypted transport stream, requires cracking working key, then program key, then category key, and finally the three seed keys. You might wonder how many set top boxes it took for me to complete this project. The truth is I only needed the one truckload. Some of the boxes had different versions of the ACP chip. Many of the boxes had different PCB layouts, so it was interesting to be able to look at a variety of boxes. The cost of used set top boxes was low, around $20. And for this research, I was focusing on the signal security and didn't need the PVR functionality or any of the advanced features from the expensive set top boxes. So at this point, I have a brief anti-piracy message. I don't recommend you pirate cable or satellite TV. There's never anything good on. It doesn't matter how many channels you can decrypt. Believe me, I lucked. It's not worth the effort. Do we have questions from the room? Questions, please use the microphones. I know there is one question from the interwebs. Okay, hello, this is working, good. So the first question from the internet is, how many chips did you destroy or make unusable? And how did you get all those set up boxes? Because the cost of the used set top boxes was quite low, I wasn't afraid to destroy several chips in the process. It didn't take as many as I would have expected in the beginning. Two or three chips were used for the decapsulation and the de-layering process. I ended up extracting the ROM from a single chip. And then when it came to glitching, there were three or four chips that I removed and erased the RAM from to develop the glitch. When I finally got to the point where I was extracting keys from a valid chip, the very first chip that I tried worked. So there were a few casualties involved. Thank you. Microphone three was the first one, please. How many years did this project take you? I would work for a few weeks at a time and then get burnt out and take a break and then come back to it. Most of the work for the project was completed over about a two-year period. Thank you. And microphone two, please. Hi, thank you for a great lecture. How comes that the content encryption was des and not a dvbCSA? Because we used to usually that content is encrypted with dvbCSA in this dvbCSA. In North America, we don't believe in standards. Okay. The timing was also a part of it. The system was being developed at the same time as dvb was being standardized. So a general instrument, rather than going along with a standards group and waiting for the standardization, they went with des directly. Thank you. And another one from Cybersyber, Space Cyber. Okay. Another question from the internet is you had all this fancy lab equipment and stuff. How were you able to afford that? I've been quite interested in this for a long time. So I've collected this equipment over a period of years. And I do some work professionally in reverse engineering. So whenever possible, I use a client's money to buy another piece of equipment for the lab. To do this actual work, though, you could even use more basic equipment because of the age of the chip. You could use a microscope that you could find easily for $1,000 or $2,000 or even less and have quite good results. So it's not trivial, but it's not a huge amount of money for lab equipment. Not that huge. Microphone too, please. What do you do for a living besides reverse engineering? Reverse engineering. Thank you. And the internet, again. Okay. Next question is you, or somebody wants to know how, well, which software did you use for the automated image analyzing and is it available somewhere? Like everybody else that I've known that's done optical wrong extraction, I developed it myself. Everybody seems to develop their own tools from scratch for that. The image processing I used was really quite simple, so it didn't take a lot of advance algorithms or anything like that. So yeah, I'm using some software I developed personally and it hasn't been released. Microphone too, please. And how did you cap the boxes subscribed? So did you call them every week? Oh, my box broke down. I got another one, or how is this done? For most of the research that I did, I didn't need an active box. I did all the research just on previously activated boxes that had lost their authorization and by the time I had the process figured out that I knew how to extract keys from a valid box, I only needed the one box. And had you heard back from the cable provider about this? No. Okay, thank you. Microphone three, please. Hello, thanks very much for the lecture and well done on all the work. My question is how does the glitching work, the glitching attack? For the glitcher, it was quite simple. I dropped the voltage for a very brief period of time and it's enough time that it causes at least one instruction to not execute properly, but it's too short of a time to cause the chip to reset. So essentially, I'm corrupting one instruction. As far as the specific target that I hit that led to my code in RAM, I'm not actually sure. I found that if I glitch it this time, then the code ends up executing my code. Good enough for me. Okay, thank you, Chris. Please, dear audience, give an anniversary edition applause to Chris Galinsky.