unlock

How Do I Crack Satellite and Cable Pay TV? (33c3)

[Music]

so coming over to our next talk tonight

if you switch off your deck phone and if

you're full of different impressions

full of different impressions of this

day you maybe want to watch TV but it

would be cool to have pay TV unencrypted

prey TV so Chris Galinski 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 unequipped it since the

late 90s please welcome with an

anniversary edition applause Chris

kolinsky

[Applause]

hello everyone my name is Chris Carr

linskey I am a hacker from Canada and

I'm here today to talk about how I crack

digital cable and satellite TV security

I studied an access control platform

that's widely used across Canada in the

USA it's one of the two common platforms

that's used in cable TV and it's also

used in satellite TV by one of the two

Canadian satellite TV operators as far

as I know the system has remained secure

since it was introduced in the 1990s and

I was curious if I could understand the

system based on the older set-top boxes

some of them are 15 years old and

they're still in use so these devices

haven't received upgraded security

hardware in that time and I started

looking at how 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 television are pretty similar

for the most part there are a variety of

signal modulations used the relevant

ones here are QPSK at about 27 megabits

and 8 PSK turbofolk at about thirty

eight megabits for satellite and QAM 256

at about thirty eight megabits for cable

there's also an out-of-band channel used

by cable which is QPSK modulated at two

megabits this outa Bantul carries the

subscription management program guide

information firmware upgrades etc and

while you change channels and the cable

box Tunes to different frequencies this

outer band channel remains tuned so that

the Box continuously receives this data

no matter what TV channel you are tuned

to in the satellite TV this type of data

is included within the main transport

stream instead of in a secondary out of

an transport stream the video is sent as

mpeg-2 or h.264 transport stream this is

a standard format for carrying video

streams so we can be played by any

hardware video decoder or a software

decoder for example VLC and the

encryption system used here is called

digisight for two

which does not follow the DVB standards

that are used in the rest of the world

the MPEG transport stream is made up of

packets of 188 bytes each packet has a

pid' this is used to differentiate

different types of data

pidz range from zero to x1 f FF each Pig

carries an MPEG packetized elementary

stream that's a video or audio stream or

the pit may carry one or more service

information tables the service

information tables have an 8-bit table

ID and a length of up to a thousand 24

bytes

including a CRC 32 for error detection

and this table ID identifies the type of

data that you can expect within the

table table 0 is the program association

table containing a list of programs

carried in this transport stream and the

PMT pit for each program the program

association table is always on pit 0

table 2 is the program map table which

contains the list of packetize

elementary streams and the pit for each

as well as an ECM pit there's a program

map table for each MPEG program or TV

channel that's found in the stream the

ECM pit is where entitlement control

messages are sent containing information

that's used to Det generate the key that

decrypts the packetized elementary

streams this system uses two types of

ECM table 40 I call ECM 40 and table 41

I call ECM 41 on pit one there may be

one or more conditional access tables

table ID number one these tables

identify a pit that carries EMS

entitlement management messages these

messages are used to set access rights

for individual set-top boxes the

subscription information like what

channels are available is carried inside

of EMS this is a hardware interface to

receive satellite data Jen picks

Skywalker one the dc2 QPSK modulation

isn't widely supported in the US v or

PCI dvb-s

devices and the 8-psk turbofolk

modulation support is even less common

and one of the devices that does support

these signals is this chat

Fix device which is using a Broadcom BCM

for 500g modulator and it supports both

the dc2 QPSK and the 8 PSK modulations

it works well the Linux drivers need to

be recompiled to include the support for

these modes and patches for this we're

published by update Lee there's a link

on the slide for cable there's a variety

of adapters supporting QAM 256

demodulation I use the USB hvr 950 Q

tuner unfortunately two to 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 chipset

and for the clear QAM consumer devices

such as USB interfaces access to the

outer band data isn't actually required

and so they don't include it inside of

the hardware this outer band data is

used only for pay-tv services with the

satellite and cable interfaces DVB snoop

can be used to view a lot of information

about the transport stream it's enough

information to be quite overwhelming so

the trick using it is to being able to

sift through the output for the relevant

information DVB snoop also doesn't

recognize all of the digits i42 tables

because it's a non-standard system and

DVB snoop is targeted towards the

standard systems so DVB snoop may not be

able to tell you everything about the

transport stream but it was still a very

useful tool for all the information that

it can provide DVB snoop and most other

tools and documentation or deveined

designed for the DVD standard or other

recognized standards such as atsc

digital for 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 SCT e65 there is no BA T

or SD T as you'd expect in DVB instead

there is a virtual channel table that

