[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]