<i>33C3 preroll music</i>

Herald: So… coming over to our next talk.

Tonight, if you switch off
your DECT phone, and

if you’re full of different impressions

– full of different impressions of this
day you maybe want to watch TV.

But it would be cool to have pay-TV
– unencrypted pay-TV.

So Chris Gerlinsky asks himself the same.
And how to achieve unencrypted pay-TV

– but the Hacker way. So Chris
reverse-engineered nothing less

than the signal and the encryption for
a standard that remains unencrypted

since the late 90s. Please welcome with an
Anniversary Edition applause Chris Gerlinsky!

<i>applause</i>

Chris Gerlinsky: Hello everyone.
My name is Chris Gerlinsky.

I am a hacker from Canada and I’m here
today to talk about how I cracked

digital cable and satellite TV security.
I studied an Access Control Platform (ACP)

that’s widely used across Canada and the
USA. It’s one of the two common platforms

that’s used in cable TV,
and it’s also used in satellite TV

by one of the two Canadian satellite TV
operators. As far as I know the system

has remained secure since it was
introduced in the 1990s and I was curious

if I could understand the system based on
the older set-top-boxes. Some of them

are 15 years old – and they are still in
use. So these devices haven’t received

upgraded security hardware in that time and
I started looking at how the system works.

Before I get into the reverse engineering
I’ll start with a brief description of how

digital television is sent over satellite
or cable. Satellite and cable digital TV

are pretty similar for the most part. There
are a variety of signal modulations used.

The relevant ones here are QPSK at about
27 MBit/s and 8PSK Turbo FEC at about

38 MBit/s for satellite and QAM256 at about
38 MBit/s for cable. There is also an

out-of-band channel used by cable
which is QPSK modulated at 2 MBit/s.

This out-of-band channel carries the
subscription-management, program guide

information, firmware upgrades, etc. And
while you change channels and the cable

box tunes to different frequencies this
out-of-band channel remains tuned

so that the box continuously receives the
state, and no matter what TV channel you’re

tuned to. In the satellite TV this type of
data is included within the main transport

stream (TS) instead of in a secondary
out-of-band TS. The video is sent

as MPEG2 or H.264 TS. This is a standard
format for carrying video streams.

So it can be played by any hardware video
decoder or software decoder, e.g. VLC.

And the encryption system used here is
called DigiCipher 2 (DC2), which does not

follow the DVB standards that are used
in the rest of the world. The MPEG-TS

is made out of packets of 188 bytes.
Each packet has a PID. This is used

to differentiate different types of data.
PIDs range from 0 - 0x1FFF.

Each PID carries an MPEG Packetized
Elementary Stream (PES).

That’s a video or audio stream.
Or the PID may carry one or more

Service Information Tables. The Service
Information Tables have an 8-bit table ID

and a length of up to 1024 bytes
including a CRC32 for error detection

and this table ID identifies the type of
data that you can expect within the table.

Table 0 is the Program Association Table,
containing a list of programs carried

in this TS and the PMT PID for each
program. The Program Association Table

is always on PID 0. Table 2 is the Program
Map Table which contains the list of PES

and the PID for each as well as an ECM
PID. There is Program Map Table

for each MPEG program or TV channel
that’s found in the stream.

The ECM PID is where ‘Entitlement Control
Messages’ are sent containing information

that’s used to generate the key that
decrypts the Packetized Elementary

Streams. This system uses two types of
ECM. Table 40 I call ECM40, and Table 41

I call ECM41. On PID1 there may be
one or more conditional access tables,

table ID No.1. These tables identify a PID
that carries EMMs, ‘Entitlement Management

Messages’. These messages are used to set
access rates for individual set-top-boxes.

The subscription information, like, what
channels are available is carried inside

of EMMs. This is a hardware interface to
receive satellite data, a Genpix SkyWalker-1.

The DC2 QPSK modulation isn’t widely
supported in USB or PCI DVB-S devices.

And the 8PSK Turbo FEC modulation support
is even less common. And one of the devices

that does support these signals is this
Genpix device which is using a Broadcom

BCM4500 demodulator. And it supports both
the DC2-QPSK and the 8PSK modulations.

It works well, the Linux drivers need to
be re-compiled to include the support

for these modes, and patches for this were
published by updatelee. There’s a link

on the slide. For cable there’s a variety
of adapters supporting QAM256 de-modulation.

I used a USB HVR 950Q tuner. Unfortunately,
to tune the out-of-band channel is generally

not supported by the off-the-shelf
interfaces. Inside the cable box

it’s handled within the integrated chip
set. And for the ClearQAM consumer

devices such as USB interfaces access to
the out-of-band data isn’t actually required

so they don’t include it inside of the
hardware. This out-of-band data is used

only for pay-TV services.

With the satellite and cable interfaces
DVBsnoop can be used to view a lot of

information about the transport stream.
It’s enough information to be

quite overwhelming. So the trick to using
it is being able to sift through the output

for the relevant information. DVBsnoop
also doesn’t recognize all of the

DigiCipher 2 tables because it’s a non-
standard system, and DVBsnoop is targeted

towards the standard systems. So DVBsnoop
may not be able to tell you everything

about the transport stream but it was
still a very useful tool for all the

information that it can provide.

DVBsnoop and most other tools and
documentation are designed for the DVB

standard or other recognized standards
such as ATSC. DigiCipher cable

and satellite systems use a lot of
non-standard tables to carry

the system information. For cable TV some
of these tables are standardized by

the document SCTE 65.
There is no BAT or SDT

as you’d expect in DVB. Instead there
is a virtual channel table that maps

the transport streams and programs the
channel numbers. The electronic program

guide is also not DVB standard. So you
don’t even get the current and next

program information in any
kind of a standard format.

Another cable TV adapter is the HDHomeRun
Prime. This one is a network-connected

three-tuner device with cable card
support. The set-top-boxes I studied

pre-date the cable cards. Although the
newer boxes do use the cable cards,

and they support the DigiCipher 2.
But cable card support does also mean

that this HDHomeRun Prime includes the
tuner and QPSK demodulator for the

out-of-band channel. So it is able to pass
this data to the cable card, as necessary.

However, even the HDHomeRun doesn’t
make this out-of-band data available

other than the cable card interface. So
to access the demodulated out-of-band data

I tapped in to the HDHomeRun Prime with
a cable card inserted, and connected