map's the transport streams and programs

to channel numbers the electronic

program guide is also not DVD standard

so you don't even get the current index

program information

kind of a standard format another cable

TV adapter is the HD homerun prime this

one is a network connected three tuner

device with cable card support the

set-top boxes I studied predate the

cable cards although the newer boxes do

use the cable cards and they support the

digits i42 but cable card support does

also mean that this HD homerun prime

includes the tuner and kpf QPSK

demodulator for the out of an channel so

it is able to pass this data to the

cable card as necessary however even the

HD homerun doesn't make this out of and

data available other than the cable card

interface so to access the demodulated

out of and data I tapped into the HD

homerun Prime with a cable card inserted

and connected a logic analyzer to the

data and clock signals I wrote software

using the salia SDK to capture the QPSK

demodulated data then in software I

perform the interleaving D randomization

in the forward error connection and the

output is an MPEG transport stream so

using an HD homerun prime connected to

the logic analyzer connected to the PC

running the software the output finally

is the 2 megabyte transport stream and

this transport stream looks like a

standard transport stream and inside are

the conditional access management

messages program guide information in

etc everything that was missing from the

main QAM transport stream 2 bits in each

packet but 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 would change every five to

thirty seconds DC to every 133

milliseconds or one 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 decoy

the descrambler uses a working key this

is a 56 bit desk key that changes every

133 milliseconds or in some cases they

have it slowed down to changing every

one second this working key is generated

by encrypting the frame count from ECM

forty packets with the program key the

program key again des comes from the ECM

forty-one message and is encrypted with

a category key the program key is unique

to each channel and it changes daily or

for every pay-per-view event the

category key also des is shared by all

the set-top boxes that are authorized

for any channel from this provider the

category key is sent to each set-top box

individually inside the EMM ninety-five

message and this category key typically

changes monthly but many cable operators

change keys much less frequently some of

them using the same key for years at a

time to decrypt the EMM in order to get

the category key seed keys or use 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 EMS so this

forms a chain from the seed keys

initialize drug manufacturing and never

changing to the decryption of the MPEG

transport stream inside a set 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 laia and 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 is a

TV pass slot near the power supply this

is an upgrade slot with a card hedge

connector to allow for security upgrades

the system stayed secure so the TV pass

slot was never used and the newer

set-top boxes don't actually include

a TV past slot inside so at this point

it seems quite unlikely that this TV

pass card will ever actually be used

inside a cable set-top box it's very

similar to a satellite set-top box but

the cable box is tend to be more tightly

integrated signal enters the tuner and

passes through a Broadcom chip that

handles demodulation and the same trip

will also handle MPEG decoding after the

transport stream has been decrypted by

the ACP a 68k microcontroller acts as

the set-top box main controller again

talking the ECP via spi and a battery

provides backup power to the ACP and

also to the non-volatile Ram used by the

main controller a TV pass slot is

underneath the mainboard

it's not visible in this photo the cable

set-top boxes include a second tuner

that's used to receive the outer band

data this Oda band tuner operates

independently of the main tuner and on a

separate C frequency range and it's used

to provide a transport stream containing

the system information with the program

guide for more updates emmc etc here we

see the ACP chip it's a 100 pin T QFP

package from the markings we can see

it's a custom system-on-chip

made for general instrument corporation

g i see all the decryption is performed

by the ACP and all the encryption 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 box is using this chip or

actively used it remains irrelevant

target whether the newer ACPs include

more advanced security features or if

they exist only for cost savings due to

shrinking the die size I don't really

know some of the interesting pins on the

ACP are labeled here pin 1 is marked at

the top left corner of the chip there's

an SPI slave controller on pins 1 to 5

used for communication with the set-top

box main controller there's a battery

backup pin that's connected to a 3 volt

battery to keep the RAM contents of the

ACP intact at all times there's a serial

transport stream input on pin

88 to 92 which receives the data from

the demodulator and there's a serial

transport stream output on pins 28 to 33

which sends the decrypted transport

stream from the MPEG to the MPEG decoder

to be output to the TV at one point I

had written software for an AVR 32

device not the one that shown here that

has a synchronous serial peripheral that

supports sending and receiving data at

the 27 megabit rate of the transport

stream my AVR 32 implementation turned

out a bit ugly but rather than cleaning

it up I was able to use it as it was it

had some limitations like only accepting

64 kilobytes of data for replay logging

which was just barely good enough for my

studies what the transport stream

logging in circuit did show me was that

the transport stream passes through the

ACP with selected pits being decrypted

and then the output is the full

transport stream but a selected program

has been decrypted the AVR 32 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

