1 00:00:00,000 --> 00:00:13,580 *33C3 preroll music* 2 00:00:13,580 --> 00:00:19,470 Herald: So… coming over to our next talk. 3 00:00:19,470 --> 00:00:26,320 Tonight, if you switch off your DECT phone, and 4 00:00:26,320 --> 00:00:29,870 if you’re full of different impressions 5 00:00:29,870 --> 00:00:35,830 – full of different impressions of this day you maybe want to watch TV. 6 00:00:35,830 --> 00:00:41,129 But it would be cool to have pay-TV – unencrypted pay-TV. 7 00:00:41,129 --> 00:00:47,130 So Chris Gerlinsky asks himself the same. And how to achieve unencrypted pay-TV 8 00:00:47,130 --> 00:00:52,229 – but the Hacker way. So Chris reverse-engineered nothing less 9 00:00:52,229 --> 00:00:57,659 than the signal and the encryption for a standard that remains unencrypted 10 00:00:57,659 --> 00:01:05,340 since the late 90s. Please welcome with an Anniversary Edition applause Chris Gerlinsky! 11 00:01:05,340 --> 00:01:23,650 *applause* 12 00:01:23,650 --> 00:01:26,550 Chris Gerlinsky: Hello everyone. My name is Chris Gerlinsky. 13 00:01:26,550 --> 00:01:30,000 I am a hacker from Canada and I’m here today to talk about how I cracked 14 00:01:30,000 --> 00:01:35,320 digital cable and satellite TV security. I studied an Access Control Platform (ACP) 15 00:01:35,320 --> 00:01:40,600 that’s widely used across Canada and the USA. It’s one of the two common platforms 16 00:01:40,600 --> 00:01:44,310 that’s used in cable TV, and it’s also used in satellite TV 17 00:01:44,310 --> 00:01:49,560 by one of the two Canadian satellite TV operators. As far as I know the system 18 00:01:49,560 --> 00:01:54,240 has remained secure since it was introduced in the 1990s and I was curious 19 00:01:54,240 --> 00:01:57,990 if I could understand the system based on the older set-top-boxes. Some of them 20 00:01:57,990 --> 00:02:02,641 are 15 years old – and they are still in use. So these devices haven’t received 21 00:02:02,641 --> 00:02:10,750 upgraded security hardware in that time and I started looking at how the system works. 22 00:02:10,750 --> 00:02:13,730 Before I get into the reverse engineering I’ll start with a brief description of how 23 00:02:13,730 --> 00:02:19,110 digital television is sent over satellite or cable. Satellite and cable digital TV 24 00:02:19,110 --> 00:02:23,860 are pretty similar for the most part. There are a variety of signal modulations used. 25 00:02:23,860 --> 00:02:30,760 The relevant ones here are QPSK at about 27 MBit/s and 8PSK Turbo FEC at about 26 00:02:30,760 --> 00:02:38,490 38 MBit/s for satellite and QAM256 at about 38 MBit/s for cable. There is also an 27 00:02:38,490 --> 00:02:44,010 out-of-band channel used by cable which is QPSK modulated at 2 MBit/s. 28 00:02:44,010 --> 00:02:47,180 This out-of-band channel carries the subscription-management, program guide 29 00:02:47,180 --> 00:02:51,560 information, firmware upgrades, etc. And while you change channels and the cable 30 00:02:51,560 --> 00:02:55,540 box tunes to different frequencies this out-of-band channel remains tuned 31 00:02:55,540 --> 00:02:59,150 so that the box continuously receives the state, and no matter what TV channel you’re 32 00:02:59,150 --> 00:03:03,810 tuned to. In the satellite TV this type of data is included within the main transport 33 00:03:03,810 --> 00:03:09,480 stream (TS) instead of in a secondary out-of-band TS. The video is sent 34 00:03:09,480 --> 00:03:16,480 as MPEG2 or H.264 TS. This is a standard format for carrying video streams. 35 00:03:16,480 --> 00:03:22,340 So it can be played by any hardware video decoder or software decoder, e.g. VLC. 36 00:03:22,340 --> 00:03:26,670 And the encryption system used here is called DigiCipher 2 (DC2), which does not 37 00:03:26,670 --> 00:03:33,980 follow the DVB standards that are used in the rest of the world. The MPEG-TS 38 00:03:33,980 --> 00:03:39,430 is made out of packets of 188 bytes. Each packet has a PID. This is used 39 00:03:39,430 --> 00:03:45,980 to differentiate different types of data. PIDs range from 0 - 0x1FFF. 40 00:03:45,980 --> 00:03:49,380 Each PID carries an MPEG Packetized Elementary Stream (PES). 41 00:03:49,380 --> 00:03:52,959 That’s a video or audio stream. Or the PID may carry one or more 42 00:03:52,959 --> 00:03:58,540 Service Information Tables. The Service Information Tables have an 8-bit table ID 43 00:03:58,540 --> 00:04:03,879 and a length of up to 1024 bytes including a CRC32 for error detection 44 00:04:03,879 --> 00:04:09,261 and this table ID identifies the type of data that you can expect within the table. 45 00:04:09,261 --> 00:04:13,989 Table 0 is the Program Association Table, containing a list of programs carried 46 00:04:13,989 --> 00:04:19,298 in this TS and the PMT PID for each program. The Program Association Table 47 00:04:19,298 --> 00:04:26,370 is always on PID 0. Table 2 is the Program Map Table which contains the list of PES 48 00:04:26,370 --> 00:04:30,870 and the PID for each as well as an ECM PID. There is Program Map Table 49 00:04:30,870 --> 00:04:36,080 for each MPEG program or TV channel that’s found in the stream. 50 00:04:36,080 --> 00:04:40,870 The ECM PID is where ‘Entitlement Control Messages’ are sent containing information 51 00:04:40,870 --> 00:04:44,909 that’s used to generate the key that decrypts the Packetized Elementary 52 00:04:44,909 --> 00:04:53,059 Streams. This system uses two types of ECM. Table 40 I call ECM40, and Table 41 53 00:04:53,059 --> 00:04:59,300 I call ECM41. On PID1 there may be one or more conditional access tables, 54 00:04:59,300 --> 00:05:05,399 table ID No.1. These tables identify a PID that carries EMMs, ‘Entitlement Management 55 00:05:05,399 --> 00:05:11,550 Messages’. These messages are used to set access rates for individual set-top-boxes. 56 00:05:11,550 --> 00:05:14,830 The subscription information, like, what channels are available is carried inside 57 00:05:14,830 --> 00:05:24,319 of EMMs. This is a hardware interface to receive satellite data, a Genpix SkyWalker-1. 58 00:05:24,319 --> 00:05:32,330 The DC2 QPSK modulation isn’t widely supported in USB or PCI DVB-S devices. 59 00:05:32,330 --> 00:05:37,909 And the 8PSK Turbo FEC modulation support is even less common. And one of the devices 60 00:05:37,909 --> 00:05:41,809 that does support these signals is this Genpix device which is using a Broadcom 61 00:05:41,809 --> 00:05:50,749 BCM4500 demodulator. And it supports both the DC2-QPSK and the 8PSK modulations. 62 00:05:50,749 --> 00:05:54,999 It works well, the Linux drivers need to be re-compiled to include the support 63 00:05:54,999 --> 00:06:00,210 for these modes, and patches for this were published by updatelee. There’s a link 64 00:06:00,210 --> 00:06:08,199 on the slide. For cable there’s a variety of adapters supporting QAM256 de-modulation. 65 00:06:08,199 --> 00:06:16,039 I used a USB HVR 950Q tuner. Unfortunately, to tune the out-of-band channel is generally 66 00:06:16,039 --> 00:06:20,599 not supported by the off-the-shelf interfaces. Inside the cable box 67 00:06:20,599 --> 00:06:24,699 it’s handled within the integrated chip set. And for the ClearQAM consumer 68 00:06:24,699 --> 00:06:31,550 devices such as USB interfaces access to the out-of-band data isn’t actually required 69 00:06:31,550 --> 00:06:34,529 so they don’t include it inside of the hardware. This out-of-band data is used 70 00:06:34,529 --> 00:06:40,560 only for pay-TV services. 71 00:06:40,560 --> 00:06:44,439 With the satellite and cable interfaces DVBsnoop can be used to view a lot of 72 00:06:44,439 --> 00:06:47,469 information about the transport stream. It’s enough information to be 73 00:06:47,469 --> 00:06:52,389 quite overwhelming. So the trick to using it is being able to sift through the output 74 00:06:52,389 --> 00:06:57,370 for the relevant information. DVBsnoop also doesn’t recognize all of the 75 00:06:57,370 --> 00:07:01,749 DigiCipher 2 tables because it’s a non- standard system, and DVBsnoop is targeted 76 00:07:01,749 --> 00:07:06,159 towards the standard systems. So DVBsnoop may not be able to tell you everything 77 00:07:06,159 --> 00:07:09,620 about the transport stream but it was still a very useful tool for all the 78 00:07:09,620 --> 00:07:17,740 information that it can provide. 79 00:07:17,740 --> 00:07:21,939 DVBsnoop and most other tools and documentation are designed for the DVB 80 00:07:21,939 --> 00:07:26,689 standard or other recognized standards such as ATSC. DigiCipher cable 81 00:07:26,689 --> 00:07:29,610 and satellite systems use a lot of non-standard tables to carry 82 00:07:29,610 --> 00:07:34,089 the system information. For cable TV some of these tables are standardized by 83 00:07:34,089 --> 00:07:39,909 the document SCTE 65. There is no BAT or SDT 84 00:07:39,909 --> 00:07:44,000 as you’d expect in DVB. Instead there is a virtual channel table that maps 85 00:07:44,000 --> 00:07:47,810 the transport streams and programs the channel numbers. The electronic program 86 00:07:47,810 --> 00:07:52,111 guide is also not DVB standard. So you don’t even get the current and next 87 00:07:52,111 --> 00:07:57,030 program information in any kind of a standard format. 88 00:07:57,030 --> 00:08:01,680 Another cable TV adapter is the HDHomeRun Prime. This one is a network-connected 89 00:08:01,680 --> 00:08:06,729 three-tuner device with cable card support. The set-top-boxes I studied 90 00:08:06,729 --> 00:08:10,520 pre-date the cable cards. Although the newer boxes do use the cable cards, 91 00:08:10,520 --> 00:08:14,819 and they support the DigiCipher 2. But cable card support does also mean 92 00:08:14,819 --> 00:08:20,059 that this HDHomeRun Prime includes the tuner and QPSK demodulator for the 93 00:08:20,059 --> 00:08:25,879 out-of-band channel. So it is able to pass this data to the cable card, as necessary. 94 00:08:25,879 --> 00:08:30,279 However, even the HDHomeRun doesn’t make this out-of-band data available 95 00:08:30,279 --> 00:08:35,339 other than the cable card interface. So to access the demodulated out-of-band data 96 00:08:35,339 --> 00:08:39,630 I tapped in to the HDHomeRun Prime with a cable card inserted, and connected 97 00:08:39,630 --> 00:08:46,370 a logic analyzer to the Data and Clock signals. I wrote software using the 98 00:08:46,370 --> 00:08:52,200 Saleae SDK to capture the QPSK demodulated data. Then, in software, I performed 99 00:08:52,200 --> 00:08:56,050 de-interleaving, de-randomization, and the forward error correction. 100 00:08:56,050 --> 00:09:02,160 And the output is an MPEG transport stream. So using an HDHomeRun Prime 101 00:09:02,160 --> 00:09:06,780 connected to the logic analyzer, connected to the PC running the software 102 00:09:06,780 --> 00:09:11,340 the output finally is a 2Mbit/s transport stream. And this transport stream 103 00:09:11,340 --> 00:09:15,070 looks like a standard transport stream, and inside are the conditional access 104 00:09:15,070 --> 00:09:19,130 management messages, program guide information etc. Everything that was 105 00:09:19,130 --> 00:09:26,410 missing from the main QAM transport stream. 106 00:09:26,410 --> 00:09:33,470 Two bits in each packet will indicate if the packet is scrambled with the even key, 107 00:09:33,470 --> 00:09:38,820 odd key, or not scrambled at all. The key is changed at short intervals. 108 00:09:38,820 --> 00:09:45,150 DVB systems typically will change every 5 .. 30 seconds. DC2 every 133 ms 109 00:09:45,150 --> 00:09:50,830 or 1 second. The key used for decryption alternates between even and odd. 110 00:09:50,830 --> 00:09:54,110 The odd key is in use while the even key is updated; and then the even key is 111 00:09:54,110 --> 00:09:58,720 in use while the odd key is updated. An encrypted transport stream is sent 112 00:09:58,720 --> 00:10:03,550 via the cable or satellite, and it’s passed through the descrambler in the ACP. 113 00:10:03,550 --> 00:10:08,360 And the result is a decrypted transport stream that is played by the MPEG decoder. 114 00:10:08,360 --> 00:10:12,920 The descrambler uses a Working Key. This is a 56-bit DES key that changes 115 00:10:12,920 --> 00:10:19,610 every 133ms, or in some cases they have it slowed down to changing every 1 second. 116 00:10:19,610 --> 00:10:24,060 This Working Key is generated by encrypting the frame count from ECM40 117 00:10:24,060 --> 00:10:29,750 packets with the Program Key. The Program Key, again DES, comes from the ECM41 118 00:10:29,750 --> 00:10:33,730 message, and is encrypted with the Category Key. The Program Key 119 00:10:33,730 --> 00:10:38,630 is unique to each channel, and it changes daily or for every pay-per-view event. 120 00:10:38,630 --> 00:10:43,790 The Category Key, also DES, is shared by all the set-top-boxes that authorize 121 00:10:43,790 --> 00:10:48,370 for any channel from this provider. The Category Key is sent to each set-top-box, 122 00:10:48,370 --> 00:10:53,950 individually, inside the EMM95 message. And this Category Key typically changes 123 00:10:53,950 --> 00:10:58,430 monthly, but many cable operators change keys much less frequently. Some of them 124 00:10:58,430 --> 00:11:04,210 are using the same key for years at a time. To decrypt the EMM, in order 125 00:11:04,210 --> 00:11:09,270 to get the Category Key Seed Keys are used. Each set-top-box has a set of 126 00:11:09,270 --> 00:11:13,540 56 bit DES Seed Keys inside of battery-backed RAM. These are 127 00:11:13,540 --> 00:11:17,780 initialized during manufacturing. For the lifetime of the set-top-box these keys 128 00:11:17,780 --> 00:11:23,070 are used to secure EMMs. So this forms a chain from the Seed Keys, 129 00:11:23,070 --> 00:11:26,850 initialized during manufacturing and never changing, to the decryption of the MPEG 130 00:11:26,850 --> 00:11:31,550 transport stream. 131 00:11:31,550 --> 00:11:34,710 Inside the satellite set-top-box we can see the main 132 00:11:34,710 --> 00:11:38,060 components of the system. The signal enters the tuner and is passed 133 00:11:38,060 --> 00:11:41,440 through the demodulator which outputs a serial transport stream. 134 00:11:41,440 --> 00:11:46,000 This transport stream passes through the ACP – Access Control Processor – 135 00:11:46,000 --> 00:11:51,120 and is then sent to the MPEG decoder to output a video signal to the TV. 136 00:11:51,120 --> 00:11:55,800 A 68k microcontroller acts as the set-top box main controller. It communicates 137 00:11:55,800 --> 00:12:00,340 with the MPEG decoder as well as with the ACP via an SPI bus. 138 00:12:00,340 --> 00:12:03,880 A battery provides backup power to the ACP. So it will retain RAM contents 139 00:12:03,880 --> 00:12:08,810 even when the set-top-box is unplugged. There’s a TVpass slot near the power 140 00:12:08,810 --> 00:12:12,110 supply. This is an upgrade slot with a card edge connector to allow 141 00:12:12,110 --> 00:12:14,830 for security upgrades. The system 142 00:12:14,830 --> 00:12:19,400 stayed secure, so the TVpass slot was never used. And the newer set-top-boxes 143 00:12:19,400 --> 00:12:23,930 don’t actually include a TVpass slot inside. So at this point it seems 144 00:12:23,930 --> 00:12:30,710 quite unlikely that this TVpass card will ever actually be used. 145 00:12:30,710 --> 00:12:34,630 Inside the cable set-top-box… it’s very similar to a satellite set-top-box 146 00:12:34,630 --> 00:12:38,840 but the cable boxes tend to be more tightly integrated. The signal enters 147 00:12:38,840 --> 00:12:42,740 the tuner and passes through a Broadcom chip that handles demodulation. 148 00:12:42,740 --> 00:12:46,260 And the same chip will also handle MPEG decoding after the transport stream’s been 149 00:12:46,260 --> 00:12:52,400 decrypted by the ACP. A 68k microcontroller acts as the set-top-box’s main controller. 150 00:12:52,400 --> 00:12:57,490 Again, talking to the ACP via SPI. And a battery provides backup power 151 00:12:57,490 --> 00:13:03,070 to the ACP, and also to the non-volatile RAM used by the main controller. 152 00:13:03,070 --> 00:13:08,500 A TVpass slot is underneath the main board, it’s not visible in this photo. 153 00:13:08,500 --> 00:13:11,370 The cable set-top-boxes include a second tuner that’s used to receive 154 00:13:11,370 --> 00:13:15,810 the out-of-band data. This OOB tuner operates independently of the main tuner 155 00:13:15,810 --> 00:13:20,081 and on a separate frequency range. And it’s used to provide a transport stream 156 00:13:20,081 --> 00:13:23,450 containing the system information, with the program guide, firmware updates, 157 00:13:23,450 --> 00:13:28,630 EMMs etc. 158 00:13:28,630 --> 00:13:35,110 Here we see the ACP chip. It’s a 100-pin TQFP package. From the markings 159 00:13:35,110 --> 00:13:39,920 we can see it’s a custom System-On-Chip made for General Instrument Corp. (GIC). 160 00:13:39,920 --> 00:13:43,470 All the decryption is performed by the ACP, and all decryption keys are kept 161 00:13:43,470 --> 00:13:49,600 only within this chip. The newer set-top- boxes use newer versions of the ACP. 162 00:13:49,600 --> 00:13:53,850 I studied the original ACP chip that’s seen in this photo. 163 00:13:53,850 --> 00:13:57,250 As long as the set-top-boxes using this chip are actively used it remains 164 00:13:57,250 --> 00:14:02,740 a relevant target. Whether the newer ACPs include more advanced security features 165 00:14:02,740 --> 00:14:07,310 or if they exist only for cost-savings due to shrinking the die size 166 00:14:07,310 --> 00:14:12,720 I don’t really know. 167 00:14:12,720 --> 00:14:16,480 Some of the interesting pins on the ACP are labeled here. Pin 1 is marked 168 00:14:16,480 --> 00:14:20,160 at the top left corner of the chip. There’s an SPI slave controller 169 00:14:20,160 --> 00:14:24,170 on Pins 1 - 5, used for communication with the set-top-box main controller. 170 00:14:24,170 --> 00:14:28,140 There’s a battery backup pin that’s connected to a 3V battery to keep 171 00:14:28,140 --> 00:14:33,050 the RAM contents of the ACP intact at all times. There’s a serial transport 172 00:14:33,050 --> 00:14:38,240 stream input on pins 88 - 92 which receives the data from the demodulator. 173 00:14:38,240 --> 00:14:42,490 And there’s a serial transport stream output on pins 28 - 33 which sends 174 00:14:42,490 --> 00:14:52,180 the decrypted transport stream to the MPEG decoder to be output to the TV. 175 00:14:52,180 --> 00:14:56,460 At one point I had written software for an AVR32 device, not the one that’s 176 00:14:56,460 --> 00:15:00,240 shown here, that has a synchronous serial peripheral, that supports sending and 177 00:15:00,240 --> 00:15:04,920 receiving data at the 27 MBit/s rate of the transport stream. My AVR32 implementation 178 00:15:04,920 --> 00:15:10,690 turned out a bit ugly. But rather than cleaning up I was able to use it as it was. 179 00:15:10,690 --> 00:15:16,060 It had some limitations like only accepting 64kB of data for replay logging. 180 00:15:16,060 --> 00:15:20,120 Which was just barely good enough for my studies. What the transport stream 181 00:15:20,120 --> 00:15:22,000 logging in-circuit digital mean was 182 00:15:22,000 --> 00:15:27,320 that the transport stream passes through the ACP with selected PIDs being decrypted. 183 00:15:27,320 --> 00:15:31,410 And then the output is the full transport stream but a selected program has been 184 00:15:31,410 --> 00:15:37,420 decrypted. The AVR32 logging interface had rather limited use for me. 185 00:15:37,420 --> 00:15:42,710 Later on when I did more thorough research I did so using an ACP that I’d removed from 186 00:15:42,710 --> 00:15:46,680 the box and I put on a breakout board. And then I could control the clock, and 187 00:15:46,680 --> 00:15:50,860 at that point it was much easier to use an XMEGA AVR platform to send and receive 188 00:15:50,860 --> 00:15:55,490 the transport stream through the ACP at a much slower bit rate. Shown here 189 00:15:55,490 --> 00:15:57,250 is the XMEGA platform I settled on using 190 00:15:57,250 --> 00:16:03,510 for SPI and also the transport stream interfacing. To honor the data 191 00:16:03,510 --> 00:16:08,100 passed between the set-top-box main controller and the ACP on the SPI bus 192 00:16:08,100 --> 00:16:15,220 I used the XMEGA development board. Two SPI ports acted as slave with Master Out - 193 00:16:15,220 --> 00:16:18,951 Slave In (MOSI) signal connected to 1 and Master In - Slave Out (MISO) signal 194 00:16:18,951 --> 00:16:23,779 connected to the Master Out - Slave In input of the second port. So from one port 195 00:16:23,779 --> 00:16:26,280 Bytes sent by the set-top-box controller are received. 196 00:16:26,280 --> 00:16:28,000 From the other port it receives 197 00:16:28,000 --> 00:16:33,490 bytes from the ACP. In case I want to talk directly to the ACP or the set-top-box 198 00:16:33,490 --> 00:16:37,730 main controller it’s only necessary to connect both the MOSI and MISO signals 199 00:16:37,730 --> 00:16:43,410 on one of the SPI interfaces. By holding the main controller in Reset my XMEGA 200 00:16:43,410 --> 00:16:48,540 was able to act as the SPI Master and then talk to the ACP. So this setup works for 201 00:16:48,540 --> 00:16:52,550 passively monitoring the SPI communications in the set-top-box and can also act as 202 00:16:52,550 --> 00:16:59,530 the SPI Master for interrogating the chip directly. 203 00:16:59,530 --> 00:17:01,360 By logging the SPI bus between 204 00:17:01,360 --> 00:17:05,240 the main controller and the ACP we see that information about the current access 205 00:17:05,240 --> 00:17:12,149 levels are sent from the ACP. The ACP also receives EMMs via the SPI bus. 206 00:17:12,149 --> 00:17:16,970 EMMs have been filtered by the Unit Address number, or the set-top-box serial number. 207 00:17:16,970 --> 00:17:22,519 So the ACP only receives messages that are intended for that specific unit. 208 00:17:22,519 --> 00:17:26,329 Command 04 includes the current Category Key epochs and Keyselects in use. 209 00:17:26,329 --> 00:17:31,639 Command 05 includes the Unit Address number. Command 13 returns the authorized 210 00:17:31,639 --> 00:17:37,340 Subscription tiers for this unit. Commands 7 and 87 provide information about the channel 211 00:17:37,340 --> 00:17:43,321 being currently decrypted. Additionally, via the SPI interface the set-top-box 212 00:17:43,321 --> 00:17:49,050 main controller tells the ACP which PIDs to decrypt and which is the ECM PID. 213 00:17:49,050 --> 00:17:53,440 The ACP doesn’t send any keys on the bus, and it only receives Category Keys that 214 00:17:53,440 --> 00:17:58,070 are encrypted within EMMs via the SPI. So all of the really interesting data is 215 00:17:58,070 --> 00:18:06,340 contained within the ACP chip itself, and it’s never sent out on any kind of a bus. 216 00:18:06,340 --> 00:18:10,299 So next I started an invasive study of the chip – studying it under a microscope. 217 00:18:10,299 --> 00:18:13,940 And the cost of microscopes can range from hundreds of Dollars to tens of thousands 218 00:18:13,940 --> 00:18:18,150 of Dollars, or even higher for things like electron microscopes or other specialized 219 00:18:18,150 --> 00:18:23,830 equipment. I have a couple of microscopes that I use. This one is a Mitutoyo FS70 220 00:18:23,830 --> 00:18:27,990 microscope. These Mitutoyo are often used for microprobing, but you can also use it 221 00:18:27,990 --> 00:18:33,049 for other uses. For this project I didn’t do any microprobing but I used this 222 00:18:33,049 --> 00:18:37,470 microscope because it was what I had. For studying this kind of technology you could 223 00:18:37,470 --> 00:18:40,700 use even more basic equipment but, of course, if you have the higher-end 224 00:18:40,700 --> 00:18:44,720 equipment it’s a lot nicer to work with. 225 00:18:44,720 --> 00:18:48,549 Another microscope I use is the Zeiss Axiotron. This microscope is designed 226 00:18:48,549 --> 00:18:53,679 for inspecting wafers and has really good optical quality. I said that more basic 227 00:18:53,679 --> 00:18:56,960 equipment could be used and it’s true. But when you get into this kind of thing 228 00:18:56,960 --> 00:19:00,579 you might find yourself again and again investing in more equipment. 229 00:19:00,579 --> 00:19:04,279 I've owed $10.000 in this setup including the microscope and the camera and the 230 00:19:04,279 --> 00:19:12,289 scanning stage and other parts. To look at the chip under the microscope requires 231 00:19:12,289 --> 00:19:16,650 that the chip is de-capsulated. Fuming Nitric Acid is used for this. 232 00:19:16,650 --> 00:19:21,190 The chip is immersed in heated red Fuming Nitric Acid which reacts with the plastic 233 00:19:21,190 --> 00:19:26,220 packaging and removes it. The chip is then rinsed in acetone, and cleaned with 234 00:19:26,220 --> 00:19:31,540 isopropyl alcohol in an ultrasonic bath which leaves the die bare and clean. 235 00:19:31,540 --> 00:19:35,470 The Nitric Acid is quite aggressive, and it’s important to handle it carefully. 236 00:19:35,470 --> 00:19:39,190 But the process is really straight-forward. Most people probably wouldn’t want 237 00:19:39,190 --> 00:19:40,569 to do this in their home. 238 00:19:40,569 --> 00:19:47,489 So you should go out to the garage and use your fume hood there. 239 00:19:47,489 --> 00:19:50,989 After the decapsulation the bare chips are left with bonding wires attached 240 00:19:50,989 --> 00:19:53,660 to them. So these wires will be plucked off using tweezers to get them 241 00:19:53,660 --> 00:19:58,600 out of the way. Already in this photo we can see some of the larger structures 242 00:19:58,600 --> 00:20:02,059 on the chip. Half of it is covered with a metal plane, and the other half 243 00:20:02,059 --> 00:20:09,509 shows some kind of visible circuitry. 244 00:20:09,509 --> 00:20:12,520 This is an image of the chip under the microscope. It’s been stitched together 245 00:20:12,520 --> 00:20:16,789 from several smaller images, to give an overview of the chip. 246 00:20:16,789 --> 00:20:21,259 Looking at the decapsulated chip we see the bond pads around the outside, 247 00:20:21,259 --> 00:20:25,450 a metal plane covering the top part of the chip and wires on the bottom of the chip, 248 00:20:25,450 --> 00:20:29,679 the spaghetti logic running all ov er the place. With a couple of structures 249 00:20:29,679 --> 00:20:33,630 that look like they could be a type of memory. There’s a lot still hidden 250 00:20:33,630 --> 00:20:40,120 from us. To see more of the chip it will be necessary to delayer it. 251 00:20:40,120 --> 00:20:45,059 To delayer the chip I used hydrofluoric acid to perform a wet etch. I used the Whink 252 00:20:45,059 --> 00:20:49,600 Rust Stain Remover product. It’s available in hardware stores all over the USA. 253 00:20:49,600 --> 00:20:55,100 It’s a dilute HF solution that works really well for delayering ICs. 254 00:20:55,100 --> 00:20:59,230 I put a small amount of the Whink liquid in a beaker and heated it on the hot plate. 255 00:20:59,230 --> 00:21:03,259 Then I dropped the decapsulated die in. Using a pipette I agitated the liquid 256 00:21:03,259 --> 00:21:07,420 to disturb the bubbles that form on the surface of the chip. So the acid can 257 00:21:07,420 --> 00:21:12,110 actually chip more evenly. The etching result isn’t perfect. Some parts of the chip 258 00:21:12,110 --> 00:21:15,049 will be etched deeper than other parts. But I’ve gotten quite useful results using 259 00:21:15,049 --> 00:21:19,409 this technique. You really don’t wanna breathe in these fumes, so do this 260 00:21:19,409 --> 00:21:25,889 in a fume hood in your garage, also. 261 00:21:25,889 --> 00:21:29,029 After a short time immersed in the heated Whink solution the chip was rinsed and 262 00:21:29,029 --> 00:21:32,730 put back under the microscope. Now the top metal plane has been removed 263 00:21:32,730 --> 00:21:37,490 so we can see what’s below. There are some visual effects that we start to see 264 00:21:37,490 --> 00:21:40,749 in the photo from the etching being a little bit uneven. But overall 265 00:21:40,749 --> 00:21:46,419 the delayered chip looks quite good and able to start studying it. At the top left 266 00:21:46,419 --> 00:21:51,119 the tall rectangles are RAM. The four blocks at the top right are ROM. 267 00:21:51,119 --> 00:21:56,630 And then there’s logic that tie these into the logic area below. 268 00:21:56,630 --> 00:22:01,039 I was interested in finding how the bits were encoded in ROM. So I continued 269 00:22:01,039 --> 00:22:04,289 delayering the chip. This was another dip in the Whink – and another metal layer 270 00:22:04,289 --> 00:22:07,990 has been removed. Bits in the ROM were not visible yet so I continued 271 00:22:07,990 --> 00:22:11,830 the delayering process. At this point we’re starting to see more of the visual 272 00:22:11,830 --> 00:22:19,700 effects from the uneven etching but it’s still not too bad. After a third dip 273 00:22:19,700 --> 00:22:23,299 in the Whink more metal has been removed. At this point the delayering is becoming 274 00:22:23,299 --> 00:22:26,820 more and more uneven. We can see the ROM blocks have been half-etched 275 00:22:26,820 --> 00:22:31,899 to a lower layer while half of the upper layer is still remaining. The wet etching 276 00:22:31,899 --> 00:22:36,940 process can be quite difficult to perform completely consistently without adding 277 00:22:36,940 --> 00:22:40,899 additional steps such as polishing. And at the time I did this project I didn’t have 278 00:22:40,899 --> 00:22:45,409 the polisher available so I was relying only on the wet etch. Some of the areas 279 00:22:45,409 --> 00:22:48,879 of the ROM are now showing visible bits. The other areas haven’t been etched 280 00:22:48,879 --> 00:22:55,249 deeply enough. So I continued to etch further to try and get a clean ROM. 281 00:22:55,249 --> 00:22:59,179 We can see the ROM bits quite clearly now. They’re arranged in rows and columns, and 282 00:22:59,179 --> 00:23:04,679 in this image if a black dot is visible that indicates that the bit is a One. 283 00:23:04,679 --> 00:23:07,889 Image quality is important. The better the photographs the more consistently the bits 284 00:23:07,889 --> 00:23:12,039 will be visible. But it doesn’t have to be really perfect. You can do some image 285 00:23:12,039 --> 00:23:16,789 processing on it, you can even repeat the process on multiple chips, delayer them 286 00:23:16,789 --> 00:23:20,710 and photograph them, and at some point you’ll be able to have the entire ROM 287 00:23:20,710 --> 00:23:26,279 clean and consistently visible. With the visible bits exposed and photographs taken 288 00:23:26,279 --> 00:23:30,860 the bits can be extracted using a software image analysis tool. Or the bits could be 289 00:23:30,860 --> 00:23:37,559 extracted manually. The ROM here is 32 kB or over 260.000 bits. So manual extraction 290 00:23:37,559 --> 00:23:43,630 would be a bit labor-intensive but it isn’t impossible. A software tool is 291 00:23:43,630 --> 00:23:48,909 more efficient. So I wrote some software to analyze the images and identify 292 00:23:48,909 --> 00:23:53,640 the 1 and 0 bits. There are bits marked with a yellow box for 0 bits or a blue box 293 00:23:53,640 --> 00:23:57,640 for 1 bits. I use a software to analyze the image and then I can quickly review 294 00:23:57,640 --> 00:24:04,980 the results manually, and identify any errors that I can see. After extracting 295 00:24:04,980 --> 00:24:08,500 the bits from the photographs I have a binary version of the ROM data. 296 00:24:08,500 --> 00:24:12,289 This is a visual representation of the bits extracted from this piece of ROM. 297 00:24:12,289 --> 00:24:18,679 Little black boxes signify 1 bits, and the white boxes signify 0 bits. 298 00:24:18,679 --> 00:24:23,539 In this image I’ve overlayed the extracted bottom 13 rows of bits over the photograph. 299 00:24:23,539 --> 00:24:27,340 You can see some visual patterns inside this, also. And these visual patterns 300 00:24:27,340 --> 00:24:33,799 are a good indicator that this ROM is probably not scrambled. 301 00:24:33,799 --> 00:24:37,519 This image shows the end of the ROM where you can see a pattern covering most of 302 00:24:37,519 --> 00:24:41,769 the image due to a repeated pattern of filler bytes that occupy unused space 303 00:24:41,769 --> 00:24:47,049 at the end of the ROM. At the very end of ROM the pattern is interrupted. This is 304 00:24:47,049 --> 00:24:50,370 where the vectors table exists at the top end of memory indicating the reset address 305 00:24:50,370 --> 00:24:54,950 and the addresses of interrupt handlers. The ROM has unused space, the filler bytes 306 00:24:54,950 --> 00:25:01,929 at the end. And the vectors table address is 0xFFF6 through 0xFFFF. 307 00:25:01,929 --> 00:25:06,289 After extracting the bits and decoding them into bytes the hex dump can be studied. 308 00:25:06,289 --> 00:25:11,899 There is a “Copyright 1997 CHCC” ASCII string in ROM which is helpful to identify 309 00:25:11,899 --> 00:25:15,139 when the ROM has been decoded correctly. *laughter* 310 00:25:15,139 --> 00:25:18,999 If you can read the ASCII text then surely the bits are in the correct order. 311 00:25:18,999 --> 00:25:22,759 The decoding in this case was just a matter of organizing the bits into bytes, it’s quite 312 00:25:22,759 --> 00:25:29,100 straightforward, there was no scrambling or anything else that was complex. 313 00:25:29,100 --> 00:25:32,549 With the ROM contents extracted the software can be disassembled and analyzed. 314 00:25:32,549 --> 00:25:37,200 The first step was to identify the CPU architecture. Studying the binary dump 315 00:25:37,200 --> 00:25:40,960 it appeared to be an 8-bit CPU but wasn’t 8051 or 6805 316 00:25:40,960 --> 00:25:46,019 or any of the processor types I tried first. Eventually, I tried disassembling 317 00:25:46,019 --> 00:25:50,429 it 6502 and the code made sense. Later I had remembered that I had looked at 318 00:25:50,429 --> 00:25:53,990 a previous version of the Access Controller from the same manufacturer. 319 00:25:53,990 --> 00:25:58,830 Which was used in another system, VideoCipher 2+, an ancestor of DigiCipher. 320 00:25:58,830 --> 00:26:05,249 On the older chip was a Copyright notice from WDC who licenses the 6502 core IP. 321 00:26:05,249 --> 00:26:09,270 It was visible directly on the chip die under the microscope. 322 00:26:09,270 --> 00:26:12,240 So this would have been a great clue for the CPU architecture if I had actually 323 00:26:12,240 --> 00:26:18,179 noticed it earlier. For disassembly I used IDA. It supports 6502 and is of course 324 00:26:18,179 --> 00:26:25,510 a very powerful disassembler. In addition to disassembly I used 6502 simulation 325 00:26:25,510 --> 00:26:29,799 software to study the software in a virtual CPU. The simulation is really 326 00:26:29,799 --> 00:26:33,289 helpful when disassembling the software. It provides a lot of insight into what’s 327 00:26:33,289 --> 00:26:38,269 going on. Since 6502 is a very well-known architecture it was not at all difficult 328 00:26:38,269 --> 00:26:43,409 to find an existing simulator. Even free, with source code. The 6502 is used 329 00:26:43,409 --> 00:26:47,850 in 8-bit computers, like the Apple II, in Commodore 64. So there’s really 330 00:26:47,850 --> 00:26:51,700 a lot of enthusiasts and a great deal of information about this architecture. 331 00:26:51,700 --> 00:26:55,369 As I gained understanding of the System On Chip through disassembling the software 332 00:26:55,369 --> 00:26:59,330 I began adding some other features into the simulator to emulate some of the 333 00:26:59,330 --> 00:27:08,779 hardware peripherals that were found inside the ACP, the device itself. 334 00:27:08,779 --> 00:27:11,282 One of the first things I saw in the disassembly was that there are two 335 00:27:11,282 --> 00:27:15,779 operating modes. During startup values in RAM are checked. And if the ACP 336 00:27:15,779 --> 00:27:18,649 hasn’t been initialized it enters a personalization mode used during 337 00:27:18,649 --> 00:27:23,390 manufacturing to assign the Unit Address and Seed keys. In normal conditions, 338 00:27:23,390 --> 00:27:26,509 after the set-top-box has left the factory this personalization software 339 00:27:26,509 --> 00:27:32,459 is bypassed and the ACP will always run its main application. The next thing 340 00:27:32,459 --> 00:27:36,830 I found was the application wasn’t very simple. This 6502 actually runs 341 00:27:36,830 --> 00:27:41,169 a task switching operating system. Eight tasks are run supporting decryption 342 00:27:41,169 --> 00:27:45,690 of up to two channels at the same time. There are two tasks to handle processing 343 00:27:45,690 --> 00:27:50,330 of ECM40 messages and generation of the Working Keys used to decrypt the transport 344 00:27:50,330 --> 00:27:55,200 stream. And two tasks to handle processing of ECM41 messages to generate 345 00:27:55,200 --> 00:28:00,749 the Program Keys that are used to process the ECM40. One task for handling 346 00:28:00,749 --> 00:28:05,190 EMM processing. And there’s also a task to communicate with the TVpass interface 347 00:28:05,190 --> 00:28:09,710 for security upgrades. With another task to handle the messages that are coming in 348 00:28:09,710 --> 00:28:17,090 over the SPI interface. Since the ACP is a custom System On Chip 349 00:28:17,090 --> 00:28:21,320 there is no documentation available describing the hardware capabilities. 350 00:28:21,320 --> 00:28:24,629 So the disassembly was studied and the input/output registers had to be guessed 351 00:28:24,629 --> 00:28:29,649 based on the software usage. There’s an SPI slave peripheral for communication 352 00:28:29,649 --> 00:28:33,690 with the main controller. The SPI peripheral sends and receives data 353 00:28:33,690 --> 00:28:37,330 directly to RAM. And then a signal is set indicating that the transport has been 354 00:28:37,330 --> 00:28:41,350 completed. There’s a DES crypto peripheral; 355 00:28:41,350 --> 00:28:45,980 key, data and operating mode are set in registers. And when the decryption 356 00:28:45,980 --> 00:28:50,029 has been completed the result can be read from additional registers. There’s 357 00:28:50,029 --> 00:28:54,269 a transport stream descrambler. The Working Key is set in hardware registers. 358 00:28:54,269 --> 00:28:57,590 And the descrambler will then output the decrypted transport stream on the serial 359 00:28:57,590 --> 00:29:03,389 transport stream interface. There are PID filters set by the set-top-box main 360 00:29:03,389 --> 00:29:07,850 controller over the SPI bus. These filters select which video and audio streams 361 00:29:07,850 --> 00:29:15,309 to descramble and which ECM packets should be received by the ACP. The received ECMs 362 00:29:15,309 --> 00:29:23,229 are placed in RAM, and the 6502 is notified of a new ECM via a register bit. 363 00:29:23,229 --> 00:29:26,049 So at this point I’m starting to get an idea of how the system works. 364 00:29:26,049 --> 00:29:29,859 I have studied the MPEG transport stream and logged ECM and EMM data. 365 00:29:29,859 --> 00:29:33,940 I’ve logged the SPI bus, and understand messages between the set-top-box 366 00:29:33,940 --> 00:29:38,740 main controller and the ACP. I was able to extract the entire ROM contents optically. 367 00:29:38,740 --> 00:29:43,559 And I’ve disassembled the software and run it in simulation. There are some keys 368 00:29:43,559 --> 00:29:47,539 that are found in ROM. Fixed keys which never change and are used when a channel 369 00:29:47,539 --> 00:29:51,999 has a “free preview weekend” or something of the sort. Any set-top-box that has ever 370 00:29:51,999 --> 00:29:55,809 had any kind of authorization in the past is allowed to decrypt channels that are 371 00:29:55,809 --> 00:30:01,409 encrypted using the “fixed key” mode. So now the focus is on understanding the ECM 372 00:30:01,409 --> 00:30:05,869 and EMM algorithms within the ROM software. At this point I’m still missing 373 00:30:05,869 --> 00:30:10,669 some important information from the ACP. All the Seed Keys, Category Keys and 374 00:30:10,669 --> 00:30:14,769 Program Keys exist only within RAM. So to decrypt any of the channels 375 00:30:14,769 --> 00:30:21,960 not in free preview isn’t possible yet at this point. The ECM40 message 376 00:30:21,960 --> 00:30:26,049 is used to generate the Working Key, used to descramble the MPEG streams. 377 00:30:26,049 --> 00:30:30,080 There’s a Service ID, used to identify each channel, and a frame count 378 00:30:30,080 --> 00:30:33,770 that’s used with the Program Key to calculate the Working Key. 379 00:30:33,770 --> 00:30:37,840 The crypt mode identifies if the channels are operating unencrypted, with a fixed 380 00:30:37,840 --> 00:30:41,450 key, or with the normal secure keys which are typically used. 381 00:30:41,450 --> 00:30:45,899 The frame count is simply a 24 bit counter that increments each time the Working Key 382 00:30:45,899 --> 00:30:51,090 changes. There’s a byte I’ve labeled ‘Hardware’ that has one bit set in it. 383 00:30:51,090 --> 00:30:57,029 This selects a special decryption mode that I’ll come back to a little bit later. 384 00:30:57,029 --> 00:31:03,890 The ECM41 contains encrypted Program Key that’s needed to correctly decrypt the ECM40. 385 00:31:03,890 --> 00:31:08,690 There’s a Provider ID that indicates which TV operator subscribers this ECM should 386 00:31:08,690 --> 00:31:12,739 be processed by. And there’s the same Service ID that will be found within 387 00:31:12,739 --> 00:31:19,190 the ECM40 messages. The Category epoch identifies which Category Key is in use. 388 00:31:19,190 --> 00:31:23,369 There’s also information about how long this Program Key will be valid for. 389 00:31:23,369 --> 00:31:27,739 ECM41 contains one or more subscription tiers that must be found within 390 00:31:27,739 --> 00:31:32,359 the customer’s ACP to allow this message to be processed. The subscription tiers 391 00:31:32,359 --> 00:31:37,340 are written to the ACP when the EMM containing authorization details is received. 392 00:31:37,340 --> 00:31:44,340 There is, again, a hardware crypto select byte that I will get back to. 393 00:31:44,340 --> 00:31:48,729 This slide shows what a half of a second of ECM40 and ECM41 activity might 394 00:31:48,729 --> 00:31:53,879 look like. To be able to descramble the program the ACP must process a current 395 00:31:53,879 --> 00:31:59,409 ECM41 to get the Program Key and then process an ECM40 to get the Working Key. 396 00:31:59,409 --> 00:32:04,100 The Working Key is then used by the descrambler to decrypt MPEG stream. 397 00:32:04,100 --> 00:32:08,900 Until the ACP receives the ECM41 with the current key as well as an ECM40 with 398 00:32:08,900 --> 00:32:14,119 the frame count it’s not yet possible to decrypt the transport stream. 399 00:32:14,119 --> 00:32:20,419 The Working Keys have a short life time, only 133 ms. The series of ECMs shown here 400 00:32:20,419 --> 00:32:25,950 all would happen within a period of a half of a second. 401 00:32:25,950 --> 00:32:27,460 The EMMs are split into 402 00:32:27,460 --> 00:32:31,910 four parts. Each part contains a portion of the subscription information for this 403 00:32:31,910 --> 00:32:36,650 set-top-box. A Category Key is calculated from each of the four parts and the key 404 00:32:36,650 --> 00:32:40,370 that is calculated for each part has to match the others, or the EMM will be 405 00:32:40,370 --> 00:32:46,190 rejected, and all authorization in Category Key will be wiped from this ACP. 406 00:32:46,190 --> 00:32:51,309 When the first EMM, part Zero, is received the authorization data inside the ACP 407 00:32:51,309 --> 00:32:54,590 is reset and will be replaced with authorization data from the EMM. 408 00:32:54,590 --> 00:33:00,009 When the next part, part One, is received the existing authorization data within 409 00:33:00,009 --> 00:33:05,700 the ACP from part Zero is hashed along with the data in part One. If the result 410 00:33:05,700 --> 00:33:09,049 is correct then the authorization from part One is copied into the ACP 411 00:33:09,049 --> 00:33:13,309 alongside the existing data from part Zero. If the result is incorrect then 412 00:33:13,309 --> 00:33:19,629 the ACP’s authorization is erased. In this way the four EMM messages are linked 413 00:33:19,629 --> 00:33:22,570 together, and if anything is modified within any of the EMM messages 414 00:33:22,570 --> 00:33:26,450 the authorization will fail. 415 00:33:26,450 --> 00:33:31,220 This is an example of an EMM. Each of the four EMM parts contains some common 416 00:33:31,220 --> 00:33:35,000 information, like the Unit Address, and which Category epoch this EMM contains 417 00:33:35,000 --> 00:33:41,090 information for. The EMM can contain two Category Keys. One for the current epoch 418 00:33:41,090 --> 00:33:45,379 and also for the next so that when there’s the change of the Category Key the ACP 419 00:33:45,379 --> 00:33:51,460 already has the next key available. To decrypt the Category Key from the EMM 420 00:33:51,460 --> 00:33:57,359 the Seed Keys contained in the ACP are used. The Seed Keys are unique to each ACP 421 00:33:57,359 --> 00:34:01,479 and are assigned during manufacturing. EMMs are transmitted out-of-band 422 00:34:01,479 --> 00:34:04,899 for cable systems but they’re passed to the ACP in the same way as for satellite 423 00:34:04,899 --> 00:34:08,480 systems. So at the ACP level, there’s no difference between the satellite and 424 00:34:08,480 --> 00:34:12,790 the cable systems. 425 00:34:12,790 --> 00:34:15,179 At this point it should be possible to decrypt channels that are using 426 00:34:15,179 --> 00:34:19,060 a fixed-key mode. Analysis of the ROM has shown the algorithms used to process 427 00:34:19,060 --> 00:34:21,530 the ECMs and generate the Working Key. 428 00:34:21,530 --> 00:34:25,750 The fixed keys are known because they’re contained in ROM. There could have been 429 00:34:25,750 --> 00:34:29,800 some question about the possibility of bit errors from the optical ROM extraction 430 00:34:29,800 --> 00:34:33,370 process. But the fixed keys can be confirmed as correct because the ROM 431 00:34:33,370 --> 00:34:38,100 software performs a checksum of this 256 byte area that contains the keys. 432 00:34:38,100 --> 00:34:41,100 Successfully running the checksum on the extracted ROM data indicates that 433 00:34:41,100 --> 00:34:45,889 the extracted keys seem to be correct. But when I attempted to decrypt 434 00:34:45,889 --> 00:34:50,040 a fixed-key channel there was a problem, it did not work. 435 00:34:50,040 --> 00:34:52,300 Whether it was a bug in my decryption implementation or something else 436 00:34:52,300 --> 00:34:57,670 was unclear. However, I had noticed the bit in ECM40 was set that causes a bit 437 00:34:57,670 --> 00:35:02,760 within the ACP hardware peripherals to be set. The purpose of the bit was unclear. 438 00:35:02,760 --> 00:35:06,990 But its address was suspiciously close to the transport stream descrambler key. 439 00:35:06,990 --> 00:35:09,660 So I started to suspect that there might be some encryption other than just 440 00:35:09,660 --> 00:35:12,170 standard DES. 441 00:35:12,170 --> 00:35:18,070 To be able to learn more about the ACP I started to look at glitchers. 442 00:35:18,070 --> 00:35:21,120 If I can succeed to glitch the chip I may be able to find a way to read and even 443 00:35:21,120 --> 00:35:25,740 write memory. And possibly a way to run my own software directly on the chip. 444 00:35:25,740 --> 00:35:28,290 This will allow me to control the hardware peripherals and be able to observe 445 00:35:28,290 --> 00:35:33,870 the chip’s operation under different conditions. Timing tests of the ACP 446 00:35:33,870 --> 00:35:38,050 suggest that the 6502 is running from an internal clock source. So this will allow 447 00:35:38,050 --> 00:35:42,680 a clock glitch attack. A VCC glitch makes sense, and with the age of this chip 448 00:35:42,680 --> 00:35:46,370 it seemed reasonable to expect that it would be susceptible to VCC glitches. 449 00:35:46,370 --> 00:35:50,830 The stronger protections against this type of attack are relatively recent. 450 00:35:50,830 --> 00:35:55,470 My glitcher design is quite simple. It’s based on an XMEGA development board 451 00:35:55,470 --> 00:35:59,820 and breadboard. I use the XMEGA to communicate with the ACP over SPI 452 00:35:59,820 --> 00:36:05,020 and to control the glitch. A 74xx series 4053 analog switch is used to quickly 453 00:36:05,020 --> 00:36:11,120 switch the ACP VCC between two voltages, a normal operating voltage, and a lower 454 00:36:11,120 --> 00:36:17,060 glitch voltage. I use a bench top DC power supply and two outputs so I can easily 455 00:36:17,060 --> 00:36:22,740 adjust both the normal VCC and glitch VCC levels. Other parts on the breadboard 456 00:36:22,740 --> 00:36:26,750 are an oscillator to provide some clock inputs necessary for the ACP to operate 457 00:36:26,750 --> 00:36:32,430 and an inverter and NAND gate to cut out the clock during the time of the glitch. 458 00:36:32,430 --> 00:36:36,020 To simplify the test setup as much as possible the ACP was removed from 459 00:36:36,020 --> 00:36:39,640 the set-top-box and soldered to a break-out board. In this process 460 00:36:39,640 --> 00:36:42,700 the battery-backed RAM was disconnected and all the keys were lost. 461 00:36:42,700 --> 00:36:47,580 But for the purpose of developing a working glitch this was okay. The simple, 462 00:36:47,580 --> 00:36:49,910 breadboard-based glitcher is quite flexible. The breadboard can be modified 463 00:36:49,910 --> 00:36:54,570 to test different ideas, and reconfigured quickly. More complex and advanced 464 00:36:54,570 --> 00:36:59,320 glitcher wasn’t necessary. 465 00:36:59,320 --> 00:37:02,020 To test the glitcher, to find out if it will work and what voltage levels 466 00:37:02,020 --> 00:37:06,620 are successful we can send a command to the ACP, then glitch, and then see 467 00:37:06,620 --> 00:37:11,310 the response from the ACP. The general strategy is to lower the voltage just 468 00:37:11,310 --> 00:37:15,430 to the point where the chip sometimes resets due to the glitch. 469 00:37:15,430 --> 00:37:18,740 By adjusting voltage levels and glitch length and timing when the glitch will end 470 00:37:18,740 --> 00:37:25,300 I succeeded to cause ACP responses to be altered. The checksum on SPI packets 471 00:37:25,300 --> 00:37:30,000 is very convenient. When unusual data is received from the ACP chip with a valid 472 00:37:30,000 --> 00:37:33,630 checksum it’s a pretty good sign that the glitch caused a temporary fault within 473 00:37:33,630 --> 00:37:38,300 the CPU, but their normal operation was resumed. Depending when the glitch 474 00:37:38,300 --> 00:37:42,170 is delivered different effects are seen. We can see that generally, as the glitches 475 00:37:42,170 --> 00:37:46,380 moved later, it’s the later bytes of the response packets that change. 476 00:37:46,380 --> 00:37:54,140 So at this point it looks like the glitcher works, and is able to cause a pretty fault. 477 00:37:54,140 --> 00:37:57,110 Since I had an effectve glitch I took the circuit from the breadboard 478 00:37:57,110 --> 00:38:01,130 and etched a simple PCB that I could plug directly on the XMEGA development board. 479 00:38:01,130 --> 00:38:04,240 This performs exactly the same function as the breadboard glitcher but 480 00:38:04,240 --> 00:38:07,641 I’m a bit less likely to accidently unplug a wire from the breadboard and 481 00:38:07,641 --> 00:38:10,800 have to repair things. The circuit was simple enough that I could create 482 00:38:10,800 --> 00:38:18,020 a one-sided PCB, so it was very easy for myself to etch at home. 483 00:38:18,020 --> 00:38:22,830 Now my goal is to have the ACP execute the code of my choice. Because the 6502 484 00:38:22,830 --> 00:38:27,920 is a von-Neumann architecture all code and data memories share the same address space. 485 00:38:27,920 --> 00:38:32,830 From software disassembly I saw that there didn't appear to be any paging or MMU 486 00:38:32,830 --> 00:38:37,780 features. The software in ROM is fully self-contained. There is no EEPROM 487 00:38:37,780 --> 00:38:41,660 and RAM is never used to hold executable code. So there aren’t jumps into 488 00:38:41,660 --> 00:38:45,790 these areas to exploit and, in fact, it wasn’t clear if there’s anything preventing 489 00:38:45,790 --> 00:38:51,980 code execution outside of ROM. I decided to take a chance and test if RAM is executable. 490 00:38:51,980 --> 00:38:56,710 So I sent a message via SPI, knowing that this message will be stored in RAM. 491 00:38:56,710 --> 00:39:01,420 The message contained 6502 executable code that will copy itself to an unused area 492 00:39:01,420 --> 00:39:06,130 of RAM, execute from this area and send an ACK indicating it was successful. 493 00:39:06,130 --> 00:39:09,820 Because I studied the use of the SPI interface and the ROM code I’m able 494 00:39:09,820 --> 00:39:13,770 to create this executable payload that will continue to receive commands via SPI 495 00:39:13,770 --> 00:39:17,260 after it’s taken control over the ACP. 496 00:39:17,260 --> 00:39:20,610 To try to maximize chances of success I looked through the ROM code for 497 00:39:20,610 --> 00:39:24,560 multi-byte instructions, which, if broken up, would have contained within them 498 00:39:24,560 --> 00:39:29,480 a jump op code with a destination that should lead to where my executable 499 00:39:29,480 --> 00:39:35,270 payload was placed at RAM. Since the ACP has a single address space this gives 500 00:39:35,270 --> 00:39:39,180 a lot of opportunities for glitching to cause execution to reach the payload. 501 00:39:39,180 --> 00:39:43,700 There are multiple scenarios possible in addition to my selected glitch target. 502 00:39:43,700 --> 00:39:47,370 Stack corruption is a possibility, and really any abnormal program flow has 503 00:39:47,370 --> 00:39:51,710 some possibility that it could eventually land in my code. The von-Neumann 504 00:39:51,710 --> 00:39:54,760 architecture, without strong memory management, is a very fertile ground 505 00:39:54,760 --> 00:39:59,700 for glitching. Anything in RAM potentially could be executed. 506 00:39:59,700 --> 00:40:02,660 So at this point there are several uncertainties, but so far nothing 507 00:40:02,660 --> 00:40:06,510 totally rules out the possibility of success. The ACP operates from 508 00:40:06,510 --> 00:40:10,370 an internal clock source. And the interrupt-driven task switching 509 00:40:10,370 --> 00:40:15,140 does add some further timing uncertainty. So I’ll send the code payload, 510 00:40:15,140 --> 00:40:19,110 delay, then glitch, and see the result. When it’s unsuccessful I change 511 00:40:19,110 --> 00:40:22,540 the delay and I try again. I tried to aim for the instruction 512 00:40:22,540 --> 00:40:26,210 that I’ve identified as possibly corruptible into a jump. 513 00:40:26,210 --> 00:40:29,980 But there are a lot of unknowns, so, really, the processor is like fishing: 514 00:40:29,980 --> 00:40:33,830 throw the line and hope. I have a target but no way to know if I can 515 00:40:33,830 --> 00:40:38,510 hit it, or if it will have the expected result. 516 00:40:38,510 --> 00:40:42,730 But sometimes fishing is good. Relatively quickly the ACP returns 517 00:40:42,730 --> 00:40:46,730 an ACK indicating a successful glitch. The first successful glitch took some hours 518 00:40:46,730 --> 00:40:50,220 to find. And then, after this it was possible to make it work repeatedly 519 00:40:50,220 --> 00:40:53,970 in a matter of minutes or even seconds. So now I have my code executing 520 00:40:53,970 --> 00:40:58,560 in RAM, I’m able to send the ACP additional pieces of code to be executed. 521 00:40:58,560 --> 00:41:01,971 This allows me to read any memory address, write any memory address, and perform 522 00:41:01,971 --> 00:41:07,490 any other operations possible with the 6502. 523 00:41:07,490 --> 00:41:11,140 I wrote a simple application to perform glitch surges, and then to interact 524 00:41:11,140 --> 00:41:15,050 with the code payload backdoor installed in RAM. And this program allows me 525 00:41:15,050 --> 00:41:19,900 to enter an address and length and have data returned. Or write memory etc. 526 00:41:19,900 --> 00:41:23,290 There’s also support for setting the key and data, and performing DES encrypt 527 00:41:23,290 --> 00:41:28,010 or decrypt using the DES hardware that’s inside the ACP. A few things I noticed 528 00:41:28,010 --> 00:41:32,849 at this point: there’s a 2 kB area of ROM that, if I attempted to read it, caused 529 00:41:32,849 --> 00:41:37,030 the chip to reset. This area of ROM contains the personalization routines 530 00:41:37,030 --> 00:41:41,040 that are never normally used after the device leaves the factory. 531 00:41:41,040 --> 00:41:44,470 There’s also protection against modifying the Seed Keys in RAM. Trying to store 532 00:41:44,470 --> 00:41:48,880 a value in these memory locations appeared to do nothing. 533 00:41:48,880 --> 00:41:53,520 There are specific addresses within RAM that can’t be read or the chip will lock up. 534 00:41:53,520 --> 00:41:57,600 These are clever traps put in place as a security measure. The 7-byte 535 00:41:57,600 --> 00:42:02,790 56 bit keys stored in RAM stride all these dead addresses. So a potential exploit 536 00:42:02,790 --> 00:42:06,230 that could cause a linear dump of memory will be stopped before a complete key 537 00:42:06,230 --> 00:42:11,370 is ever read. When the chip is reset it means having to glitch it again, because 538 00:42:11,370 --> 00:42:14,720 my code payload exists only in RAM, and there is no way to hook in a permanent 539 00:42:14,720 --> 00:42:19,100 backdoor. 540 00:42:19,100 --> 00:42:22,480 Since we can execute code on the ACP the receiver responds, we can read the ROM 541 00:42:22,480 --> 00:42:25,410 to have its contents without any of the errors that were introduced during 542 00:42:25,410 --> 00:42:30,120 the optical extraction process. Comparing the results of the optical ROM extraction 543 00:42:30,120 --> 00:42:34,590 with the proper dump we can see how many errors were in the optical extraction. 544 00:42:34,590 --> 00:42:37,920 Overall the optical extraction was quite good. It was, after all, good enough 545 00:42:37,920 --> 00:42:41,830 to understand the software and get us to this point. There is only one byte with 546 00:42:41,830 --> 00:42:46,210 more than a single incorrectly flipped bit. Many of the errors that existed 547 00:42:46,210 --> 00:42:50,290 were quite obvious from disassembling the software. If an instruction is out of place 548 00:42:50,290 --> 00:42:55,030 but flipping a single bit would make it sensible then it was probably a bit error. 549 00:42:55,030 --> 00:42:58,510 I didn’t keep detailed records but I think I probably caught about half of the ROM 550 00:42:58,510 --> 00:43:05,610 errors during the disassembly process before I started glitching. 551 00:43:05,610 --> 00:43:10,040 The interesting keys in the ACP are all stored in RAM only. This includes 552 00:43:10,040 --> 00:43:14,060 Working/Program/Category and Seed Keys. The RAM is battery-backed. 553 00:43:14,060 --> 00:43:18,570 If the Seed Keys are ever lost from RAM this ACP can no longer process EMMs 554 00:43:18,570 --> 00:43:23,360 and so is useless. It’s possible to glitch the ACP and read memory, but the glitcher 555 00:43:23,360 --> 00:43:28,770 works on an ACP removed from their set-top-box. When the ACP is in-circuit 556 00:43:28,770 --> 00:43:33,590 the connections to other components and 16 VCC-connected pins pose the problem. 557 00:43:33,590 --> 00:43:38,130 To glitch the ACP in-circuit we’ll require some modifications to the set-top-box 558 00:43:38,130 --> 00:43:42,340 disconnecting the ACP from other parts. Or, another alternative is to remove 559 00:43:42,340 --> 00:43:47,000 the ACP from the set-top-box and place it on a breakout board without loosing 560 00:43:47,000 --> 00:43:52,871 the battery power and wiping RAM. Rather than modify the set-top-box, where each 561 00:43:52,871 --> 00:43:56,650 of several different models would have required unique modifications I decided 562 00:43:56,650 --> 00:44:01,440 to try to remove the ACP with the battery still attached. The plan is to carefully 563 00:44:01,440 --> 00:44:07,650 lift the Battery and Ground pins while the set-top-box is powered on providing VCC. 564 00:44:07,650 --> 00:44:11,280 I use a small tool I made from a razorblade using a Dremel tool, then attached 565 00:44:11,280 --> 00:44:15,060 the handle of a screw driver. This tool can be wedged under a pin, then with 566 00:44:15,060 --> 00:44:18,420 some hot air the solder will melt and a single pin can be lifted straight up 567 00:44:18,420 --> 00:44:23,920 without damaging any of the other pins. 568 00:44:23,920 --> 00:44:27,470 With the pins lifted an external battery can be attached. 569 00:44:27,470 --> 00:44:29,240 After attaching an external battery… 570 00:44:29,240 --> 00:44:38,330 *applause* 571 00:44:38,330 --> 00:44:41,700 After attaching an external battery the set-top-box is unplugged, and the ACP 572 00:44:41,700 --> 00:44:46,370 can be removed from the set-top.box using hot air. The ACP can be removed from 573 00:44:46,370 --> 00:44:51,040 the set-top-box, glitched, and can even be placed back in the set-top-box, if desired. 574 00:44:51,040 --> 00:44:55,480 To do this I just use hot air and a lot of flux. Additionally, once the interesting 575 00:44:55,480 --> 00:44:59,190 keys have been extracted it may not even be necessary to replace the ACP 576 00:44:59,190 --> 00:45:04,490 in the set-top-box. The ACP is now placed on a breakout board and connected 577 00:45:04,490 --> 00:45:08,580 with the glitcher. Not all the pins need to be connected. Only a handful of pins 578 00:45:08,580 --> 00:45:12,180 are actually used by the glitcher. You can also see at this point the glitcher is 579 00:45:12,180 --> 00:45:17,050 in a project box. The aesthetics greatly improved since the breadboard-based 580 00:45:17,050 --> 00:45:22,370 glitcher. But the functionality is identical. The timing of ACP responses 581 00:45:22,370 --> 00:45:25,570 is different on a chip with valid RAM compared to the previous chips 582 00:45:25,570 --> 00:45:30,040 that I had glitched before. I didn’t confirm whether the cause of the timing 583 00:45:30,040 --> 00:45:32,770 difference was due to a different oscillator configuration or just 584 00:45:32,770 --> 00:45:35,950 a different software path. But by adjusting the timing of the glitches 585 00:45:35,950 --> 00:45:41,150 the executable code payload runs as it did on the previous chips. So now we can read 586 00:45:41,150 --> 00:45:45,190 the RAM contents of a valid ACP, including the Category Keys, if the set-top-box had 587 00:45:45,190 --> 00:45:49,720 current authorization, as well as the Seed Keys that are used by this ACP to decrypt 588 00:45:49,720 --> 00:45:56,910 EMMs. With a valid Category Key ECMs can be decrypted, and a cracked Working Key 589 00:45:56,910 --> 00:46:03,330 can be calculated for any channel. Now, with the capability of running my own code 590 00:46:03,330 --> 00:46:07,010 of the ACP it’s time to look at the transport stream descrambling. 591 00:46:07,010 --> 00:46:10,720 There’s a hardware register bit that is set or cleared, based on a byte 592 00:46:10,720 --> 00:46:15,050 in the ECM40. When this bit is cleared standard DES decryption is used. 593 00:46:15,050 --> 00:46:19,180 When the bit is set the transport stream descrambler acts differently. Additionally, 594 00:46:19,180 --> 00:46:23,650 there’s an 8-bit hardware register in the DES peripheral area. When it’s Zero 595 00:46:23,650 --> 00:46:26,610 the peripheral operates the standard DES. For any other value the peripheral acts 596 00:46:26,610 --> 00:46:29,910 differently. At this point I started to think I might be looking at doing 597 00:46:29,910 --> 00:46:34,150 a Gate-level reverse engineering of the chip to understand this functionality. 598 00:46:34,150 --> 00:46:38,500 The chip is using technology that’s older. So reverse-engineering should be feasible. 599 00:46:38,500 --> 00:46:42,020 But, if possible, I’d like to avoid all this extra work. It would be quite 600 00:46:42,020 --> 00:46:44,670 time consuming, and might give imperfect results, similar to the optical ROM 601 00:46:44,670 --> 00:46:48,490 extraction. So I started with trying to characterize descrambling modes. 602 00:46:48,490 --> 00:46:51,890 The transport stream packet is made up of a 4-byte header and 23 blocks of 603 00:46:51,890 --> 00:46:56,610 8 bytes each. The DES operates on these 8 byte (64 bit) blocks. 604 00:46:56,610 --> 00:47:03,280 By flipping one bit in encrypted input ECB, CBC or OFB modes can be differentiated. 605 00:47:03,280 --> 00:47:07,310 Flipping one bit causes an 8-byte block to be corrupted, and the corresponding bit 606 00:47:07,310 --> 00:47:11,870 in the following block to be flipped. This indicates CBC mode is in use. 607 00:47:11,870 --> 00:47:14,740 Timing of the input compared to the decrypted output was measured with 608 00:47:14,740 --> 00:47:18,120 the descrambler and standard DES, and in the custom hardware mode. 609 00:47:18,120 --> 00:47:21,670 No timing difference was seen. This suggests the internal properties of DES 610 00:47:21,670 --> 00:47:24,920 haven't changed. Which makes sense because the decryption has to be done 611 00:47:24,920 --> 00:47:29,610 in realtime. So this suggests that crypto customizations are not affecting 612 00:47:29,610 --> 00:47:34,590 some DES internals like the number of rounds. Also by using ACP as a decryption 613 00:47:34,590 --> 00:47:38,590 oracle I determined that the customization affects each of the 23 blocks of the 614 00:47:38,590 --> 00:47:44,150 transport stream differently. Next I tested the software using DES ‘weak keys’. 615 00:47:44,150 --> 00:47:48,070 These are certain keys not recommended for use with DES because their properties 616 00:47:48,070 --> 00:47:51,890 weaken the cryptographic strength. A key of all Zero or all One bits 617 00:47:51,890 --> 00:47:56,520 will cause DES decryption and encryption to be identical. That is running the same 618 00:47:56,520 --> 00:48:01,850 data through Encrypt or Decrypt will give the same result. I can test this on an ACP 619 00:48:01,850 --> 00:48:06,410 configured for standard DES decryption and see the expected ‘weak key’ behavior. 620 00:48:06,410 --> 00:48:10,270 When tested with the descrambler in custom mode the ‘weak key’ behaviour changes. 621 00:48:10,270 --> 00:48:13,990 Using a key of all Zero or all One didn’t produce the same results in Encrypt 622 00:48:13,990 --> 00:48:18,580 and Decrypt modes. Looking at the other hardware register, testing the DES 623 00:48:18,580 --> 00:48:22,710 peripheral with different values in the 8-bit register, and using ‘weak keys’, 624 00:48:22,710 --> 00:48:26,960 shows that the standard DES ‘weak key’ behaviour still exists. So my hunch 625 00:48:26,960 --> 00:48:29,870 at this point is that one customization affects the key, and the other customization 626 00:48:29,870 --> 00:48:33,040 affects the data. At this point I can’t be certain, but I have a good feeling about 627 00:48:33,040 --> 00:48:37,310 the theory, so I continue to investigate. 628 00:48:37,310 --> 00:48:40,110 Based on the idea that the hardware customization affects only the key 629 00:48:40,110 --> 00:48:44,160 and decryption is static I thought the simplest customization will be an XOR 630 00:48:44,160 --> 00:48:48,660 mask that’s applied to the key before it’s used for DES decryption. XOR requires 631 00:48:48,660 --> 00:48:51,630 only a single gate in series of the DES engine so it fits the requirements of 632 00:48:51,630 --> 00:48:55,830 fast and very simple implement in hardware. A change of even a single bit 633 00:48:55,830 --> 00:48:59,480 in the key could cause the observed effects. Flipping more than 28 bits 634 00:48:59,480 --> 00:49:04,310 will be pointless. That’s the same as inverting a key and flipping fewer bits. 635 00:49:04,310 --> 00:49:07,180 More flipped bits means more gates necessary for the customization, so 636 00:49:07,180 --> 00:49:11,470 it makes sense to flip a minimal number of bits. So I wrote this wonderful FOR loop, 637 00:49:11,470 --> 00:49:15,810 nested 16 levels deep, to test decryption results after flipping one bit of the key, 638 00:49:15,810 --> 00:49:20,030 then flipping two bits, then three bits etc. of the 16 bits. To test all the 639 00:49:20,030 --> 00:49:22,780 possible keys will take a long time. But if only a few bits are flipped then it 640 00:49:22,780 --> 00:49:27,170 might be possible to run it in a shorter period of time. And promising results 641 00:49:27,170 --> 00:49:31,010 did come quickly. It turns out the theory held up. And some of the blocks have 642 00:49:31,010 --> 00:49:35,610 as few as three bits flipped. This takes only seconds for the software to identify. 643 00:49:35,610 --> 00:49:39,510 After verifying that these work for XOR masks, for these logs the software then 644 00:49:39,510 --> 00:49:42,450 was left running to find all 23 masks. 645 00:49:42,450 --> 00:49:45,830 The simple brute-force method worked, it ran for a couple of days to identify 646 00:49:45,830 --> 00:49:50,380 all the 23 masks. By more carefully analyzing which bits were being flipped 647 00:49:50,380 --> 00:49:54,230 in the early results a pattern can actually be found. So the search could 648 00:49:54,230 --> 00:49:57,460 have been more limited. Using this technique the software cracker could have 649 00:49:57,460 --> 00:50:02,210 completed it in under a second. 650 00:50:02,210 --> 00:50:04,720 After successfully solving the first hardware customization the theory 651 00:50:04,720 --> 00:50:10,320 that the second customization is a Data XOR looks promising. It makes sense 652 00:50:10,320 --> 00:50:14,590 that one or more XOR gate is enabled by each bit of the 8-bit hardware register. 653 00:50:14,590 --> 00:50:18,430 Using the ACP as a decryption oracle a known key in Data were decrypted 654 00:50:18,430 --> 00:50:22,500 with all values of the 8-bit register. Software attack of this function 655 00:50:22,500 --> 00:50:28,260 was successful, and 255 XOR masks were identified, behavior matching what was 656 00:50:28,260 --> 00:50:33,820 expected. I haven’t actually seen this customization in actual use. Presumably, 657 00:50:33,820 --> 00:50:36,000 they’re saving it to be used as a countermeasure against pirate devices 658 00:50:36,000 --> 00:50:39,410 when necessary. But it hasn’t been necessary since the system never had 659 00:50:39,410 --> 00:50:43,860 a security breach. 660 00:50:43,860 --> 00:50:51,730 *laughs* *applause* 661 00:50:51,730 --> 00:50:55,160 In order to implement a Softcam, a software implementation of the descrambler, 662 00:50:55,160 --> 00:50:59,480 a few cryptographic details need to be identified. But at this point I have 663 00:50:59,480 --> 00:51:03,770 all the tools to do so. The initialization vector used for CBC mode can be found 664 00:51:03,770 --> 00:51:07,260 through simple XOR. And the handling of short blocks – those less than the 665 00:51:07,260 --> 00:51:11,790 64 bit DES block size can be identified likewise. With all these details 666 00:51:11,790 --> 00:51:14,980 a software implementation of the EMM decryption of Category Key and 667 00:51:14,980 --> 00:51:19,161 ECM decryption of Program Key and Working Keys can be made and the transport stream 668 00:51:19,161 --> 00:51:23,540 descrambler can also be implemented in software. The rapid key changes and the 669 00:51:23,540 --> 00:51:27,290 use of DES with h/w customizations makes it a bit different to implement, compared 670 00:51:27,290 --> 00:51:32,120 to a Softcam for typical DVB systems, but overall the concept is the same. 671 00:51:32,120 --> 00:51:37,070 And now it’s all working! I was able to test it, and it’s fully working on both 672 00:51:37,070 --> 00:51:40,901 the satellite and cable systems. This is a screen that’s broadcast before 673 00:51:40,901 --> 00:51:44,740 a pay-per-view event goes live. The pay-per-view, like all other channels, 674 00:51:44,740 --> 00:51:48,010 can be decrypted with the Softcam using the algorithms learned in these keys that 675 00:51:48,010 --> 00:51:53,960 were extracted. With the ECM and EMM algorithms and Seed Keys for a set-top-box 676 00:51:53,960 --> 00:51:57,680 with any level of authorization the Category Key can be decrypted 677 00:51:57,680 --> 00:52:01,550 and then used to decrypt any and all of the channels that are broadcast 678 00:52:01,550 --> 00:52:05,150 by this provider. 679 00:52:05,150 --> 00:52:14,060 *applause* 680 00:52:14,060 --> 00:52:18,590 A few of the weaknesses that I identified in this system were that the ACP I studied 681 00:52:18,590 --> 00:52:23,160 is relatively old technology, almost 20 years old. So this makes it a lot 682 00:52:23,160 --> 00:52:26,500 easier for invasive analysis today than one that was brand new. 683 00:52:26,500 --> 00:52:32,490 The TQFP100 package is quite easy to deal with compared to modern alternatives. 684 00:52:32,490 --> 00:52:38,170 The chip is susceptible to voltage glitching. It’s a van-Neumann architecture 685 00:52:38,170 --> 00:52:42,350 without strong MMU protection preventing code to be executed from RAM. 686 00:52:42,350 --> 00:52:47,040 They didn’t leave any possibility for code update or dynamic code execution 687 00:52:47,040 --> 00:52:52,200 for countermeasure purposes. The software for the ACP is contained entirely in ROM 688 00:52:52,200 --> 00:52:57,070 with no mechanism for software updates in the field. The hardware customizations 689 00:52:57,070 --> 00:53:00,990 to the crypto were quite simple and required no reverse-engineering 690 00:53:00,990 --> 00:53:08,880 of the chip logic. I was basically able to guess the hardware customizations. 691 00:53:08,880 --> 00:53:11,650 I was impressed with the design of the system. It was actually stronger than 692 00:53:11,650 --> 00:53:16,190 I anticipated when I started the project. All the key handling and decryption 693 00:53:16,190 --> 00:53:20,010 is contained within a single chip which makes it impossible to do key sharing 694 00:53:20,010 --> 00:53:23,891 that’s being done with some of the smartcard systems. The fast Working Key 695 00:53:23,891 --> 00:53:29,050 change interval – only a 133 ms – also makes key sharing more difficult. 696 00:53:29,050 --> 00:53:34,240 And the short lifetime of the key makes cracking it in realtime quite unrealistic. 697 00:53:34,240 --> 00:53:37,640 The lack of code in any rewritable memory means there’s nowhere to write code for 698 00:53:37,640 --> 00:53:45,500 a permanent backdoor to disable the access controls. I listed this also as 699 00:53:45,500 --> 00:53:49,420 a weakness but in fact this is a strength as it limits the attacker’s capability 700 00:53:49,420 --> 00:53:53,850 to install any kind of persistent backdoor. The chip operates 701 00:53:53,850 --> 00:53:56,940 on an internal clock eliminating clock glitch attack and making timing 702 00:53:56,940 --> 00:54:01,550 a voltage glitch a lot more difficult. These dead addresses in the middle 703 00:54:01,550 --> 00:54:05,730 of DES keys prevent linear readout of keys. If one were to cause a loop reading 704 00:54:05,730 --> 00:54:09,290 data to go out of bounds and reach the area of RAM where keys are stored 705 00:54:09,290 --> 00:54:13,430 the chip will reset before an entire key is read. After the first couple of bytes 706 00:54:13,430 --> 00:54:17,790 a dead address will be accessed that causes the chip to reset. 707 00:54:17,790 --> 00:54:22,390 The personalization ROM appears to be inaccessible so it can’t easily be used 708 00:54:22,390 --> 00:54:28,030 to modify the keys and Unit Address within the ACP. The Seed Keys 709 00:54:28,030 --> 00:54:32,120 aren’t easily changed so the set-top-boxes can’t easily be cloned. 710 00:54:32,120 --> 00:54:37,170 The keys exist only in RAM so you have to maintain a battery backup at all times. 711 00:54:37,170 --> 00:54:42,840 This rules out a lot of invasive attacks to retrieve the keys. And there are 712 00:54:42,840 --> 00:54:46,360 no group keys used for EMMs. All the unit addressing is to individual units. 713 00:54:46,360 --> 00:54:51,350 So you have to pull keys from an actively subscribed box in order to get active keys. 714 00:54:51,350 --> 00:54:54,730 That said if you have keys from a box that is subscribed to any channel 715 00:54:54,730 --> 00:54:58,650 you’ll receive an EMM containing the Category Key which is capable of 716 00:54:58,650 --> 00:55:02,140 decrypting all channels. So you don’t need to have a subscription to all channels 717 00:55:02,140 --> 00:55:04,980 you want to decrypt as long as you’re authorized for at least one channel 718 00:55:04,980 --> 00:55:09,710 on the system. 719 00:55:09,710 --> 00:55:13,180 The software is generally well designed and written. I didn’t notice any glaring 720 00:55:13,180 --> 00:55:18,660 bugs within it. Although DES is used the EMM decryption requires using three 721 00:55:18,660 --> 00:55:23,580 DES keys, and multiple rounds are performed when decrypting EMM and ECMs. 722 00:55:23,580 --> 00:55:28,480 So this part isn’t as simple as cracking a single 56-bit key. 723 00:55:28,480 --> 00:55:32,010 Brute-forcing, starting from the encrypted transport stream requires cracking 724 00:55:32,010 --> 00:55:35,660 Working Key, then Program Key, then Category Key and, finally, 725 00:55:35,660 --> 00:55:43,370 the three Seed Keys. 726 00:55:43,370 --> 00:55:46,810 You might wonder how many set-top-boxes it took for me to complete this project! 727 00:55:46,810 --> 00:55:56,520 *laughter and applause* 728 00:55:56,520 --> 00:55:59,780 The truth is I only needed the one… …truck load! 729 00:55:59,780 --> 00:56:02,100 *laughter* 730 00:56:02,100 --> 00:56:05,990 Some of the boxes had different versions of the ACP chip. Many of the boxes had 731 00:56:05,990 --> 00:56:08,710 different PCB layouts. So it was interesting to be able to look at 732 00:56:08,710 --> 00:56:14,320 a variety of boxes. The cost of used set top boxes was low, ca. $20. And for 733 00:56:14,320 --> 00:56:17,540 this research I was focusing on the signal security and didn’t need the PVR 734 00:56:17,540 --> 00:56:24,500 functionality or any of the advanced features from the expensive set-top-boxes. 735 00:56:24,500 --> 00:56:28,310 So at this point I have a brief anti-piracy message: I don’t recommend you pirate 736 00:56:28,310 --> 00:56:32,420 cable or satellite TV. There is never anything good on. It doesn’t matter 737 00:56:32,420 --> 00:56:34,620 how many channels you can decrypt. Believe me – I looked! 738 00:56:34,620 --> 00:56:36,300 It’s not worth the effort! 739 00:56:36,300 --> 00:56:51,450 *laughter and applause* 740 00:56:51,450 --> 00:56:55,250 Herald: Do we have questions from the room? 741 00:56:55,250 --> 00:56:59,820 Questions – please use the microphones. 742 00:56:59,820 --> 00:57:05,750 I know there is one question from the interwebs. 743 00:57:05,750 --> 00:57:08,410 Signal Angel: Okay, hello. This is working? Good. 744 00:57:08,410 --> 00:57:13,990 So the first question from the internet is: how many chips did you destroy 745 00:57:13,990 --> 00:57:20,810 or make unusable, and how did you get all those set-top-boxes? 746 00:57:20,810 --> 00:57:24,440 Chris: Because the cost of the used set-top-boxes was quite low I wasn’t 747 00:57:24,440 --> 00:57:29,421 afraid to destroy several chips in the process. It didn’t take as many 748 00:57:29,421 --> 00:57:36,330 as I would have expected in the beginning. Two or three chips were used for the 749 00:57:36,330 --> 00:57:39,970 decapsulation and the delayering process. I ended up extracting the ROM 750 00:57:39,970 --> 00:57:44,660 from a single chip. And then, when it came to glitching, there were 751 00:57:44,660 --> 00:57:49,600 three or four chips that I removed and erased the RAM from to develop the glitch. 752 00:57:49,600 --> 00:57:53,310 When I finally got to the point where I was extracting keys from a valid chip 753 00:57:53,310 --> 00:57:59,260 the very first chip that I tried worked. So there were few casualties involved! 754 00:57:59,260 --> 00:58:03,510 Herald: Thank you! Microphone 3 was the first one, please! 755 00:58:03,510 --> 00:58:09,500 Mic3: How many years did this project take you? 756 00:58:09,500 --> 00:58:12,470 Chris: I would work for a few weeks at a time and then get burned out and 757 00:58:12,470 --> 00:58:16,420 take a break, and then come back to it. Most of the work for the project 758 00:58:16,420 --> 00:58:22,020 was completed over about a 2-year period. 759 00:58:22,020 --> 00:58:25,530 Herald: Thank you. And… Microphone 2, please! 760 00:58:25,530 --> 00:58:29,170 Mic2: Hi, thank you for a great lecture. How comes that 761 00:58:29,170 --> 00:58:35,960 the content decryption was DES and not a DVB-CSA because we're used 762 00:58:35,960 --> 00:58:39,090 that content is encrypted with DVB-CSA in these DVB systems. 763 00:58:39,090 --> 00:58:41,860 Chris: In North America we don’t believe in standards! 764 00:58:41,860 --> 00:58:45,240 *laughter* 765 00:58:45,240 --> 00:58:48,680 Mic2: Thanks! 766 00:58:48,680 --> 00:58:51,650 Chris: The timing was also a part of it. The system was being developed 767 00:58:51,650 --> 00:58:55,760 at the same time as DVB was being standardized. So General Instrument 768 00:58:55,760 --> 00:58:59,060 rather than going along with the Standards Group and waiting for the standardization 769 00:58:59,060 --> 00:59:03,090 they went with DES, directly. 770 00:59:03,090 --> 00:59:07,460 Herald: Thank you. And another one from Cyber-Cyber… space! 771 00:59:07,460 --> 00:59:11,230 Signal Angel: Okay. Another question from the internet is: you have all this fancy 772 00:59:11,230 --> 00:59:16,130 like lab equipment stuff. How were you able to afford that? 773 00:59:16,130 --> 00:59:19,260 Chris: I’ve been quite interested in this for a long time. So I’ve collected 774 00:59:19,260 --> 00:59:23,920 this equipment over a period of years. And I do some work, professionally, 775 00:59:23,920 --> 00:59:27,540 in reverse-engineering. So whenever possible I use our client’s money 776 00:59:27,540 --> 00:59:34,040 to buy another piece of equipment for the lab. 777 00:59:34,040 --> 00:59:37,300 To do this actual work, though, you could even use more basic equipment 778 00:59:37,300 --> 00:59:41,560 because of the age of the chip. You could use a microscope that you could find 779 00:59:41,560 --> 00:59:45,740 easily for $1.000 .. $2.000 or even less and have quite good results. 780 00:59:45,740 --> 00:59:51,480 So it’s not trivial but it’s not a huge amount of money for a lab equipment! 781 00:59:51,480 --> 00:59:54,990 Herald: Not that huge! Microphone 2, please! 782 00:59:54,990 --> 00:59:58,910 Mic2: What do you do for a living besides reverse-engineering? 783 00:59:58,910 --> 01:00:03,540 Chris: Reverse-engineering! *laughs* 784 01:00:03,540 --> 01:00:07,420 Herald: Thank you. And the internet! Again. 785 01:00:07,420 --> 01:00:13,160 Signal Angel: Okay. Next question is… somebody wants to know how… 786 01:00:13,160 --> 01:00:17,360 …which software did you use for the automated image analyzing, and 787 01:00:17,360 --> 01:00:20,060 is it available somewhere? 788 01:00:20,060 --> 01:00:24,020 Chris: Like everybody else that I’ve known that’s done optical ROM extraction 789 01:00:24,020 --> 01:00:28,170 I developed it myself. Everybody seems to develop their own tools from scratch 790 01:00:28,170 --> 01:00:33,461 for that. The image processing I used was really quite simple. So it didn’t take 791 01:00:33,461 --> 01:00:38,540 a lot of advanced algorithms or anything like that. So I’m using some software 792 01:00:38,540 --> 01:00:43,860 I developed personally, and it hasn’t been released. 793 01:00:43,860 --> 01:00:45,900 Herald: Microphone 2, please! 794 01:00:45,900 --> 01:00:50,450 Mic2: And how did you keep the boxes subscribed? So did you call them 795 01:00:50,450 --> 01:00:54,260 every week “Oh, my box broke down, I got another one”, or how is this done? 796 01:00:54,260 --> 01:00:58,520 Chris: For most of the research that I did I didn’t need an active box. I did 797 01:00:58,520 --> 01:01:02,100 all the research just on previously activated boxes that had lost their 798 01:01:02,100 --> 01:01:05,840 authorization. And by the time I had the process figured out, that I knew how 799 01:01:05,840 --> 01:01:10,230 to extract keys from a valid box I only needed the one box. 800 01:01:10,230 --> 01:01:13,520 Mic2: And had you heard back from the cable provider about this? 801 01:01:13,520 --> 01:01:15,330 Chris: No. 802 01:01:15,330 --> 01:01:18,670 Herald: Okay, thank you. Microphone 3, please! 803 01:01:18,670 --> 01:01:22,360 Mic3: Hello, thanks very much for the lecture and ‘well done’ on all the work! 804 01:01:22,360 --> 01:01:29,400 My question is: how does the glitching work, the glitching attack? 805 01:01:29,400 --> 01:01:34,770 Chris: The glitcher was quite simple. I drop the voltage for a very brief period 806 01:01:34,770 --> 01:01:40,270 of time. And it’s enough time that it causes at least one instruction to 807 01:01:40,270 --> 01:01:44,800 not execute properly. But it’s too short of a time to cause the chip to reset. 808 01:01:44,800 --> 01:01:48,640 So essentially I’m corrupting one instruction. It is for the specific target 809 01:01:48,640 --> 01:01:54,170 that I hit that led to my code in RAM. I’m not actually sure. I found that 810 01:01:54,170 --> 01:01:57,950 if I glitch it this time then the code ends up executing my code – 811 01:01:57,950 --> 01:02:01,610 good enough for me! 812 01:02:01,610 --> 01:02:04,550 Herald: Okay. Thank you, Chris! Please, dear audience, 813 01:02:04,550 --> 01:02:08,100 give an Anniversary Edition applause to Chris Gerlinsky! 814 01:02:08,100 --> 01:02:17,370 *Anniversary Edition applause* 815 01:02:17,370 --> 01:02:37,150 *postroll music* 816 01:02:37,150 --> 01:02:40,550 *subtitles created by c3subtitles.de in the year 2018*