a logic analyzer to the Data and Clock
signals. I wrote software using the

Saleae SDK to capture the QPSK demodulated
data. Then, in software, I performed

de-interleaving, de-randomization,
and the forward error correction.

And the output is an MPEG transport
stream. So using an HDHomeRun Prime

connected to the logic analyzer, connected
to the PC running the software

the output finally is a 2Mbit/s transport
stream. And this transport stream

looks like a standard transport stream,
and inside are the conditional access

management messages, program guide
information etc. Everything that was

missing from the main
QAM transport stream.

Two bits in each packet will indicate if
the packet is scrambled with the even key,

odd key, or not scrambled at all.
The key is changed at short intervals.

DVB systems typically will change every
5 .. 30 seconds. DC2 every 133 ms

or 1 second. The key used for decryption
alternates between even and odd.

The odd key is in use while the even key
is updated; and then the even key is

in use while the odd key is updated.
An encrypted transport stream is sent

via the cable or satellite, and it’s passed
through the descrambler in the ACP.

And the result is a decrypted transport
stream that is played by the MPEG decoder.

The descrambler uses a Working Key.
This is a 56-bit DES key that changes

every 133ms, or in some cases they have it
slowed down to changing every 1 second.

This Working Key is generated by
encrypting the frame count from ECM40

packets with the Program Key. The Program
Key, again DES, comes from the ECM41

message, and is encrypted with the
Category Key. The Program Key

is unique to each channel, and it changes
daily or for every pay-per-view event.

The Category Key, also DES, is shared
by all the set-top-boxes that authorize

for any channel from this provider. The
Category Key is sent to each set-top-box,

individually, inside the EMM95 message.
And this Category Key typically changes

monthly, but many cable operators change
keys much less frequently. Some of them

are using the same key for years at
a time. To decrypt the EMM, in order

to get the Category Key Seed Keys are
used. Each set-top-box has a set of

56 bit DES Seed Keys inside of
battery-backed RAM. These are

initialized during manufacturing. For the
lifetime of the set-top-box these keys

are used to secure EMMs. So this
forms a chain from the Seed Keys,

initialized during manufacturing and never
changing, to the decryption of the MPEG

transport stream.

Inside the satellite
set-top-box we can see the main

components of the system. The signal
enters the tuner and is passed

through the demodulator which
outputs a serial transport stream.

This transport stream passes through
the ACP – Access Control Processor –

and is then sent to the MPEG decoder
to output a video signal to the TV.

A 68k microcontroller acts as the set-top
box main controller. It communicates

with the MPEG decoder as well as
with the ACP via an SPI bus.

A battery provides backup power to the
ACP. So it will retain RAM contents

even when the set-top-box is unplugged.
There’s a TVpass slot near the power

supply. This is an upgrade slot with
a card edge connector to allow

for security upgrades. The system

stayed secure, so the TVpass slot was
never used. And the newer set-top-boxes

don’t actually include a TVpass slot
inside. So at this point it seems

quite unlikely that this TVpass card
will ever actually be used.

Inside the cable set-top-box… it’s
very similar to a satellite set-top-box

but the cable boxes tend to be more
tightly integrated. The signal enters

the tuner and passes through a Broadcom
chip that handles demodulation.

And the same chip will also handle MPEG
decoding after the transport stream’s been

decrypted by the ACP. A 68k microcontroller
acts as the set-top-box’s main controller.

Again, talking to the ACP via SPI.
And a battery provides backup power

to the ACP, and also to the non-volatile
RAM used by the main controller.

A TVpass slot is underneath the main
board, it’s not visible in this photo.

The cable set-top-boxes include a second
tuner that’s used to receive

the out-of-band data. This OOB tuner
operates independently of the main tuner

and on a separate frequency range. And
it’s used to provide a transport stream

containing the system information, with
the program guide, firmware updates,

EMMs etc.

Here we see the ACP chip. It’s a 100-pin
TQFP package. From the markings

we can see it’s a custom System-On-Chip
made for General Instrument Corp. (GIC).

All the decryption is performed by the
ACP, and all decryption keys are kept

only within this chip. The newer set-top-
boxes use newer versions of the ACP.

I studied the original ACP chip
that’s seen in this photo.

As long as the set-top-boxes using this
chip are actively used it remains

a relevant target. Whether the newer ACPs
include more advanced security features

or if they exist only for cost-savings
due to shrinking the die size

I don’t really know.

Some of the interesting pins on the ACP
are labeled here. Pin 1 is marked

at the top left corner of the chip.
There’s an SPI slave controller

on Pins 1 - 5, used for communication
with the set-top-box main controller.

There’s a battery backup pin that’s
connected to a 3V battery to keep

the RAM contents of the ACP intact
at all times. There’s a serial transport

stream input on pins 88 - 92 which
receives the data from the demodulator.

And there’s a serial transport stream
output on pins 28 - 33 which sends

the decrypted transport stream to the
MPEG decoder to be output to the TV.

At one point I had written software for
an AVR32 device, not the one that’s

shown here, that has a synchronous serial
peripheral, that supports sending and

receiving data at the 27 MBit/s rate of the
transport stream. My AVR32 implementation

turned out a bit ugly. But rather than
cleaning up I was able to use it as it was.

It had some limitations like only accepting
64kB of data for replay logging.

Which was just barely good enough for my
studies. What the transport stream

logging in-circuit digital mean was

that the transport stream passes through
the ACP with selected PIDs being decrypted.

And then the output is the full transport
stream but a selected program has been

decrypted. The AVR32 logging interface
had rather limited use for me.

Later on when I did more thorough research
I did so using an ACP that I’d removed from

the box and I put on a breakout board.
And then I could control the clock, and

at that point it was much easier to use an
XMEGA AVR platform to send and receive

the transport stream through the ACP
at a much slower bit rate. Shown here

is the XMEGA platform I settled on using

for SPI and also the transport stream
interfacing. To honor the data

passed between the set-top-box main
controller and the ACP on the SPI bus

I used the XMEGA development board. Two
SPI ports acted as slave with Master Out -

Slave In (MOSI) signal connected to 1 and
Master In - Slave Out (MISO) signal

connected to the Master Out - Slave In
input of the second port. So from one port

Bytes sent by the set-top-box
controller are received.

From the other port it receives

bytes from the ACP. In case I want to talk
directly to the ACP or the set-top-box