remove 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 X mega AVR platform to

send and receive the transport stream

through the ACP at a much slower bitrate

shown here is the X mega platform I

settled on using 4 SPI and also the

transport stream interfacing to honor

the data pass between the set-top box

main controller and the ACP on the SPI

bus I use the X mega development board

to SPI a ports which acted as slave with

the master out slave in signal connected

to 1 and master in slave out signal

connected to the master out slave in

input of the second port so for one port

byte sent by the set-top box controller

are received from the other port it

receives bytes from the ACP in case I

want to talk directly to the ACP or the

set-top box main controller it's only

necessary to connect both the mazi and

my so signals on one of the SPI

interfaces by holding the main

controller in reset my X mega was able

to act as the SPI master and then talk

to the ACP

so this sad talk works for passively

monitoring the SPI communications in the

set-top box and can also act as the SPI

master for indicate interrogating the

chip directly by logging the SPI bus

between the main controller of the ACP

we see that information about the

current access levels is sent from the

ACP the ACP also receives EMM s via the

SPI bus

EMM s 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 zero four includes the current

category key epochs and key selects in

use command zero five includes the unit

address number command 13 returns the

authorized subscription tiers for this

unit command seven and eighty-seven

provide information about the channel

being currently decrypted additionally

via the SPI interface the set-top box

main controller tells the ACP which pins

to decrypt and which is the ECM pit

the ACP doesn't send any keys on the bus

and it only receives category keys that

are encrypted within a MMS 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

[Music]

so next I started an invasive study of

the chip studying it under a microscope

the cost of microscopes can range from

hundreds of dollars to tens of thousands

of dollars or even higher for things

like electron microscopes or other

specialized equipment though I have a

couple of microscopes that I use this

one is the meter Toyo FS 7d microscope

these meter Toyo are often used for

micro probing but you can also use it

for other uses for this project I didn't

do any micro probing but I used this

microscope because it was what I had for

studying this kind of technology you

could use even more basic equipment but

of course if you have the higher-end

equipment it's a lot nicer to work with

another microscope I use is a Zeiss

axial Tron 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

about ten thousand dollars in this set

up 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 D

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

removes it the chip is then rinsed in

acetone and cleaned with isopropyl

alcohol in an ultrasonic bath which

leaves the dye bare and clean the nitric

acid is quite aggressive and it's

important to handle it carefully but the

process is really straightforward most

people probably wouldn't 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's covered with a metal

plane and the other half shows some kind

of visible circuitry this is an image of

the chip under the microscope it's been

stitched together from several smaller

images to give an overview of the chip

looking at the D capsulated chip we see

the bond pads around the outside a metal

plate covering the top part of the chip

and wires on the bottom of the chip the

spaghetti logic running all over the

place with a couple of structures that

look like they could be a type of memory

there's a lot still hidden from us to

see more of the chip it will be

necessary to Dallaire it to D layer the

chip

I used hydrofluoric acid to preform a

wet etch I use the wink rust stain

remover product it's available in

hardware stores all over the USA it's a

dilute HF solution that works really

well for delayering ICS

I put a small amount of the wink liquid

in a beaker and heat it on the hot plate

then I dropped the D capsulated dye in

using a pipette I agitate the liquid to

disturb the bubbles that form on the

surface of the chip so the acid can

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 want to breathe in these fumes so

do this in the fume hood in your garage

also after a short time immersed in the

heated wing 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

dealership looks quite good and is able

to start studying it at the top left the

tall rectangles are round the four

blocks at the top right or ROM and then

there's logic that tie these into the

logic area below I was interested in

finding how the bits were encoded and

wrong so I continued delayering the chip

this was another dip in the wink and

another metal layer has been removed

bits in the row were not visible yet so

I continued the D layering process at

this point we're starting to see more of

the visual effects from the uneven

etching but it's still not too bad after

a third dip in the wink more metal has

been removed at this point the D

layering is becoming more and more

uneven we can see the wrong blocks a bit

half etch to a lower layer while half of

the upper layers 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 continue to etch further to try and

get a clean ROM

we can see the wrong bits quite clearly

now there are 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 do you layer them and

photograph them and at some point you'll

be able to have the entire ROM clean and

consistently visible with the visible

bits exposed and photographs taken the

bits can be extracted using a software

image analysis tool or the bits could be

extracted manually the ROM here is 32

kilobytes or over 260,000 bits so a

manual extraction would be a bit labour

a bit labor-intensive but it isn't

impossible a software tool is more

efficient so I wrote some software to

analyze the images in identify the one

in zero bits they're a bit smart with a

yellow box for zero bits or a blue box

