< Return to Video

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

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

more » « less
Video Language:
English
Duration:
01:02:41

English subtitles

Revisions