main controller it’s only necessary to
connect both the MOSI and MISO signals

on one of the SPI interfaces. By holding
the main controller in Reset my XMEGA

was able to act as the SPI Master and then
talk to the ACP. So this setup works for

passively monitoring the SPI communications
in the set-top-box and can also act as

the SPI Master for interrogating the chip
directly.

By logging the SPI bus between

the main controller and the ACP we see
that information about the current access

levels are sent from the ACP. The ACP
also receives EMMs via the SPI bus.

EMMs have been filtered by the Unit Address
number, or the set-top-box serial number.

So the ACP only receives messages
that are intended for that specific unit.

Command 04 includes the current Category
Key epochs and Keyselects in use.

Command 05 includes the Unit Address
number. Command 13 returns the authorized

Subscription tiers for this unit. Commands 7
and 87 provide information about the channel

being currently decrypted. Additionally,
via the SPI interface the set-top-box

main controller tells the ACP which PIDs
to decrypt and which is the ECM PID.

The ACP doesn’t send any keys on the bus,
and it only receives Category Keys that

are encrypted within EMMs via the SPI.
So all of the really interesting data is

contained within the ACP chip itself, and
it’s never sent out on any kind of a bus.

So next I started an invasive study of the
chip – studying it under a microscope.

And the cost of microscopes can range from
hundreds of Dollars to tens of thousands

of Dollars, or even higher for things like
electron microscopes or other specialized

equipment. I have a couple of microscopes
that I use. This one is a Mitutoyo FS70

microscope. These Mitutoyo are often used
for microprobing, but you can also use it

for other uses. For this project I didn’t
do any microprobing but I used this

microscope because it was what I had. For
studying this kind of technology you could

use even more basic equipment but,
of course, if you have the higher-end

equipment it’s a lot nicer to work with.

Another microscope I use is the Zeiss
Axiotron. This microscope is designed

for inspecting wafers and has really good
optical quality. I said that more basic

equipment could be used and it’s true.
But when you get into this kind of thing

you might find yourself again and again
investing in more equipment.

I've owed $10.000 in this setup including
the microscope and the camera and the

scanning stage and other parts. To look at
the chip under the microscope requires

that the chip is de-capsulated.
Fuming Nitric Acid is used for this.

The chip is immersed in heated red Fuming
Nitric Acid which reacts with the plastic

packaging and removes it. The chip is then
rinsed in acetone, and cleaned with

isopropyl alcohol in an ultrasonic bath
which leaves the die bare and clean.

The Nitric Acid is quite aggressive,
and it’s important to handle it carefully.

But the process is really straight-forward.
Most people probably wouldn’t want

to do this in their home.

So you should go out to the garage
and use your fume hood there.

After the decapsulation the bare
chips are left with bonding wires attached

to them. So these wires will be plucked
off using tweezers to get them

out of the way. Already in this photo we
can see some of the larger structures

on the chip. Half of it is covered with
a metal plane, and the other half

shows some kind of visible circuitry.

This is an image of the chip under the
microscope. It’s been stitched together

from several smaller images,
to give an overview of the chip.

Looking at the decapsulated chip we see
the bond pads around the outside,

a metal plane covering the top part of the
chip and wires on the bottom of the chip,

the spaghetti logic running all ov er the
place. With a couple of structures

that look like they could be a type of
memory. There’s a lot still hidden

from us. To see more of the chip
it will be necessary to delayer it.

To delayer the chip I used hydrofluoric acid
to perform a wet etch. I used the Whink

Rust Stain Remover product. It’s available
in hardware stores all over the USA.

It’s a dilute HF solution that works
really well for delayering ICs.

I put a small amount of the Whink liquid in
a beaker and heated it on the hot plate.

Then I dropped the decapsulated die in.
Using a pipette I agitated the liquid

to disturb the bubbles that form on the
surface of the chip. So the acid can

actually chip more evenly. The etching
result isn’t perfect. Some parts of the chip

will be etched deeper than other parts.
But I’ve gotten quite useful results using

this technique. You really don’t wanna
breathe in these fumes, so do this

in a fume hood in your garage, also.

After a short time immersed in the heated
Whink solution the chip was rinsed and

put back under the microscope.
Now the top metal plane has been removed

so we can see what’s below. There are
some visual effects that we start to see

in the photo from the etching being
a little bit uneven. But overall

the delayered chip looks quite good and
able to start studying it. At the top left

the tall rectangles are RAM. The four
blocks at the top right are ROM.

And then there’s logic that tie
these into the logic area below.

I was interested in finding how the bits
were encoded in ROM. So I continued

delayering the chip. This was another dip
in the Whink – and another metal layer

has been removed. Bits in the ROM
were not visible yet so I continued

the delayering process. At this point
we’re starting to see more of the visual

effects from the uneven etching but
it’s still not too bad. After a third dip

in the Whink more metal has been removed.
At this point the delayering is becoming

more and more uneven. We can see the
ROM blocks have been half-etched

to a lower layer while half of the upper
layer is still remaining. The wet etching

process can be quite difficult to perform
completely consistently without adding

additional steps such as polishing. And
at the time I did this project I didn’t have

the polisher available so I was relying
only on the wet etch. Some of the areas

of the ROM are now showing visible bits.
The other areas haven’t been etched

deeply enough. So I continued to etch
further to try and get a clean ROM.

We can see the ROM bits quite clearly now.
They’re arranged in rows and columns, and

in this image if a black dot is visible
that indicates that the bit is a One.

Image quality is important. The better the
photographs the more consistently the bits

will be visible. But it doesn’t have to be
really perfect. You can do some image

processing on it, you can even repeat the
process on multiple chips, delayer them

and photograph them, and at some point
you’ll be able to have the entire ROM

clean and consistently visible. With the
visible bits exposed and photographs taken

the bits can be extracted using a software
image analysis tool. Or the bits could be

extracted manually. The ROM here is 32 kB
or over 260.000 bits. So manual extraction

would be a bit labor-intensive but it
isn’t impossible. A software tool is

more efficient. So I wrote some software
to analyze the images and identify

the 1 and 0 bits. There are bits marked
with a yellow box for 0 bits or a blue box

for 1 bits. I use a software to analyze
the image and then I can quickly review

the results manually, and identify any
errors that I can see. After extracting

the bits from the photographs I have
a binary version of the ROM data.