for 1 bits I use the software to analyze

the image and then I can quickly review

the results manually and identify any

errors that I can see after extracting

the bits from the photographs I have a

binary version of the ROM data this is a

visual representation of the bits

extracted from this piece of ROM the

black box to signify one bits and the

white boxes signifies 0 bits in this

image I've overlaid the extracted bottom

13 rows of bits over the photograph you

can see some visual patterns inside this

also and these visual patterns are a

good indicator that this ROM is probably

not scrambled this image was 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 a

new space at the end of the room at the

very end of ROM the pattern is

interrupted this is where the vectors

table exists at the top end of memory

indicating the reset address and the

addresses of interrupt handlers the ROM

has unused space the filler bytes at the

end and the vectors table at address is

ffff 6 through ffff after extracting the

bits and decoding them into bytes the

hex dump can be studied there is a

copyright 1997 C HC

the ASCII string and wrong which is

helpful to identify when the ROM has

been decoded correctly if you can read

the ASCII text and surely the bits are

in the correct order the decoding in

this case is just a matter of organizing

the bits into bytes it's quite

straightforward there was no scrambling

or anything else that was complex with

the ROM contents extracted the software

can be disassembled and analyzed the

first step was to identify the CPU

architecture studying the binary dump it

appeared to be an 8-bit CPU but wasn't

8051 or 6c 805 or any other of the

processor types I tried first eventually

I try disassembling a 6502 in the code

made sense later I had remembered that

I'd looked at a previous version of the

Access Controller from the same

manufacturer which was used in another

system video cipher - plus an ancestor

of digits ifer on the older chip was a

copyright notice from WDC who licenses

the 6502 core IP it was visible directly

on the chip die under the microscope so

this would have been a great clue for

the CPU architecture if I'd actually

notice it earlier for disassembly I used

Ida

it supports 6502 and is of course a very

powerful disassembler in addition to

disassembly I use 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 2 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 of the features into

the simulator to emulate some of the

hardware peripherals that were found

inside the ACP device itself one of the

first things I saw 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 the 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 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 ECM 40 messages and

generation of the working keys used to

decrypt the transport stream and 2 tasks

to handle processing of ECM 41 messages

to generate the program keys that are

used to process the ECM 41 tasks for

handling

EMM processing and there is also it has

to communicate with the TV pass

interface for security upgrades with

another task to handle the messages that

are coming in over the SPI interface

since the ACP is a custom system-on-chip

there is no documentation available

describing the hardware capabilities so

the disassembly was studied and the

input-output registers had to be guessed

based on the software usage there is an

SPI slave for referral for communication

with the main controller the SPI

peripheral sends and receives data

directly to RAM and then a signal is set

indicating that transfer has been

completed there is a desk crypto

peripheral key data and operating mode

or set in registers and when the

decryption has been complete the result

can be read from additional registers

there's a transport stream descrambler

the working key is set in hardware

registers and the descrambler will then

output decrypted transport stream on the

serial transport stream interface there

are paid 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 ace the received ECMs are

placed in round and the 6502 is notified

of a new ECM via register bit

so at this point I am starting to get an

idea of how the system works I've

studied the MPEG transport stream and

log ECM and EMM data I've logged the SPI

bus and understand messages between the

set-top box main controller the ACP I

was able to extract the entire ROM

contents optically and I've disassembled

the software and run it in simulation

there are some keys that are found in

ROM fixed keys which never change and

are used when a channel has a free

preview weekend or something of this

sort any set-top box that has ever had

any kind of authorization in the past is

allowed to decrypt channels that are

encrypted using the fixed key mode so

now the focus is on understanding the

ECM and EMM algorithms within the rom

software at this point I'm still missing

some important information from the ACP

all the seed keys category keys and

program keys exists only within Ram so

to decrypt any of the channels not in

free preview isn't possible yet at this

point the ECM 40 message is used to

generate the working key used to

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 operating unencrypted with a

fixed key or with a normal secure keys

which are typically used the frame count

is simply a 24 bit counter that

increments each time the working key

changes there's a byte I've labeled

hardware that has one bit set in it this

selects a special decryption mode that

I'll come back to a little bit later

the ECM 41 contains encrypted program

key that's needed to correctly decrypt

the ECM 40 there's a provider ID that

indicates which TV operator subscribers

this ECM should be processed by and

there's the same service ID that will be

found within the ECM 40 messages the

category epoch identifies which category

key is in use there's also information

about how long this program key will be

valid for ECM 41 contains one or more

subscription tiers that must be found

within the customers ACP to allow this

message to be processed the subscription

tiers are written to the ACP when the

