0:00:00.000,0:00:13.580
<i>33C3 preroll music</i>

0:00:13.580,0:00:19.470
Herald: So… coming over to our next talk.

0:00:19.470,0:00:26.320
Tonight, if you switch off[br]your DECT phone, and

0:00:26.320,0:00:29.870
if you’re full of different impressions

0:00:29.870,0:00:35.830
– full of different impressions of this[br]day you maybe want to watch TV.

0:00:35.830,0:00:41.129
But it would be cool to have pay-TV[br]– unencrypted pay-TV.

0:00:41.129,0:00:47.130
So Chris Gerlinsky asks himself the same.[br]And how to achieve unencrypted pay-TV

0:00:47.130,0:00:52.229
– but the Hacker way. So Chris[br]reverse-engineered nothing less

0:00:52.229,0:00:57.659
than the signal and the encryption for[br]a standard that remains unencrypted

0:00:57.659,0:01:05.340
since the late 90s. Please welcome with an[br]Anniversary Edition applause Chris Gerlinsky!

0:01:05.340,0:01:23.650
<i>applause</i>

0:01:23.650,0:01:26.550
Chris Gerlinsky: Hello everyone.[br]My name is Chris Gerlinsky.

0:01:26.550,0:01:30.000
I am a hacker from Canada and I’m here[br]today to talk about how I cracked

0:01:30.000,0:01:35.320
digital cable and satellite TV security.[br]I studied an Access Control Platform (ACP)

0:01:35.320,0:01:40.600
that’s widely used across Canada and the[br]USA. It’s one of the two common platforms

0:01:40.600,0:01:44.310
that’s used in cable TV,[br]and it’s also used in satellite TV

0:01:44.310,0:01:49.560
by one of the two Canadian satellite TV[br]operators. As far as I know the system

0:01:49.560,0:01:54.240
has remained secure since it was[br]introduced in the 1990s and I was curious

0:01:54.240,0:01:57.990
if I could understand the system based on[br]the older set-top-boxes. Some of them

0:01:57.990,0:02:02.641
are 15 years old – and they are still in[br]use. So these devices haven’t received

0:02:02.641,0:02:10.750
upgraded security hardware in that time and[br]I started looking at how the system works.

0:02:10.750,0:02:13.730
Before I get into the reverse engineering[br]I’ll start with a brief description of how

0:02:13.730,0:02:19.110
digital television is sent over satellite[br]or cable. Satellite and cable digital TV

0:02:19.110,0:02:23.860
are pretty similar for the most part. There[br]are a variety of signal modulations used.

0:02:23.860,0:02:30.760
The relevant ones here are QPSK at about[br]27 MBit/s and 8PSK Turbo FEC at about

0:02:30.760,0:02:38.490
38 MBit/s for satellite and QAM256 at about[br]38 MBit/s for cable. There is also an

0:02:38.490,0:02:44.010
out-of-band channel used by cable[br]which is QPSK modulated at 2 MBit/s.

0:02:44.010,0:02:47.180
This out-of-band channel carries the[br]subscription-management, program guide

0:02:47.180,0:02:51.560
information, firmware upgrades, etc. And[br]while you change channels and the cable

0:02:51.560,0:02:55.540
box tunes to different frequencies this[br]out-of-band channel remains tuned

0:02:55.540,0:02:59.150
so that the box continuously receives the[br]state, and no matter what TV channel you’re

0:02:59.150,0:03:03.810
tuned to. In the satellite TV this type of[br]data is included within the main transport

0:03:03.810,0:03:09.480
stream (TS) instead of in a secondary[br]out-of-band TS. The video is sent

0:03:09.480,0:03:16.480
as MPEG2 or H.264 TS. This is a standard[br]format for carrying video streams.

0:03:16.480,0:03:22.340
So it can be played by any hardware video[br]decoder or software decoder, e.g. VLC.

0:03:22.340,0:03:26.670
And the encryption system used here is[br]called DigiCipher 2 (DC2), which does not

0:03:26.670,0:03:33.980
follow the DVB standards that are used[br]in the rest of the world. The MPEG-TS

0:03:33.980,0:03:39.430
is made out of packets of 188 bytes.[br]Each packet has a PID. This is used

0:03:39.430,0:03:45.980
to differentiate different types of data.[br]PIDs range from 0 - 0x1FFF.

0:03:45.980,0:03:49.380
Each PID carries an MPEG Packetized[br]Elementary Stream (PES).

0:03:49.380,0:03:52.959
That’s a video or audio stream.[br]Or the PID may carry one or more

0:03:52.959,0:03:58.540
Service Information Tables. The Service[br]Information Tables have an 8-bit table ID

0:03:58.540,0:04:03.879
and a length of up to 1024 bytes[br]including a CRC32 for error detection

0:04:03.879,0:04:09.261
and this table ID identifies the type of[br]data that you can expect within the table.

0:04:09.261,0:04:13.989
Table 0 is the Program Association Table,[br]containing a list of programs carried

0:04:13.989,0:04:19.298
in this TS and the PMT PID for each[br]program. The Program Association Table

0:04:19.298,0:04:26.370
is always on PID 0. Table 2 is the Program[br]Map Table which contains the list of PES

0:04:26.370,0:04:30.870
and the PID for each as well as an ECM[br]PID. There is Program Map Table

0:04:30.870,0:04:36.080
for each MPEG program or TV channel[br]that’s found in the stream.

0:04:36.080,0:04:40.870
The ECM PID is where ‘Entitlement Control[br]Messages’ are sent containing information

0:04:40.870,0:04:44.909
that’s used to generate the key that[br]decrypts the Packetized Elementary

0:04:44.909,0:04:53.059
Streams. This system uses two types of[br]ECM. Table 40 I call ECM40, and Table 41

0:04:53.059,0:04:59.300
I call ECM41. On PID1 there may be[br]one or more conditional access tables,

0:04:59.300,0:05:05.399
table ID No.1. These tables identify a PID[br]that carries EMMs, ‘Entitlement Management

0:05:05.399,0:05:11.550
Messages’. These messages are used to set[br]access rates for individual set-top-boxes.

0:05:11.550,0:05:14.830
The subscription information, like, what[br]channels are available is carried inside

0:05:14.830,0:05:24.319
of EMMs. This is a hardware interface to[br]receive satellite data, a Genpix SkyWalker-1.

0:05:24.319,0:05:32.330
The DC2 QPSK modulation isn’t widely[br]supported in USB or PCI DVB-S devices.

0:05:32.330,0:05:37.909
And the 8PSK Turbo FEC modulation support[br]is even less common. And one of the devices

0:05:37.909,0:05:41.809
that does support these signals is this[br]Genpix device which is using a Broadcom

0:05:41.809,0:05:50.749
BCM4500 demodulator. And it supports both[br]the DC2-QPSK and the 8PSK modulations.

0:05:50.749,0:05:54.999
It works well, the Linux drivers need to[br]be re-compiled to include the support

0:05:54.999,0:06:00.210
for these modes, and patches for this were[br]published by updatelee. There’s a link

0:06:00.210,0:06:08.199
on the slide. For cable there’s a variety[br]of adapters supporting QAM256 de-modulation.

0:06:08.199,0:06:16.039
I used a USB HVR 950Q tuner. Unfortunately,[br]to tune the out-of-band channel is generally

0:06:16.039,0:06:20.599
not supported by the off-the-shelf[br]interfaces. Inside the cable box

0:06:20.599,0:06:24.699
it’s handled within the integrated chip[br]set. And for the ClearQAM consumer

0:06:24.699,0:06:31.550
devices such as USB interfaces access to[br]the out-of-band data isn’t actually required

0:06:31.550,0:06:34.529
so they don’t include it inside of the[br]hardware. This out-of-band data is used

0:06:34.529,0:06:40.560
only for pay-TV services.

0:06:40.560,0:06:44.439
With the satellite and cable interfaces[br]DVBsnoop can be used to view a lot of

0:06:44.439,0:06:47.469
information about the transport stream.[br]It’s enough information to be

0:06:47.469,0:06:52.389
quite overwhelming. So the trick to using[br]it is being able to sift through the output

0:06:52.389,0:06:57.370
for the relevant information. DVBsnoop[br]also doesn’t recognize all of the

0:06:57.370,0:07:01.749
DigiCipher 2 tables because it’s a non-[br]standard system, and DVBsnoop is targeted

0:07:01.749,0:07:06.159
towards the standard systems. So DVBsnoop[br]may not be able to tell you everything

0:07:06.159,0:07:09.620
about the transport stream but it was[br]still a very useful tool for all the

0:07:09.620,0:07:17.740
information that it can provide.

0:07:17.740,0:07:21.939
DVBsnoop and most other tools and[br]documentation are designed for the DVB

0:07:21.939,0:07:26.689
standard or other recognized standards[br]such as ATSC. DigiCipher cable

0:07:26.689,0:07:29.610
and satellite systems use a lot of[br]non-standard tables to carry

0:07:29.610,0:07:34.089
the system information. For cable TV some[br]of these tables are standardized by

0:07:34.089,0:07:39.909
the document SCTE 65.[br]There is no BAT or SDT

0:07:39.909,0:07:44.000
as you’d expect in DVB. Instead there[br]is a virtual channel table that maps

0:07:44.000,0:07:47.810
the transport streams and programs the[br]channel numbers. The electronic program

0:07:47.810,0:07:52.111
guide is also not DVB standard. So you[br]don’t even get the current and next

0:07:52.111,0:07:57.030
program information in any[br]kind of a standard format.

0:07:57.030,0:08:01.680
Another cable TV adapter is the HDHomeRun[br]Prime. This one is a network-connected

0:08:01.680,0:08:06.729
three-tuner device with cable card[br]support. The set-top-boxes I studied

0:08:06.729,0:08:10.520
pre-date the cable cards. Although the[br]newer boxes do use the cable cards,

0:08:10.520,0:08:14.819
and they support the DigiCipher 2.[br]But cable card support does also mean

0:08:14.819,0:08:20.059
that this HDHomeRun Prime includes the[br]tuner and QPSK demodulator for the

0:08:20.059,0:08:25.879
out-of-band channel. So it is able to pass[br]this data to the cable card, as necessary.

0:08:25.879,0:08:30.279
However, even the HDHomeRun doesn’t[br]make this out-of-band data available

0:08:30.279,0:08:35.339
other than the cable card interface. So[br]to access the demodulated out-of-band data

0:08:35.339,0:08:39.630
I tapped in to the HDHomeRun Prime with[br]a cable card inserted, and connected

0:08:39.630,0:08:46.370
a logic analyzer to the Data and Clock[br]signals. I wrote software using the

0:08:46.370,0:08:52.200
Saleae SDK to capture the QPSK demodulated[br]data. Then, in software, I performed