This is a visual representation of the
bits extracted from this piece of ROM.

Little black boxes signify 1 bits,
and the white boxes signify 0 bits.

In this image I’ve overlayed the extracted
bottom 13 rows of bits over the photograph.

You can see some visual patterns inside
this, also. And these visual patterns

are a good indicator that this ROM
is probably not scrambled.

This image shows the end of the ROM where
you can see a pattern covering most of

the image due to a repeated pattern of
filler bytes that occupy unused space

at the end of the ROM. At the very end of
ROM the pattern is interrupted. This is

where the vectors table exists at the top
end of memory indicating the reset address

and the addresses of interrupt handlers.
The ROM has unused space, the filler bytes

at the end. And the vectors table
address is 0xFFF6 through 0xFFFF.

After extracting the bits and decoding them
into bytes the hex dump can be studied.

There is a “Copyright 1997 CHCC” ASCII
string in ROM which is helpful to identify

when the ROM has been decoded correctly.
<i>laughter</i>

If you can read the ASCII text then
surely the bits are in the correct order.

The decoding in this case was just a matter
of organizing the bits into bytes, it’s quite

straightforward, there was no scrambling
or anything else that was complex.

With the ROM contents extracted the
software can be disassembled and analyzed.

The first step was to identify the CPU
architecture. Studying the binary dump

it appeared to be an 8-bit CPU
but wasn’t 8051 or 6805

or any of the processor types I tried
first. Eventually, I tried disassembling

it 6502 and the code made sense. Later
I had remembered that I had looked at

a previous version of the Access
Controller from the same manufacturer.

Which was used in another system,
VideoCipher 2+, an ancestor of DigiCipher.

On the older chip was a Copyright notice
from WDC who licenses the 6502 core IP.

It was visible directly on the chip die
under the microscope.

So this would have been a great clue
for the CPU architecture if I had actually

noticed it earlier. For disassembly I used
IDA. It supports 6502 and is of course

a very powerful disassembler. In addition
to disassembly I used 6502 simulation

software to study the software in
a virtual CPU. The simulation is really

helpful when disassembling the software.
It provides a lot of insight into what’s

going on. Since 6502 is a very well-known
architecture it was not at all difficult

to find an existing simulator. Even free,
with source code. The 6502 is used

in 8-bit computers, like the Apple II,
in Commodore 64. So there’s really

a lot of enthusiasts and a great deal of
information about this architecture.

As I gained understanding of the System
On Chip through disassembling the software

I began adding some other features into
the simulator to emulate some of the

hardware peripherals that were found
inside the ACP, the device itself.

One of the first things I saw in the
disassembly was that there are two

operating modes. During startup values
in RAM are checked. And if the ACP

hasn’t been initialized it enters
a personalization mode used during

manufacturing to assign the Unit Address
and Seed keys. In normal conditions,

after the set-top-box has left the
factory this personalization software

is bypassed and the ACP will always run
its main application. The next thing

I found was the application wasn’t very
simple. This 6502 actually runs

a task switching operating system. Eight
tasks are run supporting decryption

of up to two channels at the same time.
There are two tasks to handle processing

of ECM40 messages and generation of the
Working Keys used to decrypt the transport

stream. And two tasks to handle processing
of ECM41 messages to generate

the Program Keys that are used to process
the ECM40. One task for handling

EMM processing. And there’s also a task to
communicate with the TVpass interface

for security upgrades. With another task
to handle the messages that are coming in

over the SPI interface. Since the ACP
is a custom System On Chip

there is no documentation available
describing the hardware capabilities.

So the disassembly was studied and the
input/output registers had to be guessed

based on the software usage. There’s an
SPI slave peripheral for communication

with the main controller. The SPI
peripheral sends and receives data

directly to RAM. And then a signal is set
indicating that the transport has been

completed. There’s a DES crypto peripheral;

key, data and operating mode are set in
registers. And when the decryption

has been completed the result can be
read from additional registers. There’s

a transport stream descrambler. The Working
Key is set in hardware registers.

And the descrambler will then output the
decrypted transport stream on the serial

transport stream interface. There are PID
filters set by the set-top-box main

controller over the SPI bus. These filters
select which video and audio streams

to descramble and which ECM packets should
be received by the ACP. The received ECMs

are placed in RAM, and the 6502 is notified
of a new ECM via a register bit.

So at this point I’m starting to get an
idea of how the system works.

I have studied the MPEG transport stream
and logged ECM and EMM data.

I’ve logged the SPI bus, and understand
messages between the set-top-box

main controller and the ACP. I was able to
extract the entire ROM contents optically.

And I’ve disassembled the software and run
it in simulation. There are some keys

that are found in ROM. Fixed keys which
never change and are used when a channel

has a “free preview weekend” or something
of the sort. Any set-top-box that has ever

had any kind of authorization in the past
is allowed to decrypt channels that are

encrypted using the “fixed key” mode. So
now the focus is on understanding the ECM

and EMM algorithms within the ROM
software. At this point I’m still missing

some important information from the ACP.
All the Seed Keys, Category Keys and

Program Keys exist only within RAM.
So to decrypt any of the channels

not in free preview isn’t possible yet at
this point. The ECM40 message

is used to generate the Working Key, used
to descramble the MPEG streams.

There’s a Service ID, used to identify
each channel, and a frame count

that’s used with the Program Key
to calculate the Working Key.

The crypt mode identifies if the channels
are operating unencrypted, with a fixed

key, or with the normal secure keys
which are typically used.

The frame count is simply a 24 bit counter
that increments each time the Working Key

changes. There’s a byte I’ve labeled
‘Hardware’ that has one bit set in it.

This selects a special decryption mode
that I’ll come back to a little bit later.

The ECM41 contains encrypted Program Key
that’s needed to correctly decrypt the ECM40.

There’s a Provider ID that indicates which
TV operator subscribers this ECM should

be processed by. And there’s the same
Service ID that will be found within

the ECM40 messages. The Category epoch
identifies which Category Key is in use.

There’s also information about how long
this Program Key will be valid for.

ECM41 contains one or more subscription
tiers that must be found within

the customer’s ACP to allow this message
to be processed. The subscription tiers

are written to the ACP when the EMM
containing authorization details is received.

There is, again, a hardware crypto select
byte that I will get back to.

This slide shows what a half of a second
of ECM40 and ECM41 activity might