EMM containing authorization details is

received

there is again a hardware crypto select

byte that I will get back to this slide

shows what a half of a second of ECM

forty and ECM forty-one activity might

look like to be able to descramble the

program

the ACP must process a current ECM 41 to

get the program key and then process an

ECM 40 to get the working key the

working key is then used by the

descrambler to decrypt MPEG stream until

the ACP receives the ECM 41 with the

current key as well as an ECM 40 with

the frame count it's not yet possible to

decrypt the transport stream the working

Keys have a short lifetime only 133

milliseconds the series of ECM shown

here all would happen within a period of

a half of a second the EMM s are split

into four parts each part contains a

portion of the subscription information

for this set-top box a category key is

calculated from each of the four parts

and the key that is calculated for each

part has to match the others or the EMM

will be rejected and all authorization

and category key will be wiped from this

acp when the first EMM part zero is

received the authorization data inside

the ACP is reset and will be replaced

with authorization data from the EMM

when the next part part one is received

the existing authorization data within

the ACP from part zero is hashed along

with the data in part one if the result

is correct then the authorization from

part one is copied into the ACP

alongside the existing data from part

zero if the result is incorrect then the

ACPs authorization is erased in this way

the four EMM messages are linked

together and if anything is modified

within any of the EMM messages the

authorization will fail this is an

example of an EMM each of the four EMM

parts contains some common information

like the unit address and which category

epoch this EMM contains information for

the EMM can contain two category keys

one for the current epoch and also for

the next so that when there is the

change of the category key the ACP

already has the next key available

to decrypt the category key from the ECM

from the EMM the seed keys contained in

the ACP are used the seed keys are

unique to H ACP and are assigned during

manufacturing EMM s are transmitted

out-of-band for cable systems but

they're passed to the ACP in the same

ways for satellite systems so 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 ECM and

generate a working key the fixed keys

are known because they're contained in

ROM there could have been some question

about the possibility of bit errors from

the optical rom extraction process but

the fixed keys can be confirmed is

correct because the wrong software

performs a check some 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's 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

ECM 40 was set that causes a bit within

the ECP hardware peripherals to be set

the purpose of the bit was unclear but

its address was suspiciously close to

the transport stream descrambler key so

I start to suspect that there might be

some encryption other than just standard

des to be able to learn more about the

ACP I started to look at glitching

leadership 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 chips operation under

different conditions timing tests of the

ACP suggests that the 6502 is running

from an internal clock source so this

ruled out a clock glitch attack a VCC

glitch makes sense and with the age of

this chip it seemed reasonable to expect

that it would be susceptible to VCC

glitches the stronger protections

against this type of attack are

relatively recent my glitcher design is

quite simple it's based on an X mega

development board and breadboard I use

the X mega to communicate with the ACP /

SPI and to control the glitch

a 74 series 40:53 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

breakout board so in this process the

battery back Ram was disconnected and

all the keys were lost but for the

purpose of developing working glitch

this was okay this simple breadboard

base glitcher is quite flexible the

breadboard can be modified to test

different ideas and reconfigure quickly

more complex and advanced glitcher

wasn't necessary to test the glitcher to

find out if it will work and what

voltage levels are successful we can

send a command to the acp then glitch

and then see the response from the acp

the general strategy is to lower the

voltage just to the point where the

chips sometimes resets due to the glitch

by adjusting voltage levels in glitch

length and timing when the glitch will

land like lexically succeeded to cause

acp responses to be altered the checksum

on spi packets is very convenient when

unusual data is received from the acp

chip with a valid checksum it's a pretty

good sign that the glitch caused the

temporary fault within the CPU but that

normal operation was resumed depending

when the glitch is delivered different

effects are seen we can see that

generally as the glitch is moved later

it's the later bytes of the response

packets that change so at this point it

looks like the glitcher works and is

able to cause a pre fault since I had

of glitch I took the circuit from the

breadboard and etched a simple PCB that

could plug directly on the X mega

development board this performs exactly

the same function as the breadboard

glitcher but I'm a bit less likely to

accidentally unplug a wire from the

breadboard and have to repair things the

circuit was simple enough that I could

create a one sided PCB so it was very

easy for myself to etch at home now my

goal is to have the ACP execute the code

of my choice because the 6502 is a von

Neumann architecture all code and data

memories share the same address space

from software disassembly I saw that

there didn't appear to be any paging or

MMO 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 wrong I

decided to take a chance and test the

Fram is executable so I send a message

via SPI knowing that this message will

be stored in RAM the message contains

6502 executable code that will copy

itself to an unused area of RAM execute

from this area and send an ACK