0:08:52.200,0:08:56.050
de-interleaving, de-randomization,[br]and the forward error correction.

0:08:56.050,0:09:02.160
And the output is an MPEG transport[br]stream. So using an HDHomeRun Prime

0:09:02.160,0:09:06.780
connected to the logic analyzer, connected[br]to the PC running the software

0:09:06.780,0:09:11.340
the output finally is a 2Mbit/s transport[br]stream. And this transport stream

0:09:11.340,0:09:15.070
looks like a standard transport stream,[br]and inside are the conditional access

0:09:15.070,0:09:19.130
management messages, program guide[br]information etc. Everything that was

0:09:19.130,0:09:26.410
missing from the main[br]QAM transport stream.

0:09:26.410,0:09:33.470
Two bits in each packet will indicate if[br]the packet is scrambled with the even key,

0:09:33.470,0:09:38.820
odd key, or not scrambled at all.[br]The key is changed at short intervals.

0:09:38.820,0:09:45.150
DVB systems typically will change every[br]5 .. 30 seconds. DC2 every 133 ms

0:09:45.150,0:09:50.830
or 1 second. The key used for decryption[br]alternates between even and odd.

0:09:50.830,0:09:54.110
The odd key is in use while the even key[br]is updated; and then the even key is

0:09:54.110,0:09:58.720
in use while the odd key is updated.[br]An encrypted transport stream is sent

0:09:58.720,0:10:03.550
via the cable or satellite, and it’s passed[br]through the descrambler in the ACP.

0:10:03.550,0:10:08.360
And the result is a decrypted transport[br]stream that is played by the MPEG decoder.

0:10:08.360,0:10:12.920
The descrambler uses a Working Key.[br]This is a 56-bit DES key that changes

0:10:12.920,0:10:19.610
every 133ms, or in some cases they have it[br]slowed down to changing every 1 second.

0:10:19.610,0:10:24.060
This Working Key is generated by[br]encrypting the frame count from ECM40

0:10:24.060,0:10:29.750
packets with the Program Key. The Program[br]Key, again DES, comes from the ECM41

0:10:29.750,0:10:33.730
message, and is encrypted with the[br]Category Key. The Program Key

0:10:33.730,0:10:38.630
is unique to each channel, and it changes[br]daily or for every pay-per-view event.

0:10:38.630,0:10:43.790
The Category Key, also DES, is shared[br]by all the set-top-boxes that authorize

0:10:43.790,0:10:48.370
for any channel from this provider. The[br]Category Key is sent to each set-top-box,

0:10:48.370,0:10:53.950
individually, inside the EMM95 message.[br]And this Category Key typically changes

0:10:53.950,0:10:58.430
monthly, but many cable operators change[br]keys much less frequently. Some of them

0:10:58.430,0:11:04.210
are using the same key for years at[br]a time. To decrypt the EMM, in order

0:11:04.210,0:11:09.270
to get the Category Key Seed Keys are[br]used. Each set-top-box has a set of

0:11:09.270,0:11:13.540
56 bit DES Seed Keys inside of[br]battery-backed RAM. These are

0:11:13.540,0:11:17.780
initialized during manufacturing. For the[br]lifetime of the set-top-box these keys

0:11:17.780,0:11:23.070
are used to secure EMMs. So this[br]forms a chain from the Seed Keys,

0:11:23.070,0:11:26.850
initialized during manufacturing and never[br]changing, to the decryption of the MPEG

0:11:26.850,0:11:31.550
transport stream.

0:11:31.550,0:11:34.710
Inside the satellite[br]set-top-box we can see the main

0:11:34.710,0:11:38.060
components of the system. The signal[br]enters the tuner and is passed

0:11:38.060,0:11:41.440
through the demodulator which[br]outputs a serial transport stream.

0:11:41.440,0:11:46.000
This transport stream passes through[br]the ACP – Access Control Processor –

0:11:46.000,0:11:51.120
and is then sent to the MPEG decoder[br]to output a video signal to the TV.

0:11:51.120,0:11:55.800
A 68k microcontroller acts as the set-top[br]box main controller. It communicates

0:11:55.800,0:12:00.340
with the MPEG decoder as well as[br]with the ACP via an SPI bus.

0:12:00.340,0:12:03.880
A battery provides backup power to the[br]ACP. So it will retain RAM contents

0:12:03.880,0:12:08.810
even when the set-top-box is unplugged.[br]There’s a TVpass slot near the power

0:12:08.810,0:12:12.110
supply. This is an upgrade slot with[br]a card edge connector to allow

0:12:12.110,0:12:14.830
for security upgrades. The system

0:12:14.830,0:12:19.400
stayed secure, so the TVpass slot was[br]never used. And the newer set-top-boxes

0:12:19.400,0:12:23.930
don’t actually include a TVpass slot[br]inside. So at this point it seems

0:12:23.930,0:12:30.710
quite unlikely that this TVpass card[br]will ever actually be used.

0:12:30.710,0:12:34.630
Inside the cable set-top-box… it’s[br]very similar to a satellite set-top-box

0:12:34.630,0:12:38.840
but the cable boxes tend to be more[br]tightly integrated. The signal enters

0:12:38.840,0:12:42.740
the tuner and passes through a Broadcom[br]chip that handles demodulation.

0:12:42.740,0:12:46.260
And the same chip will also handle MPEG[br]decoding after the transport stream’s been

0:12:46.260,0:12:52.400
decrypted by the ACP. A 68k microcontroller[br]acts as the set-top-box’s main controller.

0:12:52.400,0:12:57.490
Again, talking to the ACP via SPI.[br]And a battery provides backup power

0:12:57.490,0:13:03.070
to the ACP, and also to the non-volatile[br]RAM used by the main controller.

0:13:03.070,0:13:08.500
A TVpass slot is underneath the main[br]board, it’s not visible in this photo.

0:13:08.500,0:13:11.370
The cable set-top-boxes include a second[br]tuner that’s used to receive

0:13:11.370,0:13:15.810
the out-of-band data. This OOB tuner[br]operates independently of the main tuner

0:13:15.810,0:13:20.081
and on a separate frequency range. And[br]it’s used to provide a transport stream

0:13:20.081,0:13:23.450
containing the system information, with[br]the program guide, firmware updates,

0:13:23.450,0:13:28.630
EMMs etc.

0:13:28.630,0:13:35.110
Here we see the ACP chip. It’s a 100-pin[br]TQFP package. From the markings

0:13:35.110,0:13:39.920
we can see it’s a custom System-On-Chip[br]made for General Instrument Corp. (GIC).

0:13:39.920,0:13:43.470
All the decryption is performed by the[br]ACP, and all decryption keys are kept

0:13:43.470,0:13:49.600
only within this chip. The newer set-top-[br]boxes use newer versions of the ACP.

0:13:49.600,0:13:53.850
I studied the original ACP chip[br]that’s seen in this photo.

0:13:53.850,0:13:57.250
As long as the set-top-boxes using this[br]chip are actively used it remains

0:13:57.250,0:14:02.740
a relevant target. Whether the newer ACPs[br]include more advanced security features

0:14:02.740,0:14:07.310
or if they exist only for cost-savings[br]due to shrinking the die size

0:14:07.310,0:14:12.720
I don’t really know.

0:14:12.720,0:14:16.480
Some of the interesting pins on the ACP[br]are labeled here. Pin 1 is marked

0:14:16.480,0:14:20.160
at the top left corner of the chip.[br]There’s an SPI slave controller

0:14:20.160,0:14:24.170
on Pins 1 - 5, used for communication[br]with the set-top-box main controller.

0:14:24.170,0:14:28.140
There’s a battery backup pin that’s[br]connected to a 3V battery to keep

0:14:28.140,0:14:33.050
the RAM contents of the ACP intact[br]at all times. There’s a serial transport

0:14:33.050,0:14:38.240
stream input on pins 88 - 92 which[br]receives the data from the demodulator.

0:14:38.240,0:14:42.490
And there’s a serial transport stream[br]output on pins 28 - 33 which sends

0:14:42.490,0:14:52.180
the decrypted transport stream to the[br]MPEG decoder to be output to the TV.

0:14:52.180,0:14:56.460
At one point I had written software for[br]an AVR32 device, not the one that’s

0:14:56.460,0:15:00.240
shown here, that has a synchronous serial[br]peripheral, that supports sending and

0:15:00.240,0:15:04.920
receiving data at the 27 MBit/s rate of the[br]transport stream. My AVR32 implementation

0:15:04.920,0:15:10.690
turned out a bit ugly. But rather than[br]cleaning up I was able to use it as it was.

0:15:10.690,0:15:16.060
It had some limitations like only accepting[br]64kB of data for replay logging.

0:15:16.060,0:15:20.120
Which was just barely good enough for my[br]studies. What the transport stream

0:15:20.120,0:15:22.000
logging in-circuit digital mean was

0:15:22.000,0:15:27.320
that the transport stream passes through[br]the ACP with selected PIDs being decrypted.

0:15:27.320,0:15:31.410
And then the output is the full transport[br]stream but a selected program has been

0:15:31.410,0:15:37.420
decrypted. The AVR32 logging interface[br]had rather limited use for me.

0:15:37.420,0:15:42.710
Later on when I did more thorough research[br]I did so using an ACP that I’d removed from

0:15:42.710,0:15:46.680
the box and I put on a breakout board.[br]And then I could control the clock, and

0:15:46.680,0:15:50.860
at that point it was much easier to use an[br]XMEGA AVR platform to send and receive

0:15:50.860,0:15:55.490
the transport stream through the ACP[br]at a much slower bit rate. Shown here

0:15:55.490,0:15:57.250
is the XMEGA platform I settled on using

0:15:57.250,0:16:03.510
for SPI and also the transport stream[br]interfacing. To honor the data

0:16:03.510,0:16:08.100
passed between the set-top-box main[br]controller and the ACP on the SPI bus

0:16:08.100,0:16:15.220
I used the XMEGA development board. Two[br]SPI ports acted as slave with Master Out -

0:16:15.220,0:16:18.951
Slave In (MOSI) signal connected to 1 and[br]Master In - Slave Out (MISO) signal

0:16:18.951,0:16:23.779
connected to the Master Out - Slave In[br]input of the second port. So from one port

0:16:23.779,0:16:26.280
Bytes sent by the set-top-box[br]controller are received.

0:16:26.280,0:16:28.000
From the other port it receives

0:16:28.000,0:16:33.490
bytes from the ACP. In case I want to talk[br]directly to the ACP or the set-top-box

0:16:33.490,0:16:37.730
main controller it’s only necessary to[br]connect both the MOSI and MISO signals

0:16:37.730,0:16:43.410
on one of the SPI interfaces. By holding[br]the main controller in Reset my XMEGA