look like. To be able to descramble the
program the ACP must process a current

ECM41 to get the Program Key and then
process an ECM40 to get the Working Key.

The Working Key is then used by the
descrambler to decrypt MPEG stream.

Until the ACP receives the ECM41 with the
current key as well as an ECM40 with

the frame count it’s not yet possible
to decrypt the transport stream.

The Working Keys have a short life time,
only 133 ms. The series of ECMs shown here

all would happen within a period of a half
of a second.

The EMMs are split into

four parts. Each part contains a portion
of the subscription information for this

set-top-box. A Category Key is calculated
from each of the four parts and the key

that is calculated for each part has to
match the others, or the EMM will be

rejected, and all authorization in Category
Key will be wiped from this ACP.

When the first EMM, part Zero, is received
the authorization data inside the ACP

is reset and will be replaced with
authorization data from the EMM.

When the next part, part One, is received
the existing authorization data within

the ACP from part Zero is hashed along
with the data in part One. If the result

is correct then the authorization from
part One is copied into the ACP

alongside the existing data from part
Zero. If the result is incorrect then

the ACP’s authorization is erased. In this
way the four EMM messages are linked

together, and if anything is modified
within any of the EMM messages

the authorization will fail.

This is an example of an EMM. Each of the
four EMM parts contains some common

information, like the Unit Address, and
which Category epoch this EMM contains

information for. The EMM can contain two
Category Keys. One for the current epoch

and also for the next so that when there’s
the change of the Category Key the ACP

already has the next key available.
To decrypt the Category Key from the EMM

the Seed Keys contained in the ACP are
used. The Seed Keys are unique to each ACP

and are assigned during manufacturing.
EMMs are transmitted out-of-band

for cable systems but they’re passed to
the ACP in the same way as for satellite

systems. So at the ACP level, there’s no
difference between the satellite and

the cable systems.

At this point it should be possible to
decrypt channels that are using

a fixed-key mode. Analysis of the ROM
has shown the algorithms used to process

the ECMs and generate the Working Key.

The fixed keys are known because they’re
contained in ROM. There could have been

some question about the possibility of
bit errors from the optical ROM extraction

process. But the fixed keys can be
confirmed as correct because the ROM

software performs a checksum of this
256 byte area that contains the keys.

Successfully running the checksum on
the extracted ROM data indicates that

the extracted keys seem to be correct.
But when I attempted to decrypt

a fixed-key channel there was
a problem, it did not work.

Whether it was a bug in my decryption
implementation or something else

was unclear. However, I had noticed the
bit in ECM40 was set that causes a bit

within the ACP hardware peripherals to be
set. The purpose of the bit was unclear.

But its address was suspiciously close to
the transport stream descrambler key.

So I started to suspect that there might
be some encryption other than just

standard DES.

To be able to learn more about the ACP
I started to look at glitchers.

If I can succeed to glitch the chip I may
be able to find a way to read and even

write memory. And possibly a way to run
my own software directly on the chip.

This will allow me to control the hardware
peripherals and be able to observe

the chip’s operation under different
conditions. Timing tests of the ACP

suggest that the 6502 is running from an
internal clock source. So this will allow

a clock glitch attack. A VCC glitch makes
sense, and with the age of this chip

it seemed reasonable to expect that it
would be susceptible to VCC glitches.

The stronger protections against this
type of attack are relatively recent.

My glitcher design is quite simple. It’s
based on an XMEGA development board

and breadboard. I use the XMEGA to
communicate with the ACP over SPI

and to control the glitch. A 74xx series
4053 analog switch is used to quickly

switch the ACP VCC between two voltages,
a normal operating voltage, and a lower

glitch voltage. I use a bench top DC power
supply and two outputs so I can easily

adjust both the normal VCC and glitch VCC
levels. Other parts on the breadboard

are an oscillator to provide some clock
inputs necessary for the ACP to operate

and an inverter and NAND gate to cut out
the clock during the time of the glitch.

To simplify the test setup as much as
possible the ACP was removed from

the set-top-box and soldered to
a break-out board. In this process

the battery-backed RAM was disconnected
and all the keys were lost.

But for the purpose of developing a
working glitch this was okay. The simple,

breadboard-based glitcher is quite
flexible. The breadboard can be modified

to test different ideas, and reconfigured
quickly. More complex and advanced

glitcher wasn’t necessary.

To test the glitcher, to find out if it
will work and what voltage levels

are successful we can send a command
to the ACP, then glitch, and then see

the response from the ACP. The general
strategy is to lower the voltage just

to the point where the chip sometimes
resets due to the glitch.

By adjusting voltage levels and glitch
length and timing when the glitch will end

I succeeded to cause ACP responses to be
altered. The checksum on SPI packets

is very convenient. When unusual data is
received from the ACP chip with a valid

checksum it’s a pretty good sign that the
glitch caused a temporary fault within

the CPU, but their normal operation was
resumed. Depending when the glitch

is delivered different effects are seen.
We can see that generally, as the glitches

moved later, it’s the later bytes of the
response packets that change.

So at this point it looks like the glitcher
works, and is able to cause a pretty fault.

Since I had an effectve glitch I took
the circuit from the breadboard

and etched a simple PCB that I could plug
directly on the XMEGA development board.

This performs exactly the same function
as the breadboard glitcher but

I’m a bit less likely to accidently unplug
a wire from the breadboard and

have to repair things. The circuit was
simple enough that I could create

a one-sided PCB, so it was very easy
for myself to etch at home.

Now my goal is to have the ACP execute
the code of my choice. Because the 6502

is a von-Neumann architecture all code and
data memories share the same address space.

From software disassembly I saw that there
didn't appear to be any paging or MMU

features. The software in ROM is fully
self-contained. There is no EEPROM

and RAM is never used to hold executable
code. So there aren’t jumps into

these areas to exploit and, in fact, it
wasn’t clear if there’s anything preventing

code execution outside of ROM. I decided to
take a chance and test if RAM is executable.

So I sent a message via SPI, knowing that
this message will be stored in RAM.

The message contained 6502 executable code
that will copy itself to an unused area

of RAM, execute from this area and send
an ACK indicating it was successful.

Because I studied the use of the SPI
interface and the ROM code I’m able

to create this executable payload that
will continue to receive commands via SPI

after it’s taken control over the ACP.