indicating it was successful because I

study the use of the SPI interface in

the ROM code I'm able to create this

executable payload that will continue to

receive commands via SPI after it's

taken control of the ACP to try to

maximize chances of success I looked

through the rom code for multibyte

instructions which have broken up would

have contained within them a jump-off

code with a destination that should lead

to where my executable play payload was

placed and round

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 in

corrupt driven task-switching does add

some further timing uncertainty so I

will send the code payload delay then

glitch and see the result when it's

unsuccessful I change the delay and I

try again I try to aim for the

instruction that I've identified as

possibly corruptible into a jump but

there are a lot of unknowns so really

the process is like fishing throw the

line and hope I have a target but no way

if I no way to know if I can really hit

it or if it will have the expected

result but sometimes fishing is good

relatively quickly the ACP returns in AK

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 searches

and then to interact with the code

payload backdoor installed and RAM this

program allows me to enter an address in

length and have data returned or write

to memory etc there's also support for

setting the key in data and performing

deaths encrypt or decrypt using the desk

Hardware that's inside the ACP a few

things I noticed at this point there is

a 2 kilobyte area of ROM that if I

attempted to read it caused the chip to

reset this area of ROM contains the

personalization routines that are never

normally used after the device leaves

the factory there's also protection

against modifying the seed keys in RAM

trying to store a value to these memory

locations appear to do nothing there are

specific addresses within RAM that can't

be read or the chip will lock up these

are clever traps put in place as a

security measure the 7 byte 56 bit Keys

stored in RAM straddle these dead

addresses so a potential exploit that

could cause a linear dump of memory will

be stopped before a complete key is ever

read when the chip is reset it means

having to glitch in again because my

code payload exists only around and

there is no way to hook in a permanent

backdoor

since we can execute code on the ECP

receiver response we can read the ROM to

have its contents without any of the

errors that were introduced during the

optical extraction process comparing the

results of the optical rom extraction

with a proper dump we can see how many

errors were in the optical extraction

overall the optical extraction was quite

good it was after all good enough to

understand the software and get us to

this point there's only one byte with

more than a single incorrectly flipped

bit many of the errors that existed were

quite obvious when disassembling the

software if an instruction is out of

place but flipping a single bit would

make it sensible then it was probably a

bit 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 for mam this ACP can no longer

process EMM s 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 cadet the

connections to other components and 16

VCC connected pins pose the problem to

glitch the ACP in circuit will require

some modifications to the set-top box

disconnecting the ECP from other parts

or another alternative is to remove the

ACP from the set-top box and place it on

a breakout board without losing the

battery power and wiping round rather

than modify the set-top box where each

of several different models would have

required unique modifications I decided

to try to remove the ACP with a battery

still attached the plan is to carefully

lift the battery and ground pins while

the set-top box is powered on providing

VCC I use a small tool I made from a

razor blade using a dremel tool then

attach the handle of a screwdriver this

tool can be wedged under a pin then with

some hot air the solder will melt and a

single pin can be lifted straight up

without damaging any of the other pins

with the pins lifted an external battery

can be attached after attaching an

external battery

[Applause]

after attaching an external battery the

set-top box is unplugged and the ACP can

remove remove from the set-top box using

hot air

the ACP can be roof from the set-top box

glitch and can even be place 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 might not even be

necessary to replace the ACP in the

set-top box the ACP is now placed on a

breakout board and connected to the

glitcher not all the pins need to be

connected only a handful of fins were

actually used by the glitcher you can

also see at this point the glitters in a

project box the aesthetics greatly

improved since the bread box plate the

bread board based lecher but the

functionality is identical the timing of

ACP responses is different on a chip

with valid ram compared to the previous

chips that I'd glitch 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 round contents of a valid ACP

including the category keys if the

set-top box like current authorization

as well as the seed keys that are used

by this ACP to decrypt a MMS without

eval with a valid category key ECMs can

be decrypted and a correct working key

can be calculated for any channel now

with the capability of running my own

code of the ACP it's time to look at the

transport stream D scrambling there's a

hardware register bit that's set or

cleared based on a bite in the ECM 40

when this bit is clear standard desk

decryption is used when the bit is set

the transport string descrambler acts

differently additionally there's an 8

bit hardware register in the DES / if

roll area when it's 0 the peripheral

operates the standard desk for any other

value the peripheral acts differently at

this point I started to think I might be

looking at doing a gate level reverse

engineering of the chip to understand

this functionality the chips using

technology that's older so reverse

engineering should be feasible but if

possible I'd like to avoid all this

extra work it would be quite

time-consuming and might give imperfect