0:16:43.410,0:16:48.540
was able to act as the SPI Master and then[br]talk to the ACP. So this setup works for

0:16:48.540,0:16:52.550
passively monitoring the SPI communications[br]in the set-top-box and can also act as

0:16:52.550,0:16:59.530
the SPI Master for interrogating the chip[br]directly.

0:16:59.530,0:17:01.360
By logging the SPI bus between

0:17:01.360,0:17:05.240
the main controller and the ACP we see[br]that information about the current access

0:17:05.240,0:17:12.149
levels are sent from the ACP. The ACP[br]also receives EMMs via the SPI bus.

0:17:12.149,0:17:16.970
EMMs have been filtered by the Unit Address[br]number, or the set-top-box serial number.

0:17:16.970,0:17:22.519
So the ACP only receives messages[br]that are intended for that specific unit.

0:17:22.519,0:17:26.329
Command 04 includes the current Category[br]Key epochs and Keyselects in use.

0:17:26.329,0:17:31.639
Command 05 includes the Unit Address[br]number. Command 13 returns the authorized

0:17:31.639,0:17:37.340
Subscription tiers for this unit. Commands 7[br]and 87 provide information about the channel

0:17:37.340,0:17:43.321
being currently decrypted. Additionally,[br]via the SPI interface the set-top-box

0:17:43.321,0:17:49.050
main controller tells the ACP which PIDs[br]to decrypt and which is the ECM PID.

0:17:49.050,0:17:53.440
The ACP doesn’t send any keys on the bus,[br]and it only receives Category Keys that

0:17:53.440,0:17:58.070
are encrypted within EMMs via the SPI.[br]So all of the really interesting data is

0:17:58.070,0:18:06.340
contained within the ACP chip itself, and[br]it’s never sent out on any kind of a bus.

0:18:06.340,0:18:10.299
So next I started an invasive study of the[br]chip – studying it under a microscope.

0:18:10.299,0:18:13.940
And the cost of microscopes can range from[br]hundreds of Dollars to tens of thousands

0:18:13.940,0:18:18.150
of Dollars, or even higher for things like[br]electron microscopes or other specialized

0:18:18.150,0:18:23.830
equipment. I have a couple of microscopes[br]that I use. This one is a Mitutoyo FS70

0:18:23.830,0:18:27.990
microscope. These Mitutoyo are often used[br]for microprobing, but you can also use it

0:18:27.990,0:18:33.049
for other uses. For this project I didn’t[br]do any microprobing but I used this

0:18:33.049,0:18:37.470
microscope because it was what I had. For[br]studying this kind of technology you could

0:18:37.470,0:18:40.700
use even more basic equipment but,[br]of course, if you have the higher-end

0:18:40.700,0:18:44.720
equipment it’s a lot nicer to work with.

0:18:44.720,0:18:48.549
Another microscope I use is the Zeiss[br]Axiotron. This microscope is designed

0:18:48.549,0:18:53.679
for inspecting wafers and has really good[br]optical quality. I said that more basic

0:18:53.679,0:18:56.960
equipment could be used and it’s true.[br]But when you get into this kind of thing

0:18:56.960,0:19:00.579
you might find yourself again and again[br]investing in more equipment.

0:19:00.579,0:19:04.279
I've owed $10.000 in this setup including[br]the microscope and the camera and the

0:19:04.279,0:19:12.289
scanning stage and other parts. To look at[br]the chip under the microscope requires

0:19:12.289,0:19:16.650
that the chip is de-capsulated.[br]Fuming Nitric Acid is used for this.

0:19:16.650,0:19:21.190
The chip is immersed in heated red Fuming[br]Nitric Acid which reacts with the plastic

0:19:21.190,0:19:26.220
packaging and removes it. The chip is then[br]rinsed in acetone, and cleaned with

0:19:26.220,0:19:31.540
isopropyl alcohol in an ultrasonic bath[br]which leaves the die bare and clean.

0:19:31.540,0:19:35.470
The Nitric Acid is quite aggressive,[br]and it’s important to handle it carefully.

0:19:35.470,0:19:39.190
But the process is really straight-forward.[br]Most people probably wouldn’t want

0:19:39.190,0:19:40.569
to do this in their home.

0:19:40.569,0:19:47.489
So you should go out to the garage[br]and use your fume hood there.

0:19:47.489,0:19:50.989
After the decapsulation the bare[br]chips are left with bonding wires attached

0:19:50.989,0:19:53.660
to them. So these wires will be plucked[br]off using tweezers to get them

0:19:53.660,0:19:58.600
out of the way. Already in this photo we[br]can see some of the larger structures

0:19:58.600,0:20:02.059
on the chip. Half of it is covered with[br]a metal plane, and the other half

0:20:02.059,0:20:09.509
shows some kind of visible circuitry.

0:20:09.509,0:20:12.520
This is an image of the chip under the[br]microscope. It’s been stitched together

0:20:12.520,0:20:16.789
from several smaller images,[br]to give an overview of the chip.

0:20:16.789,0:20:21.259
Looking at the decapsulated chip we see[br]the bond pads around the outside,

0:20:21.259,0:20:25.450
a metal plane covering the top part of the[br]chip and wires on the bottom of the chip,

0:20:25.450,0:20:29.679
the spaghetti logic running all ov er the[br]place. With a couple of structures

0:20:29.679,0:20:33.630
that look like they could be a type of[br]memory. There’s a lot still hidden

0:20:33.630,0:20:40.120
from us. To see more of the chip[br]it will be necessary to delayer it.

0:20:40.120,0:20:45.059
To delayer the chip I used hydrofluoric acid[br]to perform a wet etch. I used the Whink

0:20:45.059,0:20:49.600
Rust Stain Remover product. It’s available[br]in hardware stores all over the USA.

0:20:49.600,0:20:55.100
It’s a dilute HF solution that works[br]really well for delayering ICs.

0:20:55.100,0:20:59.230
I put a small amount of the Whink liquid in[br]a beaker and heated it on the hot plate.

0:20:59.230,0:21:03.259
Then I dropped the decapsulated die in.[br]Using a pipette I agitated the liquid

0:21:03.259,0:21:07.420
to disturb the bubbles that form on the[br]surface of the chip. So the acid can

0:21:07.420,0:21:12.110
actually chip more evenly. The etching[br]result isn’t perfect. Some parts of the chip

0:21:12.110,0:21:15.049
will be etched deeper than other parts.[br]But I’ve gotten quite useful results using

0:21:15.049,0:21:19.409
this technique. You really don’t wanna[br]breathe in these fumes, so do this

0:21:19.409,0:21:25.889
in a fume hood in your garage, also.

0:21:25.889,0:21:29.029
After a short time immersed in the heated[br]Whink solution the chip was rinsed and

0:21:29.029,0:21:32.730
put back under the microscope.[br]Now the top metal plane has been removed

0:21:32.730,0:21:37.490
so we can see what’s below. There are[br]some visual effects that we start to see

0:21:37.490,0:21:40.749
in the photo from the etching being[br]a little bit uneven. But overall

0:21:40.749,0:21:46.419
the delayered chip looks quite good and[br]able to start studying it. At the top left

0:21:46.419,0:21:51.119
the tall rectangles are RAM. The four[br]blocks at the top right are ROM.

0:21:51.119,0:21:56.630
And then there’s logic that tie[br]these into the logic area below.

0:21:56.630,0:22:01.039
I was interested in finding how the bits[br]were encoded in ROM. So I continued

0:22:01.039,0:22:04.289
delayering the chip. This was another dip[br]in the Whink – and another metal layer

0:22:04.289,0:22:07.990
has been removed. Bits in the ROM[br]were not visible yet so I continued

0:22:07.990,0:22:11.830
the delayering process. At this point[br]we’re starting to see more of the visual

0:22:11.830,0:22:19.700
effects from the uneven etching but[br]it’s still not too bad. After a third dip

0:22:19.700,0:22:23.299
in the Whink more metal has been removed.[br]At this point the delayering is becoming

0:22:23.299,0:22:26.820
more and more uneven. We can see the[br]ROM blocks have been half-etched

0:22:26.820,0:22:31.899
to a lower layer while half of the upper[br]layer is still remaining. The wet etching

0:22:31.899,0:22:36.940
process can be quite difficult to perform[br]completely consistently without adding

0:22:36.940,0:22:40.899
additional steps such as polishing. And[br]at the time I did this project I didn’t have

0:22:40.899,0:22:45.409
the polisher available so I was relying[br]only on the wet etch. Some of the areas

0:22:45.409,0:22:48.879
of the ROM are now showing visible bits.[br]The other areas haven’t been etched

0:22:48.879,0:22:55.249
deeply enough. So I continued to etch[br]further to try and get a clean ROM.

0:22:55.249,0:22:59.179
We can see the ROM bits quite clearly now.[br]They’re arranged in rows and columns, and

0:22:59.179,0:23:04.679
in this image if a black dot is visible[br]that indicates that the bit is a One.

0:23:04.679,0:23:07.889
Image quality is important. The better the[br]photographs the more consistently the bits

0:23:07.889,0:23:12.039
will be visible. But it doesn’t have to be[br]really perfect. You can do some image

0:23:12.039,0:23:16.789
processing on it, you can even repeat the[br]process on multiple chips, delayer them

0:23:16.789,0:23:20.710
and photograph them, and at some point[br]you’ll be able to have the entire ROM

0:23:20.710,0:23:26.279
clean and consistently visible. With the[br]visible bits exposed and photographs taken

0:23:26.279,0:23:30.860
the bits can be extracted using a software[br]image analysis tool. Or the bits could be

0:23:30.860,0:23:37.559
extracted manually. The ROM here is 32 kB[br]or over 260.000 bits. So manual extraction

0:23:37.559,0:23:43.630
would be a bit labor-intensive but it[br]isn’t impossible. A software tool is

0:23:43.630,0:23:48.909
more efficient. So I wrote some software[br]to analyze the images and identify

0:23:48.909,0:23:53.640
the 1 and 0 bits. There are bits marked[br]with a yellow box for 0 bits or a blue box

0:23:53.640,0:23:57.640
for 1 bits. I use a software to analyze[br]the image and then I can quickly review

0:23:57.640,0:24:04.980
the results manually, and identify any[br]errors that I can see. After extracting

0:24:04.980,0:24:08.500
the bits from the photographs I have[br]a binary version of the ROM data.

0:24:08.500,0:24:12.289
This is a visual representation of the[br]bits extracted from this piece of ROM.

0:24:12.289,0:24:18.679
Little black boxes signify 1 bits,[br]and the white boxes signify 0 bits.

0:24:18.679,0:24:23.539
In this image I’ve overlayed the extracted[br]bottom 13 rows of bits over the photograph.

0:24:23.539,0:24:27.340
You can see some visual patterns inside[br]this, also. And these visual patterns