To try to maximize chances of success
I looked through the ROM code for

multi-byte instructions, which, if broken
up, would have contained within them

a jump op code with a destination that
should lead to where my executable

payload was placed at RAM. Since the ACP
has a single address space this gives

a lot of opportunities for glitching to
cause execution to reach the payload.

There are multiple scenarios possible in
addition to my selected glitch target.

Stack corruption is a possibility, and
really any abnormal program flow has

some possibility that it could eventually
land in my code. The von-Neumann

architecture, without strong memory
management, is a very fertile ground

for glitching. Anything in RAM
potentially could be executed.

So at this point there are several
uncertainties, but so far nothing

totally rules out the possibility of
success. The ACP operates from

an internal clock source. And the
interrupt-driven task switching

does add some further timing uncertainty.
So I’ll send the code payload,

delay, then glitch, and see the result.
When it’s unsuccessful I change

the delay and I try again.
I tried to aim for the instruction

that I’ve identified as possibly
corruptible into a jump.

But there are a lot of unknowns, so,
really, the processor is like fishing:

throw the line and hope. I have
a target but no way to know if I can

hit it, or if it will have
the expected result.

But sometimes fishing is good.
Relatively quickly the ACP returns

an ACK indicating a successful glitch. The
first successful glitch took some hours

to find. And then, after this it was
possible to make it work repeatedly

in a matter of minutes or even seconds.
So now I have my code executing

in RAM, I’m able to send the ACP
additional pieces of code to be executed.

This allows me to read any memory address,
write any memory address, and perform

any other operations
possible with the 6502.

I wrote a simple application to perform
glitch surges, and then to interact

with the code payload backdoor installed
in RAM. And this program allows me

to enter an address and length and have
data returned. Or write memory etc.

There’s also support for setting the key
and data, and performing DES encrypt

or decrypt using the DES hardware that’s
inside the ACP. A few things I noticed

at this point: there’s a 2 kB area of ROM
that, if I attempted to read it, caused

the chip to reset. This area of ROM
contains the personalization routines

that are never normally used
after the device leaves the factory.

There’s also protection against modifying
the Seed Keys in RAM. Trying to store

a value in these memory locations
appeared to do nothing.

There are specific addresses within RAM
that can’t be read or the chip will lock up.

These are clever traps put in place
as a security measure. The 7-byte

56 bit keys stored in RAM stride all these
dead addresses. So a potential exploit

that could cause a linear dump of memory
will be stopped before a complete key

is ever read. When the chip is reset it
means having to glitch it again, because

my code payload exists only in RAM, and
there is no way to hook in a permanent

backdoor.

Since we can execute code on the ACP the
receiver responds, we can read the ROM

to have its contents without any of the
errors that were introduced during

the optical extraction process. Comparing
the results of the optical ROM extraction

with the proper dump we can see how many
errors were in the optical extraction.

Overall the optical extraction was quite
good. It was, after all, good enough

to understand the software and get us to
this point. There is only one byte with

more than a single incorrectly flipped
bit. Many of the errors that existed

were quite obvious from disassembling the
software. If an instruction is out of place

but flipping a single bit would make it
sensible then it was probably a bit error.

I didn’t keep detailed records but I think
I probably caught about half of the ROM

errors during the disassembly process
before I started glitching.

The interesting keys in the ACP are all
stored in RAM only. This includes

Working/Program/Category and Seed Keys.
The RAM is battery-backed.

If the Seed Keys are ever lost from RAM
this ACP can no longer process EMMs

and so is useless. It’s possible to glitch
the ACP and read memory, but the glitcher

works on an ACP removed from their
set-top-box. When the ACP is in-circuit

the connections to other components and
16 VCC-connected pins pose the problem.

To glitch the ACP in-circuit we’ll require
some modifications to the set-top-box

disconnecting the ACP from other parts.
Or, another alternative is to remove

the ACP from the set-top-box and place it
on a breakout board without loosing

the battery power and wiping RAM. Rather
than modify the set-top-box, where each

of several different models would have
required unique modifications I decided

to try to remove the ACP with the battery
still attached. The plan is to carefully

lift the Battery and Ground pins while the
set-top-box is powered on providing VCC.

I use a small tool I made from a razorblade
using a Dremel tool, then attached

the handle of a screw driver. This tool
can be wedged under a pin, then with

some hot air the solder will melt and
a single pin can be lifted straight up

without damaging any of the other pins.

With the pins lifted an external battery
can be attached.

After attaching an external battery…

<i>applause</i>

After attaching an external battery the
set-top-box is unplugged, and the ACP

can be removed from the set-top.box using
hot air. The ACP can be removed from

the set-top-box, glitched, and can even be
placed back in the set-top-box, if desired.

To do this I just use hot air and a lot of
flux. Additionally, once the interesting

keys have been extracted it may not even
be necessary to replace the ACP

in the set-top-box. The ACP is now placed
on a breakout board and connected

with the glitcher. Not all the pins need
to be connected. Only a handful of pins

are actually used by the glitcher. You can
also see at this point the glitcher is

in a project box. The aesthetics greatly
improved since the breadboard-based

glitcher. But the functionality is
identical. The timing of ACP responses

is different on a chip with valid RAM
compared to the previous chips

that I had glitched before. I didn’t
confirm whether the cause of the timing

difference was due to a different
oscillator configuration or just

a different software path. But by
adjusting the timing of the glitches

the executable code payload runs as it did
on the previous chips. So now we can read

the RAM contents of a valid ACP, including
the Category Keys, if the set-top-box had

current authorization, as well as the Seed
Keys that are used by this ACP to decrypt

EMMs. With a valid Category Key ECMs can
be decrypted, and a cracked Working Key

can be calculated for any channel. Now,
with the capability of running my own code

of the ACP it’s time to look at the
transport stream descrambling.

There’s a hardware register bit that
is set or cleared, based on a byte

in the ECM40. When this bit is cleared
standard DES decryption is used.

When the bit is set the transport stream
descrambler acts differently. Additionally,

there’s an 8-bit hardware register in the
DES peripheral area. When it’s Zero

the peripheral operates the standard DES.
For any other value the peripheral acts

differently. At this point I started to
think I might be looking at doing

a Gate-level reverse engineering of the
chip to understand this functionality.

The chip is using technology that’s older.
So reverse-engineering should be feasible.

But, if possible, I’d like to avoid all
this extra work. It would be quite