results similar to the optical ROM

extraction so I start with trying to

characterize the scrambling modes the

transport stream packet is made up of a

four byte

header and 23 blocks of 8 bytes each the

desk operates on these eight byte 64-bit

blocks by flipping one bit and encrypted

input ECB CBC or ofb modes can be

differentiated flipping one bit causes

an 8 byte block to be corrected 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 s and in

the custom hardware mode no timing

difference was seen this suggests the

internal properties of desks haven't

changed which makes sense because the

decryption has to be done in real time

so this suggests that crypto

customizations are not affecting some

deaths internals like the number of

rounds also by using an ACP as a

decryption Oracle I determined that the

customization affects each of the 23

blocks of the transport stream

differently next I tested the software

using des weak keys these are certain

keys not recommended for use with DES

because their properties weaken the

cryptographic strength a key of all 0 or

all 1 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 SACP configured for

standard DES decryption and see the

expected weak key behavior when tested

with the descrambler in custom mode the

weak key behavior changes using a key of

all 0 or l1 didn't produce the same

results in encrypt and decrypt modes

looking at the other hardware register

testing the desk peripheral with

different values in the 8-bit register

and using weak keys shows that the

standard desk weak key behavior still

exists so my hunch at this point is that

one customization affects the key and

the other customization affects the data

at this point I can't be certain but I

have a good feeling about the theory so

I continue to investigate based on the

idea that the hardware customization

affects only the key and decryption is

Thai static I thought the simplest

customization would 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 with the

DES engine so it fits the requirements

of fast and very simple to implement in

hardware a change of even a single bit

in the key could cause the observed

effects flipping more than 28 bits would

be pointless that's the same as

inverting a key in flipping fewer bits

more flip bits means more gates

necessary for the customization so it

makes sense to flip a minimal number of

bits so I wrote this wonderful four loop

nested sixteen levels deep to test

decryption results after flipping one

bit of the key then flipping two bits

and three bits and so on up to sixteen

bits to test all the possible keys will

take a long time but if only a few bits

are flipped then it might be possible to

run in a shorter period of time and

promising results did come quickly it

turns out the theory held up and some of

the blocks have this fused three bits

flipped this takes only seconds for the

software to identify after verifying

that these worked for XOR maps for these

blocks the software then was left

running to find all 23 asks 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 are being flipped in the early

results a pattern can actually be found

so the search could have been more

limited using this technique the

software tracker could have completed it

in under a second after successfully

solving the first Hardware customization

the theory that the second customization

is the 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 for identifying 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

[Applause]

in order to implement a soft cam a

software implementation of the

descrambler a few cryptographic details

need to bite be identified but at this

point I have all the tools to do so the

initialization vector used for CPC mode

can be found through simple acts or and

the handling of short blocks those less

than the 64 bit - block size can be

identified likewise with all these

details a software implementation of the

EMM decryption of category key and ECM

decryption of program key and working

Keys can be made and the transport

stream descrambler can also be

implemented in software the rapid key

changes in use of desks with hardware

customizations makes it a bit different

to implement compared to a soft cam for

typical DVD systems but overall the

concept is the same and now it's all

working I was able to test it and it's

fully working on both the satellite and

cable systems this is a screen that's

broadcast before a pay-per-view event

goes live the pay-per-view like all

other channels can be decrypted with a

soft cam using the algorithms learned in

these keys that are extracted with the

ECM and EMM algorithms and seed keys for

set-top box of any level of

authorization the category key can be

decrypted and then used to decrypt any

and all of the channels that are

broadcast by this provider

a few of the weaknesses that I

identified in this system were that the

ACP I studied is relatively old

technology and almost twenty years old

so this makes it a lot easier for

invasive analysis today than when it was

brand new

the tqf P 100 package is quite easy to

deal with compared to modern

alternatives the chip is susceptible to

the voltage glitching

it's a von Neumann architecture without

strong MMU Protection preventing code to

be executed from RAM they didn't leave

any possibility for code update or

dynamic code execution for

countermeasure purposes the software for

the ACP is contained entirely in ROM

with no mechanism for software updates

in the field the hardware customizations

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 smart

card systems the fast working key change

interval only 133 milliseconds also

makes key sharing more difficult and the

short tight lifetime of the key makes

cracking it in real time quite

unrealistic the lack of code in any

rewritable memory means there's nowhere

to write code for a permanent backdoor

to disable the access or to disable the

access controls I listed this also as a

weakness but in fact this is a strength

as it limits the attackers capability to

install any kind of persistent backdoor

the chip operates on an internal clock

eliminating clock glitch attack and

making timing a voltage glitch a lot