0:24:27.340,0:24:33.799
are a good indicator that this ROM[br]is probably not scrambled.

0:24:33.799,0:24:37.519
This image shows the end of the ROM where[br]you can see a pattern covering most of

0:24:37.519,0:24:41.769
the image due to a repeated pattern of[br]filler bytes that occupy unused space

0:24:41.769,0:24:47.049
at the end of the ROM. At the very end of[br]ROM the pattern is interrupted. This is

0:24:47.049,0:24:50.370
where the vectors table exists at the top[br]end of memory indicating the reset address

0:24:50.370,0:24:54.950
and the addresses of interrupt handlers.[br]The ROM has unused space, the filler bytes

0:24:54.950,0:25:01.929
at the end. And the vectors table[br]address is 0xFFF6 through 0xFFFF.

0:25:01.929,0:25:06.289
After extracting the bits and decoding them[br]into bytes the hex dump can be studied.

0:25:06.289,0:25:11.899
There is a “Copyright 1997 CHCC” ASCII[br]string in ROM which is helpful to identify

0:25:11.899,0:25:15.139
when the ROM has been decoded correctly.[br]<i>laughter</i>

0:25:15.139,0:25:18.999
If you can read the ASCII text then[br]surely the bits are in the correct order.

0:25:18.999,0:25:22.759
The decoding in this case was just a matter[br]of organizing the bits into bytes, it’s quite

0:25:22.759,0:25:29.100
straightforward, there was no scrambling[br]or anything else that was complex.

0:25:29.100,0:25:32.549
With the ROM contents extracted the[br]software can be disassembled and analyzed.

0:25:32.549,0:25:37.200
The first step was to identify the CPU[br]architecture. Studying the binary dump

0:25:37.200,0:25:40.960
it appeared to be an 8-bit CPU[br]but wasn’t 8051 or 6805

0:25:40.960,0:25:46.019
or any of the processor types I tried[br]first. Eventually, I tried disassembling

0:25:46.019,0:25:50.429
it 6502 and the code made sense. Later[br]I had remembered that I had looked at

0:25:50.429,0:25:53.990
a previous version of the Access[br]Controller from the same manufacturer.

0:25:53.990,0:25:58.830
Which was used in another system,[br]VideoCipher 2+, an ancestor of DigiCipher.

0:25:58.830,0:26:05.249
On the older chip was a Copyright notice[br]from WDC who licenses the 6502 core IP.

0:26:05.249,0:26:09.270
It was visible directly on the chip die[br]under the microscope.

0:26:09.270,0:26:12.240
So this would have been a great clue[br]for the CPU architecture if I had actually

0:26:12.240,0:26:18.179
noticed it earlier. For disassembly I used[br]IDA. It supports 6502 and is of course

0:26:18.179,0:26:25.510
a very powerful disassembler. In addition[br]to disassembly I used 6502 simulation

0:26:25.510,0:26:29.799
software to study the software in[br]a virtual CPU. The simulation is really

0:26:29.799,0:26:33.289
helpful when disassembling the software.[br]It provides a lot of insight into what’s

0:26:33.289,0:26:38.269
going on. Since 6502 is a very well-known[br]architecture it was not at all difficult

0:26:38.269,0:26:43.409
to find an existing simulator. Even free,[br]with source code. The 6502 is used

0:26:43.409,0:26:47.850
in 8-bit computers, like the Apple II,[br]in Commodore 64. So there’s really

0:26:47.850,0:26:51.700
a lot of enthusiasts and a great deal of[br]information about this architecture.

0:26:51.700,0:26:55.369
As I gained understanding of the System[br]On Chip through disassembling the software

0:26:55.369,0:26:59.330
I began adding some other features into[br]the simulator to emulate some of the

0:26:59.330,0:27:08.779
hardware peripherals that were found[br]inside the ACP, the device itself.

0:27:08.779,0:27:11.282
One of the first things I saw in the[br]disassembly was that there are two

0:27:11.282,0:27:15.779
operating modes. During startup values[br]in RAM are checked. And if the ACP

0:27:15.779,0:27:18.649
hasn’t been initialized it enters[br]a personalization mode used during

0:27:18.649,0:27:23.390
manufacturing to assign the Unit Address[br]and Seed keys. In normal conditions,

0:27:23.390,0:27:26.509
after the set-top-box has left the[br]factory this personalization software

0:27:26.509,0:27:32.459
is bypassed and the ACP will always run[br]its main application. The next thing

0:27:32.459,0:27:36.830
I found was the application wasn’t very[br]simple. This 6502 actually runs

0:27:36.830,0:27:41.169
a task switching operating system. Eight[br]tasks are run supporting decryption

0:27:41.169,0:27:45.690
of up to two channels at the same time.[br]There are two tasks to handle processing

0:27:45.690,0:27:50.330
of ECM40 messages and generation of the[br]Working Keys used to decrypt the transport

0:27:50.330,0:27:55.200
stream. And two tasks to handle processing[br]of ECM41 messages to generate

0:27:55.200,0:28:00.749
the Program Keys that are used to process[br]the ECM40. One task for handling

0:28:00.749,0:28:05.190
EMM processing. And there’s also a task to[br]communicate with the TVpass interface

0:28:05.190,0:28:09.710
for security upgrades. With another task[br]to handle the messages that are coming in

0:28:09.710,0:28:17.090
over the SPI interface. Since the ACP[br]is a custom System On Chip

0:28:17.090,0:28:21.320
there is no documentation available[br]describing the hardware capabilities.

0:28:21.320,0:28:24.629
So the disassembly was studied and the[br]input/output registers had to be guessed

0:28:24.629,0:28:29.649
based on the software usage. There’s an[br]SPI slave peripheral for communication

0:28:29.649,0:28:33.690
with the main controller. The SPI[br]peripheral sends and receives data

0:28:33.690,0:28:37.330
directly to RAM. And then a signal is set[br]indicating that the transport has been

0:28:37.330,0:28:41.350
completed. There’s a DES crypto peripheral;

0:28:41.350,0:28:45.980
key, data and operating mode are set in[br]registers. And when the decryption

0:28:45.980,0:28:50.029
has been completed the result can be[br]read from additional registers. There’s

0:28:50.029,0:28:54.269
a transport stream descrambler. The Working[br]Key is set in hardware registers.

0:28:54.269,0:28:57.590
And the descrambler will then output the[br]decrypted transport stream on the serial

0:28:57.590,0:29:03.389
transport stream interface. There are PID[br]filters set by the set-top-box main

0:29:03.389,0:29:07.850
controller over the SPI bus. These filters[br]select which video and audio streams

0:29:07.850,0:29:15.309
to descramble and which ECM packets should[br]be received by the ACP. The received ECMs

0:29:15.309,0:29:23.229
are placed in RAM, and the 6502 is notified[br]of a new ECM via a register bit.

0:29:23.229,0:29:26.049
So at this point I’m starting to get an[br]idea of how the system works.

0:29:26.049,0:29:29.859
I have studied the MPEG transport stream[br]and logged ECM and EMM data.

0:29:29.859,0:29:33.940
I’ve logged the SPI bus, and understand[br]messages between the set-top-box

0:29:33.940,0:29:38.740
main controller and the ACP. I was able to[br]extract the entire ROM contents optically.

0:29:38.740,0:29:43.559
And I’ve disassembled the software and run[br]it in simulation. There are some keys

0:29:43.559,0:29:47.539
that are found in ROM. Fixed keys which[br]never change and are used when a channel

0:29:47.539,0:29:51.999
has a “free preview weekend” or something[br]of the sort. Any set-top-box that has ever

0:29:51.999,0:29:55.809
had any kind of authorization in the past[br]is allowed to decrypt channels that are

0:29:55.809,0:30:01.409
encrypted using the “fixed key” mode. So[br]now the focus is on understanding the ECM

0:30:01.409,0:30:05.869
and EMM algorithms within the ROM[br]software. At this point I’m still missing

0:30:05.869,0:30:10.669
some important information from the ACP.[br]All the Seed Keys, Category Keys and

0:30:10.669,0:30:14.769
Program Keys exist only within RAM.[br]So to decrypt any of the channels

0:30:14.769,0:30:21.960
not in free preview isn’t possible yet at[br]this point. The ECM40 message

0:30:21.960,0:30:26.049
is used to generate the Working Key, used[br]to descramble the MPEG streams.

0:30:26.049,0:30:30.080
There’s a Service ID, used to identify[br]each channel, and a frame count

0:30:30.080,0:30:33.770
that’s used with the Program Key[br]to calculate the Working Key.

0:30:33.770,0:30:37.840
The crypt mode identifies if the channels[br]are operating unencrypted, with a fixed

0:30:37.840,0:30:41.450
key, or with the normal secure keys[br]which are typically used.

0:30:41.450,0:30:45.899
The frame count is simply a 24 bit counter[br]that increments each time the Working Key

0:30:45.899,0:30:51.090
changes. There’s a byte I’ve labeled[br]‘Hardware’ that has one bit set in it.

0:30:51.090,0:30:57.029
This selects a special decryption mode[br]that I’ll come back to a little bit later.

0:30:57.029,0:31:03.890
The ECM41 contains encrypted Program Key[br]that’s needed to correctly decrypt the ECM40.

0:31:03.890,0:31:08.690
There’s a Provider ID that indicates which[br]TV operator subscribers this ECM should

0:31:08.690,0:31:12.739
be processed by. And there’s the same[br]Service ID that will be found within

0:31:12.739,0:31:19.190
the ECM40 messages. The Category epoch[br]identifies which Category Key is in use.

0:31:19.190,0:31:23.369
There’s also information about how long[br]this Program Key will be valid for.

0:31:23.369,0:31:27.739
ECM41 contains one or more subscription[br]tiers that must be found within

0:31:27.739,0:31:32.359
the customer’s ACP to allow this message[br]to be processed. The subscription tiers

0:31:32.359,0:31:37.340
are written to the ACP when the EMM[br]containing authorization details is received.

0:31:37.340,0:31:44.340
There is, again, a hardware crypto select[br]byte that I will get back to.

0:31:44.340,0:31:48.729
This slide shows what a half of a second[br]of ECM40 and ECM41 activity might

0:31:48.729,0:31:53.879
look like. To be able to descramble the[br]program the ACP must process a current

0:31:53.879,0:31:59.409
ECM41 to get the Program Key and then[br]process an ECM40 to get the Working Key.

0:31:59.409,0:32:04.100
The Working Key is then used by the[br]descrambler to decrypt MPEG stream.

0:32:04.100,0:32:08.900
Until the ACP receives the ECM41 with the[br]current key as well as an ECM40 with

0:32:08.900,0:32:14.119
the frame count it’s not yet possible[br]to decrypt the transport stream.

