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