time consuming, and might give imperfect
results, similar to the optical ROM

extraction. So I started with trying to
characterize descrambling modes.

The transport stream packet is made up
of a 4-byte header and 23 blocks of

8 bytes each. The DES operates
on these 8 byte (64 bit) blocks.

By flipping one bit in encrypted input ECB,
CBC or OFB modes can be differentiated.

Flipping one bit causes an 8-byte block
to be corrupted, and the corresponding bit

in the following block to be flipped.
This indicates CBC mode is in use.

Timing of the input compared to the
decrypted output was measured with

the descrambler and standard DES,
and in the custom hardware mode.

No timing difference was seen. This
suggests the internal properties of DES

haven't changed. Which makes sense
because the decryption has to be done

in realtime. So this suggests that crypto
customizations are not affecting

some DES internals like the number of
rounds. Also by using ACP as a decryption

oracle I determined that the customization
affects each of the 23 blocks of the

transport stream differently. Next
I tested the software using DES ‘weak keys’.

These are certain keys not recommended
for use with DES because their properties

weaken the cryptographic strength.
A key of all Zero or all One bits

will cause DES decryption and encryption
to be identical. That is running the same

data through Encrypt or Decrypt will give
the same result. I can test this on an ACP

configured for standard DES decryption
and see the expected ‘weak key’ behavior.

When tested with the descrambler in custom
mode the ‘weak key’ behaviour changes.

Using a key of all Zero or all One didn’t
produce the same results in Encrypt

and Decrypt modes. Looking at the other
hardware register, testing the DES

peripheral with different values in the
8-bit register, and using ‘weak keys’,

shows that the standard DES ‘weak key’
behaviour still exists. So my hunch

at this point is that one customization
affects the key, and the other customization

affects the data. At this point I can’t be
certain, but I have a good feeling about

the theory, so I continue to investigate.

Based on the idea that the hardware
customization affects only the key

and decryption is static I thought the
simplest customization will be an XOR

mask that’s applied to the key before it’s
used for DES decryption. XOR requires

only a single gate in series of the DES
engine so it fits the requirements of

fast and very simple implement in
hardware. A change of even a single bit

in the key could cause the observed
effects. Flipping more than 28 bits

will be pointless. That’s the same as
inverting a key and flipping fewer bits.

More flipped bits means more gates
necessary for the customization, so

it makes sense to flip a minimal number
of bits. So I wrote this wonderful FOR loop,

nested 16 levels deep, to test decryption
results after flipping one bit of the key,

then flipping two bits, then three bits
etc. of the 16 bits. To test all the

possible keys will take a long time. But
if only a few bits are flipped then it

might be possible to run it in a shorter
period of time. And promising results

did come quickly. It turns out the theory
held up. And some of the blocks have

as few as three bits flipped. This takes
only seconds for the software to identify.

After verifying that these work for XOR
masks, for these logs the software then

was left running to find all 23 masks.

The simple brute-force method worked,
it ran for a couple of days to identify

all the 23 masks. By more carefully
analyzing which bits were being flipped

in the early results a pattern can
actually be found. So the search could

have been more limited. Using this
technique the software cracker could have

completed it in under a second.

After successfully solving the first
hardware customization the theory

that the second customization is
a Data XOR looks promising. It makes sense

that one or more XOR gate is enabled by
each bit of the 8-bit hardware register.

Using the ACP as a decryption oracle
a known key in Data were decrypted

with all values of the 8-bit register.
Software attack of this function

was successful, and 255 XOR masks were
identified, behavior matching what was

expected. I haven’t actually seen this
customization in actual use. Presumably,

they’re saving it to be used as
a countermeasure against pirate devices

when necessary. But it hasn’t been
necessary since the system never had

a security breach.

<i>laughs</i>
<i>applause</i>

In order to implement a Softcam, a software
implementation of the descrambler,

a few cryptographic details need to be
identified. But at this point I have

all the tools to do so. The initialization
vector used for CBC mode can be found

through simple XOR. And the handling of
short blocks – those less than the

64 bit DES block size can be identified
likewise. With all these details

a software implementation of the
EMM decryption of Category Key and

ECM decryption of Program Key and Working
Keys can be made and the transport stream

descrambler can also be implemented in
software. The rapid key changes and the

use of DES with h/w customizations makes
it a bit different to implement, compared

to a Softcam for typical DVB systems,
but overall the concept is the same.

And now it’s all working! I was able to
test it, and it’s fully working on both

the satellite and cable systems. This
is a screen that’s broadcast before

a pay-per-view event goes live. The
pay-per-view, like all other channels,

can be decrypted with the Softcam using
the algorithms learned in these keys that

were extracted. With the ECM and EMM
algorithms and Seed Keys for a set-top-box

with any level of authorization the
Category Key can be decrypted

and then used to decrypt any and all
of the channels that are broadcast

by this provider.

<i>applause</i>

A few of the weaknesses that I identified
in this system were that the ACP I studied

is relatively old technology, almost
20 years old. So this makes it a lot

easier for invasive analysis today
than one that was brand new.

The TQFP100 package is quite easy to deal
with compared to modern alternatives.

The chip is susceptible to voltage
glitching. It’s a van-Neumann architecture

without strong MMU protection preventing
code to be executed from RAM.

They didn’t leave any possibility for code
update or dynamic code execution

for countermeasure purposes. The software
for the ACP is contained entirely in ROM

with no mechanism for software updates in
the field. The hardware customizations

to the crypto were quite simple and
required no reverse-engineering

of the chip logic. I was basically able to
guess the hardware customizations.

I was impressed with the design of the
system. It was actually stronger than

I anticipated when I started the project.
All the key handling and decryption

is contained within a single chip which
makes it impossible to do key sharing

that’s being done with some of the
smartcard systems. The fast Working Key

change interval – only a 133 ms – also
makes key sharing more difficult.

And the short lifetime of the key makes
cracking it in realtime quite unrealistic.

The lack of code in any rewritable memory
means there’s nowhere to write code for

a permanent backdoor to disable the
access controls. I listed this also as

a weakness but in fact this is a strength
as it limits the attacker’s capability

to install any kind of persistent
backdoor. The chip operates

on an internal clock eliminating clock
glitch attack and making timing

a voltage glitch a lot more difficult.
These dead addresses in the middle