0:32:14.119,0:32:20.419
The Working Keys have a short life time,[br]only 133 ms. The series of ECMs shown here

0:32:20.419,0:32:25.950
all would happen within a period of a half[br]of a second.

0:32:25.950,0:32:27.460
The EMMs are split into

0:32:27.460,0:32:31.910
four parts. Each part contains a portion[br]of the subscription information for this

0:32:31.910,0:32:36.650
set-top-box. A Category Key is calculated[br]from each of the four parts and the key

0:32:36.650,0:32:40.370
that is calculated for each part has to[br]match the others, or the EMM will be

0:32:40.370,0:32:46.190
rejected, and all authorization in Category[br]Key will be wiped from this ACP.

0:32:46.190,0:32:51.309
When the first EMM, part Zero, is received[br]the authorization data inside the ACP

0:32:51.309,0:32:54.590
is reset and will be replaced with[br]authorization data from the EMM.

0:32:54.590,0:33:00.009
When the next part, part One, is received[br]the existing authorization data within

0:33:00.009,0:33:05.700
the ACP from part Zero is hashed along[br]with the data in part One. If the result

0:33:05.700,0:33:09.049
is correct then the authorization from[br]part One is copied into the ACP

0:33:09.049,0:33:13.309
alongside the existing data from part[br]Zero. If the result is incorrect then

0:33:13.309,0:33:19.629
the ACP’s authorization is erased. In this[br]way the four EMM messages are linked

0:33:19.629,0:33:22.570
together, and if anything is modified[br]within any of the EMM messages

0:33:22.570,0:33:26.450
the authorization will fail.

0:33:26.450,0:33:31.220
This is an example of an EMM. Each of the[br]four EMM parts contains some common

0:33:31.220,0:33:35.000
information, like the Unit Address, and[br]which Category epoch this EMM contains

0:33:35.000,0:33:41.090
information for. The EMM can contain two[br]Category Keys. One for the current epoch

0:33:41.090,0:33:45.379
and also for the next so that when there’s[br]the change of the Category Key the ACP

0:33:45.379,0:33:51.460
already has the next key available.[br]To decrypt the Category Key from the EMM

0:33:51.460,0:33:57.359
the Seed Keys contained in the ACP are[br]used. The Seed Keys are unique to each ACP

0:33:57.359,0:34:01.479
and are assigned during manufacturing.[br]EMMs are transmitted out-of-band

0:34:01.479,0:34:04.899
for cable systems but they’re passed to[br]the ACP in the same way as for satellite

0:34:04.899,0:34:08.480
systems. So at the ACP level, there’s no[br]difference between the satellite and

0:34:08.480,0:34:12.790
the cable systems.

0:34:12.790,0:34:15.179
At this point it should be possible to[br]decrypt channels that are using

0:34:15.179,0:34:19.060
a fixed-key mode. Analysis of the ROM[br]has shown the algorithms used to process

0:34:19.060,0:34:21.530
the ECMs and generate the Working Key.

0:34:21.530,0:34:25.750
The fixed keys are known because they’re[br]contained in ROM. There could have been

0:34:25.750,0:34:29.800
some question about the possibility of[br]bit errors from the optical ROM extraction

0:34:29.800,0:34:33.370
process. But the fixed keys can be[br]confirmed as correct because the ROM

0:34:33.370,0:34:38.100
software performs a checksum of this[br]256 byte area that contains the keys.

0:34:38.100,0:34:41.100
Successfully running the checksum on[br]the extracted ROM data indicates that

0:34:41.100,0:34:45.889
the extracted keys seem to be correct.[br]But when I attempted to decrypt

0:34:45.889,0:34:50.040
a fixed-key channel there was[br]a problem, it did not work.

0:34:50.040,0:34:52.300
Whether it was a bug in my decryption[br]implementation or something else

0:34:52.300,0:34:57.670
was unclear. However, I had noticed the[br]bit in ECM40 was set that causes a bit

0:34:57.670,0:35:02.760
within the ACP hardware peripherals to be[br]set. The purpose of the bit was unclear.

0:35:02.760,0:35:06.990
But its address was suspiciously close to[br]the transport stream descrambler key.

0:35:06.990,0:35:09.660
So I started to suspect that there might[br]be some encryption other than just

0:35:09.660,0:35:12.170
standard DES.

0:35:12.170,0:35:18.070
To be able to learn more about the ACP[br]I started to look at glitchers.

0:35:18.070,0:35:21.120
If I can succeed to glitch the chip I may[br]be able to find a way to read and even

0:35:21.120,0:35:25.740
write memory. And possibly a way to run[br]my own software directly on the chip.

0:35:25.740,0:35:28.290
This will allow me to control the hardware[br]peripherals and be able to observe

0:35:28.290,0:35:33.870
the chip’s operation under different[br]conditions. Timing tests of the ACP

0:35:33.870,0:35:38.050
suggest that the 6502 is running from an[br]internal clock source. So this will allow

0:35:38.050,0:35:42.680
a clock glitch attack. A VCC glitch makes[br]sense, and with the age of this chip

0:35:42.680,0:35:46.370
it seemed reasonable to expect that it[br]would be susceptible to VCC glitches.

0:35:46.370,0:35:50.830
The stronger protections against this[br]type of attack are relatively recent.

0:35:50.830,0:35:55.470
My glitcher design is quite simple. It’s[br]based on an XMEGA development board

0:35:55.470,0:35:59.820
and breadboard. I use the XMEGA to[br]communicate with the ACP over SPI

0:35:59.820,0:36:05.020
and to control the glitch. A 74xx series[br]4053 analog switch is used to quickly

0:36:05.020,0:36:11.120
switch the ACP VCC between two voltages,[br]a normal operating voltage, and a lower

0:36:11.120,0:36:17.060
glitch voltage. I use a bench top DC power[br]supply and two outputs so I can easily

0:36:17.060,0:36:22.740
adjust both the normal VCC and glitch VCC[br]levels. Other parts on the breadboard

0:36:22.740,0:36:26.750
are an oscillator to provide some clock[br]inputs necessary for the ACP to operate

0:36:26.750,0:36:32.430
and an inverter and NAND gate to cut out[br]the clock during the time of the glitch.

0:36:32.430,0:36:36.020
To simplify the test setup as much as[br]possible the ACP was removed from

0:36:36.020,0:36:39.640
the set-top-box and soldered to[br]a break-out board. In this process

0:36:39.640,0:36:42.700
the battery-backed RAM was disconnected[br]and all the keys were lost.

0:36:42.700,0:36:47.580
But for the purpose of developing a[br]working glitch this was okay. The simple,

0:36:47.580,0:36:49.910
breadboard-based glitcher is quite[br]flexible. The breadboard can be modified

0:36:49.910,0:36:54.570
to test different ideas, and reconfigured[br]quickly. More complex and advanced

0:36:54.570,0:36:59.320
glitcher wasn’t necessary.

0:36:59.320,0:37:02.020
To test the glitcher, to find out if it[br]will work and what voltage levels

0:37:02.020,0:37:06.620
are successful we can send a command[br]to the ACP, then glitch, and then see

0:37:06.620,0:37:11.310
the response from the ACP. The general[br]strategy is to lower the voltage just

0:37:11.310,0:37:15.430
to the point where the chip sometimes[br]resets due to the glitch.

0:37:15.430,0:37:18.740
By adjusting voltage levels and glitch[br]length and timing when the glitch will end

0:37:18.740,0:37:25.300
I succeeded to cause ACP responses to be[br]altered. The checksum on SPI packets

0:37:25.300,0:37:30.000
is very convenient. When unusual data is[br]received from the ACP chip with a valid

0:37:30.000,0:37:33.630
checksum it’s a pretty good sign that the[br]glitch caused a temporary fault within

0:37:33.630,0:37:38.300
the CPU, but their normal operation was[br]resumed. Depending when the glitch

0:37:38.300,0:37:42.170
is delivered different effects are seen.[br]We can see that generally, as the glitches

0:37:42.170,0:37:46.380
moved later, it’s the later bytes of the[br]response packets that change.

0:37:46.380,0:37:54.140
So at this point it looks like the glitcher[br]works, and is able to cause a pretty fault.

0:37:54.140,0:37:57.110
Since I had an effectve glitch I took[br]the circuit from the breadboard

0:37:57.110,0:38:01.130
and etched a simple PCB that I could plug[br]directly on the XMEGA development board.

0:38:01.130,0:38:04.240
This performs exactly the same function[br]as the breadboard glitcher but

0:38:04.240,0:38:07.641
I’m a bit less likely to accidently unplug[br]a wire from the breadboard and

0:38:07.641,0:38:10.800
have to repair things. The circuit was[br]simple enough that I could create

0:38:10.800,0:38:18.020
a one-sided PCB, so it was very easy[br]for myself to etch at home.

0:38:18.020,0:38:22.830
Now my goal is to have the ACP execute[br]the code of my choice. Because the 6502

0:38:22.830,0:38:27.920
is a von-Neumann architecture all code and[br]data memories share the same address space.

0:38:27.920,0:38:32.830
From software disassembly I saw that there[br]didn't appear to be any paging or MMU

0:38:32.830,0:38:37.780
features. The software in ROM is fully[br]self-contained. There is no EEPROM

0:38:37.780,0:38:41.660
and RAM is never used to hold executable[br]code. So there aren’t jumps into

0:38:41.660,0:38:45.790
these areas to exploit and, in fact, it[br]wasn’t clear if there’s anything preventing

0:38:45.790,0:38:51.980
code execution outside of ROM. I decided to[br]take a chance and test if RAM is executable.

0:38:51.980,0:38:56.710
So I sent a message via SPI, knowing that[br]this message will be stored in RAM.

0:38:56.710,0:39:01.420
The message contained 6502 executable code[br]that will copy itself to an unused area

0:39:01.420,0:39:06.130
of RAM, execute from this area and send[br]an ACK indicating it was successful.

0:39:06.130,0:39:09.820
Because I studied the use of the SPI[br]interface and the ROM code I’m able

0:39:09.820,0:39:13.770
to create this executable payload that[br]will continue to receive commands via SPI

0:39:13.770,0:39:17.260
after it’s taken control over the ACP.

0:39:17.260,0:39:20.610
To try to maximize chances of success[br]I looked through the ROM code for

0:39:20.610,0:39:24.560
multi-byte instructions, which, if broken[br]up, would have contained within them

0:39:24.560,0:39:29.480
a jump op code with a destination that[br]should lead to where my executable

0:39:29.480,0:39:35.270
payload was placed at RAM. Since the ACP[br]has a single address space this gives

0:39:35.270,0:39:39.180
a lot of opportunities for glitching to[br]cause execution to reach the payload.

0:39:39.180,0:39:43.700
There are multiple scenarios possible in[br]addition to my selected glitch target.