more difficult these dead addresses in

the middle of desk keys prevent linear

readout of keys if one were to cause a

loop reading data to go out of bounds

and reach the area of RAM where keys are

stored the chip will reset before an

entire key is read after the first

couple of bytes a dead address will be

accessed that causes the chip to reset

the personalization ROM appears to be

inaccessible so it can't easily be used

to modify the keys and unit address

within the ACP

the seed keys aren't easily changed so

the set-top boxes can't easily be cloned

the keys exist only in RAM so you have

to maintain a battery backup at all

times this rules out a lot of invasive

attacks to retrieve the keys there are

no group keys used for EMS all unit

addressing is to individual units so you

have to pull keys from an actively

subscribed box in order to get active

keys that said if you have keys from a

box that is subscribed to any channel

you will receive an e mm 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 use the EMM decryption

requires using three desk 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 3 seed

keys you might wonder how many set-top

boxes it took for me to complete this

project

the truth is I only needed the one

truckload some of the boxes had

different versions of the ACP chip many

of the boxes had different PCB layouts

so it was interesting to be able to look

at a variety of boxes the cost of you

set-top boxes was low around $20.00 and

for this research I was focusing on the

signal security and didn't need the PVR

functionality or any of the advanced

features from the expensive set-top

boxes so at this point I have a brief

anti-piracy message I don't recommend

you pirate cable or satellite TV there's

never anything good on it doesn't matter

how many channels you can decrypt

believe me I looked it's not worth the

effort

do we have questions from the room

questions please use the microphones I

know there is one question from the

interwebs okay hello yep 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 setup boxes because the

cost of the used set-top boxes was quite

low I wasn't afraid to destroy several

chips in the process it didn't take as

many as I would have expected in the

beginning two or three chips were used

to for the decapsulation in 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 erase the

RAM from to develop the glitch when I

finally got to the point where I was

extracting heat from a valid chip the

very first chip that I tried worked so

there were few casualties involved thank

you

microphone three was the first one

please how many years did this project

take you I would work for a few weeks at

a time and then get burnt out and take a

break and then come back to it most of

the work for the project was completed

over about a two-year period thank you

and microphone two please hi thank you

for a great lecture how comes it that

the content decryption was a DES and not

a dvb-c essay because we used to usually

that content is encrypted with dvbe csa

in this division in North America we

don't believe in standards

Thanks

the timing was also a part of it that

the system was being developed at the

same time as dvv was being standardized

so general instrument rather than going

along with a standards group and waiting

for the standardization they went with

desk directly thank you and another one

from cyber cyber space Sabo okay another

question from the internet is you had

all this fancy like lab equipment and

stuff how were you able to afford that

I've been quite interested in this for a

long time so I've collected this

equipment over over a period of years

and I do some work professionally in

reverse engineering so whenever possible

I use the clients money to buy another

piece of equipment for the lab to do

this actual work though you could even

use more basic equipment because of the

age of the chip you could use a

microscope that you could find easily

for 1,000 or 2,000 dollars or even less

and have quite good results so it's not

trivial but it's not a huge amount of

money for lab equipment not that huge

microphone to please and what do you do

for a living

besides reverse engineering reverse

engineering thank you and the internet

again okay next question is you the

somebody wants to know how well which

software did you use for the automated

image analyzing and is it available

somewhere Oh like everybody else that

I've known that's an optical rock

extraction I developed it myself

everybody seems to develop their own

tools from scratch for that the image

processing I use was really quite simple

so it didn't it didn't take a lot of

advanced algorithms or anything like

that so I'm using some software I

develop personally and it hasn't been

released microphone to please and how

did you kept the books the boxes

subscribed so did you call them every

week oh my box broke down I got another

one

or how's this done for most of the

research that I did I didn't need an

active box I I did all the research just

on previously activated boxes that had

lost the authorization and by the time I

had the process figured out that I knew

how to extract keys from a valid box I

only needed the one box and had you

heard back from the cable provider about

this No okay thank you microphone 3

please hello thanks very much for the

lecture and well done all the work

my question is how does the glitching

work glitching attack for the glitcher I

was was quite simple I I dropped the

voltage for a very brief period of time

and it's enough time that it causes at

least one instruction to not execute

properly but it's too short of a time to

cause the chip to reset so essentially

I'm corrupting one instruction as far as

the specific target that I hit that led

to my code in RAM I'm not actually sure

I found that if I glitch at this time

then the code ends up executing my code

good enough for me okay thank you Chris

please dear audience give an anniversary

edition applause - Chris Kandinsky

[Applause]

[Music]

you

[Music]