of DES keys prevent linear readout of
keys. If one were to cause a loop reading

data to go out of bounds and reach the
area of RAM where keys are stored

the chip will reset before an entire key
is read. After the first couple of bytes

a dead address will be accessed that
causes the chip to reset.

The personalization ROM appears to be
inaccessible so it can’t easily be used

to modify the keys and Unit Address
within the ACP. The Seed Keys

aren’t easily changed so the
set-top-boxes can’t easily be cloned.

The keys exist only in RAM so you have to
maintain a battery backup at all times.

This rules out a lot of invasive attacks
to retrieve the keys. And there are

no group keys used for EMMs. All the
unit addressing is to individual units.

So you have to pull keys from an actively
subscribed box in order to get active keys.

That said if you have keys from a box
that is subscribed to any channel

you’ll receive an EMM containing the
Category Key which is capable of

decrypting all channels. So you don’t need
to have a subscription to all channels

you want to decrypt as long as you’re
authorized for at least one channel

on the system.

The software is generally well designed
and written. I didn’t notice any glaring

bugs within it. Although DES is used the
EMM decryption requires using three

DES keys, and multiple rounds are
performed when decrypting EMM and ECMs.

So this part isn’t as simple as
cracking a single 56-bit key.

Brute-forcing, starting from the encrypted
transport stream requires cracking

Working Key, then Program Key,
then Category Key and, finally,

the three Seed Keys.

You might wonder how many set-top-boxes
it took for me to complete this project!

<i>laughter and applause</i>

The truth is I only needed the one…
…truck load!

<i>laughter</i>

Some of the boxes had different versions
of the ACP chip. Many of the boxes had

different PCB layouts. So it was
interesting to be able to look at

a variety of boxes. The cost of used set
top boxes was low, ca. $20. And for

this research I was focusing on the signal
security and didn’t need the PVR

functionality or any of the advanced
features from the expensive set-top-boxes.

So at this point I have a brief anti-piracy
message: I don’t recommend you pirate

cable or satellite TV. There is never
anything good on. It doesn’t matter

how many channels you can decrypt.
Believe me – I looked!

It’s not worth the effort!

<i>laughter and applause</i>

Herald: Do we have questions
from the room?

Questions – please use the microphones.

I know there is one question
from the interwebs.

Signal Angel: Okay, hello.
This is working? Good.

So the first question from the internet
is: how many chips did you destroy

or make unusable, and how did you
get all those set-top-boxes?

Chris: Because the cost of the used
set-top-boxes was quite low I wasn’t

afraid to destroy several chips in the
process. It didn’t take as many

as I would have expected in the beginning.
Two or three chips were used for the

decapsulation and the delayering process.
I ended up extracting the ROM

from a single chip. And then, when
it came to glitching, there were

three or four chips that I removed and
erased the RAM from to develop the glitch.

When I finally got to the point where
I was extracting keys from a valid chip

the very first chip that I tried worked.
So there were few casualties involved!

Herald: Thank you! Microphone 3
was the first one, please!

Mic3: How many years
did this project take you?

Chris: I would work for a few weeks at
a time and then get burned out and

take a break, and then come back to it.
Most of the work for the project

was completed over about a 2-year period.

Herald: Thank you. And…
Microphone 2, please!

Mic2: Hi, thank you for a great
lecture. How comes that

the content decryption was DES and
not a DVB-CSA because we're used

that content is encrypted
with DVB-CSA in these DVB systems.

Chris: In North America we
don’t believe in standards!

<i>laughter</i>

Mic2: Thanks!

Chris: The timing was also a part of it.
The system was being developed

at the same time as DVB was being
standardized. So General Instrument

rather than going along with the Standards
Group and waiting for the standardization

they went with DES, directly.

Herald: Thank you. And another one
from Cyber-Cyber… space!

Signal Angel: Okay. Another question from
the internet is: you have all this fancy

like lab equipment stuff. How were you
able to afford that?

Chris: I’ve been quite interested in this
for a long time. So I’ve collected

this equipment over a period of years.
And I do some work, professionally,

in reverse-engineering. So whenever
possible I use our client’s money

to buy another piece of
equipment for the lab.

To do this actual work, though, you could
even use more basic equipment

because of the age of the chip. You could
use a microscope that you could find

easily for $1.000 .. $2.000 or even less
and have quite good results.

So it’s not trivial but it’s not a huge
amount of money for a lab equipment!

Herald: Not that huge!
Microphone 2, please!

Mic2: What do you do for a living
besides reverse-engineering?

Chris: Reverse-engineering!
<i>laughs</i>

Herald: Thank you. And the internet!
Again.

Signal Angel: Okay. Next question is…
somebody wants to know how…

…which software did you use for the
automated image analyzing, and

is it available somewhere?

Chris: Like everybody else that I’ve known
that’s done optical ROM extraction

I developed it myself. Everybody seems
to develop their own tools from scratch

for that. The image processing I used was
really quite simple. So it didn’t take

a lot of advanced algorithms or anything
like that. So I’m using some software

I developed personally, and
it hasn’t been released.

Herald: Microphone 2, please!

Mic2: And how did you keep the boxes
subscribed? So did you call them

every week “Oh, my box broke down,
I got another one”, or how is this done?

Chris: For most of the research that
I did I didn’t need an active box. I did

all the research just on previously
activated boxes that had lost their

authorization. And by the time I had the
process figured out, that I knew how

to extract keys from a valid box
I only needed the one box.

Mic2: And had you heard back
from the cable provider about this?

Chris: No.

Herald: Okay, thank you.
Microphone 3, please!

Mic3: Hello, thanks very much for the
lecture and ‘well done’ on all the work!

My question is: how does the glitching
work, the glitching attack?

Chris: The glitcher was quite simple.
I drop the voltage for a very brief period

of time. And it’s enough time that it
causes at least one instruction to

not execute properly. But it’s too short
of a time to cause the chip to reset.

So essentially I’m corrupting one
instruction. It is for the specific target

that I hit that led to my code in RAM.
I’m not actually sure. I found that

if I glitch it this time then the code
ends up executing my code –

good enough for me!

Herald: Okay. Thank you, Chris!
Please, dear audience,

give an Anniversary Edition
applause to Chris Gerlinsky!

<i>Anniversary Edition applause</i>

<i>postroll music</i>

<i>subtitles created by c3subtitles.de
in the year 2018</i>