0:39:43.700,0:39:47.370
Stack corruption is a possibility, and[br]really any abnormal program flow has

0:39:47.370,0:39:51.710
some possibility that it could eventually[br]land in my code. The von-Neumann

0:39:51.710,0:39:54.760
architecture, without strong memory[br]management, is a very fertile ground

0:39:54.760,0:39:59.700
for glitching. Anything in RAM[br]potentially could be executed.

0:39:59.700,0:40:02.660
So at this point there are several[br]uncertainties, but so far nothing

0:40:02.660,0:40:06.510
totally rules out the possibility of[br]success. The ACP operates from

0:40:06.510,0:40:10.370
an internal clock source. And the[br]interrupt-driven task switching

0:40:10.370,0:40:15.140
does add some further timing uncertainty.[br]So I’ll send the code payload,

0:40:15.140,0:40:19.110
delay, then glitch, and see the result.[br]When it’s unsuccessful I change

0:40:19.110,0:40:22.540
the delay and I try again.[br]I tried to aim for the instruction

0:40:22.540,0:40:26.210
that I’ve identified as possibly[br]corruptible into a jump.

0:40:26.210,0:40:29.980
But there are a lot of unknowns, so,[br]really, the processor is like fishing:

0:40:29.980,0:40:33.830
throw the line and hope. I have[br]a target but no way to know if I can

0:40:33.830,0:40:38.510
hit it, or if it will have[br]the expected result.

0:40:38.510,0:40:42.730
But sometimes fishing is good.[br]Relatively quickly the ACP returns

0:40:42.730,0:40:46.730
an ACK indicating a successful glitch. The[br]first successful glitch took some hours

0:40:46.730,0:40:50.220
to find. And then, after this it was[br]possible to make it work repeatedly

0:40:50.220,0:40:53.970
in a matter of minutes or even seconds.[br]So now I have my code executing

0:40:53.970,0:40:58.560
in RAM, I’m able to send the ACP[br]additional pieces of code to be executed.

0:40:58.560,0:41:01.971
This allows me to read any memory address,[br]write any memory address, and perform

0:41:01.971,0:41:07.490
any other operations[br]possible with the 6502.

0:41:07.490,0:41:11.140
I wrote a simple application to perform[br]glitch surges, and then to interact

0:41:11.140,0:41:15.050
with the code payload backdoor installed[br]in RAM. And this program allows me

0:41:15.050,0:41:19.900
to enter an address and length and have[br]data returned. Or write memory etc.

0:41:19.900,0:41:23.290
There’s also support for setting the key[br]and data, and performing DES encrypt

0:41:23.290,0:41:28.010
or decrypt using the DES hardware that’s[br]inside the ACP. A few things I noticed

0:41:28.010,0:41:32.849
at this point: there’s a 2 kB area of ROM[br]that, if I attempted to read it, caused

0:41:32.849,0:41:37.030
the chip to reset. This area of ROM[br]contains the personalization routines

0:41:37.030,0:41:41.040
that are never normally used[br]after the device leaves the factory.

0:41:41.040,0:41:44.470
There’s also protection against modifying[br]the Seed Keys in RAM. Trying to store

0:41:44.470,0:41:48.880
a value in these memory locations[br]appeared to do nothing.

0:41:48.880,0:41:53.520
There are specific addresses within RAM[br]that can’t be read or the chip will lock up.

0:41:53.520,0:41:57.600
These are clever traps put in place[br]as a security measure. The 7-byte

0:41:57.600,0:42:02.790
56 bit keys stored in RAM stride all these[br]dead addresses. So a potential exploit

0:42:02.790,0:42:06.230
that could cause a linear dump of memory[br]will be stopped before a complete key

0:42:06.230,0:42:11.370
is ever read. When the chip is reset it[br]means having to glitch it again, because

0:42:11.370,0:42:14.720
my code payload exists only in RAM, and[br]there is no way to hook in a permanent

0:42:14.720,0:42:19.100
backdoor.

0:42:19.100,0:42:22.480
Since we can execute code on the ACP the[br]receiver responds, we can read the ROM

0:42:22.480,0:42:25.410
to have its contents without any of the[br]errors that were introduced during

0:42:25.410,0:42:30.120
the optical extraction process. Comparing[br]the results of the optical ROM extraction

0:42:30.120,0:42:34.590
with the proper dump we can see how many[br]errors were in the optical extraction.

0:42:34.590,0:42:37.920
Overall the optical extraction was quite[br]good. It was, after all, good enough

0:42:37.920,0:42:41.830
to understand the software and get us to[br]this point. There is only one byte with

0:42:41.830,0:42:46.210
more than a single incorrectly flipped[br]bit. Many of the errors that existed

0:42:46.210,0:42:50.290
were quite obvious from disassembling the[br]software. If an instruction is out of place

0:42:50.290,0:42:55.030
but flipping a single bit would make it[br]sensible then it was probably a bit error.

0:42:55.030,0:42:58.510
I didn’t keep detailed records but I think[br]I probably caught about half of the ROM

0:42:58.510,0:43:05.610
errors during the disassembly process[br]before I started glitching.

0:43:05.610,0:43:10.040
The interesting keys in the ACP are all[br]stored in RAM only. This includes

0:43:10.040,0:43:14.060
Working/Program/Category and Seed Keys.[br]The RAM is battery-backed.

0:43:14.060,0:43:18.570
If the Seed Keys are ever lost from RAM[br]this ACP can no longer process EMMs

0:43:18.570,0:43:23.360
and so is useless. It’s possible to glitch[br]the ACP and read memory, but the glitcher

0:43:23.360,0:43:28.770
works on an ACP removed from their[br]set-top-box. When the ACP is in-circuit

0:43:28.770,0:43:33.590
the connections to other components and[br]16 VCC-connected pins pose the problem.

0:43:33.590,0:43:38.130
To glitch the ACP in-circuit we’ll require[br]some modifications to the set-top-box

0:43:38.130,0:43:42.340
disconnecting the ACP from other parts.[br]Or, another alternative is to remove

0:43:42.340,0:43:47.000
the ACP from the set-top-box and place it[br]on a breakout board without loosing

0:43:47.000,0:43:52.871
the battery power and wiping RAM. Rather[br]than modify the set-top-box, where each

0:43:52.871,0:43:56.650
of several different models would have[br]required unique modifications I decided

0:43:56.650,0:44:01.440
to try to remove the ACP with the battery[br]still attached. The plan is to carefully

0:44:01.440,0:44:07.650
lift the Battery and Ground pins while the[br]set-top-box is powered on providing VCC.

0:44:07.650,0:44:11.280
I use a small tool I made from a razorblade[br]using a Dremel tool, then attached

0:44:11.280,0:44:15.060
the handle of a screw driver. This tool[br]can be wedged under a pin, then with

0:44:15.060,0:44:18.420
some hot air the solder will melt and[br]a single pin can be lifted straight up

0:44:18.420,0:44:23.920
without damaging any of the other pins.

0:44:23.920,0:44:27.470
With the pins lifted an external battery[br]can be attached.

0:44:27.470,0:44:29.240
After attaching an external battery…

0:44:29.240,0:44:38.330
<i>applause</i>

0:44:38.330,0:44:41.700
After attaching an external battery the[br]set-top-box is unplugged, and the ACP

0:44:41.700,0:44:46.370
can be removed from the set-top.box using[br]hot air. The ACP can be removed from

0:44:46.370,0:44:51.040
the set-top-box, glitched, and can even be[br]placed back in the set-top-box, if desired.

0:44:51.040,0:44:55.480
To do this I just use hot air and a lot of[br]flux. Additionally, once the interesting

0:44:55.480,0:44:59.190
keys have been extracted it may not even[br]be necessary to replace the ACP

0:44:59.190,0:45:04.490
in the set-top-box. The ACP is now placed[br]on a breakout board and connected

0:45:04.490,0:45:08.580
with the glitcher. Not all the pins need[br]to be connected. Only a handful of pins

0:45:08.580,0:45:12.180
are actually used by the glitcher. You can[br]also see at this point the glitcher is

0:45:12.180,0:45:17.050
in a project box. The aesthetics greatly[br]improved since the breadboard-based

0:45:17.050,0:45:22.370
glitcher. But the functionality is[br]identical. The timing of ACP responses

0:45:22.370,0:45:25.570
is different on a chip with valid RAM[br]compared to the previous chips

0:45:25.570,0:45:30.040
that I had glitched before. I didn’t[br]confirm whether the cause of the timing

0:45:30.040,0:45:32.770
difference was due to a different[br]oscillator configuration or just

0:45:32.770,0:45:35.950
a different software path. But by[br]adjusting the timing of the glitches

0:45:35.950,0:45:41.150
the executable code payload runs as it did[br]on the previous chips. So now we can read

0:45:41.150,0:45:45.190
the RAM contents of a valid ACP, including[br]the Category Keys, if the set-top-box had

0:45:45.190,0:45:49.720
current authorization, as well as the Seed[br]Keys that are used by this ACP to decrypt

0:45:49.720,0:45:56.910
EMMs. With a valid Category Key ECMs can[br]be decrypted, and a cracked Working Key

0:45:56.910,0:46:03.330
can be calculated for any channel. Now,[br]with the capability of running my own code

0:46:03.330,0:46:07.010
of the ACP it’s time to look at the[br]transport stream descrambling.

0:46:07.010,0:46:10.720
There’s a hardware register bit that[br]is set or cleared, based on a byte

0:46:10.720,0:46:15.050
in the ECM40. When this bit is cleared[br]standard DES decryption is used.

0:46:15.050,0:46:19.180
When the bit is set the transport stream[br]descrambler acts differently. Additionally,

0:46:19.180,0:46:23.650
there’s an 8-bit hardware register in the[br]DES peripheral area. When it’s Zero

0:46:23.650,0:46:26.610
the peripheral operates the standard DES.[br]For any other value the peripheral acts

0:46:26.610,0:46:29.910
differently. At this point I started to[br]think I might be looking at doing

0:46:29.910,0:46:34.150
a Gate-level reverse engineering of the[br]chip to understand this functionality.

0:46:34.150,0:46:38.500
The chip is using technology that’s older.[br]So reverse-engineering should be feasible.

0:46:38.500,0:46:42.020
But, if possible, I’d like to avoid all[br]this extra work. It would be quite

0:46:42.020,0:46:44.670
time consuming, and might give imperfect[br]results, similar to the optical ROM

0:46:44.670,0:46:48.490
extraction. So I started with trying to[br]characterize descrambling modes.

0:46:48.490,0:46:51.890
The transport stream packet is made up[br]of a 4-byte header and 23 blocks of

0:46:51.890,0:46:56.610
8 bytes each. The DES operates[br]on these 8 byte (64 bit) blocks.

