*33C3 preroll music*
Herald: So… coming over to our next talk.
Tonight, if you switch off your DECT phone, and
if you’re full of different impressions
– full of different impressions of this day you maybe want to watch TV.
But it would be cool to have pay-TV – unencrypted pay-TV.
So Chris Gerlinsky asks himself the same. And how to achieve unencrypted pay-TV
– but the Hacker way. So Chris reverse-engineered nothing less
than the signal and the encryption for a standard that remains unencrypted
since the late 90s. Please welcome with an Anniversary Edition applause Chris Gerlinsky!
*applause*
Chris Gerlinsky: Hello everyone. My name is Chris Gerlinsky.
I am a hacker from Canada and I’m here today to talk about how I cracked
digital cable and satellite TV security. I studied an Access Control Platform (ACP)
that’s widely used across Canada and the USA. It’s one of the two common platforms
that’s used in cable TV, and it’s also used in satellite TV
by one of the two Canadian satellite TV operators. As far as I know the system
has remained secure since it was introduced in the 1990s and I was curious
if I could understand the system based on the older set-top-boxes. Some of them
are 15 years old – and they are still in use. So these devices haven’t received
upgraded security hardware in that time and I started looking at how the system works.
Before I get into the reverse engineering I’ll start with a brief description of how
digital television is sent over satellite or cable. Satellite and cable digital TV
are pretty similar for the most part. There are a variety of signal modulations used.
The relevant ones here are QPSK at about 27 MBit/s and 8PSK Turbo FEC at about
38 MBit/s for satellite and QAM256 at about 38 MBit/s for cable. There is also an
out-of-band channel used by cable which is QPSK modulated at 2 MBit/s.
This out-of-band channel carries the subscription-management, program guide
information, firmware upgrades, etc. And while you change channels and the cable
box tunes to different frequencies this out-of-band channel remains tuned
so that the box continuously receives the state, and no matter what TV channel you’re
tuned to. In the satellite TV this type of data is included within the main transport
stream (TS) instead of in a secondary out-of-band TS. The video is sent
as MPEG2 or H.264 TS. This is a standard format for carrying video streams.
So it can be played by any hardware video decoder or software decoder, e.g. VLC.
And the encryption system used here is called DigiCipher 2 (DC2), which does not
follow the DVB standards that are used in the rest of the world. The MPEG-TS
is made out of packets of 188 bytes. Each packet has a PID. This is used
to differentiate different types of data. PIDs range from 0 - 0x1FFF.
Each PID carries an MPEG Packetized Elementary Stream (PES).
That’s a video or audio stream. Or the PID may carry one or more
Service Information Tables. The Service Information Tables have an 8-bit table ID
and a length of up to 1024 bytes including a CRC32 for error detection
and this table ID identifies the type of data that you can expect within the table.
Table 0 is the Program Association Table, containing a list of programs carried
in this TS and the PMT PID for each program. The Program Association Table
is always on PID 0. Table 2 is the Program Map Table which contains the list of PES
and the PID for each as well as an ECM PID. There is Program Map Table
for each MPEG program or TV channel that’s found in the stream.
The ECM PID is where ‘Entitlement Control Messages’ are sent containing information
that’s used to generate the key that decrypts the Packetized Elementary
Streams. This system uses two types of ECM. Table 40 I call ECM40, and Table 41
I call ECM41. On PID1 there may be one or more conditional access tables,
table ID No.1. These tables identify a PID that carries EMMs, ‘Entitlement Management
Messages’. These messages are used to set access rates for individual set-top-boxes.
The subscription information, like, what channels are available is carried inside
of EMMs. This is a hardware interface to receive satellite data, a Genpix SkyWalker-1.
The DC2 QPSK modulation isn’t widely supported in USB or PCI DVB-S devices.
And the 8PSK Turbo FEC modulation support is even less common. And one of the devices
that does support these signals is this Genpix device which is using a Broadcom
BCM4500 demodulator. And it supports both the DC2-QPSK and the 8PSK modulations.
It works well, the Linux drivers need to be re-compiled to include the support
for these modes, and patches for this were published by updatelee. There’s a link
on the slide. For cable there’s a variety of adapters supporting QAM256 de-modulation.
I used a USB HVR 950Q tuner. Unfortunately, to tune the out-of-band channel is generally
not supported by the off-the-shelf interfaces. Inside the cable box
it’s handled within the integrated chip set. And for the ClearQAM consumer
devices such as USB interfaces access to the out-of-band data isn’t actually required
so they don’t include it inside of the hardware. This out-of-band data is used
only for pay-TV services.
With the satellite and cable interfaces DVBsnoop can be used to view a lot of
information about the transport stream. It’s enough information to be
quite overwhelming. So the trick to using it is being able to sift through the output
for the relevant information. DVBsnoop also doesn’t recognize all of the
DigiCipher 2 tables because it’s a non- standard system, and DVBsnoop is targeted
towards the standard systems. So DVBsnoop may not be able to tell you everything
about the transport stream but it was still a very useful tool for all the
information that it can provide.
DVBsnoop and most other tools and documentation are designed for the DVB
standard or other recognized standards such as ATSC. DigiCipher cable
and satellite systems use a lot of non-standard tables to carry
the system information. For cable TV some of these tables are standardized by
the document SCTE 65. There is no BAT or SDT
as you’d expect in DVB. Instead there is a virtual channel table that maps
the transport streams and programs the channel numbers. The electronic program
guide is also not DVB standard. So you don’t even get the current and next
program information in any kind of a standard format.
Another cable TV adapter is the HDHomeRun Prime. This one is a network-connected
three-tuner device with cable card support. The set-top-boxes I studied
pre-date the cable cards. Although the newer boxes do use the cable cards,
and they support the DigiCipher 2. But cable card support does also mean
that this HDHomeRun Prime includes the tuner and QPSK demodulator for the
out-of-band channel. So it is able to pass this data to the cable card, as necessary.
However, even the HDHomeRun doesn’t make this out-of-band data available
other than the cable card interface. So to access the demodulated out-of-band data
I tapped in to the HDHomeRun Prime with a cable card inserted, and connected
a logic analyzer to the Data and Clock signals. I wrote software using the
Saleae SDK to capture the QPSK demodulated data. Then, in software, I performed
de-interleaving, de-randomization, and the forward error correction.
And the output is an MPEG transport stream. So using an HDHomeRun Prime
connected to the logic analyzer, connected to the PC running the software
the output finally is a 2Mbit/s transport stream. And this transport stream
looks like a standard transport stream, and inside are the conditional access
management messages, program guide information etc. Everything that was
missing from the main QAM transport stream.
Two bits in each packet will indicate if the packet is scrambled with the even key,
odd key, or not scrambled at all. The key is changed at short intervals.
DVB systems typically will change every 5 .. 30 seconds. DC2 every 133 ms
or 1 second. The key used for decryption alternates between even and odd.
The odd key is in use while the even key is updated; and then the even key is
in use while the odd key is updated. An encrypted transport stream is sent
via the cable or satellite, and it’s passed through the descrambler in the ACP.
And the result is a decrypted transport stream that is played by the MPEG decoder.
The descrambler uses a Working Key. This is a 56-bit DES key that changes
every 133ms, or in some cases they have it slowed down to changing every 1 second.
This Working Key is generated by encrypting the frame count from ECM40
packets with the Program Key. The Program Key, again DES, comes from the ECM41
message, and is encrypted with the Category Key. The Program Key
is unique to each channel, and it changes daily or for every pay-per-view event.
The Category Key, also DES, is shared by all the set-top-boxes that authorize
for any channel from this provider. The Category Key is sent to each set-top-box,
individually, inside the EMM95 message. And this Category Key typically changes
monthly, but many cable operators change keys much less frequently. Some of them
are using the same key for years at a time. To decrypt the EMM, in order
to get the Category Key Seed Keys are used. Each set-top-box has a set of
56 bit DES Seed Keys inside of battery-backed RAM. These are
initialized during manufacturing. For the lifetime of the set-top-box these keys
are used to secure EMMs. So this forms a chain from the Seed Keys,
initialized during manufacturing and never changing, to the decryption of the MPEG
transport stream.
Inside the satellite set-top-box we can see the main
components of the system. The signal enters the tuner and is passed
through the demodulator which outputs a serial transport stream.
This transport stream passes through the ACP – Access Control Processor –
and is then sent to the MPEG decoder to output a video signal to the TV.
A 68k microcontroller acts as the set-top box main controller. It communicates
with the MPEG decoder as well as with the ACP via an SPI bus.
A battery provides backup power to the ACP. So it will retain RAM contents
even when the set-top-box is unplugged. There’s a TVpass slot near the power
supply. This is an upgrade slot with a card edge connector to allow
for security upgrades. The system
stayed secure, so the TVpass slot was never used. And the newer set-top-boxes
don’t actually include a TVpass slot inside. So at this point it seems
quite unlikely that this TVpass card will ever actually be used.
Inside the cable set-top-box… it’s very similar to a satellite set-top-box
but the cable boxes tend to be more tightly integrated. The signal enters
the tuner and passes through a Broadcom chip that handles demodulation.
And the same chip will also handle MPEG decoding after the transport stream’s been
decrypted by the ACP. A 68k microcontroller acts as the set-top-box’s main controller.
Again, talking to the ACP via SPI. And a battery provides backup power
to the ACP, and also to the non-volatile RAM used by the main controller.
A TVpass slot is underneath the main board, it’s not visible in this photo.
The cable set-top-boxes include a second tuner that’s used to receive
the out-of-band data. This OOB tuner operates independently of the main tuner
and on a separate frequency range. And it’s used to provide a transport stream
containing the system information, with the program guide, firmware updates,
EMMs etc.
Here we see the ACP chip. It’s a 100-pin TQFP package. From the markings
we can see it’s a custom System-On-Chip made for General Instrument Corp. (GIC).
All the decryption is performed by the ACP, and all decryption keys are kept
only within this chip. The newer set-top- boxes use newer versions of the ACP.
I studied the original ACP chip that’s seen in this photo.
As long as the set-top-boxes using this chip are actively used it remains
a relevant target. Whether the newer ACPs include more advanced security features
or if they exist only for cost-savings due to shrinking the die size
I don’t really know.
Some of the interesting pins on the ACP are labeled here. Pin 1 is marked
at the top left corner of the chip. There’s an SPI slave controller
on Pins 1 - 5, used for communication with the set-top-box main controller.
There’s a battery backup pin that’s connected to a 3V battery to keep
the RAM contents of the ACP intact at all times. There’s a serial transport
stream input on pins 88 - 92 which receives the data from the demodulator.
And there’s a serial transport stream output on pins 28 - 33 which sends
the decrypted transport stream to the MPEG decoder to be output to the TV.
At one point I had written software for an AVR32 device, not the one that’s
shown here, that has a synchronous serial peripheral, that supports sending and
receiving data at the 27 MBit/s rate of the transport stream. My AVR32 implementation
turned out a bit ugly. But rather than cleaning up I was able to use it as it was.
It had some limitations like only accepting 64kB of data for replay logging.
Which was just barely good enough for my studies. What the transport stream
logging in-circuit digital mean was
that the transport stream passes through the ACP with selected PIDs being decrypted.
And then the output is the full transport stream but a selected program has been
decrypted. The AVR32 logging interface had rather limited use for me.
Later on when I did more thorough research I did so using an ACP that I’d removed from
the box and I put on a breakout board. And then I could control the clock, and
at that point it was much easier to use an XMEGA AVR platform to send and receive
the transport stream through the ACP at a much slower bit rate. Shown here
is the XMEGA platform I settled on using
for SPI and also the transport stream interfacing. To honor the data
passed between the set-top-box main controller and the ACP on the SPI bus
I used the XMEGA development board. Two SPI ports acted as slave with Master Out -
Slave In (MOSI) signal connected to 1 and Master In - Slave Out (MISO) signal
connected to the Master Out - Slave In input of the second port. So from one port
Bytes sent by the set-top-box controller are received.
From the other port it receives
bytes from the ACP. In case I want to talk directly to the ACP or the set-top-box
main controller it’s only necessary to connect both the MOSI and MISO signals
on one of the SPI interfaces. By holding the main controller in Reset my XMEGA
was able to act as the SPI Master and then talk to the ACP. So this setup works for
passively monitoring the SPI communications in the set-top-box and can also act as
the SPI Master for interrogating the chip directly.
By logging the SPI bus between
the main controller and the ACP we see that information about the current access
levels are sent from the ACP. The ACP also receives EMMs via the SPI bus.
EMMs have been filtered by the Unit Address number, or the set-top-box serial number.
So the ACP only receives messages that are intended for that specific unit.
Command 04 includes the current Category Key epochs and Keyselects in use.
Command 05 includes the Unit Address number. Command 13 returns the authorized
Subscription tiers for this unit. Commands 7 and 87 provide information about the channel
being currently decrypted. Additionally, via the SPI interface the set-top-box
main controller tells the ACP which PIDs to decrypt and which is the ECM PID.
The ACP doesn’t send any keys on the bus, and it only receives Category Keys that
are encrypted within EMMs via the SPI. So all of the really interesting data is
contained within the ACP chip itself, and it’s never sent out on any kind of a bus.
So next I started an invasive study of the chip – studying it under a microscope.
And the cost of microscopes can range from hundreds of Dollars to tens of thousands
of Dollars, or even higher for things like electron microscopes or other specialized
equipment. I have a couple of microscopes that I use. This one is a Mitutoyo FS70
microscope. These Mitutoyo are often used for microprobing, but you can also use it
for other uses. For this project I didn’t do any microprobing but I used this
microscope because it was what I had. For studying this kind of technology you could
use even more basic equipment but, of course, if you have the higher-end
equipment it’s a lot nicer to work with.
Another microscope I use is the Zeiss Axiotron. This microscope is designed
for inspecting wafers and has really good optical quality. I said that more basic
equipment could be used and it’s true. But when you get into this kind of thing
you might find yourself again and again investing in more equipment.
I've owed $10.000 in this setup including the microscope and the camera and the
scanning stage and other parts. To look at the chip under the microscope requires
that the chip is de-capsulated. Fuming Nitric Acid is used for this.
The chip is immersed in heated red Fuming Nitric Acid which reacts with the plastic
packaging and removes it. The chip is then rinsed in acetone, and cleaned with
isopropyl alcohol in an ultrasonic bath which leaves the die bare and clean.
The Nitric Acid is quite aggressive, and it’s important to handle it carefully.
But the process is really straight-forward. Most people probably wouldn’t want
to do this in their home.
So you should go out to the garage and use your fume hood there.
After the decapsulation the bare chips are left with bonding wires attached
to them. So these wires will be plucked off using tweezers to get them
out of the way. Already in this photo we can see some of the larger structures
on the chip. Half of it is covered with a metal plane, and the other half
shows some kind of visible circuitry.
This is an image of the chip under the microscope. It’s been stitched together
from several smaller images, to give an overview of the chip.
Looking at the decapsulated chip we see the bond pads around the outside,
a metal plane covering the top part of the chip and wires on the bottom of the chip,
the spaghetti logic running all ov er the place. With a couple of structures
that look like they could be a type of memory. There’s a lot still hidden
from us. To see more of the chip it will be necessary to delayer it.
To delayer the chip I used hydrofluoric acid to perform a wet etch. I used the Whink
Rust Stain Remover product. It’s available in hardware stores all over the USA.
It’s a dilute HF solution that works really well for delayering ICs.
I put a small amount of the Whink liquid in a beaker and heated it on the hot plate.
Then I dropped the decapsulated die in. Using a pipette I agitated the liquid
to disturb the bubbles that form on the surface of the chip. So the acid can
actually chip more evenly. The etching result isn’t perfect. Some parts of the chip
will be etched deeper than other parts. But I’ve gotten quite useful results using
this technique. You really don’t wanna breathe in these fumes, so do this
in a fume hood in your garage, also.
After a short time immersed in the heated Whink solution the chip was rinsed and
put back under the microscope. Now the top metal plane has been removed
so we can see what’s below. There are some visual effects that we start to see
in the photo from the etching being a little bit uneven. But overall
the delayered chip looks quite good and able to start studying it. At the top left
the tall rectangles are RAM. The four blocks at the top right are ROM.
And then there’s logic that tie these into the logic area below.
I was interested in finding how the bits were encoded in ROM. So I continued
delayering the chip. This was another dip in the Whink – and another metal layer
has been removed. Bits in the ROM were not visible yet so I continued
the delayering process. At this point we’re starting to see more of the visual
effects from the uneven etching but it’s still not too bad. After a third dip
in the Whink more metal has been removed. At this point the delayering is becoming
more and more uneven. We can see the ROM blocks have been half-etched
to a lower layer while half of the upper layer is still remaining. The wet etching
process can be quite difficult to perform completely consistently without adding
additional steps such as polishing. And at the time I did this project I didn’t have
the polisher available so I was relying only on the wet etch. Some of the areas
of the ROM are now showing visible bits. The other areas haven’t been etched
deeply enough. So I continued to etch further to try and get a clean ROM.
We can see the ROM bits quite clearly now. They’re arranged in rows and columns, and
in this image if a black dot is visible that indicates that the bit is a One.
Image quality is important. The better the photographs the more consistently the bits
will be visible. But it doesn’t have to be really perfect. You can do some image
processing on it, you can even repeat the process on multiple chips, delayer them
and photograph them, and at some point you’ll be able to have the entire ROM
clean and consistently visible. With the visible bits exposed and photographs taken
the bits can be extracted using a software image analysis tool. Or the bits could be
extracted manually. The ROM here is 32 kB or over 260.000 bits. So manual extraction
would be a bit labor-intensive but it isn’t impossible. A software tool is
more efficient. So I wrote some software to analyze the images and identify
the 1 and 0 bits. There are bits marked with a yellow box for 0 bits or a blue box
for 1 bits. I use a software to analyze the image and then I can quickly review
the results manually, and identify any errors that I can see. After extracting
the bits from the photographs I have a binary version of the ROM data.
This is a visual representation of the bits extracted from this piece of ROM.
Little black boxes signify 1 bits, and the white boxes signify 0 bits.
In this image I’ve overlayed the extracted bottom 13 rows of bits over the photograph.
You can see some visual patterns inside this, also. And these visual patterns
are a good indicator that this ROM is probably not scrambled.
This image shows the end of the ROM where you can see a pattern covering most of
the image due to a repeated pattern of filler bytes that occupy unused space
at the end of the ROM. At the very end of ROM the pattern is interrupted. This is
where the vectors table exists at the top end of memory indicating the reset address
and the addresses of interrupt handlers. The ROM has unused space, the filler bytes
at the end. And the vectors table address is 0xFFF6 through 0xFFFF.
After extracting the bits and decoding them into bytes the hex dump can be studied.
There is a “Copyright 1997 CHCC” ASCII string in ROM which is helpful to identify
when the ROM has been decoded correctly. *laughter*
If you can read the ASCII text then surely the bits are in the correct order.
The decoding in this case was just a matter of organizing the bits into bytes, it’s quite
straightforward, there was no scrambling or anything else that was complex.
With the ROM contents extracted the software can be disassembled and analyzed.
The first step was to identify the CPU architecture. Studying the binary dump
it appeared to be an 8-bit CPU but wasn’t 8051 or 6805
or any of the processor types I tried first. Eventually, I tried disassembling
it 6502 and the code made sense. Later I had remembered that I had looked at
a previous version of the Access Controller from the same manufacturer.
Which was used in another system, VideoCipher 2+, an ancestor of DigiCipher.
On the older chip was a Copyright notice from WDC who licenses the 6502 core IP.
It was visible directly on the chip die under the microscope.
So this would have been a great clue for the CPU architecture if I had actually
noticed it earlier. For disassembly I used IDA. It supports 6502 and is of course
a very powerful disassembler. In addition to disassembly I used 6502 simulation
software to study the software in a virtual CPU. The simulation is really
helpful when disassembling the software. It provides a lot of insight into what’s
going on. Since 6502 is a very well-known architecture it was not at all difficult
to find an existing simulator. Even free, with source code. The 6502 is used
in 8-bit computers, like the Apple II, in Commodore 64. So there’s really
a lot of enthusiasts and a great deal of information about this architecture.
As I gained understanding of the System On Chip through disassembling the software
I began adding some other features into the simulator to emulate some of the
hardware peripherals that were found inside the ACP, the device itself.
One of the first things I saw in the disassembly was that there are two
operating modes. During startup values in RAM are checked. And if the ACP
hasn’t been initialized it enters a personalization mode used during
manufacturing to assign the Unit Address and Seed keys. In normal conditions,
after the set-top-box has left the factory this personalization software
is bypassed and the ACP will always run its main application. The next thing
I found was the application wasn’t very simple. This 6502 actually runs
a task switching operating system. Eight tasks are run supporting decryption
of up to two channels at the same time. There are two tasks to handle processing
of ECM40 messages and generation of the Working Keys used to decrypt the transport
stream. And two tasks to handle processing of ECM41 messages to generate
the Program Keys that are used to process the ECM40. One task for handling
EMM processing. And there’s also a task to communicate with the TVpass interface
for security upgrades. With another task to handle the messages that are coming in
over the SPI interface. Since the ACP is a custom System On Chip
there is no documentation available describing the hardware capabilities.
So the disassembly was studied and the input/output registers had to be guessed
based on the software usage. There’s an SPI slave peripheral for communication
with the main controller. The SPI peripheral sends and receives data
directly to RAM. And then a signal is set indicating that the transport has been
completed. There’s a DES crypto peripheral;
key, data and operating mode are set in registers. And when the decryption
has been completed the result can be read from additional registers. There’s
a transport stream descrambler. The Working Key is set in hardware registers.
And the descrambler will then output the decrypted transport stream on the serial
transport stream interface. There are PID filters set by the set-top-box main
controller over the SPI bus. These filters select which video and audio streams
to descramble and which ECM packets should be received by the ACP. The received ECMs
are placed in RAM, and the 6502 is notified of a new ECM via a register bit.
So at this point I’m starting to get an idea of how the system works.
I have studied the MPEG transport stream and logged ECM and EMM data.
I’ve logged the SPI bus, and understand messages between the set-top-box
main controller and the ACP. I was able to extract the entire ROM contents optically.
And I’ve disassembled the software and run it in simulation. There are some keys
that are found in ROM. Fixed keys which never change and are used when a channel
has a “free preview weekend” or something of the sort. Any set-top-box that has ever
had any kind of authorization in the past is allowed to decrypt channels that are
encrypted using the “fixed key” mode. So now the focus is on understanding the ECM
and EMM algorithms within the ROM software. At this point I’m still missing
some important information from the ACP. All the Seed Keys, Category Keys and
Program Keys exist only within RAM. So to decrypt any of the channels
not in free preview isn’t possible yet at this point. The ECM40 message
is used to generate the Working Key, used to descramble the MPEG streams.
There’s a Service ID, used to identify each channel, and a frame count
that’s used with the Program Key to calculate the Working Key.
The crypt mode identifies if the channels are operating unencrypted, with a fixed
key, or with the normal secure keys which are typically used.
The frame count is simply a 24 bit counter that increments each time the Working Key
changes. There’s a byte I’ve labeled ‘Hardware’ that has one bit set in it.
This selects a special decryption mode that I’ll come back to a little bit later.
The ECM41 contains encrypted Program Key that’s needed to correctly decrypt the ECM40.
There’s a Provider ID that indicates which TV operator subscribers this ECM should
be processed by. And there’s the same Service ID that will be found within
the ECM40 messages. The Category epoch identifies which Category Key is in use.
There’s also information about how long this Program Key will be valid for.
ECM41 contains one or more subscription tiers that must be found within
the customer’s ACP to allow this message to be processed. The subscription tiers
are written to the ACP when the EMM containing authorization details is received.
There is, again, a hardware crypto select byte that I will get back to.
This slide shows what a half of a second of ECM40 and ECM41 activity might
look like. To be able to descramble the program the ACP must process a current
ECM41 to get the Program Key and then process an ECM40 to get the Working Key.
The Working Key is then used by the descrambler to decrypt MPEG stream.
Until the ACP receives the ECM41 with the current key as well as an ECM40 with
the frame count it’s not yet possible to decrypt the transport stream.
The Working Keys have a short life time, only 133 ms. The series of ECMs shown here
all would happen within a period of a half of a second.
The EMMs are split into
four parts. Each part contains a portion of the subscription information for this
set-top-box. A Category Key is calculated from each of the four parts and the key
that is calculated for each part has to match the others, or the EMM will be
rejected, and all authorization in Category Key will be wiped from this ACP.
When the first EMM, part Zero, is received the authorization data inside the ACP
is reset and will be replaced with authorization data from the EMM.
When the next part, part One, is received the existing authorization data within
the ACP from part Zero is hashed along with the data in part One. If the result
is correct then the authorization from part One is copied into the ACP
alongside the existing data from part Zero. If the result is incorrect then
the ACP’s authorization is erased. In this way the four EMM messages are linked
together, and if anything is modified within any of the EMM messages
the authorization will fail.
This is an example of an EMM. Each of the four EMM parts contains some common
information, like the Unit Address, and which Category epoch this EMM contains
information for. The EMM can contain two Category Keys. One for the current epoch
and also for the next so that when there’s the change of the Category Key the ACP
already has the next key available. To decrypt the Category Key from the EMM
the Seed Keys contained in the ACP are used. The Seed Keys are unique to each ACP
and are assigned during manufacturing. EMMs are transmitted out-of-band
for cable systems but they’re passed to the ACP in the same way as for satellite
systems. So at the ACP level, there’s no difference between the satellite and
the cable systems.
At this point it should be possible to decrypt channels that are using
a fixed-key mode. Analysis of the ROM has shown the algorithms used to process
the ECMs and generate the Working Key.
The fixed keys are known because they’re contained in ROM. There could have been
some question about the possibility of bit errors from the optical ROM extraction
process. But the fixed keys can be confirmed as correct because the ROM
software performs a checksum of this 256 byte area that contains the keys.
Successfully running the checksum on the extracted ROM data indicates that
the extracted keys seem to be correct. But when I attempted to decrypt
a fixed-key channel there was a problem, it did not work.
Whether it was a bug in my decryption implementation or something else
was unclear. However, I had noticed the bit in ECM40 was set that causes a bit
within the ACP hardware peripherals to be set. The purpose of the bit was unclear.
But its address was suspiciously close to the transport stream descrambler key.
So I started to suspect that there might be some encryption other than just
standard DES.
To be able to learn more about the ACP I started to look at glitchers.
If I can succeed to glitch the chip I may be able to find a way to read and even
write memory. And possibly a way to run my own software directly on the chip.
This will allow me to control the hardware peripherals and be able to observe
the chip’s operation under different conditions. Timing tests of the ACP
suggest that the 6502 is running from an internal clock source. So this will allow
a clock glitch attack. A VCC glitch makes sense, and with the age of this chip
it seemed reasonable to expect that it would be susceptible to VCC glitches.
The stronger protections against this type of attack are relatively recent.
My glitcher design is quite simple. It’s based on an XMEGA development board
and breadboard. I use the XMEGA to communicate with the ACP over SPI
and to control the glitch. A 74xx series 4053 analog switch is used to quickly
switch the ACP VCC between two voltages, a normal operating voltage, and a lower
glitch voltage. I use a bench top DC power supply and two outputs so I can easily
adjust both the normal VCC and glitch VCC levels. Other parts on the breadboard
are an oscillator to provide some clock inputs necessary for the ACP to operate
and an inverter and NAND gate to cut out the clock during the time of the glitch.
To simplify the test setup as much as possible the ACP was removed from
the set-top-box and soldered to a break-out board. In this process
the battery-backed RAM was disconnected and all the keys were lost.
But for the purpose of developing a working glitch this was okay. The simple,
breadboard-based glitcher is quite flexible. The breadboard can be modified
to test different ideas, and reconfigured quickly. More complex and advanced
glitcher wasn’t necessary.
To test the glitcher, to find out if it will work and what voltage levels
are successful we can send a command to the ACP, then glitch, and then see
the response from the ACP. The general strategy is to lower the voltage just
to the point where the chip sometimes resets due to the glitch.
By adjusting voltage levels and glitch length and timing when the glitch will end
I succeeded to cause ACP responses to be altered. The checksum on SPI packets
is very convenient. When unusual data is received from the ACP chip with a valid
checksum it’s a pretty good sign that the glitch caused a temporary fault within
the CPU, but their normal operation was resumed. Depending when the glitch
is delivered different effects are seen. We can see that generally, as the glitches
moved later, it’s the later bytes of the response packets that change.
So at this point it looks like the glitcher works, and is able to cause a pretty fault.
Since I had an effectve glitch I took the circuit from the breadboard
and etched a simple PCB that I could plug directly on the XMEGA development board.
This performs exactly the same function as the breadboard glitcher but
I’m a bit less likely to accidently unplug a wire from the breadboard and
have to repair things. The circuit was simple enough that I could create
a one-sided PCB, so it was very easy for myself to etch at home.
Now my goal is to have the ACP execute the code of my choice. Because the 6502
is a von-Neumann architecture all code and data memories share the same address space.
From software disassembly I saw that there didn't appear to be any paging or MMU
features. The software in ROM is fully self-contained. There is no EEPROM
and RAM is never used to hold executable code. So there aren’t jumps into
these areas to exploit and, in fact, it wasn’t clear if there’s anything preventing
code execution outside of ROM. I decided to take a chance and test if RAM is executable.
So I sent a message via SPI, knowing that this message will be stored in RAM.
The message contained 6502 executable code that will copy itself to an unused area
of RAM, execute from this area and send an ACK indicating it was successful.
Because I studied the use of the SPI interface and the ROM code I’m able
to create this executable payload that will continue to receive commands via SPI
after it’s taken control over the ACP.
To try to maximize chances of success I looked through the ROM code for
multi-byte instructions, which, if broken up, would have contained within them
a jump op code with a destination that should lead to where my executable
payload was placed at RAM. Since the ACP has a single address space this gives
a lot of opportunities for glitching to cause execution to reach the payload.
There are multiple scenarios possible in addition to my selected glitch target.
Stack corruption is a possibility, and really any abnormal program flow has
some possibility that it could eventually land in my code. The von-Neumann
architecture, without strong memory management, is a very fertile ground
for glitching. Anything in RAM potentially could be executed.
So at this point there are several uncertainties, but so far nothing
totally rules out the possibility of success. The ACP operates from
an internal clock source. And the interrupt-driven task switching
does add some further timing uncertainty. So I’ll send the code payload,
delay, then glitch, and see the result. When it’s unsuccessful I change
the delay and I try again. I tried to aim for the instruction
that I’ve identified as possibly corruptible into a jump.
But there are a lot of unknowns, so, really, the processor is like fishing:
throw the line and hope. I have a target but no way to know if I can
hit it, or if it will have the expected result.
But sometimes fishing is good. Relatively quickly the ACP returns
an ACK indicating a successful glitch. The first successful glitch took some hours
to find. And then, after this it was possible to make it work repeatedly
in a matter of minutes or even seconds. So now I have my code executing
in RAM, I’m able to send the ACP additional pieces of code to be executed.
This allows me to read any memory address, write any memory address, and perform
any other operations possible with the 6502.
I wrote a simple application to perform glitch surges, and then to interact
with the code payload backdoor installed in RAM. And this program allows me
to enter an address and length and have data returned. Or write memory etc.
There’s also support for setting the key and data, and performing DES encrypt
or decrypt using the DES hardware that’s inside the ACP. A few things I noticed
at this point: there’s a 2 kB area of ROM that, if I attempted to read it, caused
the chip to reset. This area of ROM contains the personalization routines
that are never normally used after the device leaves the factory.
There’s also protection against modifying the Seed Keys in RAM. Trying to store
a value in these memory locations appeared to do nothing.
There are specific addresses within RAM that can’t be read or the chip will lock up.
These are clever traps put in place as a security measure. The 7-byte
56 bit keys stored in RAM stride all these dead addresses. So a potential exploit
that could cause a linear dump of memory will be stopped before a complete key
is ever read. When the chip is reset it means having to glitch it again, because
my code payload exists only in RAM, and there is no way to hook in a permanent
backdoor.
Since we can execute code on the ACP the receiver responds, we can read the ROM
to have its contents without any of the errors that were introduced during
the optical extraction process. Comparing the results of the optical ROM extraction
with the proper dump we can see how many errors were in the optical extraction.
Overall the optical extraction was quite good. It was, after all, good enough
to understand the software and get us to this point. There is only one byte with
more than a single incorrectly flipped bit. Many of the errors that existed
were quite obvious from disassembling the software. If an instruction is out of place
but flipping a single bit would make it sensible then it was probably a bit error.
I didn’t keep detailed records but I think I probably caught about half of the ROM
errors during the disassembly process before I started glitching.
The interesting keys in the ACP are all stored in RAM only. This includes
Working/Program/Category and Seed Keys. The RAM is battery-backed.
If the Seed Keys are ever lost from RAM this ACP can no longer process EMMs
and so is useless. It’s possible to glitch the ACP and read memory, but the glitcher
works on an ACP removed from their set-top-box. When the ACP is in-circuit
the connections to other components and 16 VCC-connected pins pose the problem.
To glitch the ACP in-circuit we’ll require some modifications to the set-top-box
disconnecting the ACP from other parts. Or, another alternative is to remove
the ACP from the set-top-box and place it on a breakout board without loosing
the battery power and wiping RAM. Rather than modify the set-top-box, where each
of several different models would have required unique modifications I decided
to try to remove the ACP with the battery still attached. The plan is to carefully
lift the Battery and Ground pins while the set-top-box is powered on providing VCC.
I use a small tool I made from a razorblade using a Dremel tool, then attached
the handle of a screw driver. This tool can be wedged under a pin, then with
some hot air the solder will melt and a single pin can be lifted straight up
without damaging any of the other pins.
With the pins lifted an external battery can be attached.
After attaching an external battery…
*applause*
After attaching an external battery the set-top-box is unplugged, and the ACP
can be removed from the set-top.box using hot air. The ACP can be removed from
the set-top-box, glitched, and can even be placed back in the set-top-box, if desired.
To do this I just use hot air and a lot of flux. Additionally, once the interesting
keys have been extracted it may not even be necessary to replace the ACP
in the set-top-box. The ACP is now placed on a breakout board and connected
with the glitcher. Not all the pins need to be connected. Only a handful of pins
are actually used by the glitcher. You can also see at this point the glitcher is
in a project box. The aesthetics greatly improved since the breadboard-based
glitcher. But the functionality is identical. The timing of ACP responses
is different on a chip with valid RAM compared to the previous chips
that I had glitched before. I didn’t confirm whether the cause of the timing
difference was due to a different oscillator configuration or just
a different software path. But by adjusting the timing of the glitches
the executable code payload runs as it did on the previous chips. So now we can read
the RAM contents of a valid ACP, including the Category Keys, if the set-top-box had
current authorization, as well as the Seed Keys that are used by this ACP to decrypt
EMMs. With a valid Category Key ECMs can be decrypted, and a cracked Working Key
can be calculated for any channel. Now, with the capability of running my own code
of the ACP it’s time to look at the transport stream descrambling.
There’s a hardware register bit that is set or cleared, based on a byte
in the ECM40. When this bit is cleared standard DES decryption is used.
When the bit is set the transport stream descrambler acts differently. Additionally,
there’s an 8-bit hardware register in the DES peripheral area. When it’s Zero
the peripheral operates the standard DES. For any other value the peripheral acts
differently. At this point I started to think I might be looking at doing
a Gate-level reverse engineering of the chip to understand this functionality.
The chip is using technology that’s older. So reverse-engineering should be feasible.
But, if possible, I’d like to avoid all this extra work. It would be quite
time consuming, and might give imperfect results, similar to the optical ROM
extraction. So I started with trying to characterize descrambling modes.
The transport stream packet is made up of a 4-byte header and 23 blocks of
8 bytes each. The DES operates on these 8 byte (64 bit) blocks.
By flipping one bit in encrypted input ECB, CBC or OFB modes can be differentiated.
Flipping one bit causes an 8-byte block to be corrupted, and the corresponding bit
in the following block to be flipped. This indicates CBC mode is in use.
Timing of the input compared to the decrypted output was measured with
the descrambler and standard DES, and in the custom hardware mode.
No timing difference was seen. This suggests the internal properties of DES
haven't changed. Which makes sense because the decryption has to be done
in realtime. So this suggests that crypto customizations are not affecting
some DES internals like the number of rounds. Also by using ACP as a decryption
oracle I determined that the customization affects each of the 23 blocks of the
transport stream differently. Next I tested the software using DES ‘weak keys’.
These are certain keys not recommended for use with DES because their properties
weaken the cryptographic strength. A key of all Zero or all One bits
will cause DES decryption and encryption to be identical. That is running the same
data through Encrypt or Decrypt will give the same result. I can test this on an ACP
configured for standard DES decryption and see the expected ‘weak key’ behavior.
When tested with the descrambler in custom mode the ‘weak key’ behaviour changes.
Using a key of all Zero or all One didn’t produce the same results in Encrypt
and Decrypt modes. Looking at the other hardware register, testing the DES
peripheral with different values in the 8-bit register, and using ‘weak keys’,
shows that the standard DES ‘weak key’ behaviour still exists. So my hunch
at this point is that one customization affects the key, and the other customization
affects the data. At this point I can’t be certain, but I have a good feeling about
the theory, so I continue to investigate.
Based on the idea that the hardware customization affects only the key
and decryption is static I thought the simplest customization will be an XOR
mask that’s applied to the key before it’s used for DES decryption. XOR requires
only a single gate in series of the DES engine so it fits the requirements of
fast and very simple implement in hardware. A change of even a single bit
in the key could cause the observed effects. Flipping more than 28 bits
will be pointless. That’s the same as inverting a key and flipping fewer bits.
More flipped bits means more gates necessary for the customization, so
it makes sense to flip a minimal number of bits. So I wrote this wonderful FOR loop,
nested 16 levels deep, to test decryption results after flipping one bit of the key,
then flipping two bits, then three bits etc. of the 16 bits. To test all the
possible keys will take a long time. But if only a few bits are flipped then it
might be possible to run it in a shorter period of time. And promising results
did come quickly. It turns out the theory held up. And some of the blocks have
as few as three bits flipped. This takes only seconds for the software to identify.
After verifying that these work for XOR masks, for these logs the software then
was left running to find all 23 masks.
The simple brute-force method worked, it ran for a couple of days to identify
all the 23 masks. By more carefully analyzing which bits were being flipped
in the early results a pattern can actually be found. So the search could
have been more limited. Using this technique the software cracker could have
completed it in under a second.
After successfully solving the first hardware customization the theory
that the second customization is a Data XOR looks promising. It makes sense
that one or more XOR gate is enabled by each bit of the 8-bit hardware register.
Using the ACP as a decryption oracle a known key in Data were decrypted
with all values of the 8-bit register. Software attack of this function
was successful, and 255 XOR masks were identified, behavior matching what was
expected. I haven’t actually seen this customization in actual use. Presumably,
they’re saving it to be used as a countermeasure against pirate devices
when necessary. But it hasn’t been necessary since the system never had
a security breach.
*laughs* *applause*
In order to implement a Softcam, a software implementation of the descrambler,
a few cryptographic details need to be identified. But at this point I have
all the tools to do so. The initialization vector used for CBC mode can be found
through simple XOR. And the handling of short blocks – those less than the
64 bit DES block size can be identified likewise. With all these details
a software implementation of the EMM decryption of Category Key and
ECM decryption of Program Key and Working Keys can be made and the transport stream
descrambler can also be implemented in software. The rapid key changes and the
use of DES with h/w customizations makes it a bit different to implement, compared
to a Softcam for typical DVB systems, but overall the concept is the same.
And now it’s all working! I was able to test it, and it’s fully working on both
the satellite and cable systems. This is a screen that’s broadcast before
a pay-per-view event goes live. The pay-per-view, like all other channels,
can be decrypted with the Softcam using the algorithms learned in these keys that
were extracted. With the ECM and EMM algorithms and Seed Keys for a set-top-box
with any level of authorization the Category Key can be decrypted
and then used to decrypt any and all of the channels that are broadcast
by this provider.
*applause*
A few of the weaknesses that I identified in this system were that the ACP I studied
is relatively old technology, almost 20 years old. So this makes it a lot
easier for invasive analysis today than one that was brand new.
The TQFP100 package is quite easy to deal with compared to modern alternatives.
The chip is susceptible to voltage glitching. It’s a van-Neumann architecture
without strong MMU protection preventing code to be executed from RAM.
They didn’t leave any possibility for code update or dynamic code execution
for countermeasure purposes. The software for the ACP is contained entirely in ROM
with no mechanism for software updates in the field. The hardware customizations
to the crypto were quite simple and required no reverse-engineering
of the chip logic. I was basically able to guess the hardware customizations.
I was impressed with the design of the system. It was actually stronger than
I anticipated when I started the project. All the key handling and decryption
is contained within a single chip which makes it impossible to do key sharing
that’s being done with some of the smartcard systems. The fast Working Key
change interval – only a 133 ms – also makes key sharing more difficult.
And the short lifetime of the key makes cracking it in realtime quite unrealistic.
The lack of code in any rewritable memory means there’s nowhere to write code for
a permanent backdoor to disable the access controls. I listed this also as
a weakness but in fact this is a strength as it limits the attacker’s capability
to install any kind of persistent backdoor. The chip operates
on an internal clock eliminating clock glitch attack and making timing
a voltage glitch a lot more difficult. These dead addresses in the middle
of DES keys prevent linear readout of keys. If one were to cause a loop reading
data to go out of bounds and reach the area of RAM where keys are stored
the chip will reset before an entire key is read. After the first couple of bytes
a dead address will be accessed that causes the chip to reset.
The personalization ROM appears to be inaccessible so it can’t easily be used
to modify the keys and Unit Address within the ACP. The Seed Keys
aren’t easily changed so the set-top-boxes can’t easily be cloned.
The keys exist only in RAM so you have to maintain a battery backup at all times.
This rules out a lot of invasive attacks to retrieve the keys. And there are
no group keys used for EMMs. All the unit addressing is to individual units.
So you have to pull keys from an actively subscribed box in order to get active keys.
That said if you have keys from a box that is subscribed to any channel
you’ll receive an EMM containing the Category Key which is capable of
decrypting all channels. So you don’t need to have a subscription to all channels
you want to decrypt as long as you’re authorized for at least one channel
on the system.
The software is generally well designed and written. I didn’t notice any glaring
bugs within it. Although DES is used the EMM decryption requires using three
DES keys, and multiple rounds are performed when decrypting EMM and ECMs.
So this part isn’t as simple as cracking a single 56-bit key.
Brute-forcing, starting from the encrypted transport stream requires cracking
Working Key, then Program Key, then Category Key and, finally,
the three Seed Keys.
You might wonder how many set-top-boxes it took for me to complete this project!
*laughter and applause*
The truth is I only needed the one… …truck load!
*laughter*
Some of the boxes had different versions of the ACP chip. Many of the boxes had
different PCB layouts. So it was interesting to be able to look at
a variety of boxes. The cost of used set top boxes was low, ca. $20. And for
this research I was focusing on the signal security and didn’t need the PVR
functionality or any of the advanced features from the expensive set-top-boxes.
So at this point I have a brief anti-piracy message: I don’t recommend you pirate
cable or satellite TV. There is never anything good on. It doesn’t matter
how many channels you can decrypt. Believe me – I looked!
It’s not worth the effort!
*laughter and applause*
Herald: Do we have questions from the room?
Questions – please use the microphones.
I know there is one question from the interwebs.
Signal Angel: Okay, hello. This is working? Good.
So the first question from the internet is: how many chips did you destroy
or make unusable, and how did you get all those set-top-boxes?
Chris: Because the cost of the used set-top-boxes was quite low I wasn’t
afraid to destroy several chips in the process. It didn’t take as many
as I would have expected in the beginning. Two or three chips were used for the
decapsulation and the delayering process. I ended up extracting the ROM
from a single chip. And then, when it came to glitching, there were
three or four chips that I removed and erased the RAM from to develop the glitch.
When I finally got to the point where I was extracting keys from a valid chip
the very first chip that I tried worked. So there were few casualties involved!
Herald: Thank you! Microphone 3 was the first one, please!
Mic3: How many years did this project take you?
Chris: I would work for a few weeks at a time and then get burned out and
take a break, and then come back to it. Most of the work for the project
was completed over about a 2-year period.
Herald: Thank you. And… Microphone 2, please!
Mic2: Hi, thank you for a great lecture. How comes that
the content decryption was DES and not a DVB-CSA because we're used
that content is encrypted with DVB-CSA in these DVB systems.
Chris: In North America we don’t believe in standards!
*laughter*
Mic2: Thanks!
Chris: The timing was also a part of it. The system was being developed
at the same time as DVB was being standardized. So General Instrument
rather than going along with the Standards Group and waiting for the standardization
they went with DES, directly.
Herald: Thank you. And another one from Cyber-Cyber… space!
Signal Angel: Okay. Another question from the internet is: you have all this fancy
like lab equipment stuff. How were you able to afford that?
Chris: I’ve been quite interested in this for a long time. So I’ve collected
this equipment over a period of years. And I do some work, professionally,
in reverse-engineering. So whenever possible I use our client’s money
to buy another piece of equipment for the lab.
To do this actual work, though, you could even use more basic equipment
because of the age of the chip. You could use a microscope that you could find
easily for $1.000 .. $2.000 or even less and have quite good results.
So it’s not trivial but it’s not a huge amount of money for a lab equipment!
Herald: Not that huge! Microphone 2, please!
Mic2: What do you do for a living besides reverse-engineering?
Chris: Reverse-engineering! *laughs*
Herald: Thank you. And the internet! Again.
Signal Angel: Okay. Next question is… somebody wants to know how…
…which software did you use for the automated image analyzing, and
is it available somewhere?
Chris: Like everybody else that I’ve known that’s done optical ROM extraction
I developed it myself. Everybody seems to develop their own tools from scratch
for that. The image processing I used was really quite simple. So it didn’t take
a lot of advanced algorithms or anything like that. So I’m using some software
I developed personally, and it hasn’t been released.
Herald: Microphone 2, please!
Mic2: And how did you keep the boxes subscribed? So did you call them
every week “Oh, my box broke down, I got another one”, or how is this done?
Chris: For most of the research that I did I didn’t need an active box. I did
all the research just on previously activated boxes that had lost their
authorization. And by the time I had the process figured out, that I knew how
to extract keys from a valid box I only needed the one box.
Mic2: And had you heard back from the cable provider about this?
Chris: No.
Herald: Okay, thank you. Microphone 3, please!
Mic3: Hello, thanks very much for the lecture and ‘well done’ on all the work!
My question is: how does the glitching work, the glitching attack?
Chris: The glitcher was quite simple. I drop the voltage for a very brief period
of time. And it’s enough time that it causes at least one instruction to
not execute properly. But it’s too short of a time to cause the chip to reset.
So essentially I’m corrupting one instruction. It is for the specific target
that I hit that led to my code in RAM. I’m not actually sure. I found that
if I glitch it this time then the code ends up executing my code –
good enough for me!
Herald: Okay. Thank you, Chris! Please, dear audience,
give an Anniversary Edition applause to Chris Gerlinsky!
*Anniversary Edition applause*
*postroll music*
*subtitles created by c3subtitles.de in the year 2018*