0:46:56.610,0:47:03.280
By flipping one bit in encrypted input ECB,[br]CBC or OFB modes can be differentiated.

0:47:03.280,0:47:07.310
Flipping one bit causes an 8-byte block[br]to be corrupted, and the corresponding bit

0:47:07.310,0:47:11.870
in the following block to be flipped.[br]This indicates CBC mode is in use.

0:47:11.870,0:47:14.740
Timing of the input compared to the[br]decrypted output was measured with

0:47:14.740,0:47:18.120
the descrambler and standard DES,[br]and in the custom hardware mode.

0:47:18.120,0:47:21.670
No timing difference was seen. This[br]suggests the internal properties of DES

0:47:21.670,0:47:24.920
haven't changed. Which makes sense[br]because the decryption has to be done

0:47:24.920,0:47:29.610
in realtime. So this suggests that crypto[br]customizations are not affecting

0:47:29.610,0:47:34.590
some DES internals like the number of[br]rounds. Also by using ACP as a decryption

0:47:34.590,0:47:38.590
oracle I determined that the customization[br]affects each of the 23 blocks of the

0:47:38.590,0:47:44.150
transport stream differently. Next[br]I tested the software using DES ‘weak keys’.

0:47:44.150,0:47:48.070
These are certain keys not recommended[br]for use with DES because their properties

0:47:48.070,0:47:51.890
weaken the cryptographic strength.[br]A key of all Zero or all One bits

0:47:51.890,0:47:56.520
will cause DES decryption and encryption[br]to be identical. That is running the same

0:47:56.520,0:48:01.850
data through Encrypt or Decrypt will give[br]the same result. I can test this on an ACP

0:48:01.850,0:48:06.410
configured for standard DES decryption[br]and see the expected ‘weak key’ behavior.

0:48:06.410,0:48:10.270
When tested with the descrambler in custom[br]mode the ‘weak key’ behaviour changes.

0:48:10.270,0:48:13.990
Using a key of all Zero or all One didn’t[br]produce the same results in Encrypt

0:48:13.990,0:48:18.580
and Decrypt modes. Looking at the other[br]hardware register, testing the DES

0:48:18.580,0:48:22.710
peripheral with different values in the[br]8-bit register, and using ‘weak keys’,

0:48:22.710,0:48:26.960
shows that the standard DES ‘weak key’[br]behaviour still exists. So my hunch

0:48:26.960,0:48:29.870
at this point is that one customization[br]affects the key, and the other customization

0:48:29.870,0:48:33.040
affects the data. At this point I can’t be[br]certain, but I have a good feeling about

0:48:33.040,0:48:37.310
the theory, so I continue to investigate.

0:48:37.310,0:48:40.110
Based on the idea that the hardware[br]customization affects only the key

0:48:40.110,0:48:44.160
and decryption is static I thought the[br]simplest customization will be an XOR

0:48:44.160,0:48:48.660
mask that’s applied to the key before it’s[br]used for DES decryption. XOR requires

0:48:48.660,0:48:51.630
only a single gate in series of the DES[br]engine so it fits the requirements of

0:48:51.630,0:48:55.830
fast and very simple implement in[br]hardware. A change of even a single bit

0:48:55.830,0:48:59.480
in the key could cause the observed[br]effects. Flipping more than 28 bits

0:48:59.480,0:49:04.310
will be pointless. That’s the same as[br]inverting a key and flipping fewer bits.

0:49:04.310,0:49:07.180
More flipped bits means more gates[br]necessary for the customization, so

0:49:07.180,0:49:11.470
it makes sense to flip a minimal number[br]of bits. So I wrote this wonderful FOR loop,

0:49:11.470,0:49:15.810
nested 16 levels deep, to test decryption[br]results after flipping one bit of the key,

0:49:15.810,0:49:20.030
then flipping two bits, then three bits[br]etc. of the 16 bits. To test all the

0:49:20.030,0:49:22.780
possible keys will take a long time. But[br]if only a few bits are flipped then it

0:49:22.780,0:49:27.170
might be possible to run it in a shorter[br]period of time. And promising results

0:49:27.170,0:49:31.010
did come quickly. It turns out the theory[br]held up. And some of the blocks have

0:49:31.010,0:49:35.610
as few as three bits flipped. This takes[br]only seconds for the software to identify.

0:49:35.610,0:49:39.510
After verifying that these work for XOR[br]masks, for these logs the software then

0:49:39.510,0:49:42.450
was left running to find all 23 masks.

0:49:42.450,0:49:45.830
The simple brute-force method worked,[br]it ran for a couple of days to identify

0:49:45.830,0:49:50.380
all the 23 masks. By more carefully[br]analyzing which bits were being flipped

0:49:50.380,0:49:54.230
in the early results a pattern can[br]actually be found. So the search could

0:49:54.230,0:49:57.460
have been more limited. Using this[br]technique the software cracker could have

0:49:57.460,0:50:02.210
completed it in under a second.

0:50:02.210,0:50:04.720
After successfully solving the first[br]hardware customization the theory

0:50:04.720,0:50:10.320
that the second customization is[br]a Data XOR looks promising. It makes sense

0:50:10.320,0:50:14.590
that one or more XOR gate is enabled by[br]each bit of the 8-bit hardware register.

0:50:14.590,0:50:18.430
Using the ACP as a decryption oracle[br]a known key in Data were decrypted

0:50:18.430,0:50:22.500
with all values of the 8-bit register.[br]Software attack of this function

0:50:22.500,0:50:28.260
was successful, and 255 XOR masks were[br]identified, behavior matching what was

0:50:28.260,0:50:33.820
expected. I haven’t actually seen this[br]customization in actual use. Presumably,

0:50:33.820,0:50:36.000
they’re saving it to be used as[br]a countermeasure against pirate devices

0:50:36.000,0:50:39.410
when necessary. But it hasn’t been[br]necessary since the system never had

0:50:39.410,0:50:43.860
a security breach.

0:50:43.860,0:50:51.730
<i>laughs</i>[br]<i>applause</i>

0:50:51.730,0:50:55.160
In order to implement a Softcam, a software[br]implementation of the descrambler,

0:50:55.160,0:50:59.480
a few cryptographic details need to be[br]identified. But at this point I have

0:50:59.480,0:51:03.770
all the tools to do so. The initialization[br]vector used for CBC mode can be found

0:51:03.770,0:51:07.260
through simple XOR. And the handling of[br]short blocks – those less than the

0:51:07.260,0:51:11.790
64 bit DES block size can be identified[br]likewise. With all these details

0:51:11.790,0:51:14.980
a software implementation of the[br]EMM decryption of Category Key and

0:51:14.980,0:51:19.161
ECM decryption of Program Key and Working[br]Keys can be made and the transport stream

0:51:19.161,0:51:23.540
descrambler can also be implemented in[br]software. The rapid key changes and the

0:51:23.540,0:51:27.290
use of DES with h/w customizations makes[br]it a bit different to implement, compared

0:51:27.290,0:51:32.120
to a Softcam for typical DVB systems,[br]but overall the concept is the same.

0:51:32.120,0:51:37.070
And now it’s all working! I was able to[br]test it, and it’s fully working on both

0:51:37.070,0:51:40.901
the satellite and cable systems. This[br]is a screen that’s broadcast before

0:51:40.901,0:51:44.740
a pay-per-view event goes live. The[br]pay-per-view, like all other channels,

0:51:44.740,0:51:48.010
can be decrypted with the Softcam using[br]the algorithms learned in these keys that

0:51:48.010,0:51:53.960
were extracted. With the ECM and EMM[br]algorithms and Seed Keys for a set-top-box

0:51:53.960,0:51:57.680
with any level of authorization the[br]Category Key can be decrypted

0:51:57.680,0:52:01.550
and then used to decrypt any and all[br]of the channels that are broadcast

0:52:01.550,0:52:05.150
by this provider.

0:52:05.150,0:52:14.060
<i>applause</i>

0:52:14.060,0:52:18.590
A few of the weaknesses that I identified[br]in this system were that the ACP I studied

0:52:18.590,0:52:23.160
is relatively old technology, almost[br]20 years old. So this makes it a lot

0:52:23.160,0:52:26.500
easier for invasive analysis today[br]than one that was brand new.

0:52:26.500,0:52:32.490
The TQFP100 package is quite easy to deal[br]with compared to modern alternatives.

0:52:32.490,0:52:38.170
The chip is susceptible to voltage[br]glitching. It’s a van-Neumann architecture

0:52:38.170,0:52:42.350
without strong MMU protection preventing[br]code to be executed from RAM.

0:52:42.350,0:52:47.040
They didn’t leave any possibility for code[br]update or dynamic code execution

0:52:47.040,0:52:52.200
for countermeasure purposes. The software[br]for the ACP is contained entirely in ROM

0:52:52.200,0:52:57.070
with no mechanism for software updates in[br]the field. The hardware customizations

0:52:57.070,0:53:00.990
to the crypto were quite simple and[br]required no reverse-engineering

0:53:00.990,0:53:08.880
of the chip logic. I was basically able to[br]guess the hardware customizations.

0:53:08.880,0:53:11.650
I was impressed with the design of the[br]system. It was actually stronger than

0:53:11.650,0:53:16.190
I anticipated when I started the project.[br]All the key handling and decryption

0:53:16.190,0:53:20.010
is contained within a single chip which[br]makes it impossible to do key sharing

0:53:20.010,0:53:23.891
that’s being done with some of the[br]smartcard systems. The fast Working Key

0:53:23.891,0:53:29.050
change interval – only a 133 ms – also[br]makes key sharing more difficult.

0:53:29.050,0:53:34.240
And the short lifetime of the key makes[br]cracking it in realtime quite unrealistic.

0:53:34.240,0:53:37.640
The lack of code in any rewritable memory[br]means there’s nowhere to write code for

0:53:37.640,0:53:45.500
a permanent backdoor to disable the[br]access controls. I listed this also as

0:53:45.500,0:53:49.420
a weakness but in fact this is a strength[br]as it limits the attacker’s capability

0:53:49.420,0:53:53.850
to install any kind of persistent[br]backdoor. The chip operates

0:53:53.850,0:53:56.940
on an internal clock eliminating clock[br]glitch attack and making timing

0:53:56.940,0:54:01.550
a voltage glitch a lot more difficult.[br]These dead addresses in the middle

0:54:01.550,0:54:05.730
of DES keys prevent linear readout of[br]keys. If one were to cause a loop reading

0:54:05.730,0:54:09.290
data to go out of bounds and reach the[br]area of RAM where keys are stored

0:54:09.290,0:54:13.430
the chip will reset before an entire key[br]is read. After the first couple of bytes

0:54:13.430,0:54:17.790
a dead address will be accessed that[br]causes the chip to reset.

0:54:17.790,0:54:22.390
The personalization ROM appears to be[br]inaccessible so it can’t easily be used

0:54:22.390,0:54:28.030
to modify the keys and Unit Address[br]within the ACP. The Seed Keys

0:54:28.030,0:54:32.120
aren’t easily changed so the[br]set-top-boxes can’t easily be cloned.

0:54:32.120,0:54:37.170
The keys exist only in RAM so you have to[br]maintain a battery backup at all times.

0:54:37.170,0:54:42.840
This rules out a lot of invasive attacks[br]to retrieve the keys. And there are

0:54:42.840,0:54:46.360
no group keys used for EMMs. All the[br]unit addressing is to individual units.

0:54:46.360,0:54:51.350
So you have to pull keys from an actively[br]subscribed box in order to get active keys.

0:54:51.350,0:54:54.730
That said if you have keys from a box[br]that is subscribed to any channel

0:54:54.730,0:54:58.650
you’ll receive an EMM containing the[br]Category Key which is capable of

0:54:58.650,0:55:02.140
decrypting all channels. So you don’t need[br]to have a subscription to all channels

0:55:02.140,0:55:04.980
you want to decrypt as long as you’re[br]authorized for at least one channel

0:55:04.980,0:55:09.710
on the system.

0:55:09.710,0:55:13.180
The software is generally well designed[br]and written. I didn’t notice any glaring

0:55:13.180,0:55:18.660
bugs within it. Although DES is used the[br]EMM decryption requires using three

0:55:18.660,0:55:23.580
DES keys, and multiple rounds are[br]performed when decrypting EMM and ECMs.

0:55:23.580,0:55:28.480
So this part isn’t as simple as[br]cracking a single 56-bit key.

0:55:28.480,0:55:32.010
Brute-forcing, starting from the encrypted[br]transport stream requires cracking

0:55:32.010,0:55:35.660
Working Key, then Program Key,[br]then Category Key and, finally,

0:55:35.660,0:55:43.370
the three Seed Keys.

0:55:43.370,0:55:46.810
You might wonder how many set-top-boxes[br]it took for me to complete this project!

0:55:46.810,0:55:56.520
<i>laughter and applause</i>

0:55:56.520,0:55:59.780
The truth is I only needed the one…[br]…truck load!

0:55:59.780,0:56:02.100
<i>laughter</i>

0:56:02.100,0:56:05.990
Some of the boxes had different versions[br]of the ACP chip. Many of the boxes had

0:56:05.990,0:56:08.710
different PCB layouts. So it was[br]interesting to be able to look at

0:56:08.710,0:56:14.320
a variety of boxes. The cost of used set[br]top boxes was low, ca. $20. And for

0:56:14.320,0:56:17.540
this research I was focusing on the signal[br]security and didn’t need the PVR

0:56:17.540,0:56:24.500
functionality or any of the advanced[br]features from the expensive set-top-boxes.

0:56:24.500,0:56:28.310
So at this point I have a brief anti-piracy[br]message: I don’t recommend you pirate

0:56:28.310,0:56:32.420
cable or satellite TV. There is never[br]anything good on. It doesn’t matter

0:56:32.420,0:56:34.620
how many channels you can decrypt.[br]Believe me – I looked!

0:56:34.620,0:56:36.300
It’s not worth the effort!

0:56:36.300,0:56:51.450
<i>laughter and applause</i>

0:56:51.450,0:56:55.250
Herald: Do we have questions[br]from the room?

0:56:55.250,0:56:59.820
Questions – please use the microphones.

0:56:59.820,0:57:05.750
I know there is one question[br]from the interwebs.

0:57:05.750,0:57:08.410
Signal Angel: Okay, hello.[br]This is working? Good.

0:57:08.410,0:57:13.990
So the first question from the internet[br]is: how many chips did you destroy

0:57:13.990,0:57:20.810
or make unusable, and how did you[br]get all those set-top-boxes?

0:57:20.810,0:57:24.440
Chris: Because the cost of the used[br]set-top-boxes was quite low I wasn’t

0:57:24.440,0:57:29.421
afraid to destroy several chips in the[br]process. It didn’t take as many

0:57:29.421,0:57:36.330
as I would have expected in the beginning.[br]Two or three chips were used for the

0:57:36.330,0:57:39.970
decapsulation and the delayering process.[br]I ended up extracting the ROM

0:57:39.970,0:57:44.660
from a single chip. And then, when[br]it came to glitching, there were

0:57:44.660,0:57:49.600
three or four chips that I removed and[br]erased the RAM from to develop the glitch.

0:57:49.600,0:57:53.310
When I finally got to the point where[br]I was extracting keys from a valid chip

0:57:53.310,0:57:59.260
the very first chip that I tried worked.[br]So there were few casualties involved!

0:57:59.260,0:58:03.510
Herald: Thank you! Microphone 3[br]was the first one, please!

0:58:03.510,0:58:09.500
Mic3: How many years[br]did this project take you?

0:58:09.500,0:58:12.470
Chris: I would work for a few weeks at[br]a time and then get burned out and

0:58:12.470,0:58:16.420
take a break, and then come back to it.[br]Most of the work for the project

0:58:16.420,0:58:22.020
was completed over about a 2-year period.

0:58:22.020,0:58:25.530
Herald: Thank you. And…[br]Microphone 2, please!

0:58:25.530,0:58:29.170
Mic2: Hi, thank you for a great[br]lecture. How comes that

0:58:29.170,0:58:35.960
the content decryption was DES and[br]not a DVB-CSA because we're used

0:58:35.960,0:58:39.090
that content is encrypted[br]with DVB-CSA in these DVB systems.

0:58:39.090,0:58:41.860
Chris: In North America we[br]don’t believe in standards!

0:58:41.860,0:58:45.240
<i>laughter</i>

0:58:45.240,0:58:48.680
Mic2: Thanks!

0:58:48.680,0:58:51.650
Chris: The timing was also a part of it.[br]The system was being developed

0:58:51.650,0:58:55.760
at the same time as DVB was being[br]standardized. So General Instrument

0:58:55.760,0:58:59.060
rather than going along with the Standards[br]Group and waiting for the standardization

0:58:59.060,0:59:03.090
they went with DES, directly.

0:59:03.090,0:59:07.460
Herald: Thank you. And another one[br]from Cyber-Cyber… space!

0:59:07.460,0:59:11.230
Signal Angel: Okay. Another question from[br]the internet is: you have all this fancy

0:59:11.230,0:59:16.130
like lab equipment stuff. How were you[br]able to afford that?

0:59:16.130,0:59:19.260
Chris: I’ve been quite interested in this[br]for a long time. So I’ve collected

0:59:19.260,0:59:23.920
this equipment over a period of years.[br]And I do some work, professionally,

0:59:23.920,0:59:27.540
in reverse-engineering. So whenever[br]possible I use our client’s money

0:59:27.540,0:59:34.040
to buy another piece of[br]equipment for the lab.

0:59:34.040,0:59:37.300
To do this actual work, though, you could[br]even use more basic equipment

0:59:37.300,0:59:41.560
because of the age of the chip. You could[br]use a microscope that you could find

0:59:41.560,0:59:45.740
easily for $1.000 .. $2.000 or even less[br]and have quite good results.

0:59:45.740,0:59:51.480
So it’s not trivial but it’s not a huge[br]amount of money for a lab equipment!

0:59:51.480,0:59:54.990
Herald: Not that huge![br]Microphone 2, please!

0:59:54.990,0:59:58.910
Mic2: What do you do for a living[br]besides reverse-engineering?

0:59:58.910,1:00:03.540
Chris: Reverse-engineering![br]<i>laughs</i>

1:00:03.540,1:00:07.420
Herald: Thank you. And the internet![br]Again.

1:00:07.420,1:00:13.160
Signal Angel: Okay. Next question is…[br]somebody wants to know how…

1:00:13.160,1:00:17.360
…which software did you use for the[br]automated image analyzing, and

1:00:17.360,1:00:20.060
is it available somewhere?

1:00:20.060,1:00:24.020
Chris: Like everybody else that I’ve known[br]that’s done optical ROM extraction

1:00:24.020,1:00:28.170
I developed it myself. Everybody seems[br]to develop their own tools from scratch

1:00:28.170,1:00:33.461
for that. The image processing I used was[br]really quite simple. So it didn’t take

1:00:33.461,1:00:38.540
a lot of advanced algorithms or anything[br]like that. So I’m using some software

1:00:38.540,1:00:43.860
I developed personally, and[br]it hasn’t been released.

1:00:43.860,1:00:45.900
Herald: Microphone 2, please!

1:00:45.900,1:00:50.450
Mic2: And how did you keep the boxes[br]subscribed? So did you call them

1:00:50.450,1:00:54.260
every week “Oh, my box broke down,[br]I got another one”, or how is this done?

1:00:54.260,1:00:58.520
Chris: For most of the research that[br]I did I didn’t need an active box. I did

1:00:58.520,1:01:02.100
all the research just on previously[br]activated boxes that had lost their

1:01:02.100,1:01:05.840
authorization. And by the time I had the[br]process figured out, that I knew how

1:01:05.840,1:01:10.230
to extract keys from a valid box[br]I only needed the one box.

1:01:10.230,1:01:13.520
Mic2: And had you heard back[br]from the cable provider about this?

1:01:13.520,1:01:15.330
Chris: No.

1:01:15.330,1:01:18.670
Herald: Okay, thank you.[br]Microphone 3, please!

1:01:18.670,1:01:22.360
Mic3: Hello, thanks very much for the[br]lecture and ‘well done’ on all the work!

1:01:22.360,1:01:29.400
My question is: how does the glitching[br]work, the glitching attack?

1:01:29.400,1:01:34.770
Chris: The glitcher was quite simple.[br]I drop the voltage for a very brief period

1:01:34.770,1:01:40.270
of time. And it’s enough time that it[br]causes at least one instruction to

1:01:40.270,1:01:44.800
not execute properly. But it’s too short[br]of a time to cause the chip to reset.

1:01:44.800,1:01:48.640
So essentially I’m corrupting one[br]instruction. It is for the specific target

1:01:48.640,1:01:54.170
that I hit that led to my code in RAM.[br]I’m not actually sure. I found that

1:01:54.170,1:01:57.950
if I glitch it this time then the code[br]ends up executing my code –

1:01:57.950,1:02:01.610
good enough for me!

1:02:01.610,1:02:04.550
Herald: Okay. Thank you, Chris![br]Please, dear audience,

1:02:04.550,1:02:08.100
give an Anniversary Edition[br]applause to Chris Gerlinsky!

1:02:08.100,1:02:17.370
<i>Anniversary Edition applause</i>

1:02:17.370,1:02:37.150
<i>postroll music</i>

1:02:37.150,1:02:40.550
<i>subtitles created by c3subtitles.de[br]in the year